From hartmans@mit.edu Fri Apr 1 00:26:18 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3BE3A69B5 for ; Fri, 1 Apr 2011 00:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Hzz0iygQbLV for ; Fri, 1 Apr 2011 00:26:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2142A3A691A for ; Fri, 1 Apr 2011 00:26:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-577e.meeting.ietf.org [130.129.87.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9AAD7202C9 for ; Fri, 1 Apr 2011 03:24:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 859724541; Fri, 1 Apr 2011 03:27:55 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Fri, 01 Apr 2011 03:27:55 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:26:18 -0000 I'm not sure if I will be in the session today. So I wanted to give a status of naming extensions. We submitted a new version that had updates based on my comments in Beijing. We've received some comments from Scott about whether the clarity was sufficient. Now that Scott has implemented against the spec, I think he's in a good position to say either that it looks good or it needs more detail. We had a last call. Simon raised significant comments not against the new text, but against the text we all thought was OK last time around. Unfortunately it's clear we were wrong. The authors need to make a pass over the API details and fix Simon's issues and similar issues. We need to coordinate and get the chairs a new milestone date. From hartmans@mit.edu Fri Apr 1 00:31:03 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CBF3A6BEE for ; Fri, 1 Apr 2011 00:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kABK0ofZZDr2 for ; Fri, 1 Apr 2011 00:31:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C25DE3A6BD7 for ; Fri, 1 Apr 2011 00:31:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-577e.meeting.ietf.org [130.129.87.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 03A802011F; Fri, 1 Apr 2011 03:29:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1FA6D4541; Fri, 1 Apr 2011 03:32:41 -0400 (EDT) From: Sam Hartman To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> Date: Fri, 01 Apr 2011 03:32:41 -0400 In-Reply-To: <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> ("Love =?iso-8859-1?Q?H=F6rnquist?= strand"'s message of "Thu, 31 Mar 2011 18:19:01 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "" , "" , Sam Hartman Subject: Re: [kitten] Asynchronous operation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:31:03 -0000 >>>>> "Love" == Love Hörnquist Åstrand writes: Love> 31 mar 2011 kl. 10.50 skrev Nico Williams: >> Last time I talked to Love I convinced him, I think (Love, >> correct me if I'm misremembering please!) that we could do >> something like this: Love> Standardizing on libevent is a non starter for me. Why? At one level it's interesting to know you don't like it. At another level, it's a lot more constructive if you actually give your design constraints. From Volker.Lendecke@SerNet.DE Fri Apr 1 00:58:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0F8328C0EE for ; Fri, 1 Apr 2011 00:58:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Date" X-Spam-Flag: NO X-Spam-Score: -4.929 X-Spam-Level: X-Spam-Status: No, score=-4.929 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, INVALID_DATE=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-+T44TqvxEv for ; Fri, 1 Apr 2011 00:58:39 -0700 (PDT) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 4769B3A6837 for ; Fri, 1 Apr 2011 00:58:39 -0700 (PDT) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.69 #1) id 1Q5ZHE-0000tn-Hf; Fri, 01 Apr 2011 10:00:16 +0200 Received: by intern.SerNet.DE id 1Q5ZHD-00BiR3-Ke; Fri, 01 Apr 2011 10:00:16 +0200 Received: by intern.SerNet.DE id 1Q5ZHC-00BiQM-5y; Fri, 01 Apr 2011 10:00:14 +0200 Date: Fri, 1 Apr 2011 10:00:03 +0200 Date: Fri, 1 Apr 2011 10:00:03 +0200 From: Volker Lendecke To: Sam Hartman References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "" Subject: Re: [kitten] Asynchronous operation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:58:40 -0000 On Fri, Apr 01, 2011 at 03:32:41AM -0400, Sam Hartman wrote: > Love> 31 mar 2011 kl. 10.50 skrev Nico Williams: > > >> Last time I talked to Love I convinced him, I think (Love, > >> correct me if I'm misremembering please!) that we could do > >> something like this: > > Love> Standardizing on libevent is a non starter for me. > > Why? At one level it's interesting to know you don't like it. At > another level, it's a lot more constructive if you actually give your > design constraints. Stepping in here, although I'm not directly being asked. Concerns about standardizing on a particular async implementation depend on what you actually mean by exactly that. If it means that all applications which want to use async GSSAPI must have their central event loop in libevent for Samba it would also be a non-starter. We have our own event infrastructure (tevent.samba.org) that makes async programming really easy due to the virtues of talloc. We could plug in libevent as a backend for tevent, but this would be a very strong requirement in particular for platforms where that's not easily available. It's ok if you model your internal implementation along what libevent does, but the core socket and timeout operations should be pluggable to be generally useful. With best regards, Volker Lendecke -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen From simon@josefsson.org Fri Apr 1 01:05:14 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0946B3A6B25 for ; Fri, 1 Apr 2011 01:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.361 X-Spam-Level: X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFB7ewi3pfmb for ; Fri, 1 Apr 2011 01:05:13 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 2E28C3A6837 for ; Fri, 1 Apr 2011 01:05:12 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3186fcb024768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Apr 2011 10:06:43 +0200 From: Simon Josefsson To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB__29023.0954568417$1301595627$gmane$org@kth.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110401:nico@cryptonector.com::wyHp3Fhhf/sLBAMW:9RZ X-Hashcash: 1:22:110401:hartmans-ietf@mit.edu::TaVITr5Qqg+IYp80:0aHb X-Hashcash: 1:22:110401:lha@kth.se::Mm02rHKRIBor3uS0:SItf X-Hashcash: 1:22:110401:kitten@ietf.org::Lc6cfMWnH1be3fXQ:Yb9Z X-Hashcash: 1:22:110401:volker.lendecke@sernet.de::uMjo+DTDTPwImTn0:nLXP Date: Fri, 01 Apr 2011 10:06:40 +0200 In-Reply-To: <6E55A187-4E26-4B85-92D1-D070D6324EBB__29023.0954568417$1301595627$gmane$org@kth.se> ("Love =?iso-8859-1?Q?H=F6rnquist_=C5strand=22's?= message of "Thu, 31 Mar 2011 18:19:01 +0000") Message-ID: <87mxkacs4v.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "" , "" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:05:14 -0000 Love Hörnquist Åstrand writes: > 31 mar 2011 kl. 10.50 skrev Nico Williams: > >> Last time I talked to Love I convinced him, I think (Love, correct me >> if I'm misremembering please!) that we could do something like this: > > Standardizing on libevent is a non starter for me. Same for me. It may be that defining an async interface at the C level is not sufficient, and we want it at the GSS-API abstract level. /Simon From hartmans@mit.edu Fri Apr 1 01:08:56 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2A23A6B0B for ; Fri, 1 Apr 2011 01:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.877 X-Spam-Level: X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTF8Lo5CCNjd for ; Fri, 1 Apr 2011 01:08:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 74DC73A6BFB for ; Fri, 1 Apr 2011 01:08:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-577e.meeting.ietf.org [130.129.87.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 87E9E2011F; Fri, 1 Apr 2011 04:07:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 774204541; Fri, 1 Apr 2011 04:10:31 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> Date: Fri, 01 Apr 2011 04:10:31 -0400 In-Reply-To: (Nico Williams's message of "Thu, 31 Mar 2011 15:36:04 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" , Volker.Lendecke@sernet.de, Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:08:57 -0000 Nico, I agree that it would be nice to make GSS-API asynchronous, but fixing that problem is not what I'm asking for here. I see three concerns: 1) Making GSS-API asynchronous does not inherently mean the application will know about the desire to get a password. This simply needs we need such a callback. 2) We don't have implementation energy available to shift the entire control flow of GSS to be fully asynchronous. 3) We need a solution that is easy to integrate into applications that already have GSS support. So, something that is easy to use in a thread that is specific to GSS. So, while I support your general idea, I'm looking for something that is more of a point solution. Even if I had your general approach I'd probably still want the point solution to work with existing applications. I think I'm looking for something simple like an error that indicates that if a password were available it would have been used and a way to signal that UI should not be presented just to collect a password. So an error code and a cred option. From Volker.Lendecke@SerNet.DE Fri Apr 1 01:10:44 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B98D3A6BFB for ; Fri, 1 Apr 2011 01:10:44 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Date" X-Spam-Flag: NO X-Spam-Score: -4.954 X-Spam-Level: X-Spam-Status: No, score=-4.954 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, INVALID_DATE=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzjgm0tmLxvX for ; Fri, 1 Apr 2011 01:10:42 -0700 (PDT) Received: from mail.SerNet.de (mail.SerNet.de [193.175.80.2]) by core3.amsl.com (Postfix) with ESMTP id 243553A69D4 for ; Fri, 1 Apr 2011 01:10:41 -0700 (PDT) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.69 #1) id 1Q5ZSu-0001sM-2Y; Fri, 01 Apr 2011 10:12:20 +0200 Received: by intern.SerNet.DE id 1Q5ZSt-00BkBs-O5; Fri, 01 Apr 2011 10:12:19 +0200 Received: by intern.SerNet.DE id 1Q5ZSt-00BkBa-CN; Fri, 01 Apr 2011 10:12:19 +0200 Date: Fri, 1 Apr 2011 10:12:14 +0200 Date: Fri, 1 Apr 2011 10:12:14 +0200 From: Volker Lendecke To: Sam Hartman References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: "" Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:10:44 -0000 On Fri, Apr 01, 2011 at 04:10:31AM -0400, Sam Hartman wrote: > 2) We don't have implementation energy available to shift the entire > control flow of GSS to be fully asynchronous. Ok, that's pretty much what I wanted to know :-) Thanks, Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen From hartmans@mit.edu Fri Apr 1 01:59:32 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B893A65A5 for ; Fri, 1 Apr 2011 01:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.841 X-Spam-Level: X-Spam-Status: No, score=-102.841 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwmHk7RL8JMp for ; Fri, 1 Apr 2011 01:59:31 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BF4D63A63CA for ; Fri, 1 Apr 2011 01:59:31 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-577e.meeting.ietf.org [130.129.87.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 93E6B202C9; Fri, 1 Apr 2011 04:58:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C8C64541; Fri, 1 Apr 2011 05:01:09 -0400 (EDT) From: Sam Hartman To: Volker.Lendecke@sernet.de References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> <6E55A187-4E26-4B85-92D1-D070D6324EBB@kth.se> Date: Fri, 01 Apr 2011 05:01:09 -0400 In-Reply-To: (Volker Lendecke's message of "Fri, 1 Apr 2011 10:12:14 +0200, Fri, 1 Apr 2011 10:12:14 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" , Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 08:59:32 -0000 >>>>> "Volker" == Volker Lendecke writes: Volker> On Fri, Apr 01, 2011 at 04:10:31AM -0400, Sam Hartman wrote: >> 2) We don't have implementation energy available to shift the >> entire control flow of GSS to be fully asynchronous. Volker> Ok, that's pretty much what I wanted to know :-) Volker> Thanks, remember here I'm speaking as someone involved in one minor GSS mechanism. I'm not speaking about what resources MIT, Heimdal or any of the krb5 mechanisms have. If there is energy for an async gss approach, that's great. I'm involved in www.project-moonshot.org, and we'd like something sooner for the password case than that will bring us. From iesg-secretary@ietf.org Fri Apr 1 04:21:35 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821313A6814; Fri, 1 Apr 2011 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qDlth7XAA7t; Fri, 1 Apr 2011 04:21:34 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CFF3A67F3; Fri, 1 Apr 2011 04:21:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110401112134.24351.59281.idtracker@localhost> Date: Fri, 01 Apr 2011 04:21:34 -0700 Cc: kitten@ietf.org Subject: [kitten] Last Call: (Moving DIGEST-MD5 to Historic) to Informational RFC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 11:21:35 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'Moving DIGEST-MD5 to Historic' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-digest-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-digest-to-historic/ No IPR declarations have been submitted directly on this I-D. From mrex@sap.com Fri Apr 1 10:56:59 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15593A68AC for ; Fri, 1 Apr 2011 10:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vqI1pND8q6z for ; Fri, 1 Apr 2011 10:56:58 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 66BB03A686C for ; Fri, 1 Apr 2011 10:56:57 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p31Hwb4H016043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 19:58:37 +0200 (MEST) From: Martin Rex Message-Id: <201104011758.p31Hwafi028310@fs4113.wdf.sap.corp> To: ghudson@MIT.EDU Date: Fri, 1 Apr 2011 19:58:36 +0200 (MEST) In-Reply-To: <201103211536.p2LFaMoV014307@outgoing.mit.edu> from "ghudson@MIT.EDU" at Mar 21, 11 11:36:22 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Delayed credential resolution in GSSAPI X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 17:56:59 -0000 ghudson@MIT.EDU wrote: > > My questions for the working group are these: > > 1. Suppose I implement delayed resolution for the default initiator > credential. If the app inquires the name of the cred, my > understanding is that I should pick a default identity and constrain > the cred to only act as that identity. (So, by asking the question in > advance of calling gss_init_sec_context, you may change the answer.) > Does that seem correct? > > 2. We already implement delayed resolution for the default acceptor > cred. If the app inquires the name of the cred, we should determine a > name (currently we return GSS_C_NO_NAME, which is probably wrong). Is > it enough that this name by *a* name which an initiator could use to > authenticate to the service, or should the credential also be > constrained to *only* accept tokens authenticating to that name? Since it's me who is relying on this behaviour and has brought up this question for MIT Kerberos ... I just came across the following words in rfc2743 (GSS-API high-level): http://tools.ietf.org/html/rfc2743#page-39 If credential acquisition is time-consuming for a mechanism, the mechanism may choose to delay the actual acquisition until the credential is required (e.g. by GSS_Init_sec_context() or GSS_Accept_sec_context()). Such mechanism-specific implementation decisions should be invisible to the calling application; thus a call of GSS_Inquire_cred() immediately following the call of GSS_Acquire_cred() must return valid credential data, and may therefore incur the overhead of a deferred credential acquisition. -Martin From mrex@sap.com Fri Apr 1 11:04:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169713A6906 for ; Fri, 1 Apr 2011 11:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6zIYf8g1L6B for ; Fri, 1 Apr 2011 11:04:11 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D6D0C3A686C for ; Fri, 1 Apr 2011 11:04:10 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p31I5oDh016537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2011 20:05:50 +0200 (MEST) From: Martin Rex Message-Id: <201104011805.p31I5n8a028889@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 1 Apr 2011 20:05:49 +0200 (MEST) In-Reply-To: <201104011758.p31Hwafi028310@fs4113.wdf.sap.corp> from "Martin Rex" at Apr 1, 11 07:58:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, ghudson@MIT.EDU Subject: Re: [kitten] Delayed credential resolution in GSSAPI X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 18:04:12 -0000 Another quote (sorry for the seperate message): Martin Rex wrote: > > ghudson@MIT.EDU wrote: > > > > My questions for the working group are these: > > > > 1. Suppose I implement delayed resolution for the default initiator > > credential. If the app inquires the name of the cred, my > > understanding is that I should pick a default identity and constrain > > the cred to only act as that identity. (So, by asking the question in > > advance of calling gss_init_sec_context, you may change the answer.) > > Does that seem correct? > > > > 2. We already implement delayed resolution for the default acceptor > > cred. If the app inquires the name of the cred, we should determine a > > name (currently we return GSS_C_NO_NAME, which is probably wrong). Is > > it enough that this name by *a* name which an initiator could use to > > authenticate to the service, or should the credential also be > > constrained to *only* accept tokens authenticating to that name? > > > Since it's me who is relying on this behaviour and has brought > up this question for MIT Kerberos ... > > > I just came across the following words in rfc2743 (GSS-API high-level): > > http://tools.ietf.org/html/rfc2743#page-39 > > If credential acquisition is time-consuming for a mechanism, the > mechanism may choose to delay the actual acquisition until the > credential is required (e.g. by GSS_Init_sec_context() or > GSS_Accept_sec_context()). Such mechanism-specific implementation > decisions should be invisible to the calling application; thus a call > of GSS_Inquire_cred() immediately following the call of > GSS_Acquire_cred() must return valid credential data, and may > therefore incur the overhead of a deferred credential acquisition. The above was from "2.1.4: GSS_Add_cred call" (but refers to acquire_cred), and the following is from "2.1.1: GSS_Acquire_cred call", from within the second paragraph from the bottom of page 33. http://tools.ietf.org/html/rfc2743#page-33 Some implementations may therefore not support the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name resulting from applying GSS_Inquire_context() to an active context, or a name resulting from applying GSS_Inquire_cred() against a credential handle corresponding to default behavior. -Martin From cantor.2@osu.edu Fri Apr 1 11:13:02 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDA63A691B for ; Fri, 1 Apr 2011 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g0uMltfVi2U for ; Fri, 1 Apr 2011 11:13:01 -0700 (PDT) Received: from defang16.it.ohio-state.edu (defang16.it.ohio-state.edu [128.146.216.130]) by core3.amsl.com (Postfix) with ESMTP id A7F923A6912 for ; Fri, 1 Apr 2011 11:13:01 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang16.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p31IEcia016690; Fri, 1 Apr 2011 14:14:41 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::3940:6fde:690d:8647%19]) with mapi; Fri, 1 Apr 2011 14:10:15 -0400 From: "Cantor, Scott E." To: Sam Hartman , "kitten@ietf.org" Thread-Topic: [kitten] Status of naming extensions Thread-Index: AQHL8D3LvyqOvJC3gk6x+dft8zJhbpRJtZGA Date: Fri, 1 Apr 2011 18:09:46 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <24f0b624-201c-4f17-aafb-0ae408501226> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.130 Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 18:13:02 -0000 >We submitted a new version that had updates based on my comments in >Beijing. We've received some comments from Scott about whether the >clarity was sufficient. Now that Scott has implemented against the >spec, I think he's in a good position to say either that it looks good >or it needs more detail. My recollection is that the part I found a bit unclear was the section about attribute naming. I think that's mainly because it spends some time discussing how one shouldn't name SAML attributes but doesn't actually suggest an explicit way to do so. Since we're in the middle of coming up with conventions for that in Moonshot, it seems timely to ask whether we shouldn't propose a separate RFC or OASIS draft to nail that down. This draft mentions the need for a context indicator that is clearly separable from the NameFormat/Name. My preference is for a fixed string because I think the names should be consistent and deriveable, but a truly contextual name that's still fairly generatable would be the issuer, of course. In terms of my coding, I was mainly following header files from Kerberos (and managed to get that aspect right the first time, so I guess it wasn't that hard). We did have the issue that we really need a way to export and import a composite gss_name_t that preserves the attributes, and I guess the problem there is an OID that's yet to be defined... -- Scott From ghudson@mit.edu Fri Apr 1 11:58:33 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748F63A6918 for ; Fri, 1 Apr 2011 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnRZv4BMU9ow for ; Fri, 1 Apr 2011 11:58:32 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id BA7513A6916 for ; Fri, 1 Apr 2011 11:58:32 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-51-4d9620b7ddba Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 16.F5.18470.7B0269D4; Fri, 1 Apr 2011 15:00:07 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p31J0C82008863 for ; Fri, 1 Apr 2011 15:00:12 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p31J0BDm000246 for ; Fri, 1 Apr 2011 15:00:11 -0400 (EDT) Date: Fri, 1 Apr 2011 15:00:11 -0400 (EDT) From: ghudson@MIT.EDU Message-Id: <201104011900.p31J0BDm000246@outgoing.mit.edu> To: kitten@ietf.org References: <87d3ltfw4t.fsf@latte.josefsson.org> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42IRYrdT192uMM3XYNkSa4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+7luSwFd7kqZp5axd7AuI2ji5GTQ0LARGLp9desELaYxIV7 69lAbCGBfYwSH06odTFyAdlHGSVmv9rPCOH0Mkm8e/8NyOHgYBHQkmjrNgRpYBMQlfjw4QIr SJhXwEriwqlkkLCIgLDE7q3vmCFmGkjM3/WcBcQWFtCQWPPrHMsERu4FjAyrGGVTcqt0cxMz c4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxgjzKKcm7g/HdQaVDjAIcjEo8vP1/p/oKsSaWFVfm HmKU5GBSEuUVAIaDEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeDTmgHG9KYmVValE+TEqag0VJ nHempLqvkEB6YklqdmpqQWoRTFaGg0NJgveGPFCjYFFqempFWmZOCUKaiYMTZDgP0PBokBre 4oLE3OLMdIj8KUZdjrNXJu5jFGLJy89LlRLnNQIpEgApyijNg5sDi8RXjOJAbwnzioL8wAOM YrhJr4CWMAEtOTphKsiSkkSElFQDY3NGbMTnlLnXF9jttBRapj3jk4iRrVpnR2vc2QPZE905 KmZo6suv7rERi5F57eo8fVXt3FrZtEWMrzreLZ68unKOv96M9Pb3bOJ2mpl1+rpblFuu8Qu6 PFbw4hfZ3eWc+K5qusXX+UtXXDls/uLuLJ9ztzveatiGy6ySiWt/kqtQ4LX37E4VJZbijERD Leai4kQADI4nb58CAAA= Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 18:58:33 -0000 > I know this document has expired, but I don't recall if there were > any discussion or conclusion on it. The APIs are implemented and > deployed in Heimdal and Shishi for some time now (years), and the > calls are useful for GS2 implementers. Is there interest in moving > this forward in this WG? I believe it makes sense to at least > publish it as informational because it is widely deployed. The C bindings use "const" in ways which apply to the pointer argument rather than the data being pointed to. For instance, in: extern int gss_oid_equal ( const gss_OID first_oid, const gss_OID second_oid ) the implementation of gss_oid_equal will not be allowed to reassign its local first_oid or second_oid variable, but will have no problems modifying the OIDs. (You can verify this pretty easily by experimentally changing the implementation and seeing which operations cause your compiler to error.) This behavior is sufficiently useless that I've seen it generates warnings in some environments, although I can't seem to find one at the moment. There are two fairly compelling arguments for leaving this alone: 1. There are already implementations in the field. 2. This is an error already committed in RFC 2744, and there's something to be said for being consistent with your past mistakes. From simon@josefsson.org Fri Apr 1 13:43:19 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A7A828C0F4 for ; Fri, 1 Apr 2011 13:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXYvvJeO3csi for ; Fri, 1 Apr 2011 13:43:18 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 1FC4C28C0F0 for ; Fri, 1 Apr 2011 13:43:17 -0700 (PDT) Received: from latte.josefsson.org (m83-185-64-125.cust.tele2.se [83.185.64.125]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p31Kik0J026833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Apr 2011 22:44:52 +0200 From: Simon Josefsson To: ghudson@MIT.EDU References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110401:ghudson@mit.edu::8czCg61NXFPqDZG7:BlKI X-Hashcash: 1:22:110401:kitten@ietf.org::v/Tb4l627P7/FqiE:C4h5 Date: Fri, 01 Apr 2011 22:44:44 +0200 In-Reply-To: <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> (ghudson@mit.edu's message of "Fri, 1 Apr 2011 15:00:11 -0400 (EDT)") Message-ID: <87aag9r9ab.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 20:43:19 -0000 ghudson@MIT.EDU writes: >> I know this document has expired, but I don't recall if there were >> any discussion or conclusion on it. The APIs are implemented and >> deployed in Heimdal and Shishi for some time now (years), and the >> calls are useful for GS2 implementers. Is there interest in moving >> this forward in this WG? I believe it makes sense to at least >> publish it as informational because it is widely deployed. > > The C bindings use "const" in ways which apply to the pointer argument > rather than the data being pointed to. For instance, in: > > extern int > gss_oid_equal ( > const gss_OID first_oid, > const gss_OID second_oid > ) > > the implementation of gss_oid_equal will not be allowed to reassign > its local first_oid or second_oid variable, but will have no problems > modifying the OIDs. (You can verify this pretty easily by > experimentally changing the implementation and seeing which operations > cause your compiler to error.) This behavior is sufficiently useless > that I've seen it generates warnings in some environments, although I > can't seem to find one at the moment. Good point. > There are two fairly compelling arguments for leaving this alone: > > 1. There are already implementations in the field. > > 2. This is an error already committed in RFC 2744, and there's > something to be said for being consistent with your past mistakes. Agreed. If we _really_ wanted to fix this, I think it could be done without too much damage to the deployed base: adding a 'const' at the right place doesn't change the ABI since the function was never permitted to modify the OID content anyway. On the other hand, RFC 2744 has the same issue in so many places (a quick count indicate that around 10 of the APIs seems to have the same issue) that fixing only this API will make it stand out as odd. So if there aren't significant problems with how the APIs in RFC 2744 are used, this API will likely not cause any problem either, I think? /Simon From wmills@yahoo-inc.com Fri Apr 1 16:43:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 319C628C11A for ; Fri, 1 Apr 2011 16:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMJCNC31JP+R for ; Fri, 1 Apr 2011 16:43:08 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id E7EC428C114 for ; Fri, 1 Apr 2011 16:43:07 -0700 (PDT) Received: (qmail 21834 invoked by uid 60001); 1 Apr 2011 23:44:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1301701485; bh=SD7YxOrYhpfwS6/tTtGww00KOy1F2r3zcK6OVheZ2SA=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GwuWulW/BZ9+6NSSCb5edZsoyY8VKxZlWtDJo8/8AZ/MH5TP8UV65BgDEASpxWVV9bu/JvLXX5/8d+0/kJzKwYWK4XnPB/uuV7L1z05ev2hKUO+W285JnTLiKrzg/RIQB9Oo+8chLPc9kUlLDgncXaa8opWtn+UEUv2w4gpelcc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iHOPJCLy0yQZfm0ccK9OcRfCmH7MpN44XJwEr5dOceZC2QIpgEDRoOeqTgPeBkewz4xZ8wvc9rjdGRpohlutdin6DDySRKI7nF9l3eUTSJplKOE+XCFoN6XhFzLBDBG0cjgE6aVaBjijQ0kiT6/Jhg6P6r4tzxdIMGAl9wSogtA=; Message-ID: <248255.86264.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: .ZXMbXwVM1l85RLJrWqi_T0O1WklJVLqRB97NfwR7kanwKY .Isq.xzXgwWP_sZRLoAosLu98wFjXHTTcZKiLkT4Hb71DgK9BhW8N5yKF5uj 9UM42gyKiqyFFo85RcBsfHr2oaT_xl2wpHpOKEUXZLg8iFakmaKGI485YRuo bS_4QaNvHpgMl04ngsULn9HDHkx3fRiJ.Tfxkf8K.bCkmpk8yIyzEdWDHkF9 2KKBayB.ztmQzrsVgBGFC45HGBgC4j.8AvHbC3SY6l.Kioqj4RboKoKw.xzB xZhHFmCdy_JXZiMkjeP0YUG0DEGFma6ogN9S18gw9RwzhdZldvMgt_B_sOk4 YcAdW1wLew4Z94QPX2jrUzTIlgLI2Swflu8Tjkvo- Received: from [209.131.62.115] by web32303.mail.mud.yahoo.com via HTTP; Fri, 01 Apr 2011 16:44:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> Date: Fri, 1 Apr 2011 16:44:45 -0700 (PDT) From: "William J. Mills" To: Jeffrey Hutzelman In-Reply-To: <1301610771.2583.81.camel@destiny> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-896321460-1301701485=:86264" Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 23:43:09 -0000 --0-896321460-1301701485=:86264 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've been thinking about your last paragraph and I don't see how a DH key e= xchange is useful without some form of endpoint validation.=A0 I can MITM a= DH key exchange by doing my own with you, if I am truly a MITM.=A0=A0 I th= ink the most commonly understood way would be some form of validation using= the public key of the endpoint, and I'm really not sure I want to build in= a PKI requirement here.=0A=0A=0A=0A________________________________=0AFrom= : Jeffrey Hutzelman =0ATo: William J. Mills =0ACc: jhutz@cmu.edu; "kitten@ietf.org" =0ASent: Thu= rsday, March 31, 2011 3:32 PM=0ASubject: Re: [kitten] Channel binding requi= rements.=0A=0AOn Thu, 2011-03-31 at 10:59 -0700, William J. Mills wrote:=0A= > I asked this before but I did not see an answer.=A0 Is message integrity= =0A> in the mechanism a requirement for correct support of channel binding?= =0A> I believe the answer to this is yes, because an intelligent MITM can= =0A> simply modify the channel binding payload in flight otherwise, and=0A>= this would be undetectable to the endpoints.=0A=0AYou need some means of p= roviding integrity protection for channel=0Abindings.=A0 This does not mean= you need to provide the GSSAPI message=0Aintegrity service or a SASL secur= ity layer, both of which require you to=0Abe able to integrity-protect traf= fic carried afgter context=0Aestablishment is complete.=A0 So, for example,= a public-key-signature=0Amechanism which includes channel bindings in the = data it signs during=0Acontext establishment would provide channel bindings= , but not=0Anecessarily the message integrity service.=0A=0AIt is most desi= rable to provide channel bindings, PRF, message=0Aintegrity, and message co= nfidentiality; various existing GSS-API=0Aapplications depend on each of th= ese.=A0 However, given any of the first=0Athree (or a shared, session-speci= fic secret), we can show you how to=0Aderive the rest (however, if the thin= g you start with is not PRF or a=0Akey, then the derivation will likely inv= olve a key exchange protocol=0Alike DH, which can be expensive).=0A=0A-- Je= ff --0-896321460-1301701485=:86264 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've been = thinking about your last paragraph and I don't see how a DH key exchange is= useful without some form of endpoint validation.  I can MITM a DH key= exchange by doing my own with you, if I am truly a MITM.   I thi= nk the most commonly understood way would be some form of validation using = the public key of the endpoint, and I'm really not sure I want to build in = a PKI requirement here.

From: Jeffrey Hutzelman <jhutz@cmu.edu>
<= span style=3D"font-weight: bold;">To: William J. Mills <wmills@yahoo-inc.com>
Cc:<= /span> jhutz@cmu.edu; "kitten@ietf.org" <kitten@ietf.org>
<= span style=3D"font-weight: bold;">Sent: Thursday, March 31, 2011= 3:32 PM
Subject: Re: [= kitten] Channel binding requirements.

=0AOn Thu, 2011-03-31 a= t 10:59 -0700, William J. Mills wrote:
> I asked this before but I di= d not see an answer.  Is message integrity
> in the mechanism a = requirement for correct support of channel binding?
> I believe the a= nswer to this is yes, because an intelligent MITM can
> simply modify= the channel binding payload in flight otherwise, and
> this would be= undetectable to the endpoints.

You need some means of providing int= egrity protection for channel
bindings.  This does not mean you nee= d to provide the GSSAPI message
integrity service or a SASL security lay= er, both of which require you to
be able to integrity-protect traffic ca= rried afgter context
establishment is complete.  So, for example, a= public-key-signature
mechanism which includes channel bindings in the d= ata it signs during
context establishment would provide channel bindings= , but not
necessarily the message integrity service.

It is most desirable to provide channel bindings, PRF, mes= sage
integrity, and message confidentiality; various existing GSS-APIapplications depend on each of these.  However, given any of the firs= t
three (or a shared, session-specific secret), we can show you how toderive the rest (however, if the thing you start with is not PRF or a
= key, then the derivation will likely involve a key exchange protocol
lik= e DH, which can be expensive).

-- Jeff




--0-896321460-1301701485=:86264-- From lukeh@padl.com Fri Apr 1 16:46:50 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D6B28C120 for ; Fri, 1 Apr 2011 16:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNrfQtuBC3ee for ; Fri, 1 Apr 2011 16:46:47 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 4E2E728C114 for ; Fri, 1 Apr 2011 16:46:47 -0700 (PDT) Received: by us.padl.com with ESMTP id p31NmMYu024083; Fri, 1 Apr 2011 19:48:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 2 Apr 2011 10:48:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <78E2866D-B8E4-4A79-AA03-440F22B1EB2B@padl.com> References: To: "Cantor, Scott E." X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 23:46:50 -0000 > We did have the issue that we really need a way to export and import a > composite gss_name_t that preserves the attributes, and I guess the > problem there is an OID that's yet to be defined... This should happen when the draft becomes an RFC, unfortunately it = doesn't help our implementation in the meantime. -- Luke= From lukeh@padl.com Fri Apr 1 18:12:02 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8D63A69C0 for ; Fri, 1 Apr 2011 18:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXjayCJq4irs for ; Fri, 1 Apr 2011 18:12:01 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id B4F503A69BE for ; Fri, 1 Apr 2011 18:12:01 -0700 (PDT) Received: by us.padl.com with ESMTP id p321Dc0B023590; Fri, 1 Apr 2011 21:13:41 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201104011900.p31J0BDm000246@outgoing.mit.edu> Date: Sat, 2 Apr 2011 12:13:37 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246@outgoing.mit.edu> To: ghudson@MIT.EDU X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 01:12:02 -0000 > 2. This is an error already committed in RFC 2744, and there's > something to be said for being consistent with your past mistakes. Not always. RFC 5587 fixed this: use gss_const_OID. -- Luke From jhutz@cmu.edu Fri Apr 1 21:34:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F33A3A6A2C for ; Fri, 1 Apr 2011 21:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKlbPZRwE0FO for ; Fri, 1 Apr 2011 21:34:45 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 2AB6C3A6A22 for ; Fri, 1 Apr 2011 21:34:45 -0700 (PDT) Received: from [10.0.4.87] ([212.47.23.197]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p324aNAF017545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2011 00:36:24 -0400 (EDT) From: Jeffrey Hutzelman To: "William J. Mills" In-Reply-To: <248255.86264.qm@web32303.mail.mud.yahoo.com> References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> <248255.86264.qm@web32303.mail.mud.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 Apr 2011 06:36:25 +0200 Message-ID: <1301718985.2583.162.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: "kitten@ietf.org" , jhutz@cmu.edu Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 04:34:48 -0000 On Fri, 2011-04-01 at 16:44 -0700, William J. Mills wrote: > I've been thinking about your last paragraph and I don't see how a DH > key exchange is useful without some form of endpoint validation. I > can MITM a DH key exchange by doing my own with you, if I am truly a > MITM. I think the most commonly understood way would be some form of > validation using the public key of the endpoint, and I'm really not > sure I want to build in a PKI requirement here. > > OK; I'll try to explain. Bear in mind that what I'm describing here is a design process, not an algorithm to include in every mechanism. Also bear in mind that in the name of simplicity, I'm going to talk as if we're adding lots of round trips to this thing, when in reality most of them can usually be collapsed away by doing multiple things in the same message. So, assume that we start with some underlying authentication technology that, at the end of its exchange, proves the identity of each participant to the other. Of course, you can use something that only proves the initiator's identity to the acceptor, but that's less interesting, because it doesn't provide any protection from a MitM attack. However, it can still be useful, combined with TLS, server cert validation, _and_ channel binding. Now, if the authentication scheme produces as one of its outputs some secret that is known only to the client and server, we can add an exchange to negotiate an RFC3961 enctype, use the shared secret to key that enctype, at which point we can build channel bindings on an RFC3961 checksum, and do gss_getmic and gss_wrap as described in RFC4121 and PRF as described in RFC4402; that is, exactly as for Kerberos. If the authentication scheme does not provide a shared secret but does provide a PRF, we can use _that_ to derive a secret key for the purpose of keying an RFC3961 checksum, which we then use for CB, mic, and wrap. In addition, in this case, the GSS-API-layer PRF ends up being a perturbation of the underlying one, so that no input provided by a caller can result in the same key we use to provide the other services. Unfortunately, if all the underlying mechanism provides is a MIC function or some other form of integrity protection, then we need to try a bit harder. In this case, we perform a DH exchange, which we protect using the provided MIC. This results in a shared secret, which we can use to key PRF and wrap. CB and gss_getmic can be provided using the new key or directly using the built-in MIC capability. Finally, if CB is _all_ you get, that's fine, because CB is basically one-time MIC that is computed and verified as part of the authentication exchange. We can use this to protect the aforementioned DH exchange, if we do the DH exchange before the rest of the authentication. Note that you can protect both the DH exchange and the actual underlying channel identity, by producing a composite "channel binding" value which contains both; this is what GS2 does to protect SASL-specific bits of its exchange. Of course, a DH exchange is expensive both computationally and in terms of protocol complexity. But, it can be done, provided the underlying authentication method provides something we can build on. Of course, if the underlying authentication technology provides none of these capabilities, then we are stuck. We can't pull an authenticated cryptographic context out of thin air. -- Jeff From lukeh@padl.com Fri Apr 1 22:14:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0D13A69EA for ; Fri, 1 Apr 2011 22:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk9Wfw98KoHu for ; Fri, 1 Apr 2011 22:14:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 526683A6990 for ; Fri, 1 Apr 2011 22:14:51 -0700 (PDT) Received: by us.padl.com with ESMTP id p325GR1X020255; Sat, 2 Apr 2011 01:16:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 2 Apr 2011 16:16:26 +1100 Content-Transfer-Encoding: 7bit Message-Id: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> References: To: "Cantor, Scott E." X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 05:14:52 -0000 > This draft mentions the need for a context indicator that is clearly > separable from the NameFormat/Name. My preference is for a fixed string > because I think the names should be consistent and deriveable, but a truly +1 -- Luke From lukeh@padl.com Fri Apr 1 22:29:49 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2016C3A6A3D for ; Fri, 1 Apr 2011 22:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbltwO9izLzM for ; Fri, 1 Apr 2011 22:29:45 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 97DD13A63EB for ; Fri, 1 Apr 2011 22:29:43 -0700 (PDT) Received: by us.padl.com with ESMTP id p325VIib017563; Sat, 2 Apr 2011 01:31:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> Date: Sat, 2 Apr 2011 16:31:17 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> To: "Scott E. Cantor" X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 05:29:49 -0000 On 02/04/2011, at 4:16 PM, Luke Howard wrote: >> This draft mentions the need for a context indicator that is clearly >> separable from the NameFormat/Name. My preference is for a fixed = string >> because I think the names should be consistent and deriveable, but a = truly >=20 > +1 A consistent attribute name for retrieving the underlying assertion = would be a big boon for the (EAP to Kerberos) SAML protocol transition = project I'm working on now. -- Luke= From lukeh@padl.com Sat Apr 2 01:44:33 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648B83A6A61 for ; Sat, 2 Apr 2011 01:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0aAtJLerKNf for ; Sat, 2 Apr 2011 01:44:32 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 657253A6A58 for ; Sat, 2 Apr 2011 01:44:32 -0700 (PDT) Received: by us.padl.com with ESMTP id p328it4q021798; Sat, 2 Apr 2011 04:44:59 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 2 Apr 2011 19:44:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <41F003D5-D14D-4005-86BF-03076F5FBC71@padl.com> References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> To: "Scott E. Cantor" X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 08:44:33 -0000 > A consistent attribute name for retrieving the underlying assertion = would be a big boon for the (EAP to Kerberos) SAML protocol transition = project I'm working on now. Maybe even with a constant like GSS_C_ATTR_SAML_ASSERTION. -- Luke= From lukeh@padl.com Sat Apr 2 04:38:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D253A67C0 for ; Sat, 2 Apr 2011 04:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGAScPCFK1tC for ; Sat, 2 Apr 2011 04:38:55 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 2C9163A67B7 for ; Sat, 2 Apr 2011 04:38:55 -0700 (PDT) Received: by us.padl.com with ESMTP id p32BeW6o007218; Sat, 2 Apr 2011 07:40:34 -0400 From: Luke Howard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Apr 2011 22:40:31 +1100 Message-Id: <4C232ADB-ABD4-4D3F-B155-E95A5D25C7AA@padl.com> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: [kitten] New AD type X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 11:38:55 -0000 I want a new authorisation data type. Who do I ask? (It's KRB5_AUTHDATA_SAML, encapsulating a SAML assertion inside a = ticket. The contents are defined by SAML, although we will also specify = how Kerberos session and long-term keys may be used to sign the = assertion.) -- Luke= From lukeh@padl.com Sat Apr 2 07:09:54 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57653A6814 for ; Sat, 2 Apr 2011 07:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUgDHPjIAKbj for ; Sat, 2 Apr 2011 07:09:54 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 1DF5F3A6816 for ; Sat, 2 Apr 2011 07:09:53 -0700 (PDT) Received: by us.padl.com with ESMTP id p32EBUcu015781; Sat, 2 Apr 2011 10:11:32 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <78E2866D-B8E4-4A79-AA03-440F22B1EB2B@padl.com> Date: Sun, 3 Apr 2011 01:11:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <51BB637F-79D6-44CA-BF0C-DE5B0AE8C804@padl.com> References: <78E2866D-B8E4-4A79-AA03-440F22B1EB2B@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 14:09:54 -0000 On 02/04/2011, at 10:48 AM, Luke Howard wrote: >> We did have the issue that we really need a way to export and import = a >> composite gss_name_t that preserves the attributes, and I guess the >> problem there is an OID that's yet to be defined... >=20 >=20 > This should happen when the draft becomes an RFC, unfortunately it = doesn't help our implementation in the meantime. If there's a way of getting this OID sooner rather than later, that = would very useful. -- Luke From ghudson@mit.edu Sat Apr 2 07:38:42 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0FF3A6820 for ; Sat, 2 Apr 2011 07:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hllI5+L0YDZ7 for ; Sat, 2 Apr 2011 07:38:41 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 898663A67FC for ; Sat, 2 Apr 2011 07:38:41 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-39-4d973551b9cf Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 89.0F.18470.155379D4; Sat, 2 Apr 2011 10:40:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p32EeMrA007143; Sat, 2 Apr 2011 10:40:22 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p32EeHJl002731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 Apr 2011 10:40:21 -0400 (EDT) From: Greg Hudson To: Jeffrey Hutzelman In-Reply-To: <1301718985.2583.162.camel@destiny> References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> <248255.86264.qm@web32303.mail.mud.yahoo.com> <1301718985.2583.162.camel@destiny> Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 Apr 2011 10:40:16 -0400 Message-ID: <1301755216.10465.446.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0Q00ne5r8O+VrsX19+fYLY5uXsVi 8b6/2oHZY3/rMVaPJUt+MnncWfWLMYA5issmJTUnsyy1SN8ugStj/fppbAVtbBW7569ia2D8 wtLFyMkhIWAisW/xC0YIW0ziwr31bF2MXBxCAvsYJVYe/McC4axnlDjd/4sdwrnLJPFhxiJW kBZhAWOJ1etvgNlsAsoSB89+AxsrIqAqcW/OLDCbWSBW4vb8LWA1nAIGEhcP/4Ca+oNRYumz L6wQRZoSrdt/A23g4GABat6zWQwkzCugK/F781NWkDCvgKDE3x3CEJdKS3yd8IQJolNeYvvb OcwTGAVnIRk0C6FjFpKqBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MYIC mlOSdwfju4NKhxgFOBiVeHj7/071FWJNLCuuzD3EKMnBpCTKW2Ay3VeILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCK8xK1CONyWxsiq1KB8mJc3BoiTOO1NS3VdIID2xJDU7NbUgtQgmK8PBoSTB uwhkqGBRanpqRVpmTglCmomDE2Q4D9Dw78Ygw4sLEnOLM9Mh8qcYdTneTpq6j1GIJS8/L1VK nHcryCABkKKM0jy4ObBE9IpRHOgtYd4UkCoeYBKDm/QKaAkT0BJv+2kgS0oSEVJSDYzyq9xX RnP9WSnz+adPtbO/w+RfjkpLT1celry/9vyuXb9CyqaE2/jlnxd4IMTTy6//tVWehdttWkr9 5la1YAXH+6EbPvCvDa76e9e3Lsgvf4rwaS+1m4IM2UeU2tgVfsZXPslc3rJ80gyuO49n6s29 +OvvQUEpgfOLU95ULWhod/1QtoPdbrUSS3FGoqEWc1FxIgBFbP5+HwMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 14:38:43 -0000 On Sat, 2011-04-02 at 00:36 -0400, Jeffrey Hutzelman wrote: > Of course, you can use something that only > proves the initiator's identity to the acceptor, but that's less > interesting, because it doesn't provide any protection from a MitM > attack. However, it can still be useful, combined with TLS, server cert > validation, _and_ channel binding. Why is channel binding needed if you have TLS with server cert validation? I realize that in practice, TLS server cert validation is often omitted by the app, circumvented by the user, or reliant on a huge network of potentially subvertable CAs. But it sounds like you're asserting an attack on client-only authentication which works even if it takes place on a server-authenticated secure channel. From lha@kth.se Sat Apr 2 13:36:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB543A689F for ; Sat, 2 Apr 2011 13:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti6ElkkZWUwX for ; Sat, 2 Apr 2011 13:36:47 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 7C3763A6816 for ; Sat, 2 Apr 2011 13:36:47 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id BCE58155897; Sat, 2 Apr 2011 22:37:57 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id eWPzTXiMp8dN; Sat, 2 Apr 2011 22:37:56 +0200 (CEST) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 4F527154220; Sat, 2 Apr 2011 22:37:52 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.145]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0255.000; Sat, 2 Apr 2011 22:37:52 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Simon Josefsson Thread-Topic: [kitten] GSS-API additions? Thread-Index: AQHL8K2hqmO9DzvWNEClTaZrwd5O2ZRK6MgA Date: Sat, 2 Apr 2011 20:37:51 +0000 Message-ID: <5B9F3A88-08BD-4067-9AD8-D795B3D15A84@kth.se> References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> In-Reply-To: <87aag9r9ab.fsf@latte.josefsson.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <07BE56E45507314EA316FBD6E6C869B8@ug.kth.se> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 20:36:48 -0000 1 apr 2011 kl. 13:44 skrev Simon Josefsson: > If we _really_ wanted to fix this, I think it could be done without too > much damage to the deployed base: adding a 'const' at the right place > doesn't change the ABI since the function was never permitted to modify > the OID content anyway. >=20 > On the other hand, RFC 2744 has the same issue in so many places (a > quick count indicate that around 10 of the APIs seems to have the same > issue) that fixing only this API will make it stand out as odd. >=20 > So if there aren't significant problems with how the APIs in RFC 2744 > are used, this API will likely not cause any problem either, I think? Let move the const-ness to the right place since since it wont change the A= BI and will catch mistakes however unlikely. Love From jhutz@cmu.edu Sat Apr 2 14:20:50 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D8763A68CB for ; Sat, 2 Apr 2011 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsbBnm-mvCGg for ; Sat, 2 Apr 2011 14:20:49 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 61A7B3A68C0 for ; Sat, 2 Apr 2011 14:20:49 -0700 (PDT) Received: from [192.168.130.64] ([209.117.47.253]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p32LMKtu019327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2011 17:22:28 -0400 (EDT) References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> <248255.86264.qm@web32303.mail.mud.yahoo.com> <1301718985.2583.162.camel@destiny> <1301755216.10465.446.camel@t410> User-Agent: K-9 Mail for Android In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Jeffrey Hutzelman Date: Sat, 02 Apr 2011 17:22:14 -0400 To: Nico Williams , Greg Hudson Message-ID: <79397968-bc9d-4fd3-84b5-44a57a1557ce@email.android.com> X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:20:50 -0000 Nico Williams wrote: >On Apr 2, 2011 9:40 AM, "Greg Hudson" wrote: >> >> On Sat, 2011-04-02 at 00:36 -0400, Jeffrey Hutzelman wrote: >> > Of course, you can use something that only >> > proves the initiator's identity to the acceptor, but that's less >> > interesting, because it doesn't provide any protection from a MitM >> > attack. However, it can still be useful, combined with TLS, server >cert >> > validation, _and_ channel binding. >> >> Why is channel binding needed if you have TLS with server cert >> validation? >> >> I realize that in practice, TLS server cert validation is often >omitted >> by the app, circumvented by the user, or reliant on a huge network of >> potentially subvertable CAs. But it sounds like you're asserting an >> attack on client-only authentication which works even if it takes >place >> on a server-authenticated secure channel. > >You still need to make sure that the name of the GSS acceptor >corresponds to >the name of the server. The only simple way to do that is to specify >the >server's name to both libraries and hope it all works out (and forget, >too, >about the service name). And what if the TLS server cert validation >PKI is >crap? CB makes these issues go away. But I will grant that SASL/GSS >over >TLS w/o CB is not altogether a security catastrophe... it works >reasonably >well quite often - just not always. > >Nico >-- No, that argument doesn't hold in the case I was talking about, where the underlying mech doesn't prove acceptor identity. I believe I mentioned CB there because without it, the server has no protection against replay of credentials previously exposed by a stupid client. But in fact, whether that's a problem depends on the underlying mech. From hartmans@mit.edu Sat Apr 2 14:57:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D00343A68D5 for ; Sat, 2 Apr 2011 14:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.935 X-Spam-Level: X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7FGzauyJoJJ for ; Sat, 2 Apr 2011 14:57:01 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2BC543A68D4 for ; Sat, 2 Apr 2011 14:57:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 16FE520465; Sat, 2 Apr 2011 17:55:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A5654541; Sat, 2 Apr 2011 17:58:41 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> Date: Sat, 02 Apr 2011 17:58:41 -0400 In-Reply-To: (Luke Howard's message of "Sat, 2 Apr 2011 16:31:17 +1100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 21:57:02 -0000 >>>>> "Luke" == Luke Howard writes: Luke> On 02/04/2011, at 4:16 PM, Luke Howard wrote: >> This draft mentions the need for a context indicator that is clearly >>> separable from the NameFormat/Name. My preference is for a fixed >>> string because I think the names should be consistent and >>> deriveable, but a truly >> >> +1 Luke> A consistent attribute name for retrieving the underlying Luke> assertion would be a big boon for the (EAP to Kerberos) SAML Luke> protocol transition project I'm working on now. There's a fair amount of text in the draft explaining why this is probably a bad idea. See the section on context. For example a KDC-issued assertion as an attribute container within a local realm has very different semantics than an assertion from AAA. I think it's fine to use the same attribute for any of the AAA contexts. It's quite probable that SAML-EC2 and gss-eap can share the same attribute names as well, and so perhaps they need a better name. From hartmans@mit.edu Sat Apr 2 15:00:17 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689FC3A68D4 for ; Sat, 2 Apr 2011 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.917 X-Spam-Level: X-Spam-Status: No, score=-102.917 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMcc1DvBdtdL for ; Sat, 2 Apr 2011 15:00:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E8BE23A68D1 for ; Sat, 2 Apr 2011 15:00:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5955620465; Sat, 2 Apr 2011 17:58:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF5994541; Sat, 2 Apr 2011 18:01:57 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott E." References: Date: Sat, 02 Apr 2011 18:01:57 -0400 In-Reply-To: (Scott E. Cantor's message of "Fri, 1 Apr 2011 18:09:46 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 22:00:17 -0000 >>>>> "Cantor," == Cantor, Scott E writes: Cantor,> This draft mentions the need for a context indicator that Cantor,> is clearly separable from the NameFormat/Name. I don't think it does, and I'm not actually convinced that's desirable. The draft mentions that names need to have context. I don't want to disallow singleton names like the URN we plan to register for the gss-eap (or broader if they share the same context) SAML assertion. From cantor.2@osu.edu Sat Apr 2 15:05:06 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69EED3A68DA for ; Sat, 2 Apr 2011 15:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVbve64vY9LW for ; Sat, 2 Apr 2011 15:05:05 -0700 (PDT) Received: from defang4.it.ohio-state.edu (defang4.it.ohio-state.edu [128.146.216.84]) by core3.amsl.com (Postfix) with ESMTP id B1DF33A68D4 for ; Sat, 2 Apr 2011 15:05:03 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang4.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id p32M6hkG024682; Sat, 2 Apr 2011 18:06:43 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::7141:4585:75ae:c307%21]) with mapi; Sat, 2 Apr 2011 18:03:16 -0400 From: "Cantor, Scott E." To: Sam Hartman , Luke Howard Thread-Topic: [kitten] Status of naming extensions Thread-Index: AQHL8D3LvyqOvJC3gk6x+dft8zJhbpRJtZGAgACXPACAAAQmgIABE+CA//++J1A= Date: Sat, 2 Apr 2011 22:06:34 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.84 Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 22:05:06 -0000 > There's a fair amount of text in the draft explaining why this is > probably a bad idea. See the section on context. For example a > KDC-issued assertion as an attribute container within a local realm has > very different semantics than an assertion from AAA. I don't think it's a good idea to try and make up for the limited bandwidth= of the API here by burying information in the attribute names, particularl= y since using different names is a significant cost for deployers. If using= "fixed" SAML attribute names isn't appropriate for some deployments becaus= e of these concerns, that's where local mapping and filtering mechanisms sh= ould take over, by processing a SAML assertion directly. -- Scott From nico@cryptonector.com Sat Apr 2 15:34:43 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA323A68E2 for ; Sat, 2 Apr 2011 15:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLtSuGVSQKuq for ; Sat, 2 Apr 2011 15:34:42 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id C18B63A68E1 for ; Sat, 2 Apr 2011 15:34:42 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 2D9F410059 for ; Sat, 2 Apr 2011 15:36:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=rsoGuTzwdYNo7Vpl/dmC2 iLaA8UKqLxea+Jq75PNpIMfa9Apx54xhXctM8QwEccUw5rTZd7EshkcwUttFIFzG pue9Ku28gHugsfM3HyOn7oacwW4l/WvXTct23WawWD4pga2AM3BwCyrS7d3Oh2kh f4ED5f1QSMmXfT/E+idMH8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=eMTkGWz7gY/iI153Kl0H ynmFRh0=; b=Bc0d1WIDHB/47Q5HXJfEFT2fWiCpIna9Ez4mX8u5n0AiyMsdLo82 WqQ2yaEzWBIt2ORuziaO+OpTHnOfsnOrJ5sANtq2bsVrU2btNQE1gSEpQkaZxeqH 27BimAAAy//tAJ5TBnjc5WDq2XTzEqJkCvfRyEcjSIaGBe0w7XRHszY= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 018EC10058 for ; Sat, 2 Apr 2011 15:36:23 -0700 (PDT) Received: by vws12 with SMTP id 12so4094022vws.31 for ; Sat, 02 Apr 2011 15:36:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1868861vdg.70.1301783783233; Sat, 02 Apr 2011 15:36:23 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Sat, 2 Apr 2011 15:36:23 -0700 (PDT) In-Reply-To: <1301718985.2583.162.camel@destiny> References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> <248255.86264.qm@web32303.mail.mud.yahoo.com> <1301718985.2583.162.camel@destiny> Date: Sat, 2 Apr 2011 17:36:23 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 22:34:43 -0000 On Apr 1, 2011 11:37 PM, "Jeffrey Hutzelman" wrote: > Now, if the authentication scheme produces as one of its outputs some > secret that is known only to the client and server, we can add an > exchange to negotiate an RFC3961 enctype, use the shared secret to key > that enctype, at which point we can build channel bindings on an RFC3961 > checksum, and do gss_getmic and gss_wrap as described in RFC4121 and PRF > as described in RFC4402; that is, exactly as for Kerberos. Note that there's no reason to use any part of Kerberos for this other than spec and code reuse (a great reason, to be sure, but we don't to scare anyone away, which is why i mention it :). > If the authentication scheme does not provide a shared secret but does > provide a PRF, we can use _that_ [...] If you have a PRF with shared state you almost certainly have a shared secret key... > Unfortunately, if all the underlying mechanism provides is a MIC > function or some other form of integrity protection, then we need to try > a bit harder. In this case, we perform a DH exchange, which we protect > using the provided MIC. This results in a shared secret, which we can > use to key PRF and wrap. CB and gss_getmic can be provided using the > new key or directly using the built-in MIC capability. Huh? If the mech gives you a MIC, well, use it! Just exchange MICs of the CB :) From nico@cryptonector.com Sat Apr 2 15:35:07 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E2C3A68E4 for ; Sat, 2 Apr 2011 15:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tHrRv1vhOb8 for ; Sat, 2 Apr 2011 15:35:06 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 7B6BE28C0CF for ; Sat, 2 Apr 2011 15:35:05 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id AC65421DE65 for ; Sat, 2 Apr 2011 15:36:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=MZNusHP+PDP+xTfQtqGa1 zHnteVtDmbcNbkDUNM0YkvZEHmtTDW6M5r97jNoXQqfdQTBzyX9W2/Lg48cOcwZK TFmfl5YdflI7e/UFhNwQxWjo3N01fNeGvaKV6N6yea0AR0b5zUW93wBqKgDH9j+A oUNr4YeRog1E/G2Hv0oBVc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=r2RyTkfB/7caZTwT+coj v4YSouI=; b=Pn5oBqsEkzwckAYLR3EQR4O35IRQW1//aTQl7+yvlsh9KLTRKjJZ 9/VOKPQFV6Qo2tjI0wrP4u2vPfLNBcapbOh1i09DA1HzQYXXXKnyGvglf9TzrZnd PXx4FNOksO3aMDQ0SX/tbPt0RHYWKvzVy8R027h0/JZnjVWv8PC0/ag= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 772D921DE59 for ; Sat, 2 Apr 2011 15:36:46 -0700 (PDT) Received: by vws12 with SMTP id 12so4094121vws.31 for ; Sat, 02 Apr 2011 15:36:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr7503511vdb.270.1301783805748; Sat, 02 Apr 2011 15:36:45 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Sat, 2 Apr 2011 15:36:45 -0700 (PDT) In-Reply-To: <1301755216.10465.446.camel@t410> References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> <248255.86264.qm@web32303.mail.mud.yahoo.com> <1301718985.2583.162.camel@destiny> <1301755216.10465.446.camel@t410> Date: Sat, 2 Apr 2011 17:36:45 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Jeffrey Hutzelman Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 22:35:07 -0000 On Apr 2, 2011 9:40 AM, "Greg Hudson" wrote: > > On Sat, 2011-04-02 at 00:36 -0400, Jeffrey Hutzelman wrote: > > Of course, you can use something that only > > proves the initiator's identity to the acceptor, but that's less > > interesting, because it doesn't provide any protection from a MitM > > attack. However, it can still be useful, combined with TLS, server cert > > validation, _and_ channel binding. > > Why is channel binding needed if you have TLS with server cert > validation? > > I realize that in practice, TLS server cert validation is often omitted > by the app, circumvented by the user, or reliant on a huge network of > potentially subvertable CAs. But it sounds like you're asserting an > attack on client-only authentication which works even if it takes place > on a server-authenticated secure channel. You still need to make sure that the name of the GSS acceptor corresponds to the name of the server. The only simple way to do that is to specify the server's name to both libraries and hope it all works out (and forget, too, about the service name). And what if the TLS server cert validation PKI is crap? CB makes these issues go away. But I will grant that SASL/GSS over TLS w/o CB is not altogether a security catastrophe... it works reasonably well quite often - just not always. Nico -- From nico@cryptonector.com Sat Apr 2 15:37:39 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267A23A68E2 for ; Sat, 2 Apr 2011 15:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcR5vjrw7IbQ for ; Sat, 2 Apr 2011 15:37:38 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 2CF8A3A68E1 for ; Sat, 2 Apr 2011 15:37:38 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id A4AFD67C06D for ; Sat, 2 Apr 2011 15:39:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=YqtITo/+wi1rco9bZCjhGu9Bwlkwo/hM2KSawAgPMbYc g7crDixjFrPysntPgS49BEOIXncdatTtgg7Q4JP6kK0Hibng1mVgyg1qyAHh2jaI ey0FokT0eaqutg2Xs5Ho/+eh1WvoCjXap1Ynj1H8Y0uM/P8XnDQ6fkGMrRv5NfY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=PbQhDxXJj/thCAxOG/rNS5A9VCk=; b=KTVTwiEoK92 FMcN4rwUYZJIhqGYdB36Rt6fMPdkUA4E2/r5T2tk4vE7GxT2iHxy+D+GqBQ2KQeb j1i43MTOAD3Xt6RD8jAMpWz/INrgCX/m+GbywYSfGpKhhhjc8Q6kn/LWmsZhFl/f hBPGzGdgA3HKt93P//HhMX8PXdOVUC8g= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 77D1467C06B for ; Sat, 2 Apr 2011 15:39:19 -0700 (PDT) Received: by vws12 with SMTP id 12so4094802vws.31 for ; Sat, 02 Apr 2011 15:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.233 with SMTP id ct9mr7551305vdc.110.1301783958880; Sat, 02 Apr 2011 15:39:18 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Sat, 2 Apr 2011 15:39:18 -0700 (PDT) In-Reply-To: <79397968-bc9d-4fd3-84b5-44a57a1557ce@email.android.com> References: <4D94377D.5040508@oracle.com> <11220_1301594356_p2VHxFPN028287_631012.11217.qm@web32303.mail.mud.yahoo.com> <1301610771.2583.81.camel@destiny> <248255.86264.qm@web32303.mail.mud.yahoo.com> <1301718985.2583.162.camel@destiny> <1301755216.10465.446.camel@t410> <79397968-bc9d-4fd3-84b5-44a57a1557ce@email.android.com> Date: Sat, 2 Apr 2011 17:39:18 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 22:37:39 -0000 [resend] On Sat, Apr 2, 2011 at 4:22 PM, Jeffrey Hutzelman wrote: >>You still need to make sure that the name of the GSS acceptor >>corresponds to >>the name of the server. The only simple way to do that is to specify >>the >>server's name to both libraries and hope it all works out (and forget, >>too, >>about the service name). And what if the TLS server cert validation >>PKI is >>crap? CB makes these issues go away. But I will grant that SASL/GSS >>over >>TLS w/o CB is not altogether a security catastrophe... it works >>reasonably >>well quite often - just not always. > > No, that argument doesn't hold in the case I was talking about, where the= underlying mech doesn't prove acceptor identity. I believe I mentioned CB= there because without it, the server has no protection against replay of c= redentials previously exposed by a stupid client. But in fact, whether tha= t's a problem depends on the underlying mech. Sure, that's true. But I do want to make clear that just having TLS server certs does not provide a very good binding of the app-layer authentication to TLS. From simon@josefsson.org Sun Apr 3 00:19:19 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5D43A6935 for ; Sun, 3 Apr 2011 00:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEQ6-MbWFkmj for ; Sun, 3 Apr 2011 00:19:18 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 0B01B3A6822 for ; Sun, 3 Apr 2011 00:19:17 -0700 (PDT) Received: from latte.josefsson.org (m83-188-239-92.cust.tele2.se [83.188.239.92]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p337KWf8024115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 3 Apr 2011 09:20:40 +0200 From: Simon Josefsson To: Love =?iso-8859-1?Q?H=F6rnquist_=C5strand?= References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110403:ghudson@mit.edu::AiT5EomFO+bB3aaQ:01Ks X-Hashcash: 1:22:110403:lha@kth.se::29CSW30ZU8gjjV4f:DJvD X-Hashcash: 1:22:110403:kitten@ietf.org::Hpb5/jBMZpdjcQk0:aRiY Date: Sun, 03 Apr 2011 09:20:30 +0200 In-Reply-To: <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> ("Love =?iso-8859-1?Q?H=F6rnquist_=C5strand=22's?= message of "Sat, 2 Apr 2011 20:37:51 +0000") Message-ID: <87r59j3io1.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 07:19:19 -0000 Love Hörnquist Åstrand writes: > 1 apr 2011 kl. 13:44 skrev Simon Josefsson: > >> If we _really_ wanted to fix this, I think it could be done without too >> much damage to the deployed base: adding a 'const' at the right place >> doesn't change the ABI since the function was never permitted to modify >> the OID content anyway. >> >> On the other hand, RFC 2744 has the same issue in so many places (a >> quick count indicate that around 10 of the APIs seems to have the same >> issue) that fixing only this API will make it stand out as odd. >> >> So if there aren't significant problems with how the APIs in RFC 2744 >> are used, this API will likely not cause any problem either, I think? > > Let move the const-ness to the right place since since it wont change > the ABI and will catch mistakes however unlikely. Works for me, as it doesn't affect the ABI. Any preference on whether we should use 1) extern int gss_oid_equal ( const gss_OID_desc *first_oid, const gss_OID_desc *second_oid ) or 2) extern int gss_oid_equal ( gss_const_OID first_oid, gss_const_OID second_oid ) and reference RFC 5587? /Simon From lukeh@padl.com Sun Apr 3 00:29:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1410F3A6935 for ; Sun, 3 Apr 2011 00:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0J5PCSF1Muw for ; Sun, 3 Apr 2011 00:29:00 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 5D0B43A6929 for ; Sun, 3 Apr 2011 00:29:00 -0700 (PDT) Received: by us.padl.com with ESMTP id p337U62N019704; Sun, 3 Apr 2011 03:30:39 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <87r59j3io1.fsf@latte.josefsson.org> Date: Sun, 3 Apr 2011 17:30:39 +1000 Content-Transfer-Encoding: 7bit Message-Id: <39C2FC30-0F67-4FF9-BC4A-B661CB932F5F@padl.com> References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 07:29:01 -0000 > 2) > > extern int > gss_oid_equal ( > gss_const_OID first_oid, > gss_const_OID second_oid > ) > > and reference RFC 5587? 2) Greg: do you want me to update trunk with this? -- Luke From lukeh@padl.com Sun Apr 3 00:31:23 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D263A6936 for ; Sun, 3 Apr 2011 00:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7LKJhmP2gAy for ; Sun, 3 Apr 2011 00:31:22 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 7B3F83A6929 for ; Sun, 3 Apr 2011 00:31:22 -0700 (PDT) Received: by us.padl.com with ESMTP id p337WxCb024371; Sun, 3 Apr 2011 03:33:02 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <87r59j3io1.fsf@latte.josefsson.org> Date: Sun, 3 Apr 2011 17:32:59 +1000 Content-Transfer-Encoding: 7bit Message-Id: <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 07:31:23 -0000 >> Let move the const-ness to the right place since since it wont change >> the ABI and will catch mistakes however unlikely. > > Works for me, as it doesn't affect the ABI. Any preference on whether > we should use Also, you planning to change the others? OM_uint32 gss_encapsulate_token ( gss_const_buffer_t, /* input_token */ gss_const_OID /* token_oid */ gss_buffer_t /* output_token */ ); OM_uint32 gss_decapsulate_token ( gss_const_buffer_t, /* input_token */ gss_const_OID, /* token_oid */ gss_buffer_t /* output_token */ ); int gss_oid_equal ( gss_const_OID, /* first_oid */ gss_const_OID /* second_oid */ ); -- Luke From simon@josefsson.org Sun Apr 3 00:40:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C753A693E for ; Sun, 3 Apr 2011 00:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U66TTimb2cu for ; Sun, 3 Apr 2011 00:40:28 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id B64F13A6929 for ; Sun, 3 Apr 2011 00:40:27 -0700 (PDT) Received: from latte.josefsson.org (m83-188-239-92.cust.tele2.se [83.188.239.92]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p337fsAf024979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 3 Apr 2011 09:41:58 +0200 From: Simon Josefsson To: Luke Howard References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110403:kitten@ietf.org::NuyKrXaXktCCSvo2:BNgS X-Hashcash: 1:22:110403:lha@kth.se::HRLi6xPSb9OdnOdA:CyP4 X-Hashcash: 1:22:110403:ghudson@mit.edu::5TsgtgOB980Z62z8:KcgX X-Hashcash: 1:22:110403:lukeh@padl.com::B+FzGA+VhNUzouYN:TSfQ Date: Sun, 03 Apr 2011 09:41:48 +0200 In-Reply-To: <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> (Luke Howard's message of "Sun, 3 Apr 2011 17:32:59 +1000") Message-ID: <87mxk73hoj.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 07:40:28 -0000 Luke Howard writes: >>> Let move the const-ness to the right place since since it wont change >>> the ABI and will catch mistakes however unlikely. >> >> Works for me, as it doesn't affect the ABI. Any preference on whether >> we should use > > Also, you planning to change the others? If we change one, I think we should change all. Any reason not to? /Simon > > OM_uint32 gss_encapsulate_token > ( > gss_const_buffer_t, /* input_token */ > gss_const_OID /* token_oid */ > gss_buffer_t /* output_token */ > ); > > OM_uint32 gss_decapsulate_token > ( > gss_const_buffer_t, /* input_token */ > gss_const_OID, /* token_oid */ > gss_buffer_t /* output_token */ > ); > > int gss_oid_equal > ( > gss_const_OID, /* first_oid */ > gss_const_OID /* second_oid */ > ); > > > -- Luke From lukeh@padl.com Sun Apr 3 00:45:21 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374583A693E for ; Sun, 3 Apr 2011 00:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, MANGLED_EMAIL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwLG7owzi709 for ; Sun, 3 Apr 2011 00:45:20 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id A7B7C3A6929 for ; Sun, 3 Apr 2011 00:45:20 -0700 (PDT) Received: by us.padl.com with ESMTP id p337kvE5017526; Sun, 3 Apr 2011 03:47:00 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <87mxk73hoj.fsf@latte.josefsson.org> Date: Sun, 3 Apr 2011 17:46:57 +1000 Content-Transfer-Encoding: 7bit Message-Id: <9A83FB4F-4C2A-4F58-A3E2-C05EDE847905@padl.com> References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> <87mxk73hoj.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 07:45:21 -0000 On 03/04/2011, at 5:41 PM, Simon Josefsson wrote: > Luke Howard writes: > >>>> Let move the const-ness to the right place since since it wont change >>>> the ABI and will catch mistakes however unlikely. >>> >>> Works for me, as it doesn't affect the ABI. Any preference on whether >>> we should use >> >> Also, you planning to change the others? > > If we change one, I think we should change all. Any reason not to? Nope, change 'em all! I can check some fixes in for both Heimdal and MIT. -- Luke From simon@josefsson.org Sun Apr 3 02:38:06 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF593A6973 for ; Sun, 3 Apr 2011 02:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfoiLGAGFRGr for ; Sun, 3 Apr 2011 02:38:05 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id E15173A6407 for ; Sun, 3 Apr 2011 02:38:04 -0700 (PDT) Received: from latte.josefsson.org (m83-188-239-92.cust.tele2.se [83.188.239.92]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p339dV43030006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 3 Apr 2011 11:39:38 +0200 From: Simon Josefsson To: Luke Howard References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> <87mxk73hoj.fsf@latte.josefsson.org> <9A83FB4F-4C2A-4F58-A3E2-C05EDE847905__13073.0196754032$1301816837$gmane$org@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110403:kitten@ietf.org::51g8Qd2AokBD6Xpa:9E+5 X-Hashcash: 1:22:110403:lukeh@padl.com::fICjipjljjehFh84:Gpk5 X-Hashcash: 1:22:110403:ghudson@mit.edu::hABYlhZ5/yujFbgH:RDwq Date: Sun, 03 Apr 2011 11:39:30 +0200 In-Reply-To: <9A83FB4F-4C2A-4F58-A3E2-C05EDE847905__13073.0196754032$1301816837$gmane$org@padl.com> (Luke Howard's message of "Sun, 3 Apr 2011 17:46:57 +1000") Message-ID: <87aag73c8d.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, ghudson@MIT.EDU Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 09:38:06 -0000 I've submitted -03 that uses the RFC 5587 types, thanks Greg and Luke. Please take a look whether the changes are correct: http://tools.ietf.org/rfcdiff?url2=draft-josefsson-gss-capsulate-03.txt /Simon From lukeh@padl.com Sun Apr 3 03:35:10 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3688B3A67B3 for ; Sun, 3 Apr 2011 03:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux5+XVIyHTpF for ; Sun, 3 Apr 2011 03:35:09 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id D25ED3A6980 for ; Sun, 3 Apr 2011 03:35:08 -0700 (PDT) Received: by us.padl.com with ESMTP id p33AagtU010216; Sun, 3 Apr 2011 06:36:47 -0400 References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> <87mxk73hoj.fsf@latte.josefsson.org> <9A83FB4F-4C2A-4F58-A3E2-C05EDE847905__13073.0196754032$1301816837$gmane$org@padl.com> <87aag73c8d.fsf@latte.josefsson.org> In-Reply-To: <87aag73c8d.fsf@latte.josefsson.org> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8819952D-50A2-4FA7-A101-139E8044BFB7@padl.com> X-Mailer: iPhone Mail (8G4) From: Luke Howard Date: Sun, 3 Apr 2011 20:36:34 +1000 To: Simon Josefsson X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.7 Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 10:35:10 -0000 Looks good. Thanks for the acknowledgment! Now, should we do the same for na= ming extensions... (except MIT has shipped with the non const ones, but as G= reg pointed out there are no ABI issues). Von meinem iPhone gesendet Am 03/04/2011 um 19:39 schrieb Simon Josefsson : > I've submitted -03 that uses the RFC 5587 types, thanks Greg and Luke. > Please take a look whether the changes are correct: >=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-josefsson-gss-capsulate-03.txt >=20 > /Simon From simon@josefsson.org Sun Apr 3 04:01:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95213A698A for ; Sun, 3 Apr 2011 04:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzWmSRL2VAhK for ; Sun, 3 Apr 2011 04:01:01 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id C23513A67B2 for ; Sun, 3 Apr 2011 04:01:00 -0700 (PDT) Received: from latte.josefsson.org (m83-188-239-92.cust.tele2.se [83.188.239.92]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p33B2FkK001245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 3 Apr 2011 13:02:32 +0200 From: Simon Josefsson To: Luke Howard References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> <87mxk73hoj.fsf@latte.josefsson.org> <9A83FB4F-4C2A-4F58-A3E2-C05EDE847905__13073.0196754032$1301816837$gmane$org@padl.com> <87aag73c8d.fsf@latte.josefsson.org> <8819952D-50A2-4FA7-A101-139E8044BFB7__14549.2997406565$1301827029$gmane$org@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110403:lukeh@padl.com::dM9XIixnG8ZvjNBn:3Lj X-Hashcash: 1:22:110403:ghudson@mit.edu::Bv9SeuJQOuqOSq4a:2II/ X-Hashcash: 1:22:110403:kitten@ietf.org::8QIOXDWFScFaHYrf:61Tm Date: Sun, 03 Apr 2011 13:02:05 +0200 In-Reply-To: <8819952D-50A2-4FA7-A101-139E8044BFB7__14549.2997406565$1301827029$gmane$org@padl.com> (Luke Howard's message of "Sun, 3 Apr 2011 20:36:34 +1000") Message-ID: <871v1j38eq.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 11:01:02 -0000 Luke Howard writes: > Looks good. Thanks for the acknowledgment! Now, should we do the same > for naming extensions... (except MIT has shipped with the non const > ones, but as Greg pointed out there are no ABI issues). Making the change elsewhere seems like a good idea to me. I wish we had noticed the bug for the RFC 5801 interfaces as well. Possibly we could submit an errata about it, and fix it in 5801bis? (..and RFC 2744..) /Simon From hartmans@mit.edu Sun Apr 3 07:18:20 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA653A6810 for ; Sun, 3 Apr 2011 07:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9hG5Jib9R4L for ; Sun, 3 Apr 2011 07:18:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E324C3A67F5 for ; Sun, 3 Apr 2011 07:18:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A3E25203A1; Sun, 3 Apr 2011 10:16:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 639C64541; Sun, 3 Apr 2011 10:19:58 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott E." References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> Date: Sun, 03 Apr 2011 10:19:58 -0400 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> (Scott E. Cantor's message of "Sat, 2 Apr 2011 22:06:34 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 14:18:20 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> There's a fair amount of text in the draft explaining why this is >> probably a bad idea. See the section on context. For example a >> KDC-issued assertion as an attribute container within a local >> realm has very different semantics than an assertion from AAA. Cantor,> I don't think it's a good idea to try and make up for the Cantor,> limited bandwidth of the API here by burying information in Cantor,> the attribute names, particularly since using different Cantor,> names is a significant cost for deployers. If using "fixed" Cantor,> SAML attribute names isn't appropriate for some deployments Cantor,> because of these concerns, that's where local mapping and Cantor,> filtering mechanisms should take over, by processing a SAML Cantor,> assertion directly. I'd like to explicitly ask the chairs to make a call for whether this is re-opening a new issue. I believe that between Beijing and the last call, the basic direction for how to deal with context should be closed at this point. As I've said before, I don't think local filtering and mapping is appropriate because: 1) Absent context in the name I don't think we have a rich enough mechanism to have high confidence that local filtering could be done reasonably. 2) I think it's important that we be able to standardize attribute behavior in some applications. I don't think we can do this while depending on local filtering 3) The consequences of failing insecure seem bad. The consequences of failing to expose the attributes without explicit configuration also seem very problematic. It's possible this is all broken and we'll be revisiting the whole approach in a couple of years. However, I personally have two hard constraints. First, I want to see us publish something that permits the IETF to standardize attributes for use in IETf protocols and expect them to be there. I think that means some level of context and not depending on filtering. Second, I'd like to see us publish something that is an incremental evolution of what we've been working with and what people have shipped. It's my personal opinion that from a process standpoint, we've already had this discussion and that no new information has come forward. Scott may be right that we'll end up revisiting our approach. However, I know I don't have the energy to start over on this spec right now, and I think that we've demonstrated enough value that publishing what we have as a proposed standard is far better than giving up. From hartmans@mit.edu Sun Apr 3 08:56:27 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912983A697E for ; Sun, 3 Apr 2011 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1pHsOy6HkCz for ; Sun, 3 Apr 2011 08:56:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E310D3A6837 for ; Sun, 3 Apr 2011 08:56:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A18C82011F; Sun, 3 Apr 2011 11:54:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4C64D4541; Sun, 3 Apr 2011 11:58:06 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> Date: Sun, 03 Apr 2011 11:58:06 -0400 In-Reply-To: (Sam Hartman's message of "Sun, 03 Apr 2011 10:19:58 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 15:56:27 -0000 >>>>> "Sam" == Sam Hartman writes: >>>>> "Cantor," == Cantor, Scott E writes: >>> There's a fair amount of text in the draft explaining why this >>> is probably a bad idea. See the section on context. For >>> example a KDC-issued assertion as an attribute container within >>> a local realm has very different semantics than an assertion >>> from AAA. > Cantor,> I don't think it's a good idea to try and make up > for the Cantor,> limited bandwidth of the API here by burying > information in Cantor,> the attribute names, particularly since > using different Cantor,> names is a significant cost for > deployers. If using "fixed" Cantor,> SAML attribute names isn't > appropriate for some deployments Cantor,> because of these > concerns, that's where local mapping and Cantor,> filtering > mechanisms should take over, by processing a SAML Cantor,> > assertion directly. Sam> I'd like to explicitly ask the chairs to make a call for Sam> whether this is re-opening a new issue. I realize I was not clear on what I meant by this. I believe that the question of whether we will embed context in names is already decided. To what extent SAML names share a context I think is very much something we still need to discuss. I think that GSS-EAP, SAML-EC and the browser SAML mechanism can almost certainly all use the same context. I think that cases where a domain-local policy authority such as a KDC has applied additional policy (discussed at the Kerberos consortium conference and long ago on the kaml mailing list) need a separate context. It might well be appropriate in this case to also echo the names into the context used by SAML-EC, GSS-EAP and the browser mechanism. I'm not aware of anyone proposing standardizing this context or implementing at this time. From cantor.2@osu.edu Sun Apr 3 12:43:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EE43A67B5 for ; Sun, 3 Apr 2011 12:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UanYW5t0DwdX for ; Sun, 3 Apr 2011 12:43:27 -0700 (PDT) Received: from defang18.it.ohio-state.edu (defang18.it.ohio-state.edu [128.146.216.132]) by core3.amsl.com (Postfix) with ESMTP id 72D113A63D3 for ; Sun, 3 Apr 2011 12:43:25 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang18.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p33Jj5kZ002322; Sun, 3 Apr 2011 15:45:05 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::cd73:7784:284f:8055%13]) with mapi; Sun, 3 Apr 2011 15:41:34 -0400 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [kitten] Status of naming extensions Thread-Index: AQHL8D3LvyqOvJC3gk6x+dft8zJhbpRJtZGAgACXPACAAAQmgIABE+CA//++J1CAAVQEAIAAFszw Date: Sun, 3 Apr 2011 19:44:40 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007A9DB36@CIO-TNC-D1MBX09.osuad.osu.edu> References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.132 Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 19:43:28 -0000 > I'd like to explicitly ask the chairs to make a call for whether this is > re-opening a new issue. I believe that between Beijing and the last > call, the basic direction for how to deal with context should be closed > at this point. The reason I said something is that you asked me if I thought the spec was = clear now. This was the issue I felt was unclear at the time. I'm happy to = let it lie, but see below. > 2) I think it's important that we be able to standardize attribute > behavior in some applications. > I don't think we can do this while depending on local filtering I agree, that's basically the point I was making. > 3) The consequences of failing insecure seem bad. The consequences of > failing to expose the attributes without explicit configuration also > seem very problematic. This is my concern. It doesn't seem like you can add this context to the na= mes of the attributes and then expect that they'll be accessible to applica= tions without explicit configuration. Where is the context going to come fr= om? -- Scott From lukeh@padl.com Sun Apr 3 16:04:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26733A68CE for ; Sun, 3 Apr 2011 16:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gld65LEIoPfA for ; Sun, 3 Apr 2011 16:04:55 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id F29973A68C7 for ; Sun, 3 Apr 2011 16:04:54 -0700 (PDT) Received: by us.padl.com with ESMTP id p33N6Wl1013841; Sun, 3 Apr 2011 19:06:35 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Mon, 4 Apr 2011 09:06:32 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 23:04:55 -0000 > To what extent SAML names share a context I think is very much = something > we still need to discuss. Note my specific concern (although it may amount to the same thing) was = not how attributes extracted from the assertion were named, but how the = assertion itself (if available directly) was named. -- Luke= From hartmans@mit.edu Mon Apr 4 04:47:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84F528C0FD for ; Mon, 4 Apr 2011 04:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTPHQkUKvBo9 for ; Mon, 4 Apr 2011 04:47:38 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7D7513A6992 for ; Mon, 4 Apr 2011 04:47:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AE03C20463; Mon, 4 Apr 2011 07:46:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 879164541; Mon, 4 Apr 2011 07:49:16 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> Date: Mon, 04 Apr 2011 07:49:16 -0400 In-Reply-To: (Luke Howard's message of "Mon, 4 Apr 2011 09:06:32 +1000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 11:47:39 -0000 >>>>> "Luke" == Luke Howard writes: >> To what extent SAML names share a context I think is very much >> something we still need to discuss. Luke> Note my specific concern (although it may amount to the same Luke> thing) was not how attributes extracted from the assertion Luke> were named, but how the assertion itself (if available Luke> directly) was named. I think this is effectively the same, although the text string may differ slightly. From hartmans@mit.edu Mon Apr 4 05:33:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C54828C108 for ; Mon, 4 Apr 2011 05:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irEqH2LvSWyW for ; Mon, 4 Apr 2011 05:33:21 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2E6F628C102 for ; Mon, 4 Apr 2011 05:33:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B90C120265; Mon, 4 Apr 2011 08:31:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8629B4541; Mon, 4 Apr 2011 08:34:57 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott E." References: <311A25EE-5710-4783-8513-E0D3C7C514A9@padl.com> <7EE86E89365CA94F8E7B8251F926071007A9D1A3@CIO-TNC-D1MBX09.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007A9DB36@CIO-TNC-D1MBX09.osuad.osu.edu> Date: Mon, 04 Apr 2011 08:34:57 -0400 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007A9DB36@CIO-TNC-D1MBX09.osuad.osu.edu> (Scott E. Cantor's message of "Sun, 3 Apr 2011 19:44:40 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Status of naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 12:33:22 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> I'd like to explicitly ask the chairs to make a call for whether >> this is re-opening a new issue. I believe that between Beijing >> and the last call, the basic direction for how to deal with >> context should be closed at this point. Cantor,> The reason I said something is that you asked me if I Cantor,> thought the spec was clear now. This was the issue I felt Cantor,> was unclear at the time. I'm happy to let it lie, but see Cantor,> below. >> 2) I think it's important that we be able to standardize >> attribute behavior in some applications. I don't think we can do >> this while depending on local filtering Cantor,> I agree, that's basically the point I was making. I think we may be differing in how much context we think is necessary here. >> 3) The consequences of failing insecure seem bad. The >> consequences of failing to expose the attributes without explicit >> configuration also seem very problematic. Cantor,> This is my concern. It doesn't seem like you can add this Cantor,> context to the names of the attributes and then expect that Cantor,> they'll be accessible to applications without explicit Cantor,> configuration. Where is the context going to come from? In all the discussions across krb-wg, kitten, kaml, moonshot, and abfab, I've seen what I would consider few contexts discussed: 1) Unauthenticated: The security mechanism has no confirmation where the attributes come from. Possibly useful for restrictions or preferences, but definitely not entitlements or auditing. 2) Federated: We know who asserted the attribute, we've checked things like scope. However we have not actually applied local policy or filtering. 3) Kerberos KDC issued/PAC/PAD: Someone in our domain has made policy decisions about the attributes. They recommend we trust them; absent local policy it would be reasonable to do so. 4) Local: Local policy has explicitly asserted or mapped something to this attribute. I believe that these sorts of contexts are hard coded. I believe these contexts also have the property that if an application does not understand the context, it should generally not try to interpret the attribute. Well, actually, the above seem to be ordered. It would generally be OK if an application would accept a lower numbered context to accept a higher-numbered context. However, it would be better for a Kerberos-style application to completely ignore federated attributes than to interpret them if it does not understand them. So, I think these contexts can be hard-coded in IETF specs. I do think that local policy may need to tune things: filtering out attributes that are present in some cases, remapping things fand indicating trust in others. From hartmans@mit.edu Mon Apr 4 08:27:49 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764A13A69F6 for ; Mon, 4 Apr 2011 08:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPhxKtxFVbqa for ; Mon, 4 Apr 2011 08:27:49 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 076523A6952 for ; Mon, 4 Apr 2011 08:27:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 668D5204AF; Mon, 4 Apr 2011 11:26:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1864C4541; Mon, 4 Apr 2011 11:29:27 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201103292116.p2TLGIJC004475@fs4113.wdf.sap.corp> Date: Mon, 04 Apr 2011 11:29:27 -0400 In-Reply-To: (Nico Williams's message of "Thu, 31 Mar 2011 12:38:19 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Callback for Password not so good X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 15:27:49 -0000 >>>>> "Nico" == Nico Williams writes: Nico> However, we could have a mechanism attribute that indicates Nico> whether the initial gss_init_sec_context() call succeeds only Nico> if there are target-specific credentials cached (I don't have Nico> time to check, but, IIRC, we do have such an attribute). That's also not good enough for my use case. It is a prerequisite for my use case sort of. I effectively want to ask the mechanism if it needs a password to contact a possibly unconstrained target with a possibly unconstrained initiator identity. If so, I'd prefer to give it the password. If not, I'd prefer not to ask the user in the app context. From mrex@sap.com Mon Apr 4 18:29:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9119A3A6842 for ; Mon, 4 Apr 2011 18:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.223 X-Spam-Level: X-Spam-Status: No, score=-10.223 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSQ9AqOz1JZs for ; Mon, 4 Apr 2011 18:29:46 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id BB0EF3A683E for ; Mon, 4 Apr 2011 18:29:45 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p351VOCW020270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 03:31:25 +0200 (MEST) From: Martin Rex Message-Id: <201104050131.p351VO0l008653@fs4113.wdf.sap.corp> To: ghudson@MIT.EDU (Greg Hudson) Date: Tue, 5 Apr 2011 03:31:24 +0200 (MEST) In-Reply-To: <1301755216.10465.446.camel@t410> from "Greg Hudson" at Apr 2, 11 10:40:16 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Channel binding requirements. X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 01:29:46 -0000 Greg Hudson wrote: > > On Sat, 2011-04-02 at 00:36 -0400, Jeffrey Hutzelman wrote: > > Of course, you can use something that only > > proves the initiator's identity to the acceptor, but that's less > > interesting, because it doesn't provide any protection from a MitM > > attack. However, it can still be useful, combined with TLS, server cert > > validation, _and_ channel binding. > > Why is channel binding needed if you have TLS with server cert > validation? > > I realize that in practice, TLS server cert validation is often omitted > by the app, circumvented by the user, or reliant on a huge network of > potentially subvertable CAs. But it sounds like you're asserting an > attack on client-only authentication which works even if it takes place > on a server-authenticated secure channel. You want to be really sure that the authentication exchange that the server sees through TLS is actually from an authentication handshake of the client that does not use TLS (or is with a different server). This is the type of problem that rfc-4559 HTTP Negotiate without channel bindings is suffering from. And when the authentication is password-based, you may have the problem that humans often reuse passwords for different targets. -Martin From stephen.farrell@cs.tcd.ie Tue Apr 5 10:57:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 986F928C13B for ; Tue, 5 Apr 2011 10:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc+quDx3PG-E for ; Tue, 5 Apr 2011 10:57:37 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id 909E028C136 for ; Tue, 5 Apr 2011 10:57:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 936DD3E4077 for ; Tue, 5 Apr 2011 18:59:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1302026357; bh=trrRTCWDAWGZWs5Iy+hiQXkf ywA7UArl31wFoHnjZwI=; b=q9bf8Mf+8NEA7HWhO6AQI+c1zFJD+9uCL4jjuDLv IbYXnYzZkXxwxcRCgepueHR+NOs0WGIZ8W0Jmr+yRe36KrOhZZNsxkE2IVxwO2nr QhCjSWSsRr/fLUOtp1aAdkynpJkPDcuXuISOyTZSq6nNK62Oyeu8JkqXwnZkxTM/ v9/rSixXC2O0WfsZ87hGeTiewXWOx5eNGbQzIhte7WdEDcXvJeNkejNqVAwaQvFT 7i6GsIlNRD7IR6QPkWEPuxQDg3m4UOew06eQGfZUUZjf8+GEf85oUzR7+rTa2oju erBs96lmOlQtkwOUHvmCQOStzondyOgaJ+d0s070w0OXfA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id WJsJiSP4lS1g for ; Tue, 5 Apr 2011 18:59:17 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6249C3E4075 for ; Tue, 5 Apr 2011 18:59:17 +0100 (IST) Message-ID: <4D9B5876.6090005@cs.tcd.ie> Date: Tue, 05 Apr 2011 18:59:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] publication request for draft-josefsson-gss-capsulate-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 17:57:38 -0000 Hi All, Alexey (as shepherd) has sent me a publication request for this document [1] intended for proposed standard. I believe that the kitten WG agrees with its publication. Please let me know if there are any problems with this or if that's all ok. (A few positive acks appreciated.) Regards, Stephen. [1] http://tools.ietf.org/html/draft-josefsson-gss-capsulate-03 From ghudson@mit.edu Tue Apr 5 11:40:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF343A6977 for ; Tue, 5 Apr 2011 11:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9WWrvuRW3vu for ; Tue, 5 Apr 2011 11:40:08 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by core3.amsl.com (Postfix) with ESMTP id 90AD93A697D for ; Tue, 5 Apr 2011 11:40:07 -0700 (PDT) X-AuditID: 12074422-b7ccdae000003dab-a8-4d9b6271dd1a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id DF.1A.15787.1726B9D4; Tue, 5 Apr 2011 14:41:53 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p35IfopE015174 for ; Tue, 5 Apr 2011 14:41:50 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p35IfnaF018157 for ; Tue, 5 Apr 2011 14:41:50 -0400 (EDT) Date: Tue, 5 Apr 2011 14:41:49 -0400 (EDT) From: ghudson@MIT.EDU Message-Id: <201104051841.p35IfnaF018157@outgoing.mit.edu> To: kitten@ietf.org X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42IR4hRV1i1Mmu1rcOeupMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcf/TH5aCBdwVR+9GNzD+5uhi5OSQEDCR6J23jAXCFpO4cG89 WxcjF4eQwD5GiRf7zkM5Rxkltm5cwg7h9DJJ9PbdZepi5OBgEdCSaL1tCdLNJiAq8eHDBVaQ MK+AlcS3Q2BDRQSEJXZvfccMYgsD2avW7mGdwMi1gJFhFaNsSm6Vbm5iZk5xarJucXJiXl5q ka6pXm5miV5qSukmRpDn2F2UdjD+PKh0iFGAg1GJh3f1i5m+QqyJZcWVuYcYJTmYlER5pyTO 9hXiS8pPqcxILM6ILyrNSS0+xCjBwawkwmv6epavEG9KYmVValE+TEqag0VJnHeOpLqvkEB6 YklqdmpqQWoRTFaGg0NJglcBZKhgUWp6akVaZk4JQpqJgxNkOA/Q8AkgNbzFBYm5xZnpEPlT jLocZ69M3McoxJKXn5cqJc6bC1IkAFKUUZoHNwcWca8YxYHeEuadBVLFA4xWuEmvgJYwAS2p Vgb5oLgkESEl1cA4ZUUx2/216yumb8z79D//4tFJZ9Pyfp/v2+DyR/beEWX2x0n/vv3ctSFw 1pSU9y3BqtNFsrX/v3wy+Vdy+5U9ZTfMVr2zWL9G4mqowZ4DEZw3z/ufcwgx+VC2zeKaWUTs 2aw4BrvFrorvddkbwvPCJHcKX1FcZC/Tbd6UNv/KMTWd3+9Nvc/fVWIpzkg01GIuKk4EAFMR crWTAgAA Subject: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 18:40:09 -0000 I just merged Luke's implementation gss_userok to the MIT krb5 trunk, and Sam brought to my attention that it conflicts with the Gnu GSS version of the symbol, which has the prototype: int gss_userok(const gss_name_t name, const char *username); The version Luke committed is based on OpenSolaris's private __gss_userok(): OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name, const char *user, int *user_ok); We don't want to conflict with Shishi, but we do want the major and minor return codes; we believe an app should get "I ran into an error trying to find the answer" rather than just "no" if something goes wrong. So, our plan is to rename the symbol to gss_login_ok() and make a wrapper for the Gnu GSS gss_userok(). I think this is all pretty straightforward, but I wanted to raise the issue here in case other implementors thought we should do something different. (gss_userok/gss_login_ok are not the subject of a current work item, as far as we believe; we expect that it might be standardized in the future, and we think that the OpenSolaris version with major/minor returns is more likely to make it through standardization than the Gnu GSS version. The other open question is whether a function like this should take some kind of context argument which an application could hang configuration onto, but we don't want to solve that problem today.) From mrex@sap.com Tue Apr 5 11:54:17 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459E93A63C9 for ; Tue, 5 Apr 2011 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZNFZw-MWNnW for ; Tue, 5 Apr 2011 11:54:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 629BB3A6359 for ; Tue, 5 Apr 2011 11:54:15 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p35ItqRQ011403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Apr 2011 20:55:57 +0200 (MEST) From: Martin Rex Message-Id: <201104051855.p35Itqx2008588@fs4113.wdf.sap.corp> To: ghudson@MIT.EDU Date: Tue, 5 Apr 2011 20:55:52 +0200 (MEST) In-Reply-To: <201104051841.p35IfnaF018157@outgoing.mit.edu> from "ghudson@MIT.EDU" at Apr 5, 11 02:41:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 18:54:17 -0000 ghudson@MIT.EDU wrote: > > I just merged Luke's implementation gss_userok to the MIT krb5 trunk, > and Sam brought to my attention that it conflicts with the Gnu GSS > version of the symbol, which has the prototype: > > int gss_userok(const gss_name_t name, const char *username); > > The version Luke committed is based on OpenSolaris's private > __gss_userok(): > > OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name, > const char *user, int *user_ok); > > We don't want to conflict with Shishi, but we do want the major and > minor return codes; we believe an app should get "I ran into an error > trying to find the answer" rather than just "no" if something goes > wrong. So, our plan is to rename the symbol to gss_login_ok() and > make a wrapper for the Gnu GSS gss_userok(). > > I think this is all pretty straightforward, but I wanted to raise the > issue here in case other implementors thought we should do something > different. > > (gss_userok/gss_login_ok are not the subject of a current work item, > as far as we believe; we expect that it might be standardized in the > future, and we think that the OpenSolaris version with major/minor > returns is more likely to make it through standardization than the Gnu > GSS version. The other open question is whether a function like this > should take some kind of context argument which an application could > hang configuration onto, but we don't want to solve that problem > today.) To pass printable strings to GSS-API functions, GSS-API uses gss_buffer_t (with an explicit length field), but not "const char *user". -Martin From simon@josefsson.org Tue Apr 5 12:03:59 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6514A3A672F for ; Tue, 5 Apr 2011 12:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J97061FIdNMT for ; Tue, 5 Apr 2011 12:03:58 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 6F00F3A659A for ; Tue, 5 Apr 2011 12:03:58 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p35J5Wtr025512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Apr 2011 21:05:34 +0200 From: Simon Josefsson To: ghudson@MIT.EDU References: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110405:kitten@ietf.org::S4Yr45fYMd7H/XGX:MOk X-Hashcash: 1:22:110405:ghudson@mit.edu::PSMe8UdE5SfhFTTS:3vgh Date: Tue, 05 Apr 2011 21:05:32 +0200 In-Reply-To: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> (ghudson@mit.edu's message of "Tue, 5 Apr 2011 14:41:49 -0400 (EDT)") Message-ID: <87mxk4frib.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:03:59 -0000 ghudson@MIT.EDU writes: > I just merged Luke's implementation gss_userok to the MIT krb5 trunk, > and Sam brought to my attention that it conflicts with the Gnu GSS > version of the symbol, which has the prototype: > > int gss_userok(const gss_name_t name, const char *username); > > The version Luke committed is based on OpenSolaris's private > __gss_userok(): > > OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name, > const char *user, int *user_ok); > > We don't want to conflict with Shishi, but we do want the major and > minor return codes; we believe an app should get "I ran into an error > trying to find the answer" rather than just "no" if something goes > wrong. So, our plan is to rename the symbol to gss_login_ok() and > make a wrapper for the Gnu GSS gss_userok(). > > I think this is all pretty straightforward, but I wanted to raise the > issue here in case other implementors thought we should do something > different. That sounds good to me (thanks for renaming it rather than using the same name) -- but are you sure the semantics for these functions are the same? The documentation for my gss_userok is this: * Compare the username against the output from gss_export_name() * invoked on @name, after removing the leading OID. This answers the * question whether the particular mechanism would authenticate them * as the same principal It is thus only a convenience function that could be implemented by the application. I recall seeing some "userok" functions that did more than just name comparisons, e.g. doing some mechanism-dependennt authorization decision involving files in user's home directory. I'm not sure which semantics it is that you are after. /Simon From simon@josefsson.org Tue Apr 5 14:49:11 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261C93A67EB for ; Tue, 5 Apr 2011 14:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.36 X-Spam-Level: X-Spam-Status: No, score=-103.36 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik5XbZLCimZU for ; Tue, 5 Apr 2011 14:49:10 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id CC4463A67D8 for ; Tue, 5 Apr 2011 14:49:09 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p35LokYu005174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 5 Apr 2011 23:50:48 +0200 From: Simon Josefsson To: kitten@ietf.org References: <4D9B5876.6090005__10045.7584405833$1302026375$gmane$org@cs.tcd.ie> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110405:kitten@ietf.org::cULLfEmkDGYacyRh:03lO X-Hashcash: 1:22:110405:stephen.farrell@cs.tcd.ie::bLxt2d0m4/m7xuDb:0Szz Date: Tue, 05 Apr 2011 23:50:46 +0200 In-Reply-To: <4D9B5876.6090005__10045.7584405833$1302026375$gmane$org@cs.tcd.ie> (Stephen Farrell's message of "Tue, 05 Apr 2011 18:59:18 +0100") Message-ID: <871v1gxt8p.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Subject: Re: [kitten] publication request for draft-josefsson-gss-capsulate-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 21:49:11 -0000 All, There is a quick -04 with some minor fixes: http://tools.ietf.org/html/draft-josefsson-gss-capsulate-04 http://tools.ietf.org/rfcdiff?url2=draft-josefsson-gss-capsulate-04.txt The document now contains a test vector. I have interop tested the encapsulation and decapsulation function from Heimdal and GNU GSS as shipped with stable Debian Squeeze using the code below. /Simon /* Install required packages: # apt-get install libgss-dev heimdal-multidev Compile and run like this for GNU GSS: $ gcc -DGNU_GSS -o capsulate capsulate.c -lgss && ./capsulate OID (9 bytes): \x2a\x86\x48\x86\xf7\x12\x01\x02\x02 OUT (16 bytes): \x60\x0e\x06\x09\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x66\x6f\x6f $ Compile and run like this for Heimdal (heimdal-multidev): $ gcc -L/usr/lib/heimdal -I/usr/include/heimdal -o capsulate capsulate.c -lgssapi && ./capsulate OID (9 bytes): \x2a\x86\x48\x86\xf7\x12\x01\x02\x02 OUT (16 bytes): \x60\x0e\x06\x09\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x66\x6f\x6f $ */ #include #ifdef GNU_GSS # include #else # include #endif int main (void) { OM_uint32 maj_stat, min_stat; gss_buffer_desc tok1 = { 3, "foo" }; gss_buffer_desc tok2; gss_OID_desc oid = { 9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02" }; size_t i; printf ("OID (%d bytes): ", oid.length); for (i = 0; i < oid.length; i++) printf ("\\x%02x", ((char*) oid.elements)[i] & 0xFF); printf ("\n"); maj_stat = gss_encapsulate_token (&tok1, &oid, &tok2); if (GSS_ERROR(maj_stat)) { printf ("ERROR\n"); return 1; } printf ("ENC (%d bytes): ", tok2.length); for (i = 0; i < tok2.length; i++) printf ("\\x%02x", ((char*) tok2.value)[i] & 0xFF); printf ("\n"); if (tok2.length != 16 || memcmp (tok2.value, "\x60\x0e\x06\x09\x2a\x86\x48\x86" "\xf7\x12\x01\x02\x02\x66\x6f\x6f", 16) != 0) { printf ("FAIL\n"); return 1; } maj_stat = gss_decapsulate_token (&tok2, &oid, &tok1); if (GSS_ERROR(maj_stat)) { printf ("ERROR\n"); return 1; } printf ("DEC (%d bytes): ", tok1.length); for (i = 0; i < tok1.length; i++) printf ("\\x%02x", ((char*) tok1.value)[i] & 0xFF); printf ("\n"); if (tok1.length != 3 || memcmp (tok1.value, "foo", 3) != 0) { printf ("FAIL\n"); return 1; } gss_release_buffer (&min_stat, &tok1); gss_release_buffer (&min_stat, &tok2); return 0; } From ghudson@mit.edu Tue Apr 5 15:24:29 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BEBC3A67F3 for ; Tue, 5 Apr 2011 15:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCaapoW4mirL for ; Tue, 5 Apr 2011 15:24:28 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by core3.amsl.com (Postfix) with ESMTP id 1DE3F3A66B4 for ; Tue, 5 Apr 2011 15:24:27 -0700 (PDT) X-AuditID: 1209190f-b7cf3ae0000046b8-7c-4d9b96fd4d57 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 99.72.18104.DF69B9D4; Tue, 5 Apr 2011 18:26:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p35MQ9f2009423; Tue, 5 Apr 2011 18:26:09 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p35MPxRb006936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2011 18:26:08 -0400 (EDT) From: Greg Hudson To: Simon Josefsson In-Reply-To: <871v1gxt8p.fsf@latte.josefsson.org> References: <4D9B5876.6090005__10045.7584405833$1302026375$gmane$org@cs.tcd.ie> <871v1gxt8p.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Apr 2011 18:25:58 -0400 Message-ID: <1302042358.10465.477.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IR4hRV1v07bbavwaFVghZHN69isbi35RK7 A5PHkiU/mTxmnrnIHsAUxWWTkpqTWZZapG+XwJVxY8lExoJrTBUXehcxNjBOZupi5OSQEDCR +LnmFRuELSZx4d56IJuLQ0hgH6PEjW/P2SGc9YwSJ55NY4Fw7jJJ3Dl5mxmkRVggRGLRzj1g 7WwCyhIHz34DKuLgEBHQlJjbngESZhZQlzj6vAmshFPAUOLH/7fsILaQQLXErBv/2CFqNCVa t/8Gs1kEVCVmHVvBDjKGV0BXYsPOZAhTUOLvDmGIO6Ulvk54wgTRKS+x/e0c5gmMgrOQDJqF 0DELSdUCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuiZ6uZkleqkppZsYwaEryb+D8dtBpUOM AhyMSjy8Ic9m+gqxJpYVV+YeYpTkYFIS5Y0EBr4QX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV7T 17N8hXhTEiurUovyYVLSHCxK4ryzJNV9hQTSE0tSs1NTC1KLYLIyHBxKErxRIEMFi1LTUyvS MnNKENJMHJwgw3mAhqtOBarhLS5IzC3OTIfIn2LU5Xg7aeo+RiGWvPy8VClx3mKQQQIgRRml eXBzYCnnFaM40FvCvKIgVTzAdAU36RXQEiagJVungC0pSURISTUwZjUcUHU3/Hoj7pbQSb8H i7JD1j2SeTJVzfPrpydahuXneC5U/rshkyCnFPD6cu41wYfzDDft3DD9zOKEb/v7Qo6duf9N 074tmuGccGH3/7qpssyrXvRqWEptezvhW/3mqQW1hdk+u5btev9z5sZ1+/e9ELTl//Qm9qnq gRuv7rj+XxN9oejo0UNKLMUZiYZazEXFiQAwcx1MFAMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] publication request for draft-josefsson-gss-capsulate-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 22:24:29 -0000 On Tue, 2011-04-05 at 17:50 -0400, Simon Josefsson wrote: > The document now contains a test vector. I have interop tested the > encapsulation and decapsulation function from Heimdal and GNU GSS as > shipped with stable Debian Squeeze using the code below. Also confirmed for Luke's implementation in MIT krb5 (now on the trunk). From lukeh@padl.com Tue Apr 5 16:44:15 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930713A67ED for ; Tue, 5 Apr 2011 16:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0esS7KJWiMh for ; Tue, 5 Apr 2011 16:44:15 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 098BD3A6767 for ; Tue, 5 Apr 2011 16:44:13 -0700 (PDT) Received: by us.padl.com with ESMTP id p35NjqAx024079; Tue, 5 Apr 2011 19:45:55 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201104051841.p35IfnaF018157@outgoing.mit.edu> Date: Wed, 6 Apr 2011 09:45:52 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> To: ghudson@MIT.EDU X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:44:15 -0000 > The version Luke committed is based on OpenSolaris's private > __gss_userok(): >=20 > OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name, > const char *user, int *user_ok); Simon can correct me if I'm wrong, but there's probably more code that = uses the Sun prototype than the Shishi one (e.g. dovecot). What's the = impact of Shishi changing its prototype? -- Luke= From lukeh@padl.com Tue Apr 5 16:46:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83C43A6805 for ; Tue, 5 Apr 2011 16:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKJQ-qMrmm6k for ; Tue, 5 Apr 2011 16:46:55 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 3ACCB3A67ED for ; Tue, 5 Apr 2011 16:46:55 -0700 (PDT) Received: by us.padl.com with ESMTP id p35NmU6H029943; Tue, 5 Apr 2011 19:48:35 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <87mxk4frib.fsf@latte.josefsson.org> Date: Wed, 6 Apr 2011 09:48:29 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> <87mxk4frib.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 Cc: kitten@ietf.org, ghudson@MIT.EDU Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 23:46:56 -0000 > I recall seeing some "userok" functions that did more than just name > comparisons, e.g. doing some mechanism-dependennt authorization = decision > involving files in user's home directory. I'm not sure which = semantics > it is that you are after. The MIT and Heimdal implementations have three strategies: * mechanism specific (for the krb5 mech, krb5_aname_to_localname) * attribute based (look for a match against the local-login-user GSS = attribute) * name based (import username, canonicalize and compare) See below: /* If mech returns yes, we return yes */ major =3D mech_userok(minor, unionName, user, user_ok); if (major =3D=3D GSS_S_COMPLETE && *user_ok) return (GSS_S_COMPLETE); /* If attribute exists, we evaluate attribute */ if (attr_userok(minor, name, user, user_ok) =3D=3D = GSS_S_COMPLETE) return (GSS_S_COMPLETE); /* If mech returns unavail, we compare the local name */ if (major =3D=3D GSS_S_UNAVAILABLE) { major =3D compare_names_userok(minor, = unionName->mech_type, name, user, user_ok); } -- Luke= From lukeh@padl.com Tue Apr 5 17:21:18 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3583A6961 for ; Tue, 5 Apr 2011 17:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doZ2YQkAWEJ2 for ; Tue, 5 Apr 2011 17:21:18 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 350973A6844 for ; Tue, 5 Apr 2011 17:21:18 -0700 (PDT) Received: by us.padl.com with ESMTP id p360Mw3q003503; Tue, 5 Apr 2011 20:23:00 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Luke Howard In-Reply-To: Date: Wed, 6 Apr 2011 10:22:57 +1000 Content-Transfer-Encoding: 7bit Message-Id: <7166DE78-E501-4FA5-9174-82E141076465@padl.com> References: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> <87mxk4frib.fsf@latte.josefsson.org> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 00:21:18 -0000 > * mechanism specific (for the krb5 mech, krb5_aname_to_localname) Sorry, that should have been krb5_kuserok. -- Luke From nico@cryptonector.com Tue Apr 5 18:05:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33293A682B for ; Tue, 5 Apr 2011 18:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNve9vbVfMgs for ; Tue, 5 Apr 2011 18:05:46 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id F2DA03A67F4 for ; Tue, 5 Apr 2011 18:05:44 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 76F3043807E for ; Tue, 5 Apr 2011 18:07:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=XmrRAj5LRUSFmsIvCpKkl gsf123lAWH2GWRLFGN93GVP68zfWKmT7sfN3ocDJA/Z4iuj8//Xd9rpK4qvEQ1Z3 UwJu24Ny6mKMAgyws+ZMbkUiin0WVjdwR6tZtYA3rOkch0BD/1uodlSgRhy1UW9F ROOPkptD91n8E16hEQOaeU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=s8wdFbeCIGxFfHpk+HTh 8i9Hdx0=; b=IAjH0MDDhTClX4WCebi78H3OkImrMuKSewX50HogRYaE50SSka3G Xx2H4qWY3iSTJJv0c8cB3JReZMJcbeyQLo9I3M1p6qUbY7gBMhWhVSLc28hOJBH5 OmH1IZyid7f2PpxVaQMM5gDiZC0YUGnq7lcohrAY3c4FaciM33UxByg= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 480BB43807C for ; Tue, 5 Apr 2011 18:07:28 -0700 (PDT) Received: by vws12 with SMTP id 12so926574vws.31 for ; Tue, 05 Apr 2011 18:07:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.144 with SMTP id cm16mr591407vdb.30.1302052047713; Tue, 05 Apr 2011 18:07:27 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Tue, 5 Apr 2011 18:07:27 -0700 (PDT) In-Reply-To: <87mxk4frib.fsf@latte.josefsson.org> References: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> <87mxk4frib.fsf@latte.josefsson.org> Date: Tue, 5 Apr 2011 20:07:27 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:05:46 -0000 On Tue, Apr 5, 2011 at 2:05 PM, Simon Josefsson wrote: > That sounds good to me (thanks for renaming it rather than using the > same name) -- but are you sure the semantics for these functions are the > same? > > The documentation for my gss_userok is this: > > * Compare the username against the output from gss_export_name() How could that work?! > * invoked on @name, after removing the leading OID. This answers the > * question whether the particular mechanism would authenticate them > * as the same principal I don't follow. > It is thus only a convenience function that could be implemented by the > application. Of course. But the mechanism provider too could implement it. And so could the mechglue. The Solaris version lets the mechanism provider implement it. > I recall seeing some "userok" functions that did more than just name > comparisons, e.g. doing some mechanism-dependennt authorization decision > involving files in user's home directory. I'm not sure which semantics > it is that you are after. So, traditionally krb5_kuserok() did aname2lname and ~/.k5login processing. And I'd be happy to see any number of alternatives. The semantics of this function are that it answers with a boolean the question of "does this principal have the right to login to this local account?". Nico -- From nico@cryptonector.com Tue Apr 5 18:07:36 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36BE3A69A9 for ; Tue, 5 Apr 2011 18:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0dfCZXMhMOM for ; Tue, 5 Apr 2011 18:07:36 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id 4C5543A69A7 for ; Tue, 5 Apr 2011 18:07:36 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id CEE6D428075 for ; Tue, 5 Apr 2011 18:09:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=cK/ksHxXi5KcCJBx8RJWKsa6dfwjTmGL80myQ7yUcvrn bpiMjd3xLF9q8tFugZtcYR2OK4tq2p1+wcRhcEUIHcuYr4knR9FnauCO5qmXmXAr bvy78VU6RoTgQnsaLPsOnN7Hnw6i/hRjc7b96IQYnQUn0lV+HpMKx80QfxB+m4g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=sjt5Wf1jh5ErY51XQJYCbPKRqVU=; b=LVLTjnliXUn gt9U2vh3pFArv0EeMR8NdswISKsuk+ekKlIyH1qtwrFrdFk2svpfAlBBUxeWJlya g1lcVhjT+cDzdgDqPwlyBeHHy9nHwsEoHqkk7hNoBrZcUBHN4+nIQQmapaSMn4Iu pp6F5aBRQvynI7+l5UnnOeOImaCudpcs= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id A3ACB42806E for ; Tue, 5 Apr 2011 18:09:19 -0700 (PDT) Received: by vxg33 with SMTP id 33so912426vxg.31 for ; Tue, 05 Apr 2011 18:09:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.106 with SMTP id s10mr499542vdv.150.1302052159061; Tue, 05 Apr 2011 18:09:19 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Tue, 5 Apr 2011 18:09:19 -0700 (PDT) In-Reply-To: <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> Date: Tue, 5 Apr 2011 20:09:19 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 01:07:36 -0000 On Tue, Apr 5, 2011 at 6:45 PM, Luke Howard wrote: >> The version Luke committed is based on OpenSolaris's private >> __gss_userok(): >> >> =C2=A0OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 const char *user, int *user_ok); > > Simon can correct me if I'm wrong, but there's probably more code that us= es the Sun prototype than the Shishi one (e.g. dovecot). What's the impact = of Shishi changing its prototype? I too prefer the Solaris prototype and prefer using it with the name gss_userok(). However, this is really bikeshed painting -- whatever Greg et. al. decide will do. Nico -- From simon@josefsson.org Wed Apr 6 02:56:42 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CD03A68E6 for ; Wed, 6 Apr 2011 02:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.32 X-Spam-Level: X-Spam-Status: No, score=-103.32 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbhThrNVJ0EO for ; Wed, 6 Apr 2011 02:56:42 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A867728C105 for ; Wed, 6 Apr 2011 02:56:41 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p369wFBv007452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2011 11:58:17 +0200 From: Simon Josefsson To: Greg Hudson References: <4D9B5876.6090005__10045.7584405833$1302026375$gmane$org@cs.tcd.ie> <871v1gxt8p.fsf@latte.josefsson.org> <1302042358.10465.477.camel__43123.9107427702$1302042385$gmane$org@t410> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110406:ghudson@mit.edu::9zGT7pKFWMUofiEN:03WY X-Hashcash: 1:22:110406:kitten@ietf.org::wFLqzfDnUDI7jOKV:v4ii Date: Wed, 06 Apr 2011 11:58:15 +0200 In-Reply-To: <1302042358.10465.477.camel__43123.9107427702$1302042385$gmane$org@t410> (Greg Hudson's message of "Tue, 05 Apr 2011 18:25:58 -0400") Message-ID: <87oc4jwvk8.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" Subject: Re: [kitten] publication request for draft-josefsson-gss-capsulate-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 09:56:42 -0000 Greg Hudson writes: > On Tue, 2011-04-05 at 17:50 -0400, Simon Josefsson wrote: >> The document now contains a test vector. I have interop tested the >> encapsulation and decapsulation function from Heimdal and GNU GSS as >> shipped with stable Debian Squeeze using the code below. > > Also confirmed for Luke's implementation in MIT krb5 (now on the trunk). Thanks! /Simon From simon@josefsson.org Wed Apr 6 03:00:10 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6686C28C11A for ; Wed, 6 Apr 2011 03:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22I0Xwz5ymS9 for ; Wed, 6 Apr 2011 03:00:03 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 893BF28C11E for ; Wed, 6 Apr 2011 03:00:01 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p36A1a9P007691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2011 12:01:38 +0200 From: Simon Josefsson To: Luke Howard References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4__25717.4000762918$1302047172$gmane$org@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110406:ghudson@mit.edu::6w1qkpiiV+RNCrTx:rIl X-Hashcash: 1:22:110406:kitten@ietf.org::Assivp6sZPlqFxw2:2M5z X-Hashcash: 1:22:110406:lukeh@padl.com::XB/0zed6TIUGt83N:6z0k Date: Wed, 06 Apr 2011 12:01:36 +0200 In-Reply-To: <359CEB20-FE64-45E7-963B-22896B77E8F4__25717.4000762918$1302047172$gmane$org@padl.com> (Luke Howard's message of "Wed, 6 Apr 2011 09:45:52 +1000") Message-ID: <87k4f7wven.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, ghudson@MIT.EDU Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 10:00:10 -0000 Luke Howard writes: >> The version Luke committed is based on OpenSolaris's private >> __gss_userok(): >> >> OM_uint32 __gss_userok(OM_uint32 *minor, const gss_name_t name, >> const char *user, int *user_ok); > > Simon can correct me if I'm wrong, but there's probably more code that > uses the Sun prototype than the Shishi one (e.g. dovecot). What's the > impact of Shishi changing its prototype? Fixing that would require an ABI incompatible library release, with all the pains that goes with that. I'd prefer to avoid that unless there are compelling reasons. All code that is using the Sun prototype needs to be updated anyway, as far as I can tell: they call it __gss_userok and not gss_userok. When updating that code, it is equally hard to do s/__gss_userok/gss_loginok/ as it is to do s/__gss_userok/gss_userok/. So I'm not sure what would be gained by adding a new symbol gss_userok that would be incompatible with GNU GSS? /Simon From stephen.farrell@cs.tcd.ie Wed Apr 6 05:17:42 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC94A3A68BC for ; Wed, 6 Apr 2011 05:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnNcwQwc5by7 for ; Wed, 6 Apr 2011 05:17:41 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id 5125E3A67B3 for ; Wed, 6 Apr 2011 05:17:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 14D713E4089 for ; Wed, 6 Apr 2011 13:19:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1302092359; bh=GtNG5qEDFXRvlk6DxRYq7YkS xclzMfe6SGaMHJjjJ/I=; b=ORnWgYeZHIwVWpO6EfLV5MqNtmlpt4pSgOZ18qln U0GE+LmQEy1QkSwgJ36ofE4VQcj5PPus3JxHggNOiEi1x6QDlwdXGiZplgk39079 3t5jIaZJHxWeTG4urSZHzcxrDWGtwFjod3gie9QkQCuuLvIdLRh6/MgmWURlwGvP jnYRiDzB4jrGPghuoRcYLiE6sv/izQtcUH453qYNjITvy51ht1yOwz3uFIuQRpNq nVHvqqrvdgARejGcdTzMa2Es5Y7haN/IHtwTsZK45ow+GxrTzVGHTEhIAYq5ASEx 2WddoNqq0j9WcK2vqxRIM7O4SduDjuXT7vm5bG5B0Cr2Ww== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id lKTHv3GwIXqE for ; Wed, 6 Apr 2011 13:19:19 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6D8633E4082 for ; Wed, 6 Apr 2011 13:19:19 +0100 (IST) Message-ID: <4D9C5A47.5050305@cs.tcd.ie> Date: Wed, 06 Apr 2011 13:19:19 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: RE: [Editorial Errata Reported] RFC2743 (2758) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 12:17:43 -0000 Hi all, Martin filed an erratum on gssapi and John agrees that its correct, so I plan to approve and mark it as "hold for document update" tomorrow. Yell if that's wrong. Thanks, S. -------- Original Message -------- Subject: RE: [Editorial Errata Reported] RFC2743 (2758) Date: Wed, 6 Apr 2011 08:12:56 -0400 From: To: , CC: , , My understanding at this point is that Martin's erratum is correct as written, and that it should be taken into account if and when RFC-2743 is revised under kitten wg auspices. I haven't been involved in kitten wg discussion, however, and don't know whether any rationale has been raised there which might modify this conclusion. --jl -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, April 06, 2011 7:14 AM To: Linn, John; mrex@sap.com Cc: rfc-editor@rfc-editor.org; turners@ieca.com; tim.polk@nist.gov Subject: Re: [Editorial Errata Reported] RFC2743 (2758) Martin, John, Do you have consensus on whether I ought approve this erratum or not, or if the text describing the issue needs changing? Or, do we need to ask the kitten wg about it? If approved, I assume the right thing here is hold-for-document update? Thanks, Stephen. On 01/04/11 19:33, john.linn@rsa.com wrote: > Greetings, Martin. > > It seems to me that the text in RFC-2743, 2.1.4, in the description of GSS_S_COMPLETE status: "that the resulting credential from GSS_Add_cred() is ... suitable for the usage requested in cred_usage" is consistent with your erratum about a returned cred_usage value. If the available cred_usage doesn't match the set requested, then the call would fail with some status other than GSS_S_COMPLETE. So, I'm not now seeing the need for such an output value. I'd expect that the bindings spec would have inherited that behavior by reference, rather than defining it differently, but could again be surprised. Does any subsequent work in Kitten speak to this question? > > --jl > > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Friday, April 01, 2011 1:48 PM > To: Linn, John > Cc: rfc-editor@rfc-editor.org; stephen.farrell@cs.tcd.ie; turners@ieca.com; tim.polk@nist.gov > Subject: Re: [Editorial Errata Reported] RFC2743 (2758) > > Hi John, > > john.linn@rsa.com wrote: >> >> This is an interesting surprise after 11 years. I haven't been involved >> with GSS-API implementations recently, and don't know whether any >> deployments actually output cred_usage and/or mech_set as described. >> That said, it does appear (per RFC-2743, 2.1.4, and without now >> reviewing broader context) that mech_set would be redundant given >> actual_mechs, and that a cred_usage output would be redundant given >> that GSS_S_COMPLETE status asserts that the requested input >> cred_usage choices are available. > > What I've reported is a difference between GSS-API high-leval (rfc2743) > and GSS-API C-Bindings (rfc2744). > > But after searching through my CAT archives, I found the following > discussion refering to a cred_usage output parameter for gss_add_cred() > > From: Carlisle Adams > To: , Graham Bland > Subject: RE: GSS and IDUP > Date: Mon, 23 Mar 1998 18:20:50 -0500 > Message-Id: > > =Credentials and Usage > = ---------------------------------- > =1. > =The GSS C Bindings define 'cred_usage' as input only for both > =gss_acquire_cred and gss_add_cred. It does not comment on what should > =happen if only a subset of the usage is available (e.g, if BOTH is > =requested and only INITIATE is available, should that generate a > =GSS_C_NO_CRED?). > > (This is a GSS C-bindings issue.) > > =Thus, both acquire_cred and add_cred should have 'actual_cred_usage' output > =parameters. The latter is a change to the c-bindings only, bringing it in > =line with the GSS spec, the former deviates from both. However without some > =sort of resolution in this area, any application that wishes use GSS and > =IDUP would have to maintain separate credentials for each, negating much of > =the value of a core set of credential management functions. > > Done (see p.44). > > And GSS-IDUP has an acquire_cred (not add_cred) call with seperate > cred_usage input and output parameters: > > http://tools.ietf.org/html/rfc2479#page-49 > > > The purpose of mech_set in presence of actual_mechs seems less clear. > > -Martin > > > >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Tuesday, March 29, 2011 6:22 PM >> To: stephen.farrell@cs.tcd.ie; turners@ieca.com; tim.polk@nist.gov; Linn, John >> Cc: mrex@sap.com; rfc-editor@rfc-editor.org >> Subject: [Editorial Errata Reported] RFC2743 (2758) >> >> >> The following errata report has been submitted for RFC2743, >> "Generic Security Service Application Program Interface Version 2, Update 1". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=2743&eid=2758 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Martin Rex >> >> Section: 2.1.4 >> >> Original Text >> ------------- >> o actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must >> -- release with GSS_Release_oid_set() >> >> o initiator_time_rec INTEGER -- in seconds, or reserved value for >> -- INDEFINITE >> >> o acceptor_time_rec INTEGER -- in seconds, or reserved value for >> -- INDEFINITE >> >> o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, >> -- 2=ACCEPT-ONLY >> >> o mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms >> -- supported by resulting credential. >> >> Return major_status codes: >> >> >> Corrected Text >> -------------- >> o actual_mechs SET OF OBJECT IDENTIFIER, -- full set of mechanisms >> -- supported by resulting credential. If returned, caller must >> -- release with GSS_Release_oid_set() >> >> o initiator_time_rec INTEGER -- in seconds, or reserved value for >> -- INDEFINITE >> >> o acceptor_time_rec INTEGER -- in seconds, or reserved value for >> -- INDEFINITE >> >> Return major_status codes: >> >> >> Notes >> ----- >> There appears to be accidentally duplicated text trailing the list of output parameters in section 2.1.4: GSS_Add_cred call (top of page 38). >> >> The parameter "cred_usage" is an input-only parameter and also listed under input parameters, and the parameter "mech_set" is a duplicate of the actual_mechs output parameter. Compare GSS-API C-Bindings document rfc2744, section 5.3. gss_add_cred >> >> -Martin >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC2743 (draft-ietf-cat-rfc2078bis-08) >> -------------------------------------- >> Title : Generic Security Service Application Program Interface Version 2, Update 1 >> Publication Date : January 2000 >> Author(s) : J. Linn >> Category : PROPOSED STANDARD >> Source : Common Authentication Technology >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> >> > > From hartmans@mit.edu Wed Apr 6 07:44:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E305A28C0D8 for ; Wed, 6 Apr 2011 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZBgyrJWgzZt for ; Wed, 6 Apr 2011 07:44:31 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0C89C28C0D0 for ; Wed, 6 Apr 2011 07:44:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6474A20228; Wed, 6 Apr 2011 10:42:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DD680446E; Wed, 6 Apr 2011 10:46:11 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> Date: Wed, 06 Apr 2011 10:46:11 -0400 In-Reply-To: (Nico Williams's message of "Tue, 5 Apr 2011 20:09:19 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:44:32 -0000 >>>>> "Nico" == Nico Williams writes: Nico> I too prefer the Solaris prototype and prefer using it with Nico> the name gss_userok(). However, this is really bikeshed Nico> painting -- whatever Greg et. al. decide will do. I don't like any of the existing prototypes, but will live with the Solaris prototype. I expect to propose an expanded prototype on the order of a year or so. I prefer that we not stop on Simon's prototype and would recommend that implementations implement Simon's prototype as a wrapper. From simon@josefsson.org Wed Apr 6 07:59:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3563A69BB for ; Wed, 6 Apr 2011 07:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.251 X-Spam-Level: X-Spam-Status: No, score=-103.251 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BR7wbpxhDPl for ; Wed, 6 Apr 2011 07:59:24 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id D11843A693C for ; Wed, 6 Apr 2011 07:59:23 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p36F0uqf021706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2011 17:00:58 +0200 From: Simon Josefsson To: Sam Hartman References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110406:kitten@ietf.org::F8LJlTI0bnb95NkM:0JKl X-Hashcash: 1:22:110406:hartmans-ietf@mit.edu::JhTIA3C7FGZ4Qwy2:BhRD X-Hashcash: 1:22:110406:nico@cryptonector.com::r7yutBWGe/OE4/PT:YksW Date: Wed, 06 Apr 2011 17:00:56 +0200 In-Reply-To: (Sam Hartman's message of "Wed, 06 Apr 2011 10:46:11 -0400") Message-ID: <87fwpvzaon.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 14:59:24 -0000 Sam Hartman writes: >>>>>> "Nico" == Nico Williams writes: > > > Nico> I too prefer the Solaris prototype and prefer using it with > Nico> the name gss_userok(). However, this is really bikeshed > Nico> painting -- whatever Greg et. al. decide will do. > > I don't like any of the existing prototypes, but will live with the > Solaris prototype. > I expect to propose an expanded prototype on the order of a year or so. Then it sounds as if this is not something that we want to standardize at all at this point? > I prefer that we not stop on Simon's prototype and would recommend that > implementations implement Simon's prototype as a wrapper. Given the questions about different semantics of the interfaces, maybe it is not useful to coordinate even that. This interface and password prompting are the two most important GSS-API additions that I'd like to see standardized. /Simon From simon@josefsson.org Wed Apr 6 08:08:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3633C3A69C7 for ; Wed, 6 Apr 2011 08:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDbmSjDpZ0kx for ; Wed, 6 Apr 2011 08:08:08 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id D4F973A69C2 for ; Wed, 6 Apr 2011 08:08:07 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p36F9ln8021954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Apr 2011 17:09:48 +0200 From: Simon Josefsson To: kitten@ietf.org References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf__24773.333388339$1302102086$gmane$org@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110406:kitten@ietf.org::mR5MHZwCHDs9xKrE:5Etl X-Hashcash: 1:22:110406:hartmans-ietf@mit.edu::Bp6PA0ef31sted1y:32DN Date: Wed, 06 Apr 2011 17:09:47 +0200 In-Reply-To: <87fwpvzaon.fsf__24773.333388339$1302102086$gmane$org@latte.josefsson.org> (Simon Josefsson's message of "Wed, 06 Apr 2011 17:00:56 +0200") Message-ID: <878vvnza9w.fsf_-_@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Subject: [kitten] SCRAM as GSS mech X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:08:09 -0000 Simon Josefsson writes: > This interface and password prompting are the two most important GSS-API > additions that I'd like to see standardized. Password prompting is the main reason I have not implemented SCRAM as a GSS-API mechanism. Has anyone implemented SCRAM for GSS-API in any way that makes sense for a reasonable application? If so, how do you handle password prompts on the client side, and password/verifier storage on the server side? I have considered using a gnupg-agent/pinentry style approach to let the GSS-API library directly query the user for a password on the client side without the application knowing, but until I have figured out how to resolve the same problem on the server side, I don't want to write the implementation. /Simon From lukeh@padl.com Wed Apr 6 08:15:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99ED828C0DB for ; Wed, 6 Apr 2011 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lzj3lIsjgE5Q for ; Wed, 6 Apr 2011 08:15:55 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id A8F6328B23E for ; Wed, 6 Apr 2011 08:15:52 -0700 (PDT) Received: by us.padl.com with ESMTP id p36FHST4028410; Wed, 6 Apr 2011 11:17:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 7 Apr 2011 01:17:27 +1000 Content-Transfer-Encoding: 7bit Message-Id: <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:15:55 -0000 > I don't like any of the existing prototypes, but will live with the > Solaris prototype. > I expect to propose an expanded prototype on the order of a year or so. OK, how about this then? int gss_userok(const gss_name_t name, const char *username); typedef struct gss_userok_config *gss_userok_config_t; #define GSS_C_USEROK_NO_CONFIG ((gss_userok_config_t) 0) OM_uint32 gss_userok_ext(OM_uint32 *minor, const gss_name_t name, gss_const_buffer_t user, const gss_userok_config_t config, int *user_ok); -- Luke From lukeh@padl.com Wed Apr 6 08:26:36 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9980D28C10A for ; Wed, 6 Apr 2011 08:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbpBLmBg03pc for ; Wed, 6 Apr 2011 08:26:36 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id E2F5E28B23E for ; Wed, 6 Apr 2011 08:26:35 -0700 (PDT) Received: by us.padl.com with ESMTP id p36FRqWc023746; Wed, 6 Apr 2011 11:27:55 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Luke Howard In-Reply-To: <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> Date: Thu, 7 Apr 2011 01:27:51 +1000 Content-Transfer-Encoding: 7bit Message-Id: <94C163BF-0F57-4CED-9547-59D01A774FD4@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:26:36 -0000 > OM_uint32 > gss_userok_ext(OM_uint32 *minor, ^^^ Keep Simon/Nico/Greg happy > const gss_name_t name, > gss_const_buffer_t user, ^^^ Keep Martin happy > const gss_userok_config_t config, ^^^ Keep Sam happy :-) -- Luke From ghudson@mit.edu Wed Apr 6 08:28:20 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1DAB3A6878 for ; Wed, 6 Apr 2011 08:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxgHtF3mOZC8 for ; Wed, 6 Apr 2011 08:28:18 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 72A163A67E7 for ; Wed, 6 Apr 2011 08:28:18 -0700 (PDT) X-AuditID: 1209190c-b7b7aae0000047c7-8b-4d9c86fe619a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 62.33.18375.EF68C9D4; Wed, 6 Apr 2011 11:30:06 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p36FU0r6028256; Wed, 6 Apr 2011 11:30:00 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p36FTtWY017939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 11:30:00 -0400 (EDT) From: Greg Hudson To: Simon Josefsson In-Reply-To: <87mxk4frib.fsf@latte.josefsson.org> References: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> <87mxk4frib.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Apr 2011 11:29:55 -0400 Message-ID: <1302103795.10465.494.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYrdT1/3XNsfX4OcyXYujm1exWNzbcond gcljyZKfTB4zz1xkD2CK4rJJSc3JLEst0rdL4Mp48eskW8FnzorvZzYxNzA2cnQxcnJICJhI HDx5nhXCFpO4cG89WxcjF4eQwD5Gia1/3rNDOOsZJX7Ou8kOUiUkcJdJYuZ6AxBbWEBB4vus 7YwgNpuAssTBs99Yuhg5OEQENCXmtmeAhJkF1CWOPm9iA7E5BQwlTu56zAIxs5dRovlYCytE kaZE6/bfYPNZBFQlHs67xwYyh1dAV2LqvGoIU1Di7w5hiDulJb5OeMIE0Skvsf3tHOYJjIKz kAyahdAxC0nVAkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbqGermZJXqpKaWbGEGhyynJs4Px zUGlQ4wCHIxKPLxLF8/2FWJNLCuuzD3EKMnBpCTKm9E6x1eILyk/pTIjsTgjvqg0J7X4EKME B7OSCK/p61m+QrwpiZVVqUX5MClpDhYlcd4Zkuq+QgLpiSWp2ampBalFMFkZDg4lCV4NYIwK CRalpqdWpGXmlCCkmTg4QYbzAA2XAanhLS5IzC3OTIfIn2I05jh7ZeI+Ro63k6buYxRiycvP S5US5zUGKRUAKc0ozYObBks/rxjFgZ4T5pUHqeIBpi64ea+AVjEBrdo6ZTbIqpJEhJRUA2N1 94OzzTFCBgtnqVX0X142M5LXOo/nSOdyLum9Z4QqXh1cdeG2yvNtTBdtjmnsnJEZNLXLakVa f2/e0wS2xoRvyvWTdRPUVffZBq02/sTmZzw99XtZ5GGZl5rfz7P292iUn3r0r1ZZpjX4ps7d xnkOB4Lu/i7vXqMoKRftmHonTND8cWxwrhJLcUaioRZzUXEiAPNS8KMaAwAA Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:28:20 -0000 On Tue, 2011-04-05 at 15:05 -0400, Simon Josefsson wrote: > That sounds good to me (thanks for renaming it rather than using the > same name) -- but are you sure the semantics for these functions are the > same? No, which argues against creating a wrapper for your prototype. However, I'm confused about your semantics. First, why are you specifying the implementation of the function as part of the API contract? Does the app want to know how the decision is made, or does it just want to ask a question (is this MN authorized to login as this user according to the mechanism's logic)? Second, to the best of my understanding, gss_export_name() isn't intended to output anything like a username (with OID prefix). It's just intended to produce a string which compares equal to the same name exported within another process. So if you are going to specify the function's implementation, the specification you chose doesn't seem conceptually consistent with the design of GSSAPI. Sun's fallback if the mech doesn't implement a userok handler seems more consistent: 1. gss_import_name() username with name type GSS_C_NT_USER_NAME 2. gss_canonicalize_name() the result with name's mech 3. gss_compare_name() the result to name From nico@cryptonector.com Wed Apr 6 08:30:37 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867D93A67E7 for ; Wed, 6 Apr 2011 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnljSFYJmmGk for ; Wed, 6 Apr 2011 08:30:36 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id DEB3D28C11B for ; Wed, 6 Apr 2011 08:30:36 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id B9A2F768061 for ; Wed, 6 Apr 2011 08:32:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Pl+1TZofq9YT5ZUGDsqpFL7kM2oOJ2ginNR2GNoxQr3p RYNOSpmp8OGuZhElAqqMzNjsxTabSxTvuKhIhpTiS+s5KrH/t1W1FmWe3Vp+hgHd KUV8fjS+0yf7caaITR63POMKHyqZak13zCJ+U12vDh1AJEbuXiHM7rn/5YP0//8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=IftNkNTPvc95Hzoi7oNwKaqcU+c=; b=a/Vc4gZuT9V p6Y8DP0G0fb3ce1Ek5Ne9j60g9o59/MFpOnhBR9TDRWsSgR9I/e0nzeFtlBCWyI+ e1rnHpEvMwtw3HMSoBjh/Mwla4T0GG7XWHkLqrRi9+zg+mIlfQHJW906VJknRPNx r/rkQpq+AVt8JafifXgBfQotn+9z9ODU= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 8750A768064 for ; Wed, 6 Apr 2011 08:32:20 -0700 (PDT) Received: by vws12 with SMTP id 12so1481525vws.31 for ; Wed, 06 Apr 2011 08:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr1541629vdb.270.1302103939950; Wed, 06 Apr 2011 08:32:19 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 08:32:19 -0700 (PDT) In-Reply-To: <87fwpvzaon.fsf@latte.josefsson.org> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> Date: Wed, 6 Apr 2011 10:32:19 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:30:37 -0000 On Wed, Apr 6, 2011 at 10:00 AM, Simon Josefsson wrot= e: > Sam Hartman writes: >>>>>>> "Nico" =3D=3D Nico Williams writes: >> >> >> =C2=A0 =C2=A0 Nico> I too prefer the Solaris prototype and prefer using = it with >> =C2=A0 =C2=A0 Nico> the name gss_userok(). =C2=A0However, this is really= bikeshed >> =C2=A0 =C2=A0 Nico> painting -- whatever Greg et. al. decide will do. >> >> I don't like any of the existing prototypes, but will live with the >> Solaris prototype. >> I expect to propose an expanded prototype on the order of a year or so. > > Then it sounds as if this is not something that we want to standardize > at all at this point? I don't see why we wouldn't standardize it. >> I prefer that we not stop on Simon's prototype and would recommend that >> implementations implement Simon's prototype as a wrapper. > > Given the questions about different semantics of the interfaces, maybe > it is not useful to coordinate even that. I've seen no questions about semantics. The semantics are simple: the function answers this question: "is this principal allowed to login to this local user account?". The specific mechanical details of how that question is answered do not fall under "semantics". > This interface and password prompting are the two most important GSS-API > additions that I'd like to see standardized. For me they are among many. From nico@cryptonector.com Wed Apr 6 08:32:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5A33A69CC for ; Wed, 6 Apr 2011 08:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei81gKTJ2-kJ for ; Wed, 6 Apr 2011 08:32:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 1ADF93A67E7 for ; Wed, 6 Apr 2011 08:32:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 14DD26B007B for ; Wed, 6 Apr 2011 08:34:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XJzqKp8n+jIAkJqTU+ekaYGCgbLgUO3dzbR5GHv21+rD wCTDVCPAFbptE5Y4Pm37lgkzvlTWpLo2nF7WwJAhegR4ug/sf09RnPuwDrZiM7/o j5H4NWxflG4c89hj5j+us/dS7m0SMOJmvUqgD53Gsx40Up41DPs0br5dJmuQ2XA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=MOzkmNTx0Qe6ivOJ9Dq0cKTPPcI=; b=EZw/AKaUKh1 fXj1BhjHhnKuOWdNmNM4Nm+wzDaIIaINNAwicaDQ++PDdHYrZ0+kdcU6NzbZIWfT LfMFVqqJpg17O8hZLjnjbgTPYShFNULyK0MDX1sz1UmltDZdEuBPYjsX2ENg7MmN oU6v2H2XSY0TvoLHPwHJMFg2xfHenLuQ= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id D23966B0079 for ; Wed, 6 Apr 2011 08:34:21 -0700 (PDT) Received: by vxg33 with SMTP id 33so1469989vxg.31 for ; Wed, 06 Apr 2011 08:34:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr1545147vdb.270.1302104061209; Wed, 06 Apr 2011 08:34:21 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 08:34:21 -0700 (PDT) In-Reply-To: <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> Date: Wed, 6 Apr 2011 10:34:21 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:32:38 -0000 On Wed, Apr 6, 2011 at 10:17 AM, Luke Howard wrote: >> I don't like any of the existing prototypes, but will live with the >> Solaris prototype. >> I expect to propose an expanded prototype on the order of a year or so. > > OK, how about this then? > > int > gss_userok(const gss_name_t name, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const char *username); > > typedef struct gss_userok_config *gss_userok_config_t; > > #define GSS_C_USEROK_NO_CONFIG ((gss_userok_config_t) 0) > > OM_uint32 > gss_userok_ext(OM_uint32 *minor, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const gss_name_t name, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 gss_const_buffer_t user, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const gss_userok_config_= t config, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int *user_ok); What would the config argument be for? How do you acquire any values for it other than the NO_CONFIG one? I'd rather avoid adding such arguments until we need them. If this about Simon's question regarding semantics, no I don't think it's important, because be details of how this function works are implementation-specific. Nico -- From simon@josefsson.org Wed Apr 6 08:36:32 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED99A28C11B for ; Wed, 6 Apr 2011 08:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1AgAA+SJ4Eg for ; Wed, 6 Apr 2011 08:36:31 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id D94173A6945 for ; Wed, 6 Apr 2011 08:36:30 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p36Fc5Mt023314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2011 17:38:07 +0200 From: Simon Josefsson To: Nico Williams References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110406:kitten@ietf.org::TgbWAYRLY59eJ9lR:3fSc X-Hashcash: 1:22:110406:lukeh@padl.com::tfZ58D9Sxt4+dUau:6r7f X-Hashcash: 1:22:110406:hartmans-ietf@mit.edu::Kn3vp20cSM1jxmrt:6DMb X-Hashcash: 1:22:110406:nico@cryptonector.com::g2DFdcnYUG3sD3le:BfK4 Date: Wed, 06 Apr 2011 17:38:05 +0200 In-Reply-To: (Nico Williams's message of "Wed, 6 Apr 2011 10:34:21 -0500") Message-ID: <87wrj7xuea.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:36:32 -0000 Nico Williams writes: > On Wed, Apr 6, 2011 at 10:17 AM, Luke Howard wrote: >>> I don't like any of the existing prototypes, but will live with the >>> Solaris prototype. >>> I expect to propose an expanded prototype on the order of a year or so. >> >> OK, how about this then? >> >> int >> gss_userok(const gss_name_t name, >>           const char *username); >> >> typedef struct gss_userok_config *gss_userok_config_t; >> >> #define GSS_C_USEROK_NO_CONFIG ((gss_userok_config_t) 0) >> >> OM_uint32 >> gss_userok_ext(OM_uint32 *minor, >>               const gss_name_t name, >>               gss_const_buffer_t user, >>               const gss_userok_config_t config, >>               int *user_ok); > > What would the config argument be for? How do you acquire any values > for it other than the NO_CONFIG one? > > I'd rather avoid adding such arguments until we need them. If this > about Simon's question regarding semantics, no I don't think it's > important, because be details of how this function works are > implementation-specific. So we are back to something like this then? OM_uint32 gss_loginok(OM_uint32 *minor, gss_const_name_t name, gss_const_buffert_t user, int *user_ok); /Simon From nico@cryptonector.com Wed Apr 6 08:37:13 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C1E28C11A for ; Wed, 6 Apr 2011 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VflCLCiGCNBc for ; Wed, 6 Apr 2011 08:37:13 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 351F528B23E for ; Wed, 6 Apr 2011 08:37:13 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 5975D76805C for ; Wed, 6 Apr 2011 08:38:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=UwPhJ1IEn2FgrNScZMKkT iNc7iexRueHuGjIIlU6YU5u9kjkgyOyzhEEEWTTAYfYsnDZfK1AQdBaCDxC3kMo/ /kh3TdaVCLLbQ7HFz0FAN1WwRf/5AiKVfQbB96Y61My9WcRpmjtFdzUbJdRtyqIy AnjVCvs4MPFfDhqWrA0MN8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XQdzuLCJG4RhE7go/9t6 gpFHXpU=; b=WY4/qAS2ApfHP6EyyJiBsMIiNwTXYRrJxPV4sfMsE8feve13znOo /9eMXZqG2BaUamjTK4ugNLZXhHqsPT6Xo6VRRwedmdZaJHsV21SK3Nf1Hg/sPuZg 9THWN5VhmtEQSy/XQoIS3nsC6x915h5aiV066sxvcmBudF16/NtiGnc= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 2CBC5768059 for ; Wed, 6 Apr 2011 08:38:57 -0700 (PDT) Received: by vws12 with SMTP id 12so1488310vws.31 for ; Wed, 06 Apr 2011 08:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.144 with SMTP id cm16mr1674181vdb.30.1302104336580; Wed, 06 Apr 2011 08:38:56 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 08:38:56 -0700 (PDT) In-Reply-To: <1302103795.10465.494.camel@t410> References: <201104051841.p35IfnaF018157__28211.9873598733$1302028926$gmane$org@outgoing.mit.edu> <87mxk4frib.fsf@latte.josefsson.org> <1302103795.10465.494.camel@t410> Date: Wed, 6 Apr 2011 10:38:56 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:37:14 -0000 On Wed, Apr 6, 2011 at 10:29 AM, Greg Hudson wrote: > However, I'm confused about your semantics. First, why are you > specifying the implementation of the function as part of the API > contract? Does the app want to know how the decision is made, or does > it just want to ask a question (is this MN authorized to login as this > user according to the mechanism's logic)? > > Second, to the best of my understanding, gss_export_name() isn't > intended to output anything like a username (with OID prefix). It's > just intended to produce a string which compares equal to the same name > exported within another process. So if you are going to specify the > function's implementation, the specification you chose doesn't seem > conceptually consistent with the design of GSSAPI. Sun's fallback if > the mech doesn't implement a userok handler seems more consistent: I made this point too. If it doesn't work in Shishi (and I fail to see how it works as described, but then, I suspect Simon just flubbed the description) then I'll be much less inclined to accept the Shishi prototype. But also, quite separately, the specific details of how the function works are implementation-specific -- what matters is what the function is supposed to do, not how it works. BTW, we really need to get the IANA registry going. These sorts of conflicts will only arise more often now that we have so many GSS mechglues (Shishi, MIT, Heimdal, and Solaris'). Nico -- From lukeh@padl.com Wed Apr 6 08:37:32 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9A928C10A for ; Wed, 6 Apr 2011 08:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPBuZMWzw3Qn for ; Wed, 6 Apr 2011 08:37:31 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id B87A928B23E for ; Wed, 6 Apr 2011 08:37:31 -0700 (PDT) Received: by us.padl.com with ESMTP id p36Fd6R6020349; Wed, 6 Apr 2011 11:39:10 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 7 Apr 2011 01:39:05 +1000 Content-Transfer-Encoding: 7bit Message-Id: <827D64AE-54FE-4041-BF24-A5EA70A6300E@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:37:32 -0000 > What would the config argument be for? How do you acquire any values > for it other than the NO_CONFIG one? To be specified. From Sam: > Nico, I was talking to Luke about gss_userok. > > I was thinking that it wanted to take a context for configuration so, > add an input of a gss_userok_config_t, today only defining > GSS_C_USEROK_NO_CONFIG. > > I'm thinking we might want a number of configuration options in the > future: > n > 1) Whether fallback to aname == lname is permitted? > > 2) Whether to search for things like .k5login > > 3) what mechanisms to allow authorization from. > > I'm not sure whether we actually want those or not, but I think that's > compelling enough to argue for extensible configuration. > > We need to change the symbol name anyway because we don't want to make > either gssint or __gss_ symbols public. > > What are your thoughts? -- Luke From nico@cryptonector.com Wed Apr 6 08:39:13 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9AF3A6947 for ; Wed, 6 Apr 2011 08:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HNQNBdwMaYU for ; Wed, 6 Apr 2011 08:39:13 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 3760C3A6945 for ; Wed, 6 Apr 2011 08:39:13 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 5007876806B for ; Wed, 6 Apr 2011 08:40:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=oOCWRx8ZIhvaLq32tbn8H 3AbVAGPF5EeQ1CutvfEqAYfaeFo/NZr9Stm84Pso38OHIRExxpBksheaN8Opuxo4 g1wWvbDHIxc4DqPuX5hhcXlRxUwowv8Dd2JAMIzm07sSHZqxp7x2KQcKWE5JiHbU J5o63NIWdGAt+eP6ig3EaY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=boPahF6pU+/6PDgTpBem pmZ4pog=; b=kCCWMLMYVtRllS4qamHJ8Xy14ce2ghIE5Gp1D0WdnEJHAivQp+m0 I/gMz4dFQBDKHOOSGPnb2m4eRJ5JXIADRcsxr6R7g+GjUHQjBY3ItPpyRYW1SXdw 4w9Ge0LGrhby5wlArdW68jDUzEbC5EUm5OdpPcQ7AC6FDKep7dTRGy4= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 1C92676805C for ; Wed, 6 Apr 2011 08:40:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so1476567vxg.31 for ; Wed, 06 Apr 2011 08:40:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1664164vdg.70.1302104456506; Wed, 06 Apr 2011 08:40:56 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 08:40:56 -0700 (PDT) In-Reply-To: <827D64AE-54FE-4041-BF24-A5EA70A6300E@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> <827D64AE-54FE-4041-BF24-A5EA70A6300E@padl.com> Date: Wed, 6 Apr 2011 10:40:56 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 15:39:13 -0000 On Wed, Apr 6, 2011 at 10:39 AM, Luke Howard wrote: > >> What would the config argument be for? How do you acquire any values >> for it other than the NO_CONFIG one? > > To be specified. From Sam: > >> Nico, I was talking to Luke about gss_userok. >> >> I was thinking that it wanted to take a context for configuration so, >> add an input of a gss_userok_config_t, today only defining >> GSS_C_USEROK_NO_CONFIG. >> >> I'm thinking we might want a number of configuration options in the >> future: To me these are host configuration matters, not ones that the app should specify. From hartmans@mit.edu Wed Apr 6 09:03:59 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2543A6947 for ; Wed, 6 Apr 2011 09:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGSsHnoeAwna for ; Wed, 6 Apr 2011 09:03:58 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9BD6C3A69CC for ; Wed, 6 Apr 2011 09:03:57 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6D74120228; Wed, 6 Apr 2011 12:02:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A57D446E; Wed, 6 Apr 2011 12:05:40 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> Date: Wed, 06 Apr 2011 12:05:40 -0400 In-Reply-To: <87fwpvzaon.fsf@latte.josefsson.org> (Simon Josefsson's message of "Wed, 06 Apr 2011 17:00:56 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:03:59 -0000 >>>>> "Simon" == Simon Josefsson writes: Simon> Sam Hartman writes: >>>>>>> "Nico" == Nico Williams writes: >> >> Nico> I too prefer the Solaris prototype and prefer using it with Nico> the name gss_userok(). However, this is really bikeshed Nico> painting -- whatever Greg et. al. decide will do. >> >> I don't like any of the existing prototypes, but will live with >> the Solaris prototype. I expect to propose an expanded prototype >> on the order of a year or so. Simon> Then it sounds as if this is not something that we want to Simon> standardize at all at this point? No, please let's standardize this. The issue I have is that I think you might want a configuration context as an input. So, for example you can have multiple usesO: * Use for authorizing logins say for ssh and friends * use for authorizing sasl authorization identities--here checking home directory etc or assuming a posix user would be bad * possibly feeding in mechanism specific configuration I initially wanted to standardize with a GSS_C_DEFAULT_USEROK_CONFIG and not actually define manipulators for the config. The functionality we need today is roughly what the solaris prototype gives. I just don't want to box us in. However I'm happy to accept the Solaris prototype now and give an extended API later if needed. I definitely want to see standardization soon here because that will help us convince applications to adopt. From sxw@inf.ed.ac.uk Wed Apr 6 09:05:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17ED73A6949 for ; Wed, 6 Apr 2011 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHB7Ds--f0WL for ; Wed, 6 Apr 2011 09:05:50 -0700 (PDT) Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by core3.amsl.com (Postfix) with ESMTP id 686213A6947 for ; Wed, 6 Apr 2011 09:05:50 -0700 (PDT) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id B61B32207A; Wed, 6 Apr 2011 17:07:33 +0100 (BST) Received: from 87-194-107-64.bethere.co.uk (HELO logios.config) (87.194.107.64) (smtp-auth username simon@pop3.sxw.org.uk, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Wed, 06 Apr 2011 17:07:33 +0100 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Simon Wilkinson In-Reply-To: Date: Wed, 6 Apr 2011 17:07:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> <827D64AE-54FE-4041-BF24-A5EA70A6300E@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1078) X-Gradwell-MongoId: 4d9c8fc5.11ce8-74b1-1 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: simon@pop3.sxw.org.uk Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:05:51 -0000 On 6 Apr 2011, at 16:40, Nico Williams wrote: >=20 > To me these are host configuration matters, not ones that the app > should specify. I think this applies to many of the recent discussions about adding = context or configuration parameters into GSS. All of the use cases I've = seen so far are for host configuration matters that the application has = little knowledge of. As use of GSS expands, and more and more pluggable = GSS mechanisms become deployed, it's going to be unrealistic to expect = applications to provide UI to allow every aspect of every possible GSS = mechanism to be configured. Cheers, Simon. From ghudson@mit.edu Wed Apr 6 09:27:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6123A69CC for ; Wed, 6 Apr 2011 09:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNbdNevamiPN for ; Wed, 6 Apr 2011 09:27:46 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by core3.amsl.com (Postfix) with ESMTP id CE1253A6957 for ; Wed, 6 Apr 2011 09:27:45 -0700 (PDT) X-AuditID: 1209190e-b7c80ae0000047dd-c2-4d9c94efa86e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 49.88.18397.FE49C9D4; Wed, 6 Apr 2011 12:29:35 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p36GTPCL001385; Wed, 6 Apr 2011 12:29:25 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p36GTMIE002610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 12:29:24 -0400 (EDT) From: Greg Hudson To: Sam Hartman In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Apr 2011 12:29:22 -0400 Message-ID: <1302107362.10465.504.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0X0/ZY6vwZLtUhZf2x6wWRzdvIrF 4t6WS+wOzB5Llvxk8ph55iK7x8qpp9kDmKO4bFJSczLLUov07RK4MjZtLino5KrYdfoWSwNj P0cXIyeHhICJxJTmSewQtpjEhXvr2UBsIYF9jBLPOlW7GLmA7PWMEjM2NjJDOHeZJO51PmUE qRIWUJD4Pms7mM0moCxx8Ow3FhBbREBdYvUliKnMApES999C2JwCahK9L6YyQgxawySx4Poz qCJNidbtv8FsFgFVianr34EN4hXQleh5t5m1i5EDyBaU+LtDGOJSaYmvE54wQbTKS2x/O4d5 AqPgLCSTZiF0zEJStYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGusV5uZoleakrpJkZQQHNK 8u1g/HpQ6RCjAAejEg9vSOccXyHWxLLiytxDjJIcTEqivJ6TgUJ8SfkplRmJxRnxRaU5qcWH GCU4mJVEeE1fz/IV4k1JrKxKLcqHSUlzsCiJ886UVPcVEkhPLEnNTk0tSC2CycpwcChJ8HID I1dIsCg1PbUiLTOnBCHNxMEJMpwHaPgXkMW8xQWJucWZ6RD5U4y6HG8nTd3HKMSSl5+XKiXO mwJSJABSlFGaBzcHloheMYoDvSXM+xekigeYxOAmvQJawgS0ZOuU2SBLShIRUlINjAxNvPaq r/V1/JvUTnP0atg6XvyXxHRq82SN4E+bZTgnb/Ccri/zIZylnWOL5d+WzSe8u1l2cuy592HZ kc8SmoW2DxVXvrvN97trispy+ZsRy/yD7nbttSuf3LzB/OASmcfxSuL7V4Rke62dOPnfD22/ 78D42mf+8GrQ32nbV7grfn1zWeejqRJLcUaioRZzUXEiALC6TygfAwAA Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:27:48 -0000 On Wed, 2011-04-06 at 12:05 -0400, Sam Hartman wrote: > I initially wanted to standardize with a GSS_C_DEFAULT_USEROK_CONFIG and > not actually define manipulators for the config. > The functionality we need today is roughly what the solaris prototype > gives. > I just don't want to box us in. > However I'm happy to accept the Solaris prototype now and give an > extended API later if needed. I would prefer not to add a config parameter that we don't have a current use for. I don't think there's a problem with changing the name if we decide to add caller configuration later. (More generally, I favor extensibility plans which place the least complexity burden on the current system, even if they don't lead to the most elegant future result. In many cases extensibility hooks turn out to be unneeded or, worse, not quite the right shape.) > I definitely want to see standardization soon here because that will > help us convince applications to adopt. I agree that standardizing is beneficial, although I'm not volunteering to write a draft. I think Martin raises a compelling point that we shouldn't make this the first standardized GSSAPI function which takes a "const char *" parameter; fixing that requires a departure from the Sun prototype. From nico@cryptonector.com Wed Apr 6 09:52:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C067528C158 for ; Wed, 6 Apr 2011 09:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAwUHd9RJev7 for ; Wed, 6 Apr 2011 09:51:47 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 937D928C149 for ; Wed, 6 Apr 2011 09:48:31 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 69AEC508071 for ; Wed, 6 Apr 2011 09:48:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dX9K+lEy3UOkvdctmeH1vEwe05/TVIiSh0a1UytzWyev m7BuOjKVSHmHCsFJxaT4CxPmXYifZV60zLyEtGPH4Vas5X7V7MkGTfNz3KLmfWJD YjEb065I7bn/PKsicsepuQtHq2M9iHkjVAEXDKRjPQl9oitPrd0cfUTbInakZsM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=690TQe78r1/l+DOG2eDk60l1GEY=; b=K6MbGTGHfQB Rt274ny9+OwrADQ8nJ2i9SeGSZ8/sCnNTSXXRJ+o1BiXrtzL44j76sCvM8Eik91q cp/T/ZRlvSHFd+0H02X9eAx69ZRk3ZeigM3RA5SfwZnTF9Qr5w1fvc4MrepNDSo8 zGXvtBubScthzBofaAxwYvuY6Jn9aCNo= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 2B82650805B for ; Wed, 6 Apr 2011 09:48:48 -0700 (PDT) Received: by vws12 with SMTP id 12so1560784vws.31 for ; Wed, 06 Apr 2011 09:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1775490vdg.70.1302108527521; Wed, 06 Apr 2011 09:48:47 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 09:48:47 -0700 (PDT) In-Reply-To: <1302107362.10465.504.camel@t410> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Date: Wed, 6 Apr 2011 11:48:47 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:52:51 -0000 On Wed, Apr 6, 2011 at 11:29 AM, Greg Hudson wrote: > I would prefer not to add a config parameter that we don't have a > current use for. =C2=A0[...] +1 We can always add a new function later. > I agree that standardizing is beneficial, although I'm not volunteering > to write a draft. =C2=A0I think Martin raises a compelling point that we > shouldn't make this the first standardized GSSAPI function which takes a > "const char *" parameter; fixing that requires a departure from the Sun > prototype. The only places where the GSS-APIv2u1 deals with strings are: - gss_import_name(), where the input is overloaded and can be non-text, so it has to be a buffer - gss_display_name(), where the output must be released, so re-using buffer so as to avoid having to add yet another release function must have been quite tempting - gss_display_status() -- same deal as gss_display_name() Now that we're adding a funciton with a string input which is always text, never binary data, we really don't need to use gss_buffer_t for that. It hardly matters what the GSS-APIv2u1 did if it never had this particular sort of input. Nico -- From tlyu@mit.edu Wed Apr 6 09:53:06 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D63328C13D for ; Wed, 6 Apr 2011 09:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-UWGZRT-mok for ; Wed, 6 Apr 2011 09:53:00 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 36B4C28C119 for ; Wed, 6 Apr 2011 09:51:48 -0700 (PDT) X-AuditID: 1209190c-b7b7aae0000047c7-c9-4d9c9a42706c Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 41.D8.18375.24A9C9D4; Wed, 6 Apr 2011 12:52:18 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p36GqDNV024610; Wed, 6 Apr 2011 12:52:13 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p36GqBaK007466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 12:52:12 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p36GqBvQ022356; Wed, 6 Apr 2011 12:52:11 -0400 (EDT) To: Luke Howard References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> From: Tom Yu Date: Wed, 06 Apr 2011 12:52:11 -0400 In-Reply-To: <7F9B8E96-B679-4038-93F1-05A6650B9426@padl.com> (Luke Howard's message of "Thu, 7 Apr 2011 01:17:27 +1000") Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrOs0a46vwdVmY4uvbQ/YLI5uXsVi cffSf3YHZo8lS34yecz9MI3FY+XU0+wBzFFcNimpOZllqUX6dglcGfs2r2As6GWtWPbqNksD YytLFyMnh4SAicSyV1OgbDGJC/fWs3UxcnEICexjlOh79IgZwlnPKPF//nMmkCohgctMEkuX J0IkOhklLmw+yAiSEBFQkJi8fy0ziM0sYCFxf+9UsLgwUPz7rO2MEA0fGSWeH1gHtI+Dg01A WuLo4jKQGhYBVYkf11aBhTkFKiRW9rqAhHmBxuzqecMGYvMIcEr8+juBDSIuKHFy5hMWiFVa Ejf+vWSawCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbqGermZJXqpKaWbGMHB K8mzg/HNQaVDjAIcjEo8vCGdc3yFWBPLiitzDzFKcjApifLOmQkU4kvKT6nMSCzOiC8qzUkt PsQowcGsJMJr+nqWrxBvSmJlVWpRPkxKmoNFSZx3hqS6r5BAemJJanZqakFqEUxWhoNDSYJ3 DchQwaLU9NSKtMycEoQ0EwcnyHAeoOFTQGp4iwsSc4sz0yHypxgVpcR580ESAiCJjNI8uF5Y cnnFKA70ijDvTJAqHmBigut+BTSYCWjw1imzQQaXJCKkpBoYw/3vr389fcu/ubEnmTleuXWd jf5rWczttm6aN8vPG9mr15wr3OPPcii51TYqWObXvQCRzT6rLX4y8X45LZykVORZ/bkz/Jp/ 6KTjE/S6U+/EHg+1tnrzIX1rEc+Lj3GspUaxXa46Bz0q2ifd4Jo6mV328PxfeySD/4t9qFuz /mbBlYvNSpPElViKMxINtZiLihMBA8IU6gkDAAA= Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 16:53:06 -0000 Luke Howard writes: >> I don't like any of the existing prototypes, but will live with the >> Solaris prototype. >> I expect to propose an expanded prototype on the order of a year or so. > > OK, how about this then? > > int > gss_userok(const gss_name_t name, > const char *username); > > typedef struct gss_userok_config *gss_userok_config_t; Standards nitpick: the "_t" C identifier suffix is reserved by POSIX. I know we already have a bunch of non-conforming names suffixed with "_t" in the GSS-API C bindings, but have we deliberately chosen to continue making new ones for the sake of consistency? From hartmans@mit.edu Wed Apr 6 10:15:20 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2093A6962 for ; Wed, 6 Apr 2011 10:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.872 X-Spam-Level: X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi2GZweSaQpd for ; Wed, 6 Apr 2011 10:15:19 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 547353A695F for ; Wed, 6 Apr 2011 10:15:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0E17B203A2; Wed, 6 Apr 2011 13:13:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B2A88446E; Wed, 6 Apr 2011 13:16:58 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Date: Wed, 06 Apr 2011 13:16:58 -0400 In-Reply-To: (Nico Williams's message of "Wed, 6 Apr 2011 11:48:47 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:15:20 -0000 Responding. I've proposed specific non-host uses for the config parameter. namely determining the authorization scope--whether we're authorizing over SASL authorization identities, local accounts, or what. That is clearly an application matter. In preference I would prefer: 1) Luke's example with a config parameter 2) gss_userok with simon's prototype and gss_loginok with the Solaris prototype 3) gss_loginok with the solaris prototype 4) gss_userok with the Solaris prototype 5) gss_userok with Simon's prototype 6) no standard I believe that const char * is the appropriate thing to take for local account names and authorization identities, so I disagree with Martin, but I'd rather a gss_buffer_t than no standard. From ghudson@mit.edu Wed Apr 6 10:21:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45ED3A68CE for ; Wed, 6 Apr 2011 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxAr+0I6Tu+1 for ; Wed, 6 Apr 2011 10:21:37 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by core3.amsl.com (Postfix) with ESMTP id 6DDF93A68AB for ; Wed, 6 Apr 2011 10:21:37 -0700 (PDT) X-AuditID: 12074422-b7ccdae000003dab-a7-4d9ca18bc30f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id AF.21.15787.B81AC9D4; Wed, 6 Apr 2011 13:23:23 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p36HNKFr007627; Wed, 6 Apr 2011 13:23:20 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p36HNH6n014141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 13:23:19 -0400 (EDT) From: Greg Hudson To: Sam Hartman In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Apr 2011 13:23:16 -0400 Message-ID: <1302110596.10465.507.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6notu9cI6vwbsvOhZf2x6wWRzdvIrF 4tS1I2wW97ZcYndg8Xh56hyjx5IlP5k8Zp65yO6xcupp9gCWKC6blNSczLLUIn27BK6M2/2n 2ArOM1e8O/uLqYHxA1MXIyeHhICJxPx5k5khbDGJC/fWs3UxcnEICexjlFjz6wEjhLOeUeL5 +gUsEM5dJonW/gVg7cICChLfZ21nBLHZBJQlDp79xgJiiwioS6y+NIkdxGYW6GSUmPjYEcTm FFCTODWpB2rQUmaJ3defQxVpSrRu/w1mswioSixYewlsKK+ArsSMa6uA7uMAsgUl/u4QhjhV WuLrhCdMEK3yEtvfzmGewCg4C8mkWQgds5BULWBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRr qpebWaKXmlK6iREc6C5KOxh/HlQ6xCjAwajEw/urbY6vEGtiWXFl7iFGSQ4mJVFe/nlAIb6k /JTKjMTijPii0pzU4kOMEhzMSiK8pq9n+QrxpiRWVqUW5cOkpDlYlMR550iq+woJpCeWpGan phakFsFkZTg4lCR4Xy8AGipYlJqeWpGWmVOCkGbi4AQZzgM0XA2khre4IDG3ODMdIn+K0Zjj 7JWJ+xg53k6auo9RiCUvPy9VSpz3I0ipAEhpRmke3DRYsnrFKA70nDDvLZAqHmCig5v3CmgV E9CqrVNmg6wqSURISTUwzjFv6fkclm/BkcL6J8zcKTaoe7tk5sb5/tFVPJc3LWITnt3ibLV2 49aA1l23vyin7Hh46cUxS67gV5vYa9Kr/0/etD9we7hVQsrruL8X2jvVfM7veGzme91oX4PA TKnXGjylWYWmqRaG5y7YpWcEKAeUstb31KmKL1L8PyG4I61M9O1a7QdKLMUZiYZazEXFiQC1 jrN+MQMAAA== Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:21:38 -0000 On Wed, 2011-04-06 at 13:16 -0400, Sam Hartman wrote: > I believe that const char * is the appropriate thing to take for local > account names and authorization identities, so I disagree with Martin, > but I'd rather a gss_buffer_t than no standard. I am swayed by Nico's arguments on this point, so I no longer favor changing to a gss_buffer_t. A const char * is likely to be more convenient for callers. (Just for consensus-counting purposes.) From nico@cryptonector.com Wed Apr 6 10:28:42 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558993A6957 for ; Wed, 6 Apr 2011 10:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdWbLgzYThuw for ; Wed, 6 Apr 2011 10:28:41 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 5D6E13A68AB for ; Wed, 6 Apr 2011 10:28:41 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 4947D584065 for ; Wed, 6 Apr 2011 10:30:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Kg0oDQB1MSita/Yk4KyiK 3dFkxCxx1NSMSRepknJD9DDa6kG9ryuNXtZvVCJzuSdZ/E0zir+uxHsLY5Sc7eTK wnWYN/dFsk3cFj2p7JLruVbU1ksLN9IDe7EhvyR9lTA2DNnvSPHYcYNXM8Avi72K 7EaUn+aSy4QLNfb5yL8d7s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=q4R7P4Y5EK4ORus4xMmg Ps0lPbw=; b=pNz8z6EmKg/M0AAi3uH6/nI5Q0rmcG2k9bmpbp/lzKuCp11nGxKT MpnN42Y7aQc1MaPlbP+w/qYPpT3hU4rbnqlJoMXzpMGOOC136+u2Ndoj3qoXqOI4 4hplHdSvmj1cpunRjENOJkugwMZMY1pBKGlAG3LLtDkcPYFrf+BTQ4o= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 2F4EC584064 for ; Wed, 6 Apr 2011 10:30:24 -0700 (PDT) Received: by vws12 with SMTP id 12so1599925vws.31 for ; Wed, 06 Apr 2011 10:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.233 with SMTP id ct9mr10454vdc.110.1302111023288; Wed, 06 Apr 2011 10:30:23 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 10:30:23 -0700 (PDT) In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Date: Wed, 6 Apr 2011 12:30:23 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:28:42 -0000 Sam, I'm really skeptical of the application specific userok options, but let's grant that they are necessary for the sake of argument. We still couldn't standardize your proposed gss_userok() function without also standardizing a function or set of functions for manipulating the configuration argument for gss_userok(). Nico -- From hartmans@mit.edu Wed Apr 6 10:32:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7ADA3A69B9 for ; Wed, 6 Apr 2011 10:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.859 X-Spam-Level: X-Spam-Status: No, score=-102.859 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnqytiUYqtsw for ; Wed, 6 Apr 2011 10:32:48 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 408663A69B4 for ; Wed, 6 Apr 2011 10:32:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C12ED20340; Wed, 6 Apr 2011 13:31:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 25FC2446E; Wed, 6 Apr 2011 13:34:31 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Date: Wed, 06 Apr 2011 13:34:31 -0400 In-Reply-To: (Nico Williams's message of "Wed, 6 Apr 2011 12:30:23 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:32:48 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Sam, I'm really skeptical of the application specific userok Nico> options, but let's grant that they are necessary for the sake Nico> of argument. We still couldn't standardize your proposed Nico> gss_userok() function without also standardizing a function or Nico> set of functions for manipulating the configuration argument Nico> for gss_userok(). I disagree. You may not want to. That's fine. However, we certainly could. I argue that we should if we believe that we'll need that extensibility, we are convinced it will be the right extensibility, but we believe that the specifics of such an approach will take longer than the base API. I believe all those things are true. From nico@cryptonector.com Wed Apr 6 10:33:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B632B28C0EC for ; Wed, 6 Apr 2011 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG9qI1oF30xm for ; Wed, 6 Apr 2011 10:33:12 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id 0683F28C0DE for ; Wed, 6 Apr 2011 10:33:12 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 277992F406D for ; Wed, 6 Apr 2011 10:34:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=FWIC5nJhgis90frUZ1qEwp4ecleHfocWsErQ6lb1wpXa mFTWndu4LsSVo8NgCcQs6U5Fgi78z9l8PSLUVYFdXdRLA7AW+P0ZnpfIIa6oPjHQ Y+krpLgtODUtnYmH+4SC37LVxiKn2r0XHqN2b6Ko9tILuq/TSaRtEAZVC+AMPv0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ZpQA6GeoxF5NwhVwKdHdk3sfQUc=; b=GUfwDMKQxgv 2HFYRZjYwIzivyDNMFh+PhvpakIZdVEc5V/Gv7pa3RslafSQ+EITK3DCb/m101FP xhwG2+ulvMv0TTKBCHkvoezwwVpNarHTsKBrDJVYtUGu9LXT4CeRRU4wj0kT8WR/ qZLVjH6wtCdEuljeHVBJhb6SVmQOGme0= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id F08802F4059 for ; Wed, 6 Apr 2011 10:34:55 -0700 (PDT) Received: by vws12 with SMTP id 12so1603987vws.31 for ; Wed, 06 Apr 2011 10:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr1853199vdg.70.1302111295350; Wed, 06 Apr 2011 10:34:55 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 10:34:55 -0700 (PDT) In-Reply-To: <1302110596.10465.507.camel@t410> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> <1302110596.10465.507.camel@t410> Date: Wed, 6 Apr 2011 12:34:55 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:33:12 -0000 On Wed, Apr 6, 2011 at 12:23 PM, Greg Hudson wrote: > On Wed, 2011-04-06 at 13:16 -0400, Sam Hartman wrote: >> I believe that const char * is the appropriate thing to take for local >> account names and authorization identities, so I disagree with Martin, >> but I'd rather a gss_buffer_t than no standard. > > I am swayed by Nico's arguments on this point, so I no longer favor > changing to a gss_buffer_t. =C2=A0A const char * is likely to be more > convenient for callers. > > (Just for consensus-counting purposes.) Thanks. BTW, in the v3 API, should I ever restart that project, I intend to split gss_import_name() into two functions: gss3_import_query_name(), taking a const char *, and gss3_import_name(), taking a buffer containing an exported name token. As for display_name and status, I'll make them output a const char ** that is released automatically (in the case of display_name it'd be released when the name is release, and in the case of display_status it'd be released when either display_status is called again or when the caller context handle is released). I'm not really happy, as you can tell, with some of the design choices in the v2 API, particularly regarding memory management and the gss_import_name() conflation. From nico@cryptonector.com Wed Apr 6 10:35:05 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A7D3A695C for ; Wed, 6 Apr 2011 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZEFOE3naXCz for ; Wed, 6 Apr 2011 10:35:04 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id A4A073A68CE for ; Wed, 6 Apr 2011 10:35:04 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id D112667C074 for ; Wed, 6 Apr 2011 10:36:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Bcn54qsLQcLWdkQIqVulZ 7hiroa2leOKINXL9FBscyXxLYiCjlYXIpJTp1qzjo/y5EACtc3Wx6nXUKDO38gHx PsJH9hndVQrjmZTnfxaQePN/8MWiWtU6XTn0QZ/wuxFEhzWHH/n/1zROXAKW7P3X WmiyycI/hYtV0+Ev+/ZEEg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Zz2WrU7De1nAVQC6sC8l H9TCeok=; b=b9VhzX0dYjNxYu+AvTte4BHdgxPyR4eJA3W3M/1BHFDCC7yE6x9V 3OMbQx3noMo8c6bAw9jNNUbViLPAXBJJ5PbqWUsv8FIZvrGyZ3mHBw3cXjTUyAX5 /szTlVJJtWOI/C7U/j3duZ/32W7vpENDgjCI1Vmy3aSVqibNGWF8vkk= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 9AA2067C072 for ; Wed, 6 Apr 2011 10:36:48 -0700 (PDT) Received: by vws12 with SMTP id 12so1605635vws.31 for ; Wed, 06 Apr 2011 10:36:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr1747752vdb.270.1302111400082; Wed, 06 Apr 2011 10:36:40 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 10:36:39 -0700 (PDT) In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Date: Wed, 6 Apr 2011 12:36:39 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:35:05 -0000 On Wed, Apr 6, 2011 at 12:34 PM, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> Sam, I'm really skeptical of the application specific userok > Nico> options, but let's grant that they are necessary for the sake > Nico> of argument. We still couldn't standardize your proposed > Nico> gss_userok() function without also standardizing a function or > Nico> set of functions for manipulating the configuration argument > Nico> for gss_userok(). > > I disagree. You may not want to. That's fine. However, we certainly > could. I argue that we should if we believe that we'll need that > extensibility, we are convinced it will be the right extensibility, but > we believe that the specifics of such an approach will take longer than > the base API. I believe all those things are true. I'm not interested in standardizing a half-specified API. If you have secret sauce for the configuration parameter then just add a private version of gss_userok() with a different name and be done, but please don't pollute the namespace for the rest of us. Nico -- From hartmans@mit.edu Wed Apr 6 10:46:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDC63A69D4 for ; Wed, 6 Apr 2011 10:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajPSp-EZJInJ for ; Wed, 6 Apr 2011 10:46:51 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CCE3C3A69B9 for ; Wed, 6 Apr 2011 10:46:50 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8079420340; Wed, 6 Apr 2011 13:45:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DFDAB446E; Wed, 6 Apr 2011 13:48:33 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> Date: Wed, 06 Apr 2011 13:48:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 17:46:51 -0000 I think there's a way of stating what I want in a more gss friendly way. This even addresses Martin's objection: OM_uint32 gss_loginok ( OM_uint32 *minor, gss_name_t authname, gss_name_t lname); Where authname is the result of authentication and lname is the login/authorization/local name. Lname SHOULd NOT|MUST NOT be an MN. This addresses the concerns about const char * use and provides several existing options for exttensibility. With gss_userok (Simon's prototype) as a common case convenience function, even the argument that having to import the lname is inconvenient goes away. From simon@josefsson.org Wed Apr 6 12:48:26 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26FC3A696F for ; Wed, 6 Apr 2011 12:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTa9BWmHZ1ep for ; Wed, 6 Apr 2011 12:48:26 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 87B9A3A67DA for ; Wed, 6 Apr 2011 12:48:24 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p36Jnq73002231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Apr 2011 21:49:54 +0200 From: Simon Josefsson To: Nico Williams References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110406:kitten@ietf.org::zaT12sUCcWlI81l+:vLs X-Hashcash: 1:22:110406:nico@cryptonector.com::D8lyRMoR6ySQHFWh:2LO0 X-Hashcash: 1:22:110406:ghudson@mit.edu::SiMy/obPc+Sgd/dx:3bl5 X-Hashcash: 1:22:110406:hartmans-ietf@mit.edu::15NoqxnUHMfRW4Ik:9C6E Date: Wed, 06 Apr 2011 21:49:52 +0200 In-Reply-To: (Nico Williams's message of "Wed, 6 Apr 2011 11:48:47 -0500") Message-ID: <87ipuryxb3.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 19:48:27 -0000 Nico Williams writes: > On Wed, Apr 6, 2011 at 11:29 AM, Greg Hudson wrote: >> I would prefer not to add a config parameter that we don't have a >> current use for.  [...] > > +1 > > We can always add a new function later. > >> I agree that standardizing is beneficial, although I'm not volunteering >> to write a draft.  I think Martin raises a compelling point that we >> shouldn't make this the first standardized GSSAPI function which takes a >> "const char *" parameter; fixing that requires a departure from the Sun >> prototype. > > The only places where the GSS-APIv2u1 deals with strings are: > > - gss_import_name(), where the input is overloaded and can be > non-text, so it has to be a buffer > - gss_display_name(), where the output must be released, so re-using > buffer so as to avoid having to add yet another release function must > have been quite tempting > - gss_display_status() -- same deal as gss_display_name() > > Now that we're adding a funciton with a string input which is always > text, never binary data, we really don't need to use gss_buffer_t for > that. It hardly matters what the GSS-APIv2u1 did if it never had this > particular sort of input. RFC 2744 discusses character strings too: 3.2.2. Character strings Certain multiple-word data items may be regarded as simple ISO Latin-1 character strings. Examples are the printable strings passed to gss_import_name via the input_name_buffer parameter. Some GSS-API routines also return character strings. All such character strings are passed between the application and the GSS-API implementation using the gss_buffer_t datatype, which is a pointer to a gss_buffer_desc object. /Simon From mrex@sap.com Wed Apr 6 13:05:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB5553A6986 for ; Wed, 6 Apr 2011 13:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dic1d0y-ZGoY for ; Wed, 6 Apr 2011 13:05:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 5209D3A67DA for ; Wed, 6 Apr 2011 13:05:00 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p36K6bsl028267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2011 22:06:38 +0200 (MEST) From: Martin Rex Message-Id: <201104062006.p36K6b6O007109@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Wed, 6 Apr 2011 22:06:37 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 6, 11 11:48:47 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, simon@josefsson.org, hartmans-ietf@mit.edu Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:05:02 -0000 Nico Williams wrote: > > The only places where the GSS-APIv2u1 deals with strings are: I would like to draw your attention to http://tools.ietf.org/html/rfc2744#section-3.2 http://tools.ietf.org/html/rfc2744#section-3.2.2 -Martin From mrex@sap.com Wed Apr 6 13:23:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9EE03A69E1 for ; Wed, 6 Apr 2011 13:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKTMcFORloRj for ; Wed, 6 Apr 2011 13:23:24 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id E04F93A69DE for ; Wed, 6 Apr 2011 13:23:23 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p36KP7NW029885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2011 22:25:07 +0200 (MEST) From: Martin Rex Message-Id: <201104062025.p36KP6gV008275@fs4113.wdf.sap.corp> To: ghudson@MIT.EDU (Greg Hudson) Date: Wed, 6 Apr 2011 22:25:06 +0200 (MEST) In-Reply-To: <1302103795.10465.494.camel@t410> from "Greg Hudson" at Apr 6, 11 11:29:55 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, simon@josefsson.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 20:23:25 -0000 Greg Hudson wrote: > > However, I'm confused about your semantics. First, why are you > specifying the implementation of the function as part of the API > contract? Does the app want to know how the decision is made, or does > it just want to ask a question (is this MN authorized to login as this > user according to the mechanism's logic)? Standardizing a GSS-API function without nailing down the exact semantics would seem strange to me. gss_userok() appears to be an extremely Kerberos5-specific function and even there, it appears to be inherently non-portable. Only the application knows the exact usage/purpose of the authentication (file access, shell-acces, ftp access, pop/imap access, web-shop access, discussion forum access). Even Microsoft makes a careful distinction between "network logon" and "interactive logon", in that domain users are usually allowed to access a servers file shares (relying on the ACLs to provide access control), while disallowing interactive logon for mere domain users as a security precaution. The described gss_userok() semantics do not make sense for GSS-API mechanisms that are not used by the OS itself but only by the application to distinguish application-level users. The latter is actually the more common situation when using GSS-API with our apps. Most of the (~20) GSS-API mechanisms that can be used with our application are not integrated with the logon of the underlying OS. In order to support rfc4559 (HTTP Negotiate) with Kerberos, all the app would have to do is implement unpacking of AP_REQ and creation of AP_REP. There is no need for the underlying OS to be aware of any of the users that are authenticating, it is perfectly sufficient if the application is able to distinguish users. When Apps are using with PKI-based SSO-Infrastructures where some of the communication protocols are using GSS-API for authentication and others use TLS with client certs, then it is not unusual that the TLS client cert authenticated users are not even visible to the underlying OS. The application will likely want to use a unified approach to distinguish clients, independent on whether they use a communication protocol with GSS-API and client cert or a Web Browser with TLS client cert. -Martin From tlyu@mit.edu Wed Apr 6 14:06:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F64F3A6943 for ; Wed, 6 Apr 2011 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.971 X-Spam-Level: X-Spam-Status: No, score=-102.971 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+djIR0fMLuf for ; Wed, 6 Apr 2011 14:06:27 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by core3.amsl.com (Postfix) with ESMTP id 5C8063A63D3 for ; Wed, 6 Apr 2011 14:06:27 -0700 (PDT) X-AuditID: 1209190e-b7c80ae0000047dd-b2-4d9cd641ce68 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id A3.EA.18397.146DC9D4; Wed, 6 Apr 2011 17:08:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p36L89K0030714; Wed, 6 Apr 2011 17:08:09 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p36L851g006713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 17:08:08 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id p36L856i023513; Wed, 6 Apr 2011 17:08:05 -0400 (EDT) To: Stephen Farrell References: <4D9B5876.6090005@cs.tcd.ie> From: Tom Yu Date: Wed, 06 Apr 2011 17:08:05 -0400 In-Reply-To: <4D9B5876.6090005@cs.tcd.ie> (Stephen Farrell's message of "Tue, 05 Apr 2011 18:59:18 +0100") Message-ID: Lines: 14 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqret4bY6vwfdV/BZHN69isZi+9xq7 A5PH2u6rbB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4sWcnS0E7S0X/qo1sDYzLmbsYOTkkBEwk Hr5ewQhhi0lcuLeerYuRi0NIYB+jxLezP1kgnPWMEje/rYdyLjNJnJveww7SIiTQySjxZ6EA iC0ioC+xd/M5sDizgLDE8jVn2UBsYYEgic83brNC1GtI/F3wECjOwcEmIC1xdHEZiMkioCqx 6Y4LSAWnQJbExtdXmUBsXgELiTuPn4BN4RHglFjf/4wRIi4ocXLmExaITVoSN/69ZJrAKDgL SWoWktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFusZ6uZkleqkppZsYwWEqybeD8etBpUOM AhyMSjy8IZ1zfIVYE8uKK3MPMUpyMCmJ8jJdBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4V1+ FijHm5JYWZValA+TkuZgURLnnSmp7iskkJ5YkpqdmlqQWgSTleHgUJLgLbsK1ChYlJqeWpGW mVOCkGbi4AQZzgM0fAlIDW9xQWJucWY6RP4Uo6KUOG8rSEIAJJFRmgfXC0sjrxjFgV4R5l0K UsUDTEFw3a+ABjMBDV54DmxwSSJCSqqBcdbS5IllnNaHa4t2NBb+3+kwzY9L8b62U/rjcpWE +i8svLIZJT9zWJ9khospRC18c2L2E7mNn26/jXz6+Y6q79yNS3peHmiZOd1x0f/+9kzLxZz2 adOOe+tkLOZSas1YHWu+br6VQuHRrOLAZV1cjg/Na9Jv5+/wPczZtCru9u7VE/kOHj4Yp8RS nJFoqMVcVJwIAC1fMh/+AgAA Cc: kitten@ietf.org Subject: Re: [kitten] publication request for draft-josefsson-gss-capsulate-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:06:28 -0000 Stephen Farrell writes: > Please let me know if there are any problems with this > or if that's all ok. (A few positive acks appreciated.) The chairs believe that the Working Group has consensus in favor of the publication of draft-josefsson-gss-capsulate as an individual submission. Based on WG mailing list discussion, there appear to be generally positive opinions about the document, and a variety of implementations already exists. -- Tom Yu IETF KITTEN WG co-chair From stephen.farrell@cs.tcd.ie Wed Apr 6 14:21:20 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D3F28C106 for ; Wed, 6 Apr 2011 14:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XLb9Lx259Ok for ; Wed, 6 Apr 2011 14:21:19 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id F135E3A67D3 for ; Wed, 6 Apr 2011 14:21:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B26AC3E4099; Wed, 6 Apr 2011 22:23:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1302124981; bh=UHmHn 9mEupYtcf+2jfSbnK+fTY5hwn/qNkRbIhPuvOM=; b=SnXlDNSk35gVtpKKOHrsp 3M8h8BEi7VqyHLKRBdjwO2e9MLBr70IXtC1qI051BKXq3yy1XjJFSshdMxNmN/1l Az1lyK5N0t2tL5RI4hmoPq9Gbu6JWi4RDsAYo530uDZNgEbzuM3oH5Tpbw01ukBP WZa0fh4mU4mGxCdVbEcoF9LyWVWfXtgmqfdRD03Ea/XQqmwC0wMtSBqWbY+xfSH2 RuMKOtZid3tYkNYRtAvYm1gZmTyg8zMphvskjB1TjOe0zkhbcbfM2hOTaV9APHL4 5b3IAYXvrxKydQ8h7+ePzF7pVx+nRVCrpn5KJcn35IAja+vB5XhKJPHA7LJ2lwZe A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id h8VIcgBnMCNw; Wed, 6 Apr 2011 22:23:01 +0100 (IST) Received: from [10.87.48.6] (unknown [86.42.16.114]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6A7BB3E4094; Wed, 6 Apr 2011 22:23:01 +0100 (IST) References: <4D9B5876.6090005@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8F190) From: Stephen Farrell Date: Wed, 6 Apr 2011 22:22:59 +0100 To: Tom Yu Cc: "kitten@ietf.org" Subject: Re: [kitten] publication request for draft-josefsson-gss-capsulate-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 21:21:20 -0000 On 6 Apr 2011, at 22:08, Tom Yu wrote: > Stephen Farrell writes: > >> Please let me know if there are any problems with this >> or if that's all ok. (A few positive acks appreciated.) > > The chairs believe that the Working Group has consensus in favor of > the publication of draft-josefsson-gss-capsulate as an individual > submission. Based on WG mailing list discussion, there appear to be > generally positive opinions about the document, and a variety of > implementations already exists. Great. I'll start an IETF last call so, S. > > -- > Tom Yu > IETF KITTEN WG co-chair From ghudson@mit.edu Wed Apr 6 15:10:28 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A05728C0CF for ; Wed, 6 Apr 2011 15:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfDoe6PUh7oz for ; Wed, 6 Apr 2011 15:10:27 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 9A7C13A67EA for ; Wed, 6 Apr 2011 15:10:27 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-5a-4d9ce534ce21 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 45.A0.18470.435EC9D4; Wed, 6 Apr 2011 18:12:05 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p36MC9iV004269; Wed, 6 Apr 2011 18:12:10 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p36MC4S2018377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2011 18:12:06 -0400 (EDT) From: Greg Hudson To: "mrex@sap.com" In-Reply-To: <201104062025.p36KP6gV008275@fs4113.wdf.sap.corp> References: <201104062025.p36KP6gV008275@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Wed, 06 Apr 2011 18:12:04 -0400 Message-ID: <1302127924.10465.556.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IR4hTV1jV9OsfXYEcvk8XRzatYLHp/72C2 uLflErsDs8eSJT+ZPGaeucjuMeXzVsYA5igum5TUnMyy1CJ9uwSujONXe1gKZolWbHx0irWB cZFgFyMnh4SAicTa39uZIGwxiQv31rN1MXJxCAnsY5To2vaJHcJZzyjxbOpSsCohgbtMEvOb IkFsYQEFie+ztjOC2GwCyhIHz35jAbFFBBQlbrVPYwexmQXiJV58eQhWwylgJ3F530VmiDm2 EsvuPmGGqNGUaN3+G6yeRUBV4u6HlWA2r4CuRMfVyaxdjBxAtqDE3x3CEIdKS3yd8IQJolVe YvvbOcwTGAVnIZk0C6FjFpKqBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3 MYIDWpJ3B+O7g0qHGAU4GJV4eOM65/gKsSaWFVfmHmKU5GBSEuXd+AQoxJeUn1KZkVicEV9U mpNafIhRgoNZSYR3+VmgHG9KYmVValE+TEqag0VJnHempLqvkEB6YklqdmpqQWoRTFaGg0NJ gncbyFDBotT01Iq0zJwShDQTByfIcB6g4R8egwwvLkjMLc5Mh8ifYtTl+L/l0D5GIZa8/LxU KXHeBJBBAiBFGaV5cHNgiegVozjQW8K8WSBVPMAkBjfpFdASJqAlC8+BLSlJREhJNTDWvDnR tspL1cPNw+bSgr5HO7rn7nE4s1fVceLaA69cN5qZblxt48RalPV9m5/ikV0TmiaUNhu4Bcdm TfM+/qlGLcjU9W3boudqrTcVe14l+y+dJzDh14Tzru2n/V1cVL6Il0cX2OzaPuFEfMYymzlv LrPI8m+eVMR+TZVXhH/HJJMQy0s6c+OUWIozEg21mIuKEwHDF/FHHwMAAA== Cc: "kitten@ietf.org" , "simon@josefsson.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:10:28 -0000 On Wed, 2011-04-06 at 16:25 -0400, Martin Rex wrote: > Standardizing a GSS-API function without nailing down the exact > semantics would seem strange to me. Really? The exact semantics of, say, gss_acquire_cred are mech-dependent. Even if you delve into the mechanism standards, they typically only define token formats; the details of things like credential management are implementation-dependent. The proposed gss_userok() (Solaris version) has fewer constraints than something like gss_acquire_cred, but that's only because the answer is so simple (yes or no). > gss_userok() appears to be an extremely Kerberos5-specific function > and even there, it appears to be inherently non-portable. I don't think it's krb5-specific at all; it assumes that the mechanism has its fingers in the login authorization pie, but any mechanism could do that. (The krb5 team isn't wild about having its fingers in that pie, but the logistics of pulling our fingers out aren't attractive. A krb5-specific PAM module is the only other likely owner of that pie, and not every user of krb5_kuserok() necessarily wants to use PAM.) It's non-portable to some extent; a platform may or may not have a concept of "login". Within the space of POSIX platforms it's portable. > Only the application knows the exact usage/purpose of the > authentication (file access, shell-acces, ftp access, pop/imap access, > web-shop access, discussion forum access). If the application integrates with system accounts (sshd, ftpd) then it could have an interest in this function. If the application has its own concept of users, then it wouldn't be interested (although Sam may disagree on that). > The described gss_userok() semantics do not make sense for GSS-API > mechanisms that are not used by the OS itself but only by the > application to distinguish application-level users. The latter > is actually the more common situation when using GSS-API with > our apps. Most of the (~20) GSS-API mechanisms that can be > used with our application are not integrated with the logon of > the underlying OS. So, you probably wouldn't use such a mechanism with an application like sshd or ftpd. If you did, gss_userok() would probably just always say no. (In the Solaris implementation, if the mech doesn't have a gss_userok function, the mechglue performs a check using import/canonicalize/compare, and a mech like you posit would probably just refuse to import a username.) > In order to support rfc4559 (HTTP Negotiate) with Kerberos[...] I wouldn't expect an httpd to use gss_userok, unless it was running as root on a POSIX-ish system and trying to behave like an ftpd. From lukeh@padl.com Wed Apr 6 15:31:32 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CD13A695E for ; Wed, 6 Apr 2011 15:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BX6c+PG6wLgM for ; Wed, 6 Apr 2011 15:31:32 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 1D35E3A6801 for ; Wed, 6 Apr 2011 15:31:32 -0700 (PDT) Received: by us.padl.com with ESMTP id p36MX5aM019914; Wed, 6 Apr 2011 18:33:08 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 7 Apr 2011 08:33:05 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> <1302107362.10465.504.camel@t410> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 22:31:32 -0000 On 07/04/2011, at 3:48 AM, Sam Hartman wrote: > I think there's a way of stating what I want in a more gss friendly = way. > This even addresses Martin's objection: >=20 > OM_uint32 gss_loginok ( > OM_uint32 *minor, > gss_name_t authname, > gss_name_t lname); >=20 >=20 > Where authname is the result of authentication > and lname is the login/authorization/local name. >=20 > Lname SHOULd NOT|MUST NOT be an MN. >=20 > This addresses the concerns about const char * use and provides = several existing options for exttensibility. OK, I'm happy with this, although I would really prefer the name = gss_userok_ext. I really don't like gss_loginok. Do we have consensus? -- Luke= From nico@cryptonector.com Wed Apr 6 17:10:44 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81273A697E for ; Wed, 6 Apr 2011 17:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7uNI3k29UHt for ; Wed, 6 Apr 2011 17:10:44 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 029F13A6827 for ; Wed, 6 Apr 2011 17:10:44 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 3E07267C06D for ; Wed, 6 Apr 2011 17:12:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XQR/mjWIZKhui7hH2bqxTQI5IVdm35cdnj/lw9Fy8A65 3nrxIP/L+6K7vHQMzYW8TYFFH6u0VYXjuK4I9gQmMuSTeXFxhDNLdx1R+PxqBobT KJnCkV1/YTItAqYB1/SCzC/t9iOJuNoSYk4bxLVp+ohKRKx5S++5yrgTobdcVjA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=DGS8tJYeyuUnKtHqJyt1AvDRWH8=; b=yF6xN9YzPzW 4E2yKW/m3+0s7KAppJVJ9cyU0yeqtqXYz+DYK84lGtY188na2SIz0knSbujri1JD 23A6JVJcgxs0kPO9X3epfkVoRFPBzQ8HHq8mLLjvJkca93g0QChjZLFrZ0CpJe2u 58UDLCNbCh60v+EHI5EwizMhpaYYL8MY= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 1B51467C06B for ; Wed, 6 Apr 2011 17:12:28 -0700 (PDT) Received: by vxg33 with SMTP id 33so1879647vxg.31 for ; Wed, 06 Apr 2011 17:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.177.233 with SMTP id ct9mr387747vdc.110.1302135147527; Wed, 06 Apr 2011 17:12:27 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Wed, 6 Apr 2011 17:12:27 -0700 (PDT) In-Reply-To: <201104062025.p36KP6gV008275@fs4113.wdf.sap.corp> References: <1302103795.10465.494.camel@t410> <201104062025.p36KP6gV008275@fs4113.wdf.sap.corp> Date: Wed, 6 Apr 2011 19:12:27 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, simon@josefsson.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 00:10:45 -0000 On Wed, Apr 6, 2011 at 3:25 PM, Martin Rex wrote: > Standardizing a GSS-API function without nailing down the exact > semantics would seem strange to me. Just what are you (and Simon) going on about? The semantics are nailed down (the function is a boolean predicate answering the question "is the given principal allowed access to the named user account?"). Simon didn't think so and then asked about what we should all consider _implementation_-specific behaviors, not semantics. Maybe I'm missing something, maybe the implementation of MIT krb5's krb5_userok() is actually semantics and I just have a completely different understanding or expectation of where the line is between semantics and behavior that is/should be implementation-specific, but I don't think so. > gss_userok() appears to be an extremely Kerberos5-specific function > and even there, it appears to be inherently non-portable. In Solaris it also works for mech_dh. So, it's NOT mechanism-specific. I have an existence proof. Q.E.D. This function *is* specific to something though: to operating systems with a notion of user account that is distinct from GSS principal names. That's *all* multi-user operating systems that I'm aware of, pretty much. In other words: this is a theoretically not generic API, but in practice it's quite generic. > Only the application knows the exact usage/purpose of the > authentication (file access, shell-acces, ftp access, pop/imap access, > web-shop access, discussion forum access). True. That's why the function refers to a whole user account and assumes full access. If you want fine-grained authorization wrapped in a GSS function or set of functions, well, that's going to be a lot more operating system- and even application-specific, which is to say: not standardizable. And yet, so many programs are happy with a userok() type function, and so many sysadmins are happy to allow it: because it's useful enough and a whole lot better than nothing. > Even Microsoft makes a careful distinction between "network logon" > and "interactive logon", in that domain users are usually allowed > to access a servers file shares (relying on the ACLs to provide > access control), while disallowing interactive logon for mere > domain users as a security precaution. Understood. I assert that's not an issue here. I suppose we could add arguments to distinguish between types of login, but we'll quickly reach the limit of what we can reasonably standardize. > The described gss_userok() semantics do not make sense for GSS-API > mechanisms that are not used by the OS itself but only by the > application to distinguish application-level users. =C2=A0The latter > is actually the more common situation when using GSS-API with > our apps. =C2=A0Most of the (~20) GSS-API mechanisms that can be > used with our application are not integrated with the logon of > the underlying OS. This is true. Such applications must not use this function. What does this say about whether we should or should not standardize this function? Nico -- From chris.newman@oracle.com Wed Apr 6 18:46:53 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B033A69E6 for ; Wed, 6 Apr 2011 18:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.198 X-Spam-Level: X-Spam-Status: No, score=-105.198 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPw5hx93qC2v for ; Wed, 6 Apr 2011 18:46:52 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3490E3A682C for ; Wed, 6 Apr 2011 18:46:52 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id p371mYJ9011128 for ; Thu, 7 Apr 2011 01:48:35 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.4) with ESMTP id p371mYSd002336 for ; Wed, 6 Apr 2011 18:48:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.145.239.205] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.sfbay.sun.com (Oracle Communications Messaging Exchange Server 7u5-2.03 64bit (built Feb 6 2011)) with ESMTPA id <0LJ900746ECWI600@gotmail.sfbay.sun.com> for kitten@ietf.org; Wed, 06 Apr 2011 18:48:34 -0700 (PDT) Date: Wed, 06 Apr 2011 18:48:37 -0700 From: Chris Newman To: Simon Josefsson , kitten@ietf.org Message-id: <84490F444F575850E7A31820@dhcp-rmdc-twvpn-2-vpnpool-10-159-63-236.vpn.oracle.com> In-reply-to: <878vvnza9w.fsf_-_@latte.josefsson.org> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf__24773.333388339$1302102086$gmane$org@latte.josefsson.org> <878vvnza9w.fsf_-_@latte.josefsson.org> X-Mailer: Mulberry/4.0.8 (Mac OS X) Subject: Re: [kitten] SCRAM as GSS mech X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 01:46:53 -0000 --On April 6, 2011 17:09:47 +0200 Simon Josefsson wrote: > Simon Josefsson writes: >> This interface and password prompting are the two most important GSS-API >> additions that I'd like to see standardized. > > Password prompting is the main reason I have not implemented SCRAM as a > GSS-API mechanism. Has anyone implemented SCRAM for GSS-API in any way > that makes sense for a reasonable application? If so, how do you handle > password prompts on the client side, and password/verifier storage on > the server side? > > I have considered using a gnupg-agent/pinentry style approach to let the > GSS-API library directly query the user for a password on the client > side without the application knowing, but until I have figured out how > to resolve the same problem on the server side, I don't want to write > the implementation. I find RFC 5803 a satisfactory option for server-side SCRAM storage. - Chris From lha@kth.se Thu Apr 7 06:11:50 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0943528C0E3 for ; Thu, 7 Apr 2011 06:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj0nEWUmrvHV for ; Thu, 7 Apr 2011 06:11:49 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 0D1013A6987 for ; Thu, 7 Apr 2011 06:11:48 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 78BA8156B44; Thu, 7 Apr 2011 15:13:02 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id BcFo9csuvota; Thu, 7 Apr 2011 15:13:01 +0200 (CEST) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-1.sys.kth.se (Postfix) with ESMTP id BE414156B38; Thu, 7 Apr 2011 15:12:58 +0200 (CEST) Received: from EXDB2.ug.kth.se ([169.254.2.236]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.01.0255.000; Thu, 7 Apr 2011 15:12:58 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Simon Josefsson Thread-Topic: [kitten] gss_userok Thread-Index: AQHL9Gtu8s0gRvS0gEuUB3tpJQg2S5RSQKiA Date: Thu, 7 Apr 2011 13:12:58 +0000 Message-ID: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> In-Reply-To: <87fwpvzaon.fsf@latte.josefsson.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2457B98BB4956245B7B1BA6904DF6174@ug.kth.se> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 13:11:50 -0000 6 apr 2011 kl. 08:00 skrev Simon Josefsson: > This interface and password prompting are the two most important GSS-API > additions that I'd like to see standardized. The problem with gss_userok() is many of the protocols using gssapi there i= s no username to validate (sasl based one for example) and in may cases the= OS, esp when connected to directory services, can do a lot better then "st= ring-before-@" as username. Love From ghudson@mit.edu Thu Apr 7 08:43:56 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349E43A6A11 for ; Thu, 7 Apr 2011 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5xwWLpeOFpB for ; Thu, 7 Apr 2011 08:43:55 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 3387B3A69CA for ; Thu, 7 Apr 2011 08:43:55 -0700 (PDT) X-AuditID: 12074423-b7b8eae000003d4f-9f-4d9ddc29ea19 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C4.D5.15695.92CDD9D4; Thu, 7 Apr 2011 11:45:45 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p37FjdPM006935 for ; Thu, 7 Apr 2011 11:45:39 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p37Fja2u007767 for ; Thu, 7 Apr 2011 11:45:39 -0400 (EDT) Date: Thu, 7 Apr 2011 11:45:36 -0400 (EDT) From: ghudson@MIT.EDU Message-Id: <201104071545.p37Fja2u007767@outgoing.mit.edu> To: kitten@ietf.org References: <201104051841.p35IfnaF018157@outgoing.mit.edu> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IR4hRV1tW8M9fXYN9zcYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro+XaNsaCZXwVi1/0MTUwbufuYuTkkBAwkdj2fDErhC0mceHe erYuRi4OIYF9jBLvDk9ngnCOMkr82LeYCaRKSKCXSWLz6iwQm0VAS+LilqnMIDabgKjEhw8X wCbxClhJ3Fi+jw3EFhEQlti99R1QDQeHsIC4xKK/7hBjrCSWPVvBOIGRewEjwypG2ZTcKt3c xMyc4tRk3eLkxLy81CJdM73czBK91JTSTYwgn7K7KO9g/HNQ6RCjAAejEg9vSOccXyHWxLLi ytxDjJIcTEqivAG35/oK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGtrgfK8aYkVlalFuXDpKQ5 WJTEeedKqvsKCaQnlqRmp6YWpBbBZGU4OJQkeKNAhgoWpaanVqRl5pQgpJk4OEGG8wANDwGp 4S0uSMwtzkyHyJ9iVJQS580ESQiAJDJK8+B6YTH3ilEc6BVhiHYeYLzCdb8CGswENHjhuTkg g0sSEVJSDYxhl3re5i70rDVe1X35VucVFhZukVP11zcrr9hp0HtOYYHig59ORgorJ7n3PK89 tWtd4Jbw4P69Wjzes0JYlzb5bNt5fukHD693V15MyI9aseW7kKMB27bF7mqbexi/zI9Wddv5 5oz4YnujxG+fTU1lt69PCm95tVlKNzVGc8H3fyHi0sbbfkxRYinOSDTUYi4qTgQAtRGJBpQC AAA= Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:43:56 -0000 Discussion is petering out a bit. Here is where I stand (which is important insofar as it will affect what happens on the MIT krb5 trunk, in the absence of progress on a standard): * I like Sam's prototype which looks like: OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t lname); * I like the idea of a gss_userok() convenience wrapper using the Gnu GSS prototype, which will save some callers the trouble of importing the username and processing the error status. I am open to Simon's concerns that what we are implementing does not match the documentation for the Gnu GSS gss_userok() symbol, but at this time I believe that the Gnu GSS documentation overspecifies the function (and specifies something inconsistent with GSSAPI concepts, and also inconsistent with what the Gnu GSS implementation does). * A couple of people have pointed out circumstances to which gss_userok() is not applicable. I'm not sure why. The primary use case here is a protocol implementation which integrates with system accounts (e.g. sshd, ftpd), for a protocol which takes a requested username argument. Other kinds of local names could be added into Sam's suggested prototype, but we don't currently have use csaes for those. There are lots of authorization problems for which gss_userok is not interesting, and probably lots of mechanisms which won't have an interesting answer. All of this was known going in. * The name is, as usual, the most vexing question. With Sam's prototype, variants on "gss_userok" and or "gss_loginok" are probably too restrictive in scope for the function name. I've unfortunately lost Sam's most recent list of suggestions (I guess it didn't go to this list). I currently favor gss_authorize_localname(). From nico@cryptonector.com Thu Apr 7 08:52:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006B228C148 for ; Thu, 7 Apr 2011 08:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiPai+6FwY7b for ; Thu, 7 Apr 2011 08:52:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 365B628C0DB for ; Thu, 7 Apr 2011 08:52:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 0DDB4674074 for ; Thu, 7 Apr 2011 08:54:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=G/HEex4aVBfvDho4lhLIEyobgBWv+TF0qcgiKCXKsCwg LuKmjSEBHfaxAp9l3eFv0iHpfQYk8GVD+AIWcr5DW7Tn1PiITZDcQMV2S7qc4RxN TV8+hAUe/aiXOeB1NgWB0FlwMylMcIe0hUi1Mf+WSC/kcKRXruMJZ2WkDTbTxkg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=PHIFCegefam4KrYMziG9gOHoNZY=; b=sjNikPto1vP JKWmInz5mL3xc8etx99LcziX7GHMwugCSCNxF9cHNbINwEZVsjuaGrtGHdZSb2z2 UV8Ca6eTS2GgRv9P+Hg8p6G9T1h/wD06nGuOnGv/5u+vTY5zmSx2Za/dI9c+81wj 13wrjnteNkb+rz7HMBXf3qxuWA3GSXWI= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id DCAAD674070 for ; Thu, 7 Apr 2011 08:54:34 -0700 (PDT) Received: by vws12 with SMTP id 12so2488820vws.31 for ; Thu, 07 Apr 2011 08:54:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.106 with SMTP id s10mr1509777vdv.150.1302191674283; Thu, 07 Apr 2011 08:54:34 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 7 Apr 2011 08:54:34 -0700 (PDT) In-Reply-To: <201104071545.p37Fja2u007767@outgoing.mit.edu> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> Date: Thu, 7 Apr 2011 10:54:34 -0500 Message-ID: From: Nico Williams To: ghudson@mit.edu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 15:52:51 -0000 On Thu, Apr 7, 2011 at 10:45 AM, wrote: > Discussion is petering out a bit. =C2=A0Here is where I stand (which is > important insofar as it will affect what happens on the MIT krb5 > trunk, in the absence of progress on a standard): +1 Nico -- From lukeh@padl.com Thu Apr 7 16:10:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C214428C188 for ; Thu, 7 Apr 2011 16:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNmR51D5RjTq for ; Thu, 7 Apr 2011 16:10:46 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 82F5E28C120 for ; Thu, 7 Apr 2011 16:10:45 -0700 (PDT) Received: by us.padl.com with ESMTP id p37NCN2N014230; Thu, 7 Apr 2011 19:12:27 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201104071545.p37Fja2u007767@outgoing.mit.edu> Date: Fri, 8 Apr 2011 09:12:23 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> To: ghudson@MIT.EDU X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 23:10:47 -0000 > OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t = lname); What happened to user_ok boolean? -- Luke= From lukeh@padl.com Thu Apr 7 16:12:47 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2957B28C18E for ; Thu, 7 Apr 2011 16:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bhmRbcml1fc for ; Thu, 7 Apr 2011 16:12:46 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 8D5A228C188 for ; Thu, 7 Apr 2011 16:12:46 -0700 (PDT) Received: by us.padl.com with ESMTP id p37NER68019507; Thu, 7 Apr 2011 19:14:30 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201104071545.p37Fja2u007767@outgoing.mit.edu> Date: Fri, 8 Apr 2011 09:14:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> To: ghudson@MIT.EDU X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 23:12:47 -0000 > OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t = lname); If this name is not a MN, this breaks SPI-as-API. Not that there's = anything wrong with this, but the SPI will need to take a = gss_const_buffer_t for now (unless you can explain to me how we should = represent non-MNs as MNs). Hence, +1 for gss_const_buffer_t or const char * (back where we started) = from me. -- Luke= From lukeh@padl.com Thu Apr 7 16:21:08 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C363F3A6A2A for ; Thu, 7 Apr 2011 16:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkMpBecDVbaX for ; Thu, 7 Apr 2011 16:21:07 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 8B1873A69B1 for ; Thu, 7 Apr 2011 16:21:07 -0700 (PDT) Received: by us.padl.com with ESMTP id p37NMmIi003143; Thu, 7 Apr 2011 19:22:50 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <201104071545.p37Fja2u007767@outgoing.mit.edu> Date: Fri, 8 Apr 2011 09:22:47 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> To: ghudson@MIT.EDU X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 23:21:08 -0000 OK, I committed an untested implementation to moonshot-mechglue-fixes = (this branch is otherwise merged now so I figure I can re-use it). Tweak = away. -- Luke From lukeh@padl.com Thu Apr 7 17:16:53 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3929B3A67EB for ; Thu, 7 Apr 2011 17:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqpdpKz0ecXm for ; Thu, 7 Apr 2011 17:16:52 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 73E013A67DB for ; Thu, 7 Apr 2011 17:16:52 -0700 (PDT) Received: by us.padl.com with ESMTP id p380IVlb008068; Thu, 7 Apr 2011 20:18:34 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> Date: Fri, 8 Apr 2011 10:18:31 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: Greg Hudson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:16:53 -0000 Here's the prototype. I'm not saying I like anything about this API. OK, = maybe that's a bit harsh. Using gss_name_t is clever. int gss_userok(const gss_name_t name, const char *username); OM_uint32 gss_authorize_localname(OM_uint32 *minor, const gss_name_t name, const gss_name_t user, int *user_ok); The SPI prototype is: OM_uint32 (*gssspi_authorize_localname) ( OM_uint32 *, /* minor_status */ const gss_name_t, /* pname */ gss_const_buffer_t, /* local user */ int * /* user ok? */ /* */); -- Luke On 08/04/2011, at 9:22 AM, Luke Howard wrote: > OK, I committed an untested implementation to moonshot-mechglue-fixes = (this branch is otherwise merged now so I figure I can re-use it). Tweak = away. >=20 > -- Luke > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From lukeh@padl.com Thu Apr 7 17:55:41 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01143A6934 for ; Thu, 7 Apr 2011 17:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2ExoFJPTbMK for ; Thu, 7 Apr 2011 17:55:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 9A6E13A67D9 for ; Thu, 7 Apr 2011 17:55:39 -0700 (PDT) Received: by us.padl.com with ESMTP id p380vK3l020117; Thu, 7 Apr 2011 20:57:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 8 Apr 2011 10:57:19 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: Greg Hudson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:55:41 -0000 It's kind of ugly that we're using "local-login-user" (as suggested by = Sam) for the GSS attribute for the local name, but "localname" in = gss_authorize_localname(). We should either=20 * do nothing * change the symbolic name from GSS_C_ATTR_LOCAL_LOGIN_USER to = GSS_C_ATTR_LOCAL_NAME * change both symbolic name and actual attribute name -- Luke= From lukeh@padl.com Thu Apr 7 17:58:04 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B2A3A6934 for ; Thu, 7 Apr 2011 17:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zy110WbmArR for ; Thu, 7 Apr 2011 17:58:03 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 9A2723A695E for ; Thu, 7 Apr 2011 17:58:03 -0700 (PDT) Received: by us.padl.com with ESMTP id p380xiAZ024227; Thu, 7 Apr 2011 20:59:47 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> Date: Fri, 8 Apr 2011 10:59:44 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: Greg Hudson Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 00:58:04 -0000 On 08/04/2011, at 9:22 AM, Luke Howard wrote: > OK, I committed an untested implementation to moonshot-mechglue-fixes = (this branch is otherwise merged now so I figure I can re-use it). Tweak = away. Similarly untested implementation committed to moonshot branch of = Heimdal. -- Luke= From lukeh@padl.com Thu Apr 7 23:49:36 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073A23A69F8 for ; Thu, 7 Apr 2011 23:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqZCWhK7ipxc for ; Thu, 7 Apr 2011 23:49:35 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 4E0123A6989 for ; Thu, 7 Apr 2011 23:49:35 -0700 (PDT) Received: by us.padl.com with ESMTP id p386p4NW005392; Fri, 8 Apr 2011 02:51:13 -0400 References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf@latte.josefsson.org> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <565BF3DE-9F7C-4AB0-AC20-3EA857E503ED@padl.com> X-Mailer: iPhone Mail (8G4) From: Luke Howard Date: Fri, 8 Apr 2011 16:50:58 +1000 To: =?utf-8?Q?Love_H=C3=B6rnquist_=C3=85strand?= X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.6 Cc: "" , Simon Josefsson , Sam Hartman Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 06:49:36 -0000 So, use something else, like gss_get_name_attribute... Von meinem iPhone gesendet Am 07/04/2011 um 23:12 schrieb Love H=C3=B6rnquist =C3=85strand = : >=20 > 6 apr 2011 kl. 08:00 skrev Simon Josefsson: >=20 >> This interface and password prompting are the two most important GSS-API >> additions that I'd like to see standardized. >=20 > The problem with gss_userok() is many of the protocols using gssapi there i= s no username to validate (sasl based one for example) and in may cases the O= S, esp when connected to directory services, can do a lot better then "strin= g-before-@" as username. >=20 > Love >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Fri Apr 8 00:30:33 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DE43A69F3 for ; Fri, 8 Apr 2011 00:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hgU4YmogK2N for ; Fri, 8 Apr 2011 00:30:32 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id E4EBA3A681B for ; Fri, 8 Apr 2011 00:30:31 -0700 (PDT) Received: (qmail 82361 invoked by uid 60001); 8 Apr 2011 07:32:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302247933; bh=zPYhvHEClYt/oH5YA7ZXBRC4IPCfw55cXIQ0x4yfSEg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VzYP8fmGs9N9Ijna9H+GqFold1SAs8d1wyGI4Hdt5fiYNkOdqzZb+6GfDsagNTxJZAd7pEUThGExaKThpvT0CHyWcIUW0zhqWOCP9uWLU+IkfMXwTCmS8C1iylWGBq5YvxAKqrCxea3JgQNDpqGBvzQcmm2dTbNAwDG//foJFP4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=IpXkngKAHslBuLojzUuXbNUmwcLeZL6P51HcgTysQ5BhDi4Zb/v3+Kic4JTrJYbH6wPHWVD/RGJX0g2E2HJ/o1pZpkuxCws+ImK1iMN/zDacVg1Pr35jjR+DjEvFXo24UPfTdYAX9eOZxyOy2OPHI0MZAzl2O57Z9zGjapW1WL8=; Message-ID: <416848.75882.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: clnHv.0VM1nmaneufVssYysYCzuND_RNPN0bI73wlqLeg9c lrrKGtuIaDlNHy3ZKy4cEMnBNoXcfQfw_i7B5XmuEh65B8J.c1pJ6SCbY7IQ OUGQqnuP1oQhuEC5lfhYOW6h8zF8tMJellEV_WMrmL3dEEWwrhmsqHH6Q_OI vKalKhUB7AXFYLH7twt2iywxiJCv60.4cyIJjsYuxky0ClfPSgZJ9QYNmnxZ 51e3F3xvgK2FHRu206ClezLLmdnSYSQ0kyfwFUXxQVonhjXcM3m3.kykPb8_ EtYExQp5i_PUM5GLPlVSpnZLmoZbi_pN7VgA9JfImjjKMAuoKu9BNMXEWvKM HVA.1dpZ6PWsfMVVfRFqXH9TCGv55aMrmFNdQsyE7 Received: from [209.131.62.115] by web32314.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 00:32:13 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> Date: Fri, 8 Apr 2011 00:32:13 -0700 (PDT) From: "William J. Mills" To: "kitten@ietf.org" In-Reply-To: <20110408070506.12ECB3A6A4C@core3.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1399281102-1302247933=:75882" Cc: Tim Showalter Subject: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 07:30:33 -0000 --0-1399281102-1302247933=:75882 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable All,=0A=0AI have added channel binding to OAUTH mechanism draft.=A0 I would= very much appreciate someone that knows CB giving it a read to make sure I= 'm on the right track.=A0 Significant changes in this draft:=0A=0A-=A0=A0 A= dded channel binding=0A- =A0 Updated security considerations=0A-=A0=A0 Adde= d language specifying how to map identities in OAuth to identities in SASL.= =0A-=A0=A0 Updated examples=0A=0AThanks,=0A=0A-bill mills=0A=0A=0A----- For= warded Message -----=0AFrom: IETF I-D Submission Tool =0ATo: wmills@yahoo-inc.com=0ACc: timshow@yahoo-inc.com; Hannes.Tschofeni= g@gmx.net=0ASent: Friday, April 8, 2011 12:05 AM=0ASubject: New Version Not= ification for draft-mills-kitten-sasl-oauth-02 =0A=0A=0AA new version of I-= D, draft-mills-kitten-sasl-oauth-02.txt has been successfully submitted by = William Mills and posted to the IETF repository.=0A=0AFilename:=A0=A0=A0 d= raft-mills-kitten-sasl-oauth=0ARevision:=A0=A0=A0 02=0ATitle:=A0=A0=A0 =A0= =A0=A0 A SASL Mechanism for OAuth=0ACreation_date:=A0=A0=A0 2011-04-08=0A= WG ID:=A0=A0=A0 =A0=A0=A0 Independent Submission=0ANumber_of_pages: 22=0A= =0AAbstract:=0ASimple Authentication and Security Layer (SASL) is a framewo= rk for=0Aproviding authentication and data security services in connection-= =0Aoriented protocols via replaceable mechanisms.=A0 OAuth is a protocol=0A= framework for delegated HTTP authentication and thereby provides a=0Amethod= for clients to access a protected resource on behalf of a=0Aresource owner= .=0A=0AThis document defines the use of HTTP authentication over SASL, and= =0Aadditionally defines authoriation and token issuing endpoint=0Adiscovery= .=A0 Thereby, it enables schemes defined within the OAuth=0Aframework for n= on-HTTP-based application protocols.=A0 A future version=0Aof this document= will describe the integration into the Generic=0ASecurity Services Applica= tion Program Interface (GSS-APIO).=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =0A=0A=0AThe IETF Secr= etariat. --0-1399281102-1302247933=:75882 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I have added chan= nel binding to OAUTH mechanism draft.  I would very much appreciate so= meone that knows CB giving it a read to make sure I'm on the right track.&n= bsp; Significant changes in this draft:

<= /div>
-   Added channel binding
-   Updated security considerations
-   Added language specifying how to = map identities in OAuth to identities in SASL.
-&nbs= p;  Updated examples

Thanks,

-bill mills

----- Forwarded Message -----
From: IETF I-D Submission Tool <idsubmis= sion@ietf.org>
To: w= mills@yahoo-inc.com
Cc:= timshow@yahoo-inc.com; Hannes.Tschofenig@gmx.net
Sent: Friday, April 8, 2011 12:05 AM
Subject: New Version Notification = for draft-mills-kitten-sasl-oauth-02

=0A
A new version of= I-D, draft-mills-kitten-sasl-oauth-02.txt has been successfully submitted = by William Mills and posted to the IETF repository.

Filename: &= nbsp;  draft-mills-kitten-sasl-oauth
Revision:    = 02
Title:        A SASL Mechanism for OAu= th
Creation_date:    2011-04-08
WG ID:  &nb= sp;     Independent Submission
Number_of_pages: 22
Abstract:
Simple Authentication and Security Layer (SASL) is a framewo= rk for
providing authentication and data security services in connection= -
oriented protocols via replaceable mechanisms.  OAuth is a protoc= ol
framework for delegated HTTP authentication and thereby provides amethod for clients to access a protected resource on behalf of a
resour= ce owner.

This document defines the use of HTTP authentication over = SASL, and
additionally defines authoriation and token issuing endpoint
discovery.  Thereby, it enables schemes= defined within the OAuth
framework for non-HTTP-based application proto= cols.  A future version
of this document will describe the integrat= ion into the Generic
Security Services Application Program Interface (GS= S-APIO).
                  =                      = ;                     &nb= sp;                     <= br>

The IETF Secretariat.




--0-1399281102-1302247933=:75882-- From simon@josefsson.org Fri Apr 8 01:25:41 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFAC63A68CB for ; Fri, 8 Apr 2011 01:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.126 X-Spam-Level: X-Spam-Status: No, score=-103.126 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UDZm883I3Su for ; Fri, 8 Apr 2011 01:25:14 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id C14893A68B5 for ; Fri, 8 Apr 2011 01:25:00 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p388QPPJ007741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Apr 2011 10:26:27 +0200 From: Simon Josefsson To: "William J. Mills" References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110408:wmills@yahoo-inc.com::Fw3tcSSnbiQG8POK:0RQx X-Hashcash: 1:22:110408:kitten@ietf.org::ByXgFFkHGnH2CDXN:ATsl X-Hashcash: 1:22:110408:timshow@yahoo-inc.com::1mC22ABIPnvjtVtf:CBvc Date: Fri, 08 Apr 2011 10:26:25 +0200 In-Reply-To: <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> (William J. Mills's message of "Fri, 8 Apr 2011 00:32:13 -0700 (PDT)") Message-ID: <87hba9b13i.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 08:25:42 -0000 "William J. Mills" writes: > All, > > I have added channel binding to OAUTH mechanism draft.  I would very > much appreciate someone that knows CB giving it a read to make sure > I'm on the right track.  Significant changes in this draft: This is great! Channel binding [RFC5056] in this mechanism is defined in order to allow satisfying the security requirements of the authorization schemes used. This document defines the "OAUTH-SSL" mechanism to provide TLS channel binding [RFC5929] to the OAUTH mechanim, and specifically the "tls-unique" type of channel binding. The intention is that tls-server-end-point is not permitted at all, right? Perhaps it is clearer to have the last sentence say This document defines the "OAUTH-SSL" mechanism to provide the "tls-unique" TLS channel binding [RFC5929] to the OAUTH mechanim. cbdata (REQUIRED): Contains the base64 encoded first TLS Finished message sent. Don't mention the Finished message here, people have gotten the details wrong before and the gory details (including people's mistakes) are in RFC 5929. Say instead: cbdata (REQUIRED): Contains the base64 encoded "tls-unique" channel binding data. Otherwise it looks good. I'm tempted to have a go at implementing this in GNU SASL actually. :-) /Simon From simon@josefsson.org Fri Apr 8 01:35:16 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A69043A68D1 for ; Fri, 8 Apr 2011 01:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUJVFTnax694 for ; Fri, 8 Apr 2011 01:35:16 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A830D3A681B for ; Fri, 8 Apr 2011 01:35:15 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p388ahJq008188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Apr 2011 10:36:45 +0200 From: Simon Josefsson To: "William J. Mills" References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110408:wmills@yahoo-inc.com::aLT2od43deD3tvlz:44Pa X-Hashcash: 1:22:110408:kitten@ietf.org::hb2da4LsSpiRHEgu:Sl/6 X-Hashcash: 1:22:110408:timshow@yahoo-inc.com::jWby3C9dJTXToeRs:Q7us Date: Fri, 08 Apr 2011 10:36:43 +0200 In-Reply-To: <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> (William J. Mills's message of "Fri, 8 Apr 2011 00:32:13 -0700 (PDT)") Message-ID: <87d3kxb0mc.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 08:35:16 -0000 Btw, you may want to update your example with something real. Replace GET /?cbdata="SG93IGJpZyBpcyBhIFRMUyBmaW5hbCBtZXNzYWdlPwo=" HTTP/1.1 with GET /?cbdata="yYPi2+ohQa/xwhJH" HTTP/1.1 Btw should the quotes really be there? I.e., shouldn't it be: GET /?cbdata=yYPi2+ohQa/xwhJH HTTP/1.1 Btw, have you considered the issue with URL escaping of + and /? Maybe you want to use the URL-safe Base64 alphabet instead to avoid that issue? Just reference RFC 4648 and "base64url". Thanks, /Simon From ghudson@mit.edu Fri Apr 8 07:44:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 701843A68EC for ; Fri, 8 Apr 2011 07:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RH7U8TcrunT for ; Fri, 8 Apr 2011 07:44:57 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 84B103A6820 for ; Fri, 8 Apr 2011 07:44:57 -0700 (PDT) X-AuditID: 1209190c-b7b7aae0000047c7-9b-4d9f1fd794be Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 09.22.18375.7DF1F9D4; Fri, 8 Apr 2011 10:46:47 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p38Ekg6V028621; Fri, 8 Apr 2011 10:46:42 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p38EkbJB023048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2011 10:46:41 -0400 (EDT) From: Greg Hudson To: Luke Howard In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Apr 2011 10:46:37 -0400 Message-ID: <1302273997.10465.569.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0b0uP9/X4M1fLoujm1exWNy99J/d gcljyZKfTB5zP0xjCWCK4rJJSc3JLEst0rdL4Mr4s6advWADc8XTP9uYGxjvMXUxcnJICJhI LFz3hwXCFpO4cG89WxcjF4eQwD5Gias/lrNAOOuBnIlPoJy7TBL/j/5lBWkRFlCQ+D5rOyOI zSagLHHw7DewUSJA8cn71zKD2MwC6hJHnzcBjeXg4BSwkTj4yR5iznxGiRv3mtghajQlWrf/ BrNZBFQlNhyexQhSzyugK9HR7w5hCkr83SEMcai0xNcJT5ggOuUltr+dwzyBUXAWkkGzEDpm IalawMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdQLzezRC81pXQTIyh4OSV5djC+Oah0iFGA g1GJh/fmrbm+QqyJZcWVuYcYJTmYlER5v8jN9xXiS8pPqcxILM6ILyrNSS0+xCjBwawkwutm M89XiDclsbIqtSgfJiXNwaIkzjtDUt1XSCA9sSQ1OzW1ILUIJivDwaEkwWsKjFIhwaLU9NSK tMycEoQ0EwcnyHAeoOHtIIt5iwsSc4sz0yHypxh1Of5vObSPUYglLz8vVUqclx9kkABIUUZp HtwcWNJ5xSgO9JYw7xuQUTzAhAU36RXQEiagJZp8YEtKEhFSUg2MZj6+b2bxJcpsqpn9w/sX j0Og8pGEpf2yGk/z7yo5N8x9er1lBudf9Tjpc9brUhl/q/d4d12ZXM9yqnz5YZ+fJ6ceKmMX d4/2r+ab57i35dgmwfkXHolazNi0dUrBgo5lS777Bt3nvX1+2opqo2veq7LzAzcYeTh7R/Wc Z0nIKCypn8R2w/uFEktxRqKhFnNRcSIAz77r8hUDAAA= Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 14:44:58 -0000 On Thu, 2011-04-07 at 19:12 -0400, Luke Howard wrote: > > OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t lname); > > What happened to user_ok boolean? A good question. Sam, was that an oversight, or did you intend the function to return GSS_S_SUCCESS for authorized and GSS_S_UNAUTHORIZED for unauthorized? That way the mech could provide a reason for failure via the minor code if it wants. From ghudson@mit.edu Fri Apr 8 07:52:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE123A6938 for ; Fri, 8 Apr 2011 07:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktc-TmmAuq3b for ; Fri, 8 Apr 2011 07:52:54 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id B8CC23A6876 for ; Fri, 8 Apr 2011 07:52:53 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-56-4d9f21a711a9 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 38.76.18470.7A12F9D4; Fri, 8 Apr 2011 10:54:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p38EscbZ024019; Fri, 8 Apr 2011 10:54:38 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p38EsZFF024826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2011 10:54:37 -0400 (EDT) From: Greg Hudson To: Luke Howard In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Apr 2011 10:54:35 -0400 Message-ID: <1302274475.10465.575.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1l2uON/X4MJFK4ujm1exWNy99J/d gcljyZKfTB5zP0xjCWCK4rJJSc3JLEst0rdL4MrYt0y34DFbxdnH19kbGE+ydDFyckgImEi8 3HCMCcIWk7hwbz1bFyMXh5DAPkaJew/fsUI46xklZu1cB5W5yySx/P9xdpAWYQEFie+ztjOC 2GwCyhIHz34DGysCFJ+8fy0ziM0soC5x9HkTUDMHB6eAjUTvdj+IOa1MEr/OXWeEqNGUaN3+ G2wmi4CqxLkFj8Dm8AroSkx+DjKHA8gWlPi7QxjiUmmJrxOeMEG0yktsfzuHeQKj4Cwkk2Yh dMxCUrWAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcPBK8u5gfHdQ6RCj AAejEg/vg1tzfYVYE8uKK3MPMUpyMCmJ8n6Rm+8rxJeUn1KZkVicEV9UmpNafIhRgoNZSYTX zWaerxBvSmJlVWpRPkxKmoNFSZx3pqS6r5BAemJJanZqakFqEUxWhoNDSYJXEhilQoJFqemp FWmZOSUIaSYOTpDhPEDD+UBqeIsLEnOLM9Mh8qcYdTn+bzm0j1GIJS8/L1VKnPeuAlCRAEhR Rmke3BxY0nnFKA70ljCvAMgoHmDCgpv0CmgJE9ASTT6wJSWJCCmpBsbth8KtLr9aYWc64VmA NPdv1ph/b1JmXFPuY1I/tld2O3+JZa7AppoyBdOb9bN2sxVNir3xZft9bkXTHftTPKp2F+v9 W2k7YUFozbU0eeaZ9nkvb21T7r2xOvFoafbebZqv6ztvswm8v/yIVVY+qaTv13G5Svdb3VOD D5o89czTM36c9XOyvrISS3FGoqEWc1FxIgDQnMaiFQMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 14:52:55 -0000 On Thu, 2011-04-07 at 20:57 -0400, Luke Howard wrote: > It's kind of ugly that we're using "local-login-user" (as suggested by > Sam) for the GSS attribute for the local name, but "localname" in > gss_authorize_localname(). My intention in picking gss_authorize_localname() was that "localname" could eventually be a larger category than usernames (system login accounts), even though right now we only have a use case for usernames. > OM_uint32 (*gssspi_authorize_localname) > ( > OM_uint32 *, /* minor_status */ > const gss_name_t, /* pname */ > gss_const_buffer_t, /* local user */ > int * /* user ok? */ > /* */); I'd suggest a name type parameter in the SPI, to fully specify the internal name. From hartmans@mit.edu Fri Apr 8 09:32:23 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30FC3A69BD for ; Fri, 8 Apr 2011 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRM2xkJJ5wo1 for ; Fri, 8 Apr 2011 09:32:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EEE0B3A69A3 for ; Fri, 8 Apr 2011 09:32:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9076920384; Fri, 8 Apr 2011 12:30:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0AC46446E; Fri, 8 Apr 2011 12:34:00 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> Date: Fri, 08 Apr 2011 12:34:00 -0400 In-Reply-To: <1302273997.10465.569.camel@t410> (Greg Hudson's message of "Fri, 08 Apr 2011 10:46:37 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:32:23 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> On Thu, 2011-04-07 at 19:12 -0400, Luke Howard wrote: >> > OM_uint32 something(OM_uint32 *minor, gss_name_t authname, >> gss_name_t lname); >> >> What happened to user_ok boolean? Greg> A good question. Sam, was that an oversight, or did you Greg> intend the function to return GSS_S_SUCCESS for authorized and Greg> GSS_S_UNAUTHORIZED for unauthorized? That way the mech could Greg> provide a reason for failure via the minor code if it wants. That was an oversight. From hartmans@mit.edu Fri Apr 8 09:34:21 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95AC23A694F for ; Fri, 8 Apr 2011 09:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.848 X-Spam-Level: X-Spam-Status: No, score=-102.848 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0W4KWPEI+f8 for ; Fri, 8 Apr 2011 09:34:21 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1F5FA3A6889 for ; Fri, 8 Apr 2011 09:34:21 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E2E8820384; Fri, 8 Apr 2011 12:32:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56035446E; Fri, 8 Apr 2011 12:36:01 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> Date: Fri, 08 Apr 2011 12:36:01 -0400 In-Reply-To: <87hba9b13i.fsf@latte.josefsson.org> (Simon Josefsson's message of "Fri, 08 Apr 2011 10:26:25 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 16:34:21 -0000 I'm confused. Why does the oauth sasl mechanism want to restrict what channel binding types are permitted? Also, why the desire to require tls-unique instead of tls-server-endpoint? The tls-server-endpoint channel binding type is easier to implement. From lha@kth.se Fri Apr 8 10:24:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2560C3A6959 for ; Fri, 8 Apr 2011 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.835 X-Spam-Level: X-Spam-Status: No, score=-5.835 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xARHnZIi2NER for ; Fri, 8 Apr 2011 10:24:23 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 787083A68D4 for ; Fri, 8 Apr 2011 10:24:23 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id AFD1B156B4B; Fri, 8 Apr 2011 19:25:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id GX878CsbRlBB; Fri, 8 Apr 2011 19:25:36 +0200 (CEST) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 71BD0156B49; Fri, 8 Apr 2011 19:25:36 +0200 (CEST) Received: from EXDB2.ug.kth.se ([169.254.2.236]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.01.0255.000; Fri, 8 Apr 2011 19:25:35 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: " " Thread-Topic: [kitten] gss_userok Thread-Index: AQHL9TrW8s0gRvS0gEuUB3tpJQg2S5RUF/IA Date: Fri, 8 Apr 2011 17:25:35 +0000 Message-ID: <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> In-Reply-To: <201104071545.p37Fja2u007767@outgoing.mit.edu> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [17.244.24.126] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:24:24 -0000 7 apr 2011 kl. 08:45 skrev : > A couple of people have pointed out circumstances to which > gss_userok() is not applicable. I'm not sure why. The primary use > case here is a protocol implementation which integrates with system > accounts (e.g. sshd, ftpd), for a protocol which takes a requested > username argument. Other kinds of local names could be added into > Sam's suggested prototype, but we don't currently have use csaes for > those. usecase: nfsd, smbd <- protocol that integrates with system accounts and do= n't have username. Love From wmills@yahoo-inc.com Fri Apr 8 10:30:03 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093883A68D5 for ; Fri, 8 Apr 2011 10:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+zFTUYG-zvb for ; Fri, 8 Apr 2011 10:30:00 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 12B823A68D4 for ; Fri, 8 Apr 2011 10:30:00 -0700 (PDT) Received: (qmail 2238 invoked by uid 60001); 8 Apr 2011 17:31:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302283902; bh=37IgLVjf5qP0VsizaKXmmJLk+YPPWeFijkczD++NVkg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=iPX68c0FJCNbHPopVGFvb4JEb3BSVS6MUoTwLh5Dp3OTIRA+WwB88St92e1ROSLleswLoVv/UqbBCrBd4Xtbxa1iucBG/LUQCPm/ctu5gmwo9ETHKPlwXrAuo730vZV5kGbZVqfaNT2nAw4yuLheDu6RiUpIjowR0oNul/V5tec= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jIEtRrUQIWKWEIYzFJQJVRXsKI9ZkFf4VzaMIZK/ISC/DmrdSUPfoaXTUflppwG9XAII4IvpcF8oQ+xm8mkoVIjzw+aEKh5P/JXGtGijUtwtkdQHaExbt+9wPhye+vDCaJlyDqv7uNYA672WDuO+29NpprabjDVVUF6Xq0rVeag=; Message-ID: <754979.46407.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: DI6DyTMVM1m00QZS3qhl5JuJJYdObgsN1KuQEVMcfA_89xI 4co8mVw7.zxSTpONKXdc3X3QIc4pFNYQa0oPOhUIqu0NWNF_BmScZ8ya8oOu rlG3TqwOqrimTdjE8xyPRk6JaSajlfHiCV_QMZS_DFaglflXLFZnk_ZjZZ_2 8EQFVziCqjySB38w13_bMMBzrjaq8RKtWRkYztbWMtZU5zulC_WndSH4UN5x EOBX1OrewAYwNUFEAEE5gbORXLzcpjGiPo4CZw54dIX3H4AtZRxaWGlQi0dz Gx4eqeaEKRhD8yCR9PYb09UQ5.Hk7lNbdlw33aGvg7Df_.X4g.PS3nL8PFIs ZWiaaQwAaZBPyoFkoy6pf3gljnT9DNn1Byp_Dsxg- Received: from [209.131.62.115] by web32303.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 10:31:42 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> Date: Fri, 8 Apr 2011 10:31:42 -0700 (PDT) From: "William J. Mills" To: Sam Hartman , Simon Josefsson In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1789557634-1302283902=:46407" Cc: "kitten@ietf.org" , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:30:03 -0000 --0-1789557634-1302283902=:46407 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable At the moment I was going with simple.=A0 If multiple types are supported t= hen I have to be able to communicate what types of channel binding are acce= pted, which I suppose could go in the WWW-Authenticate header in the discov= ery information.=A0 It's relatively easy to add a variable for the CB type.= =0A=0AIf tls-server-end-point is easier to implement I'm happy to pick that= one, subject to limiting to a single CB type.=A0 =0A=0A=0AMy thought was t= hat if the service is offered over another secure channel then OAUTH-SSH co= uld be defined for channel binding to SSH.=0A=0A-bill=0A=0A=0A=0A__________= ______________________=0AFrom: Sam Hartman =0ATo: Si= mon Josefsson =0ACc: William J. Mills ; "kitten@ietf.org" ; Tim Showalter =0ASent: Friday, April 8, 2011 9:36 AM=0ASubject: Re: [kitten] Fw: N= ew Version Notification for draft-mills-kitten-sasl-oauth-02=0A=0AI'm conf= used.=0AWhy does the oauth sasl mechanism want to restrict what channel bin= ding=0Atypes are permitted?=0AAlso, why the desire to require tls-unique in= stead of=0Atls-server-endpoint?=0AThe tls-server-endpoint channel binding t= ype is easier to implement. --0-1789557634-1302283902=:46407 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
At the moment I was going with simple.  If multiple types are suppor= ted then I have to be able to communicate what types of channel binding are= accepted, which I suppose could go in the WWW-Authenticate header in the d= iscovery information.  It's relatively easy to add a variable for the = CB type.

If tls-s= erver-end-point is easier to implement I'm happy to pick that one, subject = to limiting to a single CB type. 

My tho= ught was that if the service is offered over another secure channel then OA= UTH-SSH could be defined for channel binding to SSH.

-bill

From: Sam Hartman <hartmans-ietf@mit.edu>
To: Simon Josefsson <simon@josefsson.org>=
Cc: William J. Mills &= lt;wmills@yahoo-inc.com>; "kitten@ietf.org" <kitten@ietf.org>; Tim= Showalter <timshow@yahoo-inc.com>
Sent: Friday, April 8, 2011 9:36 AM
Subject: Re: [kitten] Fw: New Version Notifi= cation for draft-mills-kitten-sasl-oauth-02

=0AI'm confused.=
Why does the oauth sasl mechanism want to restrict what channel binding=
types are permitted?
Also, why the desire to require tls-unique inst= ead of
tls-server-endpoint?
The tls-server-endpoint channel binding t= ype is easier to implement.


--0-1789557634-1302283902=:46407-- From hartmans@mit.edu Fri Apr 8 10:34:37 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B04EF3A6987 for ; Fri, 8 Apr 2011 10:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.839 X-Spam-Level: X-Spam-Status: No, score=-102.839 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+PgN8sqwv0c for ; Fri, 8 Apr 2011 10:34:37 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E5A263A68D4 for ; Fri, 8 Apr 2011 10:34:36 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7781620384; Fri, 8 Apr 2011 13:33:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 20737446E; Fri, 8 Apr 2011 13:36:16 -0400 (EDT) From: Sam Hartman To: "William J. Mills" References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> Date: Fri, 08 Apr 2011 13:36:16 -0400 In-Reply-To: <754979.46407.qm@web32303.mail.mud.yahoo.com> (William J. Mills's message of "Fri, 8 Apr 2011 10:31:42 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter , Sam Hartman Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:34:37 -0000 >>>>> "William" == William J Mills writes: William> At the moment I was going with simple. If multiple types William> are supported then I have to be able to communicate what William> types of channel binding are accepted, which I suppose William> could go in the WWW-Authenticate header in the discovery William> information. It's relatively easy to add a variable for William> the CB type. I don't think this is true if you're a SASL mechanism. I think that's the application's problem. I think all you have to do is communicate the channel binding type you support. Also, the abstract interface between the application and SASL assumes that all SASL mechanisms supporting any CB types support all CB types. This is even more true if you happen to be running through a GS2 bridge which may not be applicable to your mechanism. I promised Hannes at the meeting that near end of April I'd be happy to get up to speed on this and work with the draft authors on all this. I'm sorry I don't have time to do that this week or next but I'll get there. From cantor.2@osu.edu Fri Apr 8 10:43:01 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8463A69CF for ; Fri, 8 Apr 2011 10:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMZ5ViF2OZyo for ; Fri, 8 Apr 2011 10:43:00 -0700 (PDT) Received: from defang17.it.ohio-state.edu (defang17.it.ohio-state.edu [128.146.216.131]) by core3.amsl.com (Postfix) with ESMTP id 46DF33A6989 for ; Fri, 8 Apr 2011 10:43:00 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang17.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p38Higf7025784; Fri, 8 Apr 2011 13:44:42 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::cd73:7784:284f:8055%13]) with mapi; Fri, 8 Apr 2011 13:40:54 -0400 From: "Cantor, Scott E." To: Sam Hartman , "William J. Mills" Thread-Topic: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 Thread-Index: AQHL9camzvXiybg4x0K+SJssQCGSVZRUbZiAgAAPjgCAAAFHAP//vrZw Date: Fri, 8 Apr 2011 17:44:37 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.131 Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:43:01 -0000 > I think all you have to do is communicate the channel binding type you > support. I think you mean "the type you used", at least based on my reading of GS2. On the general subject of tls-unique vs. endpoint, I had a brief conversati= on with Simon about it, and I think some clarification on how server applic= ations would be expected to use tls-endpoint would be useful. How is it expected that servers would distinguish clients at the app layer = when non-unique CB is used? -- Scott From wmills@yahoo-inc.com Fri Apr 8 10:45:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A273A6989 for ; Fri, 8 Apr 2011 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA75D59P5Rab for ; Fri, 8 Apr 2011 10:45:21 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id B86C63A6841 for ; Fri, 8 Apr 2011 10:45:21 -0700 (PDT) Received: (qmail 26537 invoked by uid 60001); 8 Apr 2011 17:47:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302284821; bh=AXFgPPgHUaHx4UjiFsgsk1PS4HSyOEG8ut8BIAc4S8M=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hPStGs369rVUN5p64hQf1/HaCX89UhsN+Du3LRGLwgOQVaxsgpzERl3antsnkluOkvHqT2HjWzqmgBv+k1K/QwNCkvL44qLsmRyN5WlRm50m9XxKj2mmpjz/y8ZbBRT83emqumQ/hU+qKj5mG+naB/IKfc/EDdalIf75VjUIMF8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Dya1R5QLZOWjise5BkbPGT/1JlcwiqEu6PIHV6Ysl0XyCEg1hDaZJ0XlcBO3dC5U2tPc2ZYgtjV4DBXJiOaN4Oh8fbhRP0Tf5suQqmQM1fxA5qfSHZdjIu+Fns3TjP5kGGn6edbHvfuIOIZF7xU8PqSevbRUda/fni/85/QCb3I=; Message-ID: <951823.17690.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: UlvCClMVM1m10rP..GKzwA_62m5LJCSaK0mzQSUoF58skb9 MTI_sVSu6vi.Gl0cuhd0uuSN3jwp9ZxmMSCzNpkMtBIl7A_woa5Q9zEAi76p KuHw0GAxwWHnZSAW_6qreAQRaK80S.lQO75oZJAYLHPr0V3yOxGjmGMTPWEe wbGP3QWm2eO4FbcJj4ZAPk3pSeALe905hm5SaUXSd5jnI78.WC6_nGDuh8z6 G_QKkfWMvSIjJ.kkoJ.0fsfp37aYUPJO_kK9OLGsdqTiLlzVmf.3bv21ALGk D1j01qQbKzZ1pC4nj24jHIagfZkjofq7iXRUFnLxJ2RJ7S_DT8lrzf__wMyr MD2LmgepXctr9hQp2wr6K1enNTQReP.kks0S1uYWd Received: from [209.131.62.115] by web32314.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 10:47:01 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> Date: Fri, 8 Apr 2011 10:47:01 -0700 (PDT) From: "William J. Mills" To: Sam Hartman In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-408321053-1302284821=:17690" Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 17:45:23 -0000 --0-408321053-1302284821=:17690 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable OK, I've taken a note in my working copy to switch to -PLUS.=A0 I also need= to add communicating the CB variant.=0A=0AThanks very much for your first = look and I look forward to further feedback.=A0 Would it be useful for me t= o make these changes now and post a new draft, or is that too much churn?= =0A=0A=0A-bill=0A=0A=0A=0A________________________________=0AFrom: Sam Hart= man =0ATo: William J. Mills = =0ACc: Sam Hartman ; Simon Josefsson ; "kitten@ietf.org" ; Tim Showalter =0ASent: Friday, April 8, 2011 10:36 AM=0ASubject: Re: [kitten] Fw: = New Version Notification for draft-mills-kitten-sasl-oauth-02=0A=0A>>>>> "= William" =3D=3D William J Mills writes:=0A=0A=A0 =A0= William> At the moment I was going with simple.=A0 If multiple types=0A=A0= =A0 William> are supported then I have to be able to communicate what=0A= =A0 =A0 William> types of channel binding are accepted, which I suppose=0A= =A0 =A0 William> could go in the WWW-Authenticate header in the discovery= =0A=A0 =A0 William> information.=A0 It's relatively easy to add a variable = for=0A=A0 =A0 William> the CB type.=0A=0A=0AI don't think this is true if y= ou're a SASL mechanism.=0AI think that's the application's problem.=0AI thi= nk all you have to do is communicate=A0 the channel binding type you=0Asupp= ort.=0A=0AAlso, the abstract interface between the application and SASL ass= umes=0Athat all SASL mechanisms supporting any CB types support all CB type= s.=0AThis is even more true if you happen to be running through a GS2 bridg= e=0Awhich may not be applicable to your mechanism.=0A=0AI promised Hannes a= t the meeting that near end of April I'd be happy to=0Aget up to speed on t= his and work with the draft authors on all this.=0A=0AI'm sorry I don't hav= e time to do that this week or next but I'll get=0Athere. --0-408321053-1302284821=:17690 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
OK, I've taken a note in my working copy to switch to -PLUS.  I also= need to add communicating the CB variant.

Thanks very much for your first look and I look forward = to further feedback.  Would it be useful for me to make these changes = now and post a new draft, or is that too much churn?
<= br>
-bill

From: Sam Hartman <hartmans-i= etf@mit.edu>
To: Wil= liam J. Mills <wmills@yahoo-inc.com>
Sent: Friday, April 8, 2011 10:36 AM
Subject: Re: [kitten] Fw: New Version No= tification for draft-mills-kitten-sasl-oauth-02

=0A>>&= gt;>> "William" =3D=3D William J Mills <wmills@yahoo-inc.com<= /a>> writes:

    William> At the moment I was going = with simple.  If multiple types
    William> are suppo= rted then I have to be able to communicate what
    William>= ; types of channel binding are accepted, which I suppose
    W= illiam> could go in the WWW-Authenticate header in the discovery
&nbs= p;   William> information.  It's relatively easy to add a vari= able for
    William> the CB type.


I don't think= this is true if you're a SASL mechanism.
I think that's the application= 's problem.
I think all you have to do is communicate  the channel = binding type you
support.

Also, the abstract interface between th= e application and SASL assumes
that all SASL mechanisms supporting any CB types support all CB types.
This is even more true if= you happen to be running through a GS2 bridge
which may not be applicab= le to your mechanism.

I promised Hannes at the meeting that near end= of April I'd be happy to
get up to speed on this and work with the draf= t authors on all this.

I'm sorry I don't have time to do that this w= eek or next but I'll get
there.


--0-408321053-1302284821=:17690-- From nico@cryptonector.com Fri Apr 8 11:01:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0473A6A03 for ; Fri, 8 Apr 2011 11:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHP44JvEsz9y for ; Fri, 8 Apr 2011 11:01:45 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id D6F183A68E0 for ; Fri, 8 Apr 2011 11:01:45 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 50B3B42807B for ; Fri, 8 Apr 2011 11:03:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=cm7e3TJANOSiPyB3Ch1lSd42kqYEqtaY0zTeCpHD1DSn +UUcBaWDMpNlXLxe/bLhM8H0hChkof58PdJO3SdhefmM7Q5c7G8uXwpYVgwWBgTr kxVVlZhwflyKP99QNJSloHrb604PyVEXC5eP0bvNGglb7lw1UBMf4vEL5tKgGTM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kgXyUFe3/BOq08ztmm+kCFSZpGw=; b=VdY5JFgPG3W JXOQ41t8G1hv1osFN3+p6Q01bWwt6V8QVPwo+MhO5iW82jqilbVdc1bFwxZdQqpp irU4iPnod9lt2nug29Is9LqiEvGGNI3AAoQtjoWcNMgWihx4ZNBob/CoXr+rpNzD L0upLLv61wu2/fs3qDmAiTvdN0S5JG78= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 121E0428072 for ; Fri, 8 Apr 2011 11:03:30 -0700 (PDT) Received: by vxg33 with SMTP id 33so3527298vxg.31 for ; Fri, 08 Apr 2011 11:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.240 with SMTP id h16mr3605038vdu.214.1302285810126; Fri, 08 Apr 2011 11:03:30 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 11:03:29 -0700 (PDT) In-Reply-To: <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> Date: Fri, 8 Apr 2011 13:03:29 -0500 Message-ID: From: Nico Williams To: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:01:46 -0000 On Fri, Apr 8, 2011 at 12:25 PM, Love H=C3=B6rnquist =C3=85strand wrote: > 7 apr 2011 kl. 08:45 skrev > =C2=A0: >> =C2=A0A couple of people have pointed out circumstances to which >> =C2=A0gss_userok() is not applicable. =C2=A0I'm not sure why. =C2=A0The = primary use >> =C2=A0case here is a protocol implementation which integrates with syste= m >> =C2=A0accounts (e.g. sshd, ftpd), for a protocol which takes a requested >> =C2=A0username argument. =C2=A0Other kinds of local names could be added= into >> =C2=A0Sam's suggested prototype, but we don't currently have use csaes f= or >> =C2=A0those. > > usecase: nfsd, smbd <- protocol that integrates with system accounts and = don't have username. Solaris is probably a good example of how to handle this. Its RPCSEC_GSS library has an entry point where you pass it a GSS principal name and it returns a UID, primary GID, and a list of supplementary GIDs. Because it takes a name as input it could work in any number of ways, such = as: - extract PAD/PAD from the principal name, map SIDs and/or whatever to UIDs/GIDs - call an aname2lname API on the given name and the do traditional getpwnam_r() and getgroupsbymember() calls - lookup a database by principal name and return whatever is found there Note that Solaris does have a GSS aname2lname function. We should standardize it as well! Nico -- From hartmans@mit.edu Fri Apr 8 11:51:45 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1283A69CC for ; Fri, 8 Apr 2011 11:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.831 X-Spam-Level: X-Spam-Status: No, score=-102.831 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1qwI-XrhhyD for ; Fri, 8 Apr 2011 11:51:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 05D533A69B4 for ; Fri, 8 Apr 2011 11:51:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 591A5201A2; Fri, 8 Apr 2011 14:50:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A8682446E; Fri, 8 Apr 2011 14:53:24 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott E." References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 08 Apr 2011 14:53:24 -0400 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Fri, 8 Apr 2011 17:44:37 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 18:51:46 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> I think all you have to do is communicate the channel binding >> type you support. Cantor,> I think you mean "the type you used", at least based on my Cantor,> reading of GS2. I do. Cantor,> On the general subject of tls-unique vs. endpoint, I had a Cantor,> brief conversation with Simon about it, and I think some Cantor,> clarification on how server applications would be expected Cantor,> to use tls-endpoint would be useful. Probably. Cantor,> How is it expected that servers would distinguish clients I'd expect that is what the SASL authentication is for. (Note that HTTP is more complex; you need cookies or some other distinguisher there). In something like IMAP, at the end of SASL, we have: 1) Client did mutual auth with server. It knows that the server at the other end of the TLS exchange with a given certificate is the party named in the SASL exchange. It knows that a particular TLS connection reaches that party. 2) Server knows that the client is as named in the SASL exchange. Server also knows that the client believes that the party identified by the particular endpoint CB is the only party besides the client involved in the TLS exchange. One critical part of #2 is that if the client didn't confirm the channel binding, the client would have given up rather than starting the SASL authentication. Unless I'm missing something (wouldn't be the first time) I think 1 and 2 are sufficient for a non-HTTP use case. From nico@cryptonector.com Fri Apr 8 12:19:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7BA3A69B4 for ; Fri, 8 Apr 2011 12:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0F5bEwNBaIQ for ; Fri, 8 Apr 2011 12:19:08 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 58ADD3A6975 for ; Fri, 8 Apr 2011 12:19:08 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 04B11598065 for ; Fri, 8 Apr 2011 12:20:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=W/J8hhXfI7yzVFMdwCh0uqMVpwkthCmgmtOZeSGh7iN/ pZgfJUjJsE9z2M7Pr1GleR6WyFNDLEAUcJTpIraSFXDLbJEVQ9ubB+QGpvRo8Fho Vgu1KwH5FsJ34IPcvj2KqRvWXNZyNhQo8M4dGv2/e9gnZf5eHSxCQJ1bL+Npv+Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=3uPeHU+2djyhZVqj/XVvPoMr+x8=; b=bAj1QKNiW3O QEJVMbe1JbnNYpK96onK/ZpL4zyUrsPCJfJmY9bFqtm1OA37/NpfwPTLIGGGb2cq ix9CsgzBm2a4Wt5njQenVVYlT4i/RZwxCXXLuE3oW0BxTJp5M4xpsf3YH2y1sWME HEvpK/Xyn5R//XBOiLJfKz7Xj8p3GEd4= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id C3B6559805F for ; Fri, 8 Apr 2011 12:20:53 -0700 (PDT) Received: by vws12 with SMTP id 12so3612613vws.31 for ; Fri, 08 Apr 2011 12:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.38 with SMTP id cj6mr3657500vdb.254.1302290453205; Fri, 08 Apr 2011 12:20:53 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 12:20:53 -0700 (PDT) In-Reply-To: <754979.46407.qm@web32303.mail.mud.yahoo.com> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> Date: Fri, 8 Apr 2011 14:20:53 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter , Sam Hartman Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:19:09 -0000 On Fri, Apr 8, 2011 at 12:31 PM, William J. Mills wr= ote: > At the moment I was going with simple.=C2=A0 If multiple types are suppor= ted then > I have to be able to communicate what types of channel binding are accept= ed, > which I suppose could go in the WWW-Authenticate header in the discovery > information.=C2=A0 It's relatively easy to add a variable for the CB type= . > If tls-server-end-point is easier to implement I'm happy to pick that one= , > subject to limiting to a single CB type. Not caring about CB type is simple. Checking the CB type is not simple, particularly since the mechanism can't really know what CB type is being used. Yes, RFC5056 says apps should prefix the CB data with the type name, but that's NOT something that a mechanism should ever rely on. > My thought was that if the service is offered over another secure channel > then OAUTH-SSH could be defined for channel binding to SSH. The mechanism should not care what type of CB data is being used. The mechanism should limit itself to ensuring that the CB data are the same on the initiator and acceptor sides of a security context establishment -- that's all the mech should do. Nico -- From cantor.2@osu.edu Fri Apr 8 12:25:46 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E9D3A69E2 for ; Fri, 8 Apr 2011 12:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIUAPAZKOENa for ; Fri, 8 Apr 2011 12:25:45 -0700 (PDT) Received: from defang12.it.ohio-state.edu (defang12.it.ohio-state.edu [128.146.216.21]) by core3.amsl.com (Postfix) with ESMTP id 12F8E3A6975 for ; Fri, 8 Apr 2011 12:25:44 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang12.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p38JRT1I024119; Fri, 8 Apr 2011 15:27:29 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::fc4d:697c:5243:fd03%13]) with mapi; Fri, 8 Apr 2011 15:23:40 -0400 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 Thread-Index: AQHL9h27eQZ1CqEixkWSNA9dnCkCrJRUWMrw Date: Fri, 8 Apr 2011 19:27:45 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.21 Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:25:46 -0000 > Cantor,> How is it expected that servers would distinguish clients >=20 > I'd expect that is what the SASL authentication is for. > (Note that HTTP is more complex; you need cookies or some other > distinguisher there). I think my confusion stems from both thinking about HTTP and also thinking = about SSL session resumption across TCP connections (which is somewhat rela= ted to the HTTP thing). > Unless I'm missing something (wouldn't be the first time) I think 1 and > 2 are sufficient for a non-HTTP use case. It's sufficient for a persistent connection. I think you answered the other= case by mentioning cookies. Normally that has a fairly perjorative connota= tion, but since the client here isn't a browser (read browser as "security = sinkhole"), such a cookie isn't a cookie in the "anybody can probably steal= it" sense. -- Scott From nico@cryptonector.com Fri Apr 8 12:26:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CD23A69EF for ; Fri, 8 Apr 2011 12:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5-a+8bVvDUl for ; Fri, 8 Apr 2011 12:26:57 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 6DE1B3A6975 for ; Fri, 8 Apr 2011 12:26:57 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id E388A584064 for ; Fri, 8 Apr 2011 12:28:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Tn864hcZtkexF4zfEh4fPPfyWBj2dLIE/vE6BGHB+Hnd JlrT4iS8F6/HpP2oc0nq54wTaPQ/LSNQcf7hycqKQCZUmYyvd1MBqQdX1Nt0bnKL MI9ZGTZm5ejD6WKUsr1vaR7dUAL52f85TbXKo9tubyNtiZwGtLF4279wzLxbBKA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=0BgvYCojliBRVmhxZHSo2rem1NY=; b=rUo50hlvHYt LhBauJ0snL0SFyBtuz8K6Me5qDerJCeRt6JiGOaPLjeL154WwYUtCwLu31MwVpT2 wK6EN7KOQ8lMFwK5yjddH7RVwrd0RJjX+3dzub90Np9PuWq+BAOb7rs2HPqlKP/e CqF1p9LiejZ9Awmeee1sGFZ61e0ftWvk= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id B2D2C584058 for ; Fri, 8 Apr 2011 12:28:42 -0700 (PDT) Received: by vxg33 with SMTP id 33so3589983vxg.31 for ; Fri, 08 Apr 2011 12:28:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.38 with SMTP id cj6mr3668591vdb.254.1302290922065; Fri, 08 Apr 2011 12:28:42 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 12:28:41 -0700 (PDT) In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 8 Apr 2011 14:28:41 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott E." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman , Tim Showalter Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:26:58 -0000 On Fri, Apr 8, 2011 at 12:44 PM, Cantor, Scott E. wrote: >> I think all you have to do is communicate =C2=A0the channel binding type= you >> support. > > I think you mean "the type you used", at least based on =C2=A0my reading = of GS2. > > On the general subject of tls-unique vs. endpoint, I had a brief conversa= tion with Simon about it, and I think some clarification on how server appl= ications would be expected to use tls-endpoint would be useful. Regardless of the CB type, the application asks the channel for the CB data of the selected CB type. Since we lack a CB type negotiation facility, the CB type needs to be selected a priori. For various reasons tls-server-end-point is the most practical CB type for HTTP and various other applications. The reason tls-server-end-point is more practical than tls-unique in some cases has to do with TLS concentrators: try and extract tls-unique CB data from them :( But the TLS server certificate is easily enough copied around, configured wherever tls-server-end-point CB data might be needed. > How is it expected that servers would distinguish clients at the app laye= r when non-unique CB is used? Servers have never distinguished clients by CB data before, so this question answers itself: "the same way they always have" :) In the case of HTTPS the answer is, whether you like it or not, "cookies". Nico -- From nico@cryptonector.com Fri Apr 8 12:34:13 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E6543A69EF for ; Fri, 8 Apr 2011 12:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUdF0xs2LDOs for ; Fri, 8 Apr 2011 12:34:12 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 52BEA3A6975 for ; Fri, 8 Apr 2011 12:34:12 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id E7AFC1006D for ; Fri, 8 Apr 2011 12:35:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=F+O/xOJewUdBORjUV5qV99LoGLh/tCdUXcK8DZob3sAj l0GAFYExX+9WY2iDXBychdRQ8uMgrDe0wDcWDRIDIJ2lacS8D6io0cy2EsE1rvQj fhKPE6h1hoTJ/4zU7nDiFlLNCopfb/EPaTQEQAk3l0/y1LjUlsiB3g9cGXd1J3Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=lQo9xSMye2/P+uGnxVHIWIy6E4U=; b=M2Qhabn6BJ5 BF7yDVeFz8TNaUjRA7ihMeeC4zHUdO1Diy26XZw2al67txpnReX6hbaS/9V9GlC1 iiDXKyYsuCD5TijvyVeqGl4yboU2Eva+ZulBV1aqsIGcSEmc/0c8JUkGwLCFH7Zz fMVkCV46gsjldoltfHnRfIMz7NlSM5Rg= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id C4C7210062 for ; Fri, 8 Apr 2011 12:35:57 -0700 (PDT) Received: by vxg33 with SMTP id 33so3595992vxg.31 for ; Fri, 08 Apr 2011 12:35:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.1 with SMTP id eu1mr601567vdb.174.1302291357239; Fri, 08 Apr 2011 12:35:57 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 12:35:57 -0700 (PDT) In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 8 Apr 2011 14:35:57 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott E." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter , Sam Hartman Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:34:13 -0000 On Fri, Apr 8, 2011 at 2:27 PM, Cantor, Scott E. wrote: >> Unless I'm missing something (wouldn't be the first time) I think 1 and >> 2 are sufficient for a non-HTTP use case. > > It's sufficient for a persistent connection. I think you answered the oth= er case by mentioning cookies. Normally that has a fairly perjorative conno= tation, but since the client here isn't a browser (read browser as "securit= y sinkhole"), such a cookie isn't a cookie in the "anybody can probably ste= al it" sense. HTTP, by its nature, only really allows you to use cookies to tie all the requests (and responses) that make up an application "session". Ideally there'd be a little more to it. For example, the application could use TLS session IDs to map HTTPS requests and responses to application sessions, but this is complicated (there could be many TLS sessions mapping onto one application session, with new TLS sessions added at any time) and not actually done in practice. Or the client and server could share an established GSS security context and place a MIC in the request/response headers -- a MIC of the request/response body, and maybe some security-sensitive headers. But that's not the HTTP that we have. HTTP as it is and as we use it allows us only the use of cookies for this purpose. Fortunately we also have HTTPS, and we're talking about doing CB. So setting a secure-only cookie has been, is, and will continue to be a reasonable thing to do to solve this particular problem. Nico -- From nico@cryptonector.com Fri Apr 8 12:39:27 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB15A3A69E2 for ; Fri, 8 Apr 2011 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mK5XO2wIYJSM for ; Fri, 8 Apr 2011 12:39:27 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id 0284B3A6975 for ; Fri, 8 Apr 2011 12:39:26 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 795732F4071 for ; Fri, 8 Apr 2011 12:41:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=FzMCWEzcMtfTU3Ikb4VjWXMOC7+X8G4IjCNSClGX8gWE h8Hk8nranQQ43FyYYpMSwQ810WMs2sK6sFcO7ZsjScYSyJPPQSIY3x6BfxvvMEhj J2uRvzTYkyMeVo6KCK461i6FiZVxcN53JatonUwC7F75ZA/qlJniDTwVpXk+h/I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=ETifdQAKpryBBlDXelP8r7Dwd6U=; b=p+3j1xGxU+O g+9Pzv6GVb4OPcS/vcUeI4ihhaGVSBfCKZlT5IYoEGp6m+sG1uY2JhKLTQQ3Pz55 cj2jl2MOt6V/WImf6Z5RrpqLT0fTz3N8LYO76TxXcoXAOVjWTMYRhOOprifuSKqZ tZWZBCjRvfMwhBDpgP8UsL5kPa4HpwQ8= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 473BE2F4060 for ; Fri, 8 Apr 2011 12:41:12 -0700 (PDT) Received: by vxg33 with SMTP id 33so3600281vxg.31 for ; Fri, 08 Apr 2011 12:41:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.180.9 with SMTP id dk9mr3715761vdc.134.1302291671704; Fri, 08 Apr 2011 12:41:11 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 12:41:11 -0700 (PDT) In-Reply-To: <1302273997.10465.569.camel@t410> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> Date: Fri, 8 Apr 2011 14:41:11 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:39:28 -0000 On Fri, Apr 8, 2011 at 9:46 AM, Greg Hudson wrote: > On Thu, 2011-04-07 at 19:12 -0400, Luke Howard wrote: >> > OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t = lname); >> >> What happened to user_ok boolean? > > A good question. =C2=A0Sam, was that an oversight, or did you intend the > function to return GSS_S_SUCCESS for authorized and GSS_S_UNAUTHORIZED > for unauthorized? =C2=A0That way the mech could provide a reason for fail= ure > via the minor code if it wants. Strictly speaking the major status code would do. If GSS_S_COMPLETE then the principal is authorized, and if anything else then the principal is not authorized and the major and minor status codes would tell you that and possibly why. The redundancy implied in the boolean output + major status code output means that the API could be used incorrectly quite easily. Dropping the boolean output may well be a valuable thing to do! In any case, if we retain the boolean output we should state that it must be used to output FALSE in any and all error conditions, that it may only be set to TRUE when the function would return GSS_S_COMPLETE. Nico -- From sxw@inf.ed.ac.uk Fri Apr 8 12:40:18 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6573A6A0B for ; Fri, 8 Apr 2011 12:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq3afEszIfZl for ; Fri, 8 Apr 2011 12:40:17 -0700 (PDT) Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by core3.amsl.com (Postfix) with ESMTP id 4A48F3A69E2 for ; Fri, 8 Apr 2011 12:40:17 -0700 (PDT) Received: from outbound-edge-1.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id 0D308220C5; Fri, 8 Apr 2011 20:42:02 +0100 (BST) Received: from 87-194-107-64.bethere.co.uk (HELO alfheim.config) (87.194.107.64) (smtp-auth username simon@pop3.sxw.org.uk, mechanism cram-md5) by outbound-edge-1.mail.thdo.gradwell.net (qpsmtpd/0.83) with ESMTPA; Fri, 08 Apr 2011 20:42:02 +0100 Message-Id: From: Simon Wilkinson To: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 8 Apr 2011 20:42:01 +0100 References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> X-Mailer: Apple Mail (2.936) X-Gradwell-MongoId: 4d9f650a.ada-18c8-1 X-Gradwell-Auth-Method: mailbox X-Gradwell-Auth-Credentials: simon@pop3.sxw.org.uk Cc: "" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:40:18 -0000 On 8 Apr 2011, at 18:25, Love H=F6rnquist =C5strand wrote: > 7 apr 2011 kl. 08:45 skrev > : > >> A couple of people have pointed out circumstances to which >> gss_userok() is not applicable. I'm not sure why. The primary use >> case here is a protocol implementation which integrates with system >> accounts (e.g. sshd, ftpd), for a protocol which takes a requested >> username argument. Other kinds of local names could be added into >> Sam's suggested prototype, but we don't currently have use csaes for >> those. > > usecase: nfsd, smbd <- protocol that integrates with system accounts =20= > and don't have username. SSH is actually a use case here as well. The protocol specification =20 permits the client to provide a null username, which makes the server =20= pick the username that's appropriate for that authentication identity. =20= The GSI folk implemented this for their fork of OpenSSH, but I haven't =20= pulled their change into my patches, because they're pretty intrusive. =20= Now that I've given up any hope of OpenSSH themselves doing GSSAPI =20 completely, I should probably revisit this. Cheers, Simon. From alexey.melnikov@isode.com Fri Apr 8 13:17:43 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F7E43A696D for ; Fri, 8 Apr 2011 13:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Cx+NwIfLs0B for ; Fri, 8 Apr 2011 13:17:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BE0D43A68CB for ; Fri, 8 Apr 2011 13:17:33 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 8 Apr 2011 21:19:18 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D9F6D8C.3080409@isode.com> Date: Fri, 08 Apr 2011 21:18:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "kitten@ietf.org" References: <4D772586.60409@oracle.com> In-Reply-To: <4D772586.60409@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-openid-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:17:43 -0000 Shawn Emery wrote: > This message officially starts the Kitten Working Group Last Call for > the following document: > > A SASL & GSS-API Mechanism for OpenID > http://tools.ietf.org/html/draft-ietf-kitten-sasl-openid-01 > > The Working Group Last Call for this document starts today on > Wednesday, March 9th and will end on Wednesday, March 30th. > > Please send any comments to the Kitten mailing list or directly to the > chairs. Feed-back from reviews that found no issues are also welcome. Here is my belated review: In this review I pretend to be a be more dumb than I am in real life (hopefully ;-)). I mean, I can probably figure out some details by reading OpenID 2.0, but this draft is not making it easier. I think each document should be as readable as it can possibly be on its own. With that in mind, here are my detailed comments: 1. Introduction Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is used by application protocols such IMAP, POP and XMPP, with the goal Strictly speaking all of these need Informative references. of modularizing authentication and security layers, so that newer mechanisms can be added as needed. This memo specifies just such a mechanism. The OpenID mechanism described in this memo aims to re-use the available OpenID specification to a maximum extent and therefore does not establish a separate authentication, integrity and confidentiality mechanism. It is anticipated that existing security layers, such as Transport Layer Security (TLS), will continued to be An Informative reference is missing here. used. 1.2. Applicability Because this mechanism transports information that should not be controlled by an attacker, the OpenID mechanism MUST only be used over channels protected by TLS [RFC5246], and the client MUST successfully validate the server certificate, or similar integrity Are references to RFC 5280 and RFC 6125 missing here? protected and authenticated channels. 2. Applicability for non-HTTP Use Cases OpenID was originally envisioned for HTTP/HTML based communications, Informative references are missing. Is any specific version of HTML required here? 2. The client initiates a SASL authentiation and transmits the typo: authentication User-Supplied Identifier as well as an optional return_to parameter. From the description later in the document, the return_to parameter is only generated by the server. So I think something is wrong in the document (either here, or elsewhere). 3. After normalizing the User-Supplied Identifier, How? the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication. 4. The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. Where is this described normatively? The text seems fairly informative. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response. 8. Next the client optionally authenticates to the OP and then approves or disapproves authentication to the Relying Party. The manner in which the end user is authenticated to their respective OP and any policies surrounding such authentication is out of scope of OpenID and and hence also out of scope for this specification. This step happens out of band from SASL. Hmm, this suggests that one can't implement this mechanism interoperably on the client side. I think this is a problem. ----- = SASL - - - = HTTP or SSL Did you mean "HTTP over TLS"? (Avoiding a use of the term "SSL", as SSL 2.0 is deprecated and 3.0 might follow the same path.) 2.1. Binding SASL to OpenID in the Relying Party To ensure that a specific request is bound, and in particular to ease interprocess communication, it may be necessary for the relying party to encode some sort of nonce in the URIs it transmits through the client for success or failure. This can be done in any number of ways. Isn't this necessary to implement? Examples would include making changes to the base URI or otherwise including an additional fragment. Can you provide expanded examples? 2.2. Discussion As mentioned above OpenID is primarily designed to interact with web- based applications. Portions of the authentication stream are only defined in the crudest sense. That is, when one is prompted to approve or disapprove an authentication, anything that one might find on a browser is allowed, including JavaScript, fancy style-sheets, etc. Because of this lack of structure, implementations will need to invoke a fairly rich browser in order to insure that the authentication can be completed. This is not well defined. I have doubts that that is implementable without invoking a browser. If that was never the intent, I think a clear applicability statement upfront is needed. I also have a more general issue with this: are you saying that this mechanism is only implementable by invoking one of the 5 major (and some number of less deployed) browsers? Are certain features required from a browser being invoked? 3.2. Initiation initial-response = gs2-header Auth-Identifier Auth-Identifier = Identifier ; authentication identifier Identifier = URI | XRI ; Identifer is specified in typo: Identifier (in the comment) ; Sec. 7.2 of the OpenID 2.0 spec. ABNF should be using "/", not "|" to delimit alternatives. 3.3. Authentication Request The SASL Server sends an OpenID message that contains an openid.mode of either "checkid_immediate" or "checkid_setup", as specified in Section 9.1 of the OpenID 2.0 specification. As part of this request, the SASL server MUST append a unique transaction id to the "e;return_to" portion of the request. The Typo in the source XML (""e;")? The client now sends that request via an HTTP GET to the OP, as if redirected to do so from an HTTP server. What does such request include as far as HTTP operation is concerned? I.e. which header fields are required? Is Referer header field required? The client MUST handle both user authentication to the OP and confirmation or rejection of the authentiation of the RP. Is this process fully prescribed by the OpenID spec? After all authentication has been completed by the OP, and after the response has been sent to the client, the client will relay the response to the Relying Party via HTTP or SSL. HTTP and SSL are not interchangeable, so I don't know what this means. Also, I am a bit confused at this point: what is the corresponding section 2 step number for this operation? If this is the step 9, then I don't understand why the client is involved in this at all? Figure 1 doesn't seem to show this interaction path. 3.4. Server Response sreg_word = 1* ( unreserved / pct-encoded ) ; pct-encoded from Section 2.1 of RFC 3896 ; unreserved from Section 2.3 of RFC 3896 s/3896/3986 (twice) If the application protocol allows, openid.error and openid.error_code and any other useful diagnostic information SHOULD be included in authentication failures. Why wouldn't it allow? (This doesn't read normative and I think it should.) In Section 5: IMAP and SASL-IR need Informative references. 6.2. RP redirected by malicious URL to take an improper action In the initial SASL client response a user or host can transmit a malicious response to the RP for purposes of taking advantage of weaknesses in the RP's OpenID implementation. It is possible to add port numbers to the URL so that the outcome is the RP does a port scan of the site. The URL could send the connection to an internal host or even the local host, which the attacker would not normally have access to. The URL could contain a protocol other than http or https, such as file or ftp. Should HTTP/HTTPS be mandatory to implement URI schemes for such responses? 7. Room for Improvement We note one area where there is possible room for improvement over existing OpenID implementations. Because SASL is often implemented atop protocols that have required some amount of provisioning, it may be possible for the SASL client to signal the browser that it should increase scrutiny of invalid credentials. How this would be done is beyond the scope of this specification, but may be the subject of future updates. For instance, the browser may wish to fail the request entirely if the certificate is invalid and has not been accessed prior to this point. One thing that this would require would be the exposure of a "return_to" URL by the SASL server in case Exposure to which entity? of such failures, so that the authentication is not left hanging. Other comments: I am missing some text saying that a SASL authorization identity can be used with this mechanism. This follows from the definition of the GS2 bridge, but I think it would be worth stating that explicitly. This SASL mechanism is using 3 round trips! I am wondering if we can do better. (I haven't though too much on this question, so maybe the answer is "no") Best Regards, Alexey From wmills@yahoo-inc.com Fri Apr 8 13:23:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3793A6405 for ; Fri, 8 Apr 2011 13:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH2YhlifZ1Ff for ; Fri, 8 Apr 2011 13:23:02 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id 5C2E83A68CB for ; Fri, 8 Apr 2011 13:23:02 -0700 (PDT) Received: (qmail 90983 invoked by uid 60001); 8 Apr 2011 20:24:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302294285; bh=ZgL9+G/7w+V/qnUNjw+aaLmSN8DOsrKhs4C1DhzK5V8=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BuypwpqxJkJNu+miJYah7cEcv5elxZ/7OCvqivZqeuuoVm4BW3bULmHWIYDlt+6TcqhuK48j8VMj+3duJUzyJ+R8nMv8/BKaPdFFYwQ7/urARIxHha21jwEFihOKXI+C25ruuHlflv5nfUCAVfY7JEevkgzO0vKEz4f9G3ROtxc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=O+BxCtBz0jzwkQ77yhpC2jmZuYbBv4gy2Zw89RPGZcS/aF1H9HlNSSseqMlGC6bRqSEZgcMdDwzWr7od+8UuYUydv/06O+QkZ1+d2Jd86QIfUu2+Af4DxJjWwNRB4VDbF3LVGkb+s/4KFx+dX6+22squxa53k/rPx6rL8vcQSgY=; Message-ID: <187924.77808.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: nXcMVMsVM1n3GvZC2iTkyK6jNyQIzVNAGYTK.V2JIcKKXUG mPnxhlXJtxlwfvexof4_kmfxOONKg52aQgp4IV8OENJmm.vvQoOt5r3uOq_s tg03zdTCjdVl36vJBIglZm_hT8zX37ywOgXITjx1e9aftugs8IO7bWTWO.6I DK0NmaUerqwOu5G11XD9GUqbpOrFk9mDoRZcuNlBW8Q25ddY2OhIlX7sQxfb BV4cAYrbJqLl7JYGdb3mqclZ99cLb2m8wAsGns6fkWNOsZaZ_EERcgBXoSV_ IUshSif5VJ8UOMKrhEb_Z9OhxlVDouSs_6.Dmh.bb7TnnIK6AjtSsG_0w7fk hcZM0rM3HHjxuXBshvXjbS3ORptbd2tDC Received: from [209.131.62.115] by web32314.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 13:24:45 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> Date: Fri, 8 Apr 2011 13:24:45 -0700 (PDT) From: "William J. Mills" To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-711671551-1302294285=:77808" Cc: "kitten@ietf.org" , Simon Josefsson , Tim Showalter , Sam Hartman Subject: Re: [kitten] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:23:09 -0000 --0-711671551-1302294285=:77808 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ah now see... this is exactly why to assk the experts...=0A=0A> Yes, RFC505= 6 says apps should prefix the CB data=0A> with the type name, but that's NO= T something that a mechanism should=0A> ever rely on.=0A=0AAnd my life is s= impler.=A0 I simply remove any references to being more specific and know t= hat the cbdata is of the format "%s:%s".=0A=0AThank you.=0A=0A=0A=0A=0A____= ____________________________=0AFrom: Nico Williams = =0ATo: William J. Mills =0ACc: Sam Hartman ; Simon Josefsson ; "kitten@ietf.org" ; Tim Showalter =0ASent: Friday, April= 8, 2011 12:20 PM=0ASubject: Re: [kitten] Fw: New Version Notification for = draft-mills-kitten-sasl-oauth-02=0A=0AOn Fri, Apr 8, 2011 at 12:31 PM, Will= iam J. Mills wrote:=0A> At the moment I was going wi= th simple.=A0 If multiple types are supported then=0A> I have to be able to= communicate what types of channel binding are accepted,=0A> which I suppos= e could go in the WWW-Authenticate header in the discovery=0A> information.= =A0 It's relatively easy to add a variable for the CB type.=0A> If tls-serv= er-end-point is easier to implement I'm happy to pick that one,=0A> subject= to limiting to a single CB type.=0A=0ANot caring about CB type is simple.= =A0 Checking the CB type is not=0Asimple, particularly since the mechanism = can't really know what CB=0Atype is being used.=A0 Yes, RFC5056 says apps s= hould prefix the CB data=0Awith the type name, but that's NOT something tha= t a mechanism should=0Aever rely on.=0A=0A> My thought was that if the serv= ice is offered over another secure channel=0A> then OAUTH-SSH could be defi= ned for channel binding to SSH.=0A=0AThe mechanism should not care what typ= e of CB data is being used.=A0 The=0Amechanism should limit itself to ensur= ing that the CB data are the=0Asame on the initiator and acceptor sides of = a security context=0Aestablishment -- that's all the mech should do.=0A=0AN= ico=0A-- --0-711671551-1302294285=:77808 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ah now see... this is exactly why to assk the experts...

> Yes, RFC5056 says apps should prefix the = CB data
> with the type name, but that's NOT something that a mechani= sm should
> ever rely on.

And my life is sim= pler.  I simply remove any references to being more specific and know = that the cbdata is of the format "%s:%s".

Thank yo= u.


From: Nico Williams <nico@cryptonector.com>
To:= William J. Mills <wmills@yahoo-inc.com>
Cc: Sam Hartman <hartmans-ietf@mit.ed= u>; Simon Josefsson <simon@josefsson.org>; "kitten@ietf.org" <k= itten@ietf.org>; Tim Showalter <timshow@yahoo-inc.com>
Sent: Friday, April 8, 2011 12:20 = PM
Subject: Re: [kitten= ] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

=0AOn Fri, Apr 8, 2011 at 12:31 PM, William J. Mills <wmill= s@yahoo-inc.com> wrote:
> At the moment I was going with simpl= e.  If multiple types are supported then
> I have to be able to = communicate what types of channel binding are accepted,
> which I sup= pose could go in the WWW-Authenticate header in the discovery
> infor= mation.  It's relatively easy to add a variable for the CB type.
&g= t; If tls-server-end-point is easier to implement I'm happy to pick that on= e,
> subject to limiting to a single CB type.

Not caring about= CB type is simple.  Checking the CB type is not
simple, particular= ly since the mechanism can't really know what CB
type is being used.&nbs= p; Yes, RFC5056 says apps should prefix the CB data
with the type name, = but that's NOT something that a mechanism should
ever rely on.

&g= t; My thought was that if the service is offered over another secure channel
= > then OAUTH-SSH could be defined for channel binding to SSH.

The= mechanism should not care what type of CB data is being used.  Themechanism should limit itself to ensuring that the CB data are the
same= on the initiator and acceptor sides of a security context
establishment= -- that's all the mech should do.

Nico
--


--0-711671551-1302294285=:77808-- From lukeh@padl.com Fri Apr 8 15:36:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4E43A6A36 for ; Fri, 8 Apr 2011 15:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAXWPrP11g27 for ; Fri, 8 Apr 2011 15:36:12 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 053393A6A40 for ; Fri, 8 Apr 2011 15:36:11 -0700 (PDT) Received: by us.padl.com with ESMTP id p38MbTmC015819; Fri, 8 Apr 2011 18:37:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 9 Apr 2011 08:37:26 +1000 Content-Transfer-Encoding: 7bit Message-Id: <78E885E6-A5F0-47A5-85A7-67186C5DD77E@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:36:12 -0000 > Note that Solaris does have a GSS aname2lname function. We should > standardize it as well! So does MIT, the same as Solaris. -- Luke From nico@cryptonector.com Fri Apr 8 15:44:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2D83A6A2D for ; Fri, 8 Apr 2011 15:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEx2Vd3kHhWR for ; Fri, 8 Apr 2011 15:44:30 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id B58353A67E5 for ; Fri, 8 Apr 2011 15:44:30 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 7C65A584064 for ; Fri, 8 Apr 2011 15:46:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=XQOi1hCtwzxaDj4kFp1KJcOytRGYJcYqYUg25jbUDvpj CeRBgd3iPVPtwV7Hc6kDKK0EfxcFpLdEWcwhPNPSHsLOD1bIp3JVEHmSzkkVl8uc ddp39OfhA9t+2x8qNgHGKI2UQXxjAhHttRwmAgXs8nQEOpNFett+tSvZPAZOfJk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=yVWncN3vV3HFkunn45/xS3j5EW4=; b=N1n9xK/VnHy Qvop8BytkkN1SnKs1NFIiZZNU9tiKQmYLhi80jwabUYoMUWPvn43mjx4ClW4ITFX ZxUKneWbVnjFf1r0W+Bagc3iN5OQrkHtjH4P2qEjV9eaIUig6Si9f4iEMWCyOySn fcHRjktyb+Esrp6vPp6Fexy9mpE2lcLc= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 501CB584059 for ; Fri, 8 Apr 2011 15:46:16 -0700 (PDT) Received: by vxg33 with SMTP id 33so3708974vxg.31 for ; Fri, 08 Apr 2011 15:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.180.9 with SMTP id dk9mr3955168vdc.134.1302302775713; Fri, 08 Apr 2011 15:46:15 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 15:46:15 -0700 (PDT) In-Reply-To: <78E885E6-A5F0-47A5-85A7-67186C5DD77E@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> <78E885E6-A5F0-47A5-85A7-67186C5DD77E@padl.com> Date: Fri, 8 Apr 2011 17:46:15 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:44:31 -0000 On Fri, Apr 8, 2011 at 5:37 PM, Luke Howard wrote: >> Note that Solaris does have a GSS aname2lname function. =C2=A0We should >> standardize it as well! > > So does MIT, the same as Solaris. Oh, actually, Solaris doesn't have one. SunSSH's sshd has an internal one. Excuse my lousy memory. Can you post the MIT prototype? Thanks! From lukeh@padl.com Fri Apr 8 15:54:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE403A67E5 for ; Fri, 8 Apr 2011 15:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9030N4JWIln for ; Fri, 8 Apr 2011 15:54:33 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 809A73A67CC for ; Fri, 8 Apr 2011 15:54:33 -0700 (PDT) Received: by us.padl.com with ESMTP id p38Mstxv015637; Fri, 8 Apr 2011 18:55:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 9 Apr 2011 08:54:51 +1000 Content-Transfer-Encoding: 7bit Message-Id: <070FE4C0-F3D3-46EA-90F0-299AE3F4FEE3@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <7AF353F8-620A-45FF-8FCE-C559BE066A63@kth.se> <78E885E6-A5F0-47A5-85A7-67186C5DD77E@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 22:54:34 -0000 Sorry it's not quite 2lname. OM_uint32 gss_pname_to_uid(OM_uint32 *minor, const gss_name_t pname, const gss_OID mech_type, uid_t *uidp) -- Luke On 09/04/2011, at 8:46 AM, Nico Williams wrote: > On Fri, Apr 8, 2011 at 5:37 PM, Luke Howard wrote: >>> Note that Solaris does have a GSS aname2lname function. We should >>> standardize it as well! >> >> So does MIT, the same as Solaris. > > Oh, actually, Solaris doesn't have one. SunSSH's sshd has an internal > one. Excuse my lousy memory. > > Can you post the MIT prototype? Thanks! From wmills@yahoo-inc.com Fri Apr 8 17:09:08 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A9CD3A6A42 for ; Fri, 8 Apr 2011 17:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9277oAc2OpRb for ; Fri, 8 Apr 2011 17:09:07 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id DD31C3A6A20 for ; Fri, 8 Apr 2011 17:09:06 -0700 (PDT) Received: (qmail 74039 invoked by uid 60001); 9 Apr 2011 00:10:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302307848; bh=dDz4SQK6hdeM9wOJmR//zXSI2bT9CCGPlXKoOnzPh9M=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=SYyxL+Vm8BHHBqVMbFdbfuImlDv5yjIy3T2GHEOr9u/HiVzQO5AZ7mk0OxiQ5CKDz5gsD4Xj3t7JLVTbjAnY6qvpLtbLP+No+GI5yQ7zouJecKnPh/06oCnuyQBiKt5OYzIsPIWdOrzsB/GkvD2wzNb0p9vswjm19ofsr0Q6wXM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RAmSC5HojdegbVVPULMSGQlrZG95TYonlCM4OMSowm6KJdiQ3IqjHij7DDY49cpoQ3GaRYU5B63JSNn/2LwPusJnp6veFnFZjRnA/dgqdohXBNzSraDtfv3uZUs0E95O1zF8UbkIYSuPJdqNhEOE0waxzvvmAh12Gn4cDIFzFag=; Message-ID: <991228.73942.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: Fhj1MBQVM1kK2L8Gr26Z.4ODbxPZ5EODe5LXEj155elNxa2 CQZhbfgCVa7EE84dUJ5ERygJXciMThLOHUv_ilBDVY3TPtN5G6p493Ez4qXt 37Xo6t9I6L6MjVoLdRKNMyIDLwfvC8ZCHuQg6c3hjgc53OrCTQ7T.Gho7qdB p52aUzVXmKrLS_Lk2KBS8me81SpKvxW3i5D3QVF6Sm5cmcWCJrkAeqaMQxEW 4XOtexT6VET_34HYk9Xq.ZDH1MfvATsCNZT8flXB4L4C2cJzOdHM9R6oez4q TWqJeuaTJ9laYQQUWvU7kRih2LbLMSGrr4hGmacXILTN9eY2dnPiemEEYvmq 8XML9SiwFsihoRl4khPftafnr0B9zG3FR Received: from [209.131.62.115] by web32303.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 17:10:48 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Fri, 8 Apr 2011 17:10:48 -0700 (PDT) From: "William J. Mills" To: "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-479900375-1302307848=:73942" Subject: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:09:08 -0000 --0-479900375-1302307848=:73942 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Related questions about channel binding data...=0A=0ACB data is prefixed wi= th the channel binding scheme name and a colon, is there BNF or a definitio= n for what the rest of that looks like?=A0 Do I need to base64 it to make i= t safe to move in an HTML context?=0A=0AAlso, how big will it end up?=A0 I = suppose an SSL certificate can be a few k in the extreme case.=0A=0AThanks,= =0A=0A-bill=0A=0A=0A________________________________=0AFrom: Nico Williams = =0ATo: "Cantor, Scott E." =0ACc: "= kitten@ietf.org" ; Simon Josefsson ; = Tim Showalter ; Sam Hartman = =0ASent: Friday, April 8, 2011 12:35 PM=0ASubject: Re: [kitten] Fw: New Ver= sion Notification for draft-mills-kitten-sasl-oauth-02=0A=0AOn Fri, Apr 8, = 2011 at 2:27 PM, Cantor, Scott E. wrote:=0A>> Unless I'm= missing something (wouldn't be the first time) I think 1 and=0A>> 2 are su= fficient for a non-HTTP use case.=0A>=0A> It's sufficient for a persistent = connection. I think you answered the other case by mentioning cookies. Norm= ally that has a fairly perjorative connotation, but since the client here i= sn't a browser (read browser as "security sinkhole"), such a cookie isn't a= cookie in the "anybody can probably steal it" sense.=0A=0AHTTP, by its nat= ure, only really allows you to use cookies to tie all=0Athe requests (and r= esponses) that make up an application "session".=0AIdeally there'd be a lit= tle more to it.=A0 For example, the application=0Acould use TLS session IDs= to map HTTPS requests and responses to=0Aapplication sessions, but this is= complicated (there could be many TLS=0Asessions mapping onto one applicati= on session, with new TLS sessions=0Aadded at any time) and not actually don= e in practice.=A0 Or the client=0Aand server could share an established GSS= security context and place a=0AMIC in the request/response headers -- a MI= C of the request/response=0Abody, and maybe some security-sensitive headers= .=A0 But that's not the=0AHTTP that we have.=A0 HTTP as it is and as we use= it allows us only the=0Ause of cookies for this purpose.=0A=0AFortunately = we also have HTTPS, and we're talking about doing CB.=A0 So=0Asetting a sec= ure-only cookie has been, is, and will continue to be a=0Areasonable thing = to do to solve this particular problem.=0A=0ANico=0A--=0A__________________= _____________________________=0AKitten mailing list=0AKitten@ietf.org=0Ahtt= ps://www.ietf.org/mailman/listinfo/kitten --0-479900375-1302307848=:73942 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Related questions about channel binding data...

CB data is prefixed with the channel binding scheme name = and a colon, is there BNF or a definition for what the rest of that looks l= ike?  Do I need to base64 it to make it safe to move in an HTML contex= t?

Also, how big will it end up?  I suppose a= n SSL certificate can be a few k in the extreme case.

<= div>Thanks,

-bill

From: Nico Williams <nico@cryptonector.com>
To:= "Cantor, Scott E." <cantor.2@osu.edu>
Cc: "kitten@ietf.org" <kitten@ietf.or= g>; Simon Josefsson <simon@josefsson.org>; Tim Showalter <timsh= ow@yahoo-inc.com>; Sam Hartman <hartmans-ietf@mit.edu>
Sent: Friday, April 8, 2011 12:35 = PM
Subject: Re: [kitten= ] Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02

=0AOn Fri, Apr 8, 2011 at 2:27 PM, Cantor, Scott E. <cantor.2@osu.= edu> wrote:
>> Unless I'm missing something (wouldn't be th= e first time) I think 1 and
>> 2 are sufficient for a non-HTTP use= case.
>
> It's sufficient for a persistent connection. I think= you answered the other case by mentioning cookies. Normally that has a fai= rly perjorative connotation, but since the client here isn't a browser (rea= d browser as "security sinkhole"), such a cookie isn't a cookie in the "any= body can probably steal it" sense.

HTTP, by its nature, only really = allows you to use cookies to tie all
the requests (and responses) that m= ake up an application "session".
Ideally there'd be a little more to it.=   For example, the application
could use TLS session IDs to map HTT= PS requests and responses to
application sessions, but this is complicat= ed (there could be many TLS
sessions mapping onto one application session, with n= ew TLS sessions
added at any time) and not actually done in practice.&nb= sp; Or the client
and server could share an established GSS security con= text and place a
MIC in the request/response headers -- a MIC of the req= uest/response
body, and maybe some security-sensitive headers.  But= that's not the
HTTP that we have.  HTTP as it is and as we use it = allows us only the
use of cookies for this purpose.

Fortunately w= e also have HTTPS, and we're talking about doing CB.  So
setting a = secure-only cookie has been, is, and will continue to be a
reasonable th= ing to do to solve this particular problem.

Nico
--
__________= _____________________________________
Kitten mailing list
Kitten@ietf.org=
https://www.ietf.org/mailman/listinfo/kitten

=
--0-479900375-1302307848=:73942-- From lukeh@padl.com Fri Apr 8 17:21:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E14A3A6905 for ; Fri, 8 Apr 2011 17:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQA5GZZELwU3 for ; Fri, 8 Apr 2011 17:21:57 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id C2DBE3A6A20 for ; Fri, 8 Apr 2011 17:21:57 -0700 (PDT) Received: by us.padl.com with ESMTP id p390NZCx025838; Fri, 8 Apr 2011 20:23:44 -0400 References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> <1302274475.10465.575.camel@t410> In-Reply-To: <1302274475.10465.575.camel@t410> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2459D70C-AF2E-4D58-8F44-90214834DF0C@padl.com> X-Mailer: iPhone Mail (8G4) From: Luke Howard Date: Sat, 9 Apr 2011 10:23:14 +1000 To: Greg Hudson X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.7 Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:21:58 -0000 Re: name type, good idea, I shall fix. Shall we require it in the Kerberos m= ech to be the null OID or...? Von meinem iPhone gesendet Am 09/04/2011 um 0:54 schrieb Greg Hudson : > On Thu, 2011-04-07 at 20:57 -0400, Luke Howard wrote: >> It's kind of ugly that we're using "local-login-user" (as suggested by >> Sam) for the GSS attribute for the local name, but "localname" in >> gss_authorize_localname(). >=20 > My intention in picking gss_authorize_localname() was that "localname" > could eventually be a larger category than usernames (system login > accounts), even though right now we only have a use case for usernames. >=20 >> OM_uint32 (*gssspi_authorize_localname) >> ( >> OM_uint32 *, /* minor_status */ >> const gss_name_t, /* pname */ >> gss_const_buffer_t, /* local user */ >> int * /* user ok? */ >> /* */); >=20 > I'd suggest a name type parameter in the SPI, to fully specify the > internal name. >=20 >=20 From lukeh@padl.com Fri Apr 8 17:23:52 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AF83A6A1F for ; Fri, 8 Apr 2011 17:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nLtUoPr61Sb for ; Fri, 8 Apr 2011 17:23:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id B82963A6820 for ; Fri, 8 Apr 2011 17:23:51 -0700 (PDT) Received: by us.padl.com with ESMTP id p390PiKI032384; Fri, 8 Apr 2011 20:25:50 -0400 References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> In-Reply-To: <1302273997.10465.569.camel@t410> Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8G4) From: Luke Howard Date: Sat, 9 Apr 2011 10:25:22 +1000 To: Greg Hudson X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.7 Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 00:23:52 -0000 Is GSS_S_UNAUTHORIZED defined anywhere? I sort of prefer the separate argume= nt but I realize it may set a trap for API consumers. I do want a way to dis= tinguish between an authorization failure and some other error. Von meinem iPhone gesendet Am 09/04/2011 um 0:46 schrieb Greg Hudson : > On Thu, 2011-04-07 at 19:12 -0400, Luke Howard wrote: >>> OM_uint32 something(OM_uint32 *minor, gss_name_t authname, gss_name_t ln= ame); >>=20 >> What happened to user_ok boolean? >=20 > A good question. Sam, was that an oversight, or did you intend the > function to return GSS_S_SUCCESS for authorized and GSS_S_UNAUTHORIZED > for unauthorized? That way the mech could provide a reason for failure > via the minor code if it wants. >=20 >=20 From lukeh@padl.com Fri Apr 8 18:33:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3543A6A48 for ; Fri, 8 Apr 2011 18:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5cFPw1FGNp3 for ; Fri, 8 Apr 2011 18:33:49 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id E15673A6808 for ; Fri, 8 Apr 2011 18:33:48 -0700 (PDT) Received: by us.padl.com with ESMTP id p391ZpaI022227; Fri, 8 Apr 2011 21:35:54 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <2459D70C-AF2E-4D58-8F44-90214834DF0C@padl.com> Date: Sat, 9 Apr 2011 11:35:25 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8E57AC34-743A-4E07-A930-1274C07A3854@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> <1302274475.10465.575.camel@t410> <2459D70C-AF2E-4D58-8F44-90214834DF0C@padl.com> To: Greg Hudson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 01:33:51 -0000 On 09/04/2011, at 10:23 AM, Luke Howard wrote: > Re: name type, good idea, I shall fix. Shall we require it in the = Kerberos mech to be the null OID=20 OK, SPI fix committed to both MIT (moonshot-mechglue-fixes) and Heimdal = (moonshot). -- Luke From lukeh@padl.com Fri Apr 8 18:37:03 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917623A6A5D for ; Fri, 8 Apr 2011 18:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtiCgFwB9KkY for ; Fri, 8 Apr 2011 18:37:01 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id C34B53A6A48 for ; Fri, 8 Apr 2011 18:37:01 -0700 (PDT) Received: by us.padl.com with ESMTP id p391d5wS028637; Fri, 8 Apr 2011 21:39:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Luke Howard In-Reply-To: <8E57AC34-743A-4E07-A930-1274C07A3854@padl.com> Date: Sat, 9 Apr 2011 11:38:39 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <463073FC-C192-4FC9-B675-4D50F38D6D05@padl.com> <1302274475.10465.575.camel@t410> <2459D70C-AF2E-4D58-8F44-90214834DF0C@padl.com> <8E57AC34-743A-4E07-A930-1274C07A3854@padl.com> To: kitten@ietf.org X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 01:37:03 -0000 Which looks like (from Heimdal sources): typedef OM_uint32 GSSAPI_CALLCONV _gss_authorize_localname_t ( OM_uint32 *, /* minor_status */ const gss_name_t, /* name */ gss_const_buffer_t, /* user */ gss_const_OID, /* user_name_type */ int * /* user_ok */ ); On 09/04/2011, at 11:35 AM, Luke Howard wrote: >=20 > On 09/04/2011, at 10:23 AM, Luke Howard wrote: >=20 >> Re: name type, good idea, I shall fix. Shall we require it in the = Kerberos mech to be the null OID=20 >=20 > OK, SPI fix committed to both MIT (moonshot-mechglue-fixes) and = Heimdal (moonshot). >=20 > -- Luke >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From wmills@yahoo-inc.com Fri Apr 8 20:04:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5E53A69A5 for ; Fri, 8 Apr 2011 20:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EWLOndKlXKd for ; Fri, 8 Apr 2011 20:04:39 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id 970F43A69A2 for ; Fri, 8 Apr 2011 20:04:39 -0700 (PDT) Received: (qmail 70229 invoked by uid 60001); 9 Apr 2011 03:06:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302318382; bh=rXGg3f+2FhHGbqFYKtzFe+3/tK6zOcVoPq/pf1XJ5Gg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=U0co8qyBV9TDmfPgHLEpFw4mrdTEiU8wbnemDMNjQWf3xO1OAZO7Wq6w0Lfl37T951Qp7mUOuvMBI45OBi4IvHPDOOB/HG0IZbVjg3hlOvPdhSsg/fm9Z6/2WltKp3Obn0w+8XA1+r+4wlbmFtp81bISTS67yQ6kuM4PaowZVEo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DCzlQvYn0ESssCHCngVEYWRrmMzXf9RsWPzjhcmnT7BEUFxyzPK1rT0YW2EDSc2SOFfAuxVnuZM7C26Fu1LvLiNH+JvPD+oZB0jltYg+1TXie8Igwk7DQFTjxQxxUVhJ1KfnL2Ai8Au9vXKJw9C+AAAvFR/ml4/Sf8pWyEYaCvs=; Message-ID: <277844.39554.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: pRFhjiwVM1l7krFvnWzc5yhw7vyZ7goL9qaRiNKYWVZo5gH RQ3OiBOWf85LRfppcpbDT9QcdPUzGhu05F7dDtHk3RKk.9mBqCS_k4m4cgiB P5w.k8s7mek8V9dVC0Bq0kqsqImK77zh6F2DV005B.34peKJvWNn_5kcS1MG 59HY45Me3QmmK5wGD0dTAe_VZtb0R0zBiz3yu9x_YicWWQQo15ryok._vols jKBGaMCChxB6DNFiPds3POnVZwYBR73OGo45YO874RIj1VqNnmb53aj3jPnI KQd_zr98Nx83qqVcAGBoURDEY8d4Hdr_MZVYlEkU6Zxr01UYaeIhZthep92D bRZRsgUP8n0IRO_sc4.eRFHn8OLMZONkkyaBAt_NX Received: from [209.131.62.115] by web32314.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 20:06:22 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> Date: Fri, 8 Apr 2011 20:06:22 -0700 (PDT) From: "William J. Mills" To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-353438638-1302318382=:39554" Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 03:04:40 -0000 --0-353438638-1302318382=:39554 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ah, so it would be valid for me to specify a cryptographic hash of the chan= nel binding data and send the hash?=0A=0A=0A=0A____________________________= ____=0AFrom: Nico Williams =0ATo: William J. Mills =0ACc: "kitten@ietf.org" =0ASent: Friday,= April 8, 2011 5:13 PM=0ASubject: Re: [kitten] CB data characteristics Re: = Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02=0A=0A=0AO= n Apr 8, 2011 7:11 PM, "William J. Mills" wrote:=0A>= =0A> Related questions about channel binding data...=0A>=0A> CB data is pre= fixed with the channel binding scheme name and a colon, is there BNF or a d= efinition for what the rest of that looks like?=A0 Do I need to base64 it t= o make it safe to move in an HTML context?=0ANo, there is no such thing.=A0= Each channel defines its CB data.=0A> Also, how big will it end up?=A0 I s= uppose an SSL certificate can be a few k in the extreme case.=0AIt can get = large.=A0 Mechanisms should either MAC the CB data or mix it into key deriv= ation.=0ANico=0A-- --0-353438638-1302318382=:39554 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Ah, so it would be valid for me to specify a cryptographic hash of the ch= annel binding data and send the hash?

From: Nico Williams <nico103@g= mail.com>
To: Willia= m J. Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Friday, April 8, 2011 5:13 PM=
Subject: Re: [kitten] = CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sa= sl-oauth-02

=0A
On Apr 8, 2011 7:11 PM, "William= J. Mills" <wmills@yahoo-inc.com= > wrote:
=0A>
=0A> Related questions about channel bindi= ng data...
=0A>
=0A> CB data is prefixed with the channel bindi= ng scheme name and a colon, is there BNF or a definition for what the rest = of that looks like?  Do I need to base64 it to make it safe to move in= an HTML context?
=0A
No, there is no such thing.  Each chann= el defines its CB data.
=0A
> Also, how big will it end up?&nbs= p; I suppose an SSL certificate can be a few k in the extreme case.
= =0A
It can get large.  Mechanisms should either MAC the CB data or= mix it into key derivation.
=0A
Nico
=0A--
=0A


=
--0-353438638-1302318382=:39554-- From ghudson@mit.edu Fri Apr 8 20:18:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF043A69AF for ; Fri, 8 Apr 2011 20:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlT7MBw8PXjO for ; Fri, 8 Apr 2011 20:18:51 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by core3.amsl.com (Postfix) with ESMTP id 2ECB63A69A5 for ; Fri, 8 Apr 2011 20:18:50 -0700 (PDT) X-AuditID: 1209190f-b7cf3ae0000046b8-4f-4d9fd07fc2cd Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 23.BD.18104.F70DF9D4; Fri, 8 Apr 2011 23:20:31 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p393KZRB032580; Fri, 8 Apr 2011 23:20:35 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p393KWve018665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 8 Apr 2011 23:20:34 -0400 (EDT) From: Greg Hudson To: Luke Howard In-Reply-To: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> Content-Type: text/plain; charset="UTF-8" Date: Fri, 08 Apr 2011 23:20:31 -0400 Message-ID: <1302319231.10465.585.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT162/MN/X4NFVC4ujm1exWNy99J/d gcljyZKfTB5zP0xjCWCK4rJJSc3JLEst0rdL4Mr48fkBe8EZporLq44zNTD+Z+xi5OSQEDCR 2LVnPZQtJnHh3nq2LkYuDiGBfYwSLVe/s0M46xkl7n5cDlYlJHCXSaLhSgGILSygIPF91naw OJuAssTBs99YQGwRoPjk/WuZQWxmAXWJo8+bgKZycHAK2EgcbwqCmPmdUWLnimmMEDWaEq3b f7OD2CwCqhIHHn0Fi/MK6Eoc6D/MBNLLKyAo8XeHMMSh0hJfJzxhgmiVl9j+dg7zBEbBWUgm zULomIWkagEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYyg4OWU5N/B+O2g 0iFGAQ5GJR7e/abzfYVYE8uKK3MPMUpyMCmJ8jafBQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS 4WU/ApTjTUmsrEotyodJSXOwKInzzpJU9xUSSE8sSc1OTS1ILYLJynBwKEnwLjkP1ChYlJqe WpGWmVOCkGbi4AQZzgM0vOUMyPDigsTc4sx0iPwpRl2O/1sO7WMUYsnLz0uVEudtARkkAFKU UZoHNweWdF4xigO9Jcw7DaSKB5iw4Ca9AlrCBLSk8DTYkpJEhJRUA2P31w+CunPSpiR23YuO DTW6Uu6yK/LlpNUPmr3smSq0TBdqLNj9z2rR17352zuDxXXXR8imdyxcpbdo2Rzj3s7E9s+Z dssu3Isv4Zv+X+T7Mg4HRbmb2249W/1o6ekrDcu9OPc975r1edqb09eS921PqdPuuuiwJ+Tp o2k8r52nJwtfkHrtNvONEktxRqKhFnNRcSIAEbvBzhUDAAA= Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 03:18:52 -0000 On Fri, 2011-04-08 at 20:25 -0400, Luke Howard wrote: > Is GSS_S_UNAUTHORIZED defined anywhere? Yes, in RFC 2743 and RFC 2744. > Re: name type, good idea, I shall fix. Shall we require it in the > Kerberos mech to be the null OID or...? How would that work? I would expect to require it to be GSS_C_NT_USER_NAME. From lukeh@padl.com Fri Apr 8 20:23:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918B63A69AF for ; Fri, 8 Apr 2011 20:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KapmEdRG5oL for ; Fri, 8 Apr 2011 20:23:22 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id DC3F93A6A72 for ; Fri, 8 Apr 2011 20:23:21 -0700 (PDT) Received: by us.padl.com with ESMTP id p393Pecd019588; Fri, 8 Apr 2011 23:25:43 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1302319231.10465.585.camel@t410> Date: Sat, 9 Apr 2011 13:24:59 +1000 Content-Transfer-Encoding: 7bit Message-Id: References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> <1302319231.10465.585.camel@t410> To: Greg Hudson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 03:23:22 -0000 On 09/04/2011, at 1:20 PM, Greg Hudson wrote: > On Fri, 2011-04-08 at 20:25 -0400, Luke Howard wrote: >> Is GSS_S_UNAUTHORIZED defined anywhere? > > Yes, in RFC 2743 and RFC 2744. OK, perhaps this is cleaner then. >> Re: name type, good idea, I shall fix. Shall we require it in the >> Kerberos mech to be the null OID or...? > > How would that work? I would expect to require it to be > GSS_C_NT_USER_NAME. Right you are. -- Luke From lukeh@padl.com Fri Apr 8 20:41:00 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7453A6A35 for ; Fri, 8 Apr 2011 20:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0w7lesN5e-o for ; Fri, 8 Apr 2011 20:40:59 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 607473A6A2A for ; Fri, 8 Apr 2011 20:40:59 -0700 (PDT) Received: by us.padl.com with ESMTP id p393hNBP021859; Fri, 8 Apr 2011 23:43:26 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1302319231.10465.585.camel@t410> Date: Sat, 9 Apr 2011 13:42:40 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> <1302319231.10465.585.camel@t410> To: Greg Hudson X-Mailer: Apple Mail (2.1084) Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 03:41:00 -0000 On 09/04/2011, at 1:20 PM, Greg Hudson wrote: > On Fri, 2011-04-08 at 20:25 -0400, Luke Howard wrote: >> Is GSS_S_UNAUTHORIZED defined anywhere?=20 >=20 > Yes, in RFC 2743 and RFC 2744. OK, now it looks like: OM_uint32 gss_authorize_localname(OM_uint32 *minor, const gss_name_t name, const gss_name_t user); Committed for Heimdal and MIT. Not tested yet. I'll try and do that next = week. -- Luke= From nico@cryptonector.com Fri Apr 8 21:44:29 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E507F3A69EA for ; Fri, 8 Apr 2011 21:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IA8VF7KxQMR for ; Fri, 8 Apr 2011 21:44:29 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 2CDC83A69A7 for ; Fri, 8 Apr 2011 21:44:29 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id EF5EB678056 for ; Fri, 8 Apr 2011 21:46:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=UaMciiISfyzFZxYaYnl6y mQkRk1gzxwuta/u4fN61NrCZ87udQwNBrQXDpX+8uhcfEBc60t1WDODUgYRMmPAd PL1Jqb4QfVDQ+zA7bU8HKODqX5cOdYVVmvM9v634T4SukRNv6u4Kg1z6cW1xysmm 9ZzdfdH29eGTUKVT9VYJl8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=31mO0kOr5wTD0TT2ezH7 0iDmDD0=; b=ox20LxbmS3YNutMCKKPzzVl3x5fMA4xapebF5Bhwbizo2uaKhUIb 25imQdXcetTMO/wDuIkInYobrmIzeaWamx42Gc2sE+6x1biKLYurL5adQ8pnBXwF vgwNgkkCfIxSdmm3TZk4EoL+lB+gqq0f6B8VSa4d+N8+z23cZ1d6i+I= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id CD784678055 for ; Fri, 8 Apr 2011 21:46:14 -0700 (PDT) Received: by vws12 with SMTP id 12so3875737vws.31 for ; Fri, 08 Apr 2011 21:46:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.180.9 with SMTP id dk9mr4256951vdc.134.1302324374034; Fri, 08 Apr 2011 21:46:14 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 21:46:13 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 21:46:13 -0700 (PDT) In-Reply-To: <991228.73942.qm@web32303.mail.mud.yahoo.com> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> Date: Fri, 8 Apr 2011 23:46:13 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: multipart/alternative; boundary=bcaec5186a4cb25a2c04a075057c Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 04:44:30 -0000 --bcaec5186a4cb25a2c04a075057c Content-Type: text/plain; charset=UTF-8 >On Apr 8, 2011 7:11 PM, "William J. Mills" wrote: > Related questions about channel binding data... > CB data is prefixed with the channel binding scheme name and a colon, is there BNF or a definition for what the rest of that looks like? Do I need to base64 it to make it safe to move in an HTML context? No, there is no such thing. Each channel defines its CB data. > Also, how big will it end up? I suppose an SSL certificate can be a few k in the extreme case. It can get large. Mechanisms should either MAC the CB data or mix it into key derivation. Nico -- --bcaec5186a4cb25a2c04a075057c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>On Apr 8, 2011 7:11 PM, "William J. Mills" <wmills@yahoo-inc.com> wrote:
> Related questions about channel binding data...
> CB data is prefixed with the channel binding scheme name and a colon, = is there BNF or a definition for what the rest of that looks like?=C2=A0 Do= I need to base64 it to make it safe to move in an HTML context?

No, there is no such thing.=C2=A0 Each channel defines its CB data.

> Also, how big will it end up?=C2=A0 I suppose an SSL certificate ca= n be a few k in the extreme case.

It can get large.=C2=A0 Mechanisms should either MAC the CB data or mix = it into key derivation.

Nico
--

--bcaec5186a4cb25a2c04a075057c-- From wmills@yahoo-inc.com Fri Apr 8 22:21:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A2B3A6866 for ; Fri, 8 Apr 2011 22:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo1aLWCLRs4V for ; Fri, 8 Apr 2011 22:21:32 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 52BFB3A6A81 for ; Fri, 8 Apr 2011 22:21:32 -0700 (PDT) Received: (qmail 99592 invoked by uid 60001); 9 Apr 2011 05:23:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302326595; bh=Rtot1sEERdW+aybB1lqjzbA503V584KctAfBiSgWq78=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CQ9I7u5n9Gk42SJRehXgeF8zPBfF4kv2O5BtIcyzqYjdySv+SBbANPjuDCShRGlq0Y2RPyFpYAuyWmw0IQT9eYT+KrLUAsaJd0kP7LKxSB/j+WSbQBcE68SZiWDDzKH0HDCoRxFIst/qlC8WLVA8g0K+gF1KErENJ5AJDe2+Ng8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=jf+Mt44Ml2Q9IzFeJo3hwwupo97qQ5HTOn15tciCZRpk2CPuY3Ny8r325lCRMDwaLqH12EW2q4x6WeLBUkxVpwwd6UrtK0rb3cIb5GKf3JIM4QZAeOMgLsYmKJU2fEzlmWai4hAZ1eXWI1A+V38L2gS7bjy1UnzwMn1BpcPRfxU=; Message-ID: <342439.86947.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: zGpeHMAVM1kyq1BZ9ZuTaK8_8cJhU9jpDoM4tfcG8iYtUtt G0v64nNhB4yUW7nYu51g7Ar0HYUzBUG0Tbg9jafahzkFQfmxbisGMHbm0ZmW kNsToupWhEsVND.WhkEhuZj.L.XekvqN7fhWo2qP9xKeuVVnNrfPJ33GTKk2 wWvghcz7d_vElxuucawIWMKaFGLbnwg28LDgR_SUYfhtNPAEQ0whEBIlP6rZ wTab9s6QySH9tg4iT1UNbzsgjW9J3eovd61.3edspduFNUy6OVNEVitHvNuY EJX83RaYlUhtsq9mT8Xg42x1Ivy7W2ZgV0rlpjeYqPZs7Xxzk8j8Fs9bPW6b nS1xn4JYzL4J7e4pChiNwdwmVZFdstSjD Received: from [209.131.62.115] by web32303.mail.mud.yahoo.com via HTTP; Fri, 08 Apr 2011 22:23:15 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> Date: Fri, 8 Apr 2011 22:23:15 -0700 (PDT) From: "William J. Mills" To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-474468664-1302326595=:86947" Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 05:21:34 -0000 --0-474468664-1302326595=:86947 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable At the moment in the IANA registry I only see the tls-* channel bindings de= fined.=A0 Does that sound correct?=A0 Does this mean the mechanism has to r= oll-it's-own in cases other than TLS?=0A=0A=0A=0A__________________________= ______=0AFrom: Nico Williams =0ATo: William J. Mills= =0ACc: "kitten@ietf.org" =0ASent: F= riday, April 8, 2011 9:46 PM=0ASubject: Re: [kitten] CB data characteristic= s Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02=0A= =0A=0A>On Apr 8, 2011 7:11 PM, "William J. Mills" wr= ote:=0A> Related questions about channel binding data...=0A> CB data is pre= fixed with the channel binding scheme name and a colon, is there BNF or a d= efinition for what the rest of that looks like?=A0 Do I need to base64 it t= o make it safe to move in an HTML context?=0ANo, there is no such thing.=A0= Each channel defines its CB data.=0A> Also, how big will it end up?=A0 I s= uppose an SSL certificate can be a few k in the extreme case.=0AIt can get = large.=A0 Mechanisms should either MAC the CB data or mix it into key deriv= ation.=0ANico=0A-- --0-474468664-1302326595=:86947 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
At t= he moment in the IANA registry I only see the tls-* channel bindings define= d.  Does that sound correct?  Does this mean the mechanism has to= roll-it's-own in cases other than TLS?

From: Nico Williams <nico@cryptone= ctor.com>
To: Willia= m J. Mills <wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Friday, April 8, 2011 9:46 PM=
Subject: Re: [kitten] CB data char= acteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oa= uth-02

=0A
>On Apr 8, 2011 7:11 PM, "William= J. Mills" <wmills@yahoo-inc.com= > wrote:
=0A> Related questions about channel binding data...<= br>=0A> CB data is prefixed with the channel binding scheme name and a c= olon, is there BNF or a definition for what the rest of that looks like?&nb= sp; Do I need to base64 it to make it safe to move in an HTML context?=0A
No, there is no such thing.  Each channel defines its CB data= .
=0A
> Also, how big will it end up?  I suppose an SSL ce= rtificate can be a few k in the extreme case.
=0A
It can get large= .  Mechanisms should either MAC the CB data or mix it into key derivat= ion.
=0A
Nico
=0A--
=0A


--0-474468664-1302326595=:86947-- From nico@cryptonector.com Fri Apr 8 23:52:38 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF483A69EC for ; Fri, 8 Apr 2011 23:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgE-yUyk0THg for ; Fri, 8 Apr 2011 23:52:37 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 94EE73A6868 for ; Fri, 8 Apr 2011 23:52:37 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 7CB0876805C for ; Fri, 8 Apr 2011 23:54:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fkREZmitzaGu8iBqsxckQ gTYTxNyNpPTD6jg/8xzTDV6AlsfKNlFpdHpiAvR1OPW0KwMPv70IRMuLfRWL12Tc HPXjWSAUqtFCgcL3RW7kZngmpI7ZwiYgm9CXH7kWjgXJi+N7JXWXKf85lQmdy6vL RvHjPK34ae8GM8ANR0hCC0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Kjfdji5rqG2KSfO8VwA+ 0S1RgRQ=; b=q9pwZ8k2qQ6cPL6tN9GujRRUmF3fCPK63DnCmv3pxFHDS4zM60h/ 5UeuIaDIgL4PQlO0xhJVbloUfbrNqds1XL6oFeNnbipe3Lims3NpGNqUDnkHJmXh T87Jw5n/t9qSj8VMxik/ZLNhMsVVFEzTJbtC/NbIP1eWe6atbKVRmb8= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 4D32A768059 for ; Fri, 8 Apr 2011 23:54:23 -0700 (PDT) Received: by vws12 with SMTP id 12so3920314vws.31 for ; Fri, 08 Apr 2011 23:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.1 with SMTP id eu1mr1269505vdb.174.1302332062666; Fri, 08 Apr 2011 23:54:22 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 23:54:22 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 23:54:22 -0700 (PDT) In-Reply-To: <277844.39554.qm@web32314.mail.mud.yahoo.com> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> Date: Sat, 9 Apr 2011 01:54:22 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: multipart/alternative; boundary=20cf3071c6fcf98f9304a076cfbb Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 06:52:39 -0000 --20cf3071c6fcf98f9304a076cfbb Content-Type: text/plain; charset=UTF-8 On Apr 8, 2011 10:06 PM, "William J. Mills" wrote: > > Ah, so it would be valid for me to specify a cryptographic hash of the channel binding data and send the hash? Yes, very much so. Keyed hashes (MACs) are better, if you can swing that, but a hash will do. --20cf3071c6fcf98f9304a076cfbb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 8, 2011 10:06 PM, "William J. Mills" <wmills@yahoo-inc.com> wrote:
>
> Ah, so it would be valid for me to specify a cryptographic hash of the= channel binding data and send the hash?

Yes, very much so.=C2=A0 Keyed hashes (MACs) are better, if you can swin= g that, but a hash will do.

--20cf3071c6fcf98f9304a076cfbb-- From nico@cryptonector.com Fri Apr 8 23:54:53 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFB63A69EC for ; Fri, 8 Apr 2011 23:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXAfD8FxwKnL for ; Fri, 8 Apr 2011 23:54:53 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 23E333A69E0 for ; Fri, 8 Apr 2011 23:54:53 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 223FC438072 for ; Fri, 8 Apr 2011 23:56:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=hESjNkqzhobXRA7F+wYms jSe/qfObH+uT0BzYBxFfv95fJFb+6jb0Gf2MVXdM21HriO2TrK+rjq0/lsJfc6Qv BYJVC1wAW4UcNlSmbKCxscrbfla+WU88wGPTIyj/KBaU3cT7MD2js8M2Sl7SqW16 tUpV6SyAF4jqokBVLq3+0g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vmWPWJaNbk1PHKTaXW5b vvgt/Ks=; b=yZ+AXQ1nVCDDZm+AdshrcC58K4keowPhuKYDDnU84bOLKHd92/gT wqkCK4fFT38ImSOXkdmqhGw5U0mx6H7FvuB4vhvWSgSQZ5yvSoDyTmFK1l/XHp2v 7KjNVjOZnOIos/pLczqyvM2tIedpmkZQbCTOplq14wgnIDNgjYI3P1c= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id F3E7443806C for ; Fri, 8 Apr 2011 23:56:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so3888828vxg.31 for ; Fri, 08 Apr 2011 23:56:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.1 with SMTP id eu1mr1271616vdb.174.1302332198257; Fri, 08 Apr 2011 23:56:38 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 23:56:38 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Fri, 8 Apr 2011 23:56:38 -0700 (PDT) In-Reply-To: <342439.86947.qm@web32303.mail.mud.yahoo.com> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <342439.86947.qm@web32303.mail.mud.yahoo.com> Date: Sat, 9 Apr 2011 01:56:38 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: multipart/alternative; boundary=20cf3071c6fc0e850304a076d841 Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 06:54:53 -0000 --20cf3071c6fc0e850304a076d841 Content-Type: text/plain; charset=UTF-8 On Apr 9, 2011 12:23 AM, "William J. Mills" wrote: > > At the moment in the IANA registry I only see the tls-* channel bindings defined. Does that sound correct? Does this mean the mechanism has to roll-it's-own in cases other than TLS? No, mechanisms never get to "roll their own". The channel is responsible for producing its CB data. We know how to construct CB for other channel types... We just haven't registered them yet :) --20cf3071c6fc0e850304a076d841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 9, 2011 12:23 AM, "William J. Mills" <wmills@yahoo-inc.com> wrote:
>
> At the moment in the IANA registry I only see the tls-* channel bindin= gs defined.=C2=A0 Does that sound correct?=C2=A0 Does this mean the mechani= sm has to roll-it's-own in cases other than TLS?

No, mechanisms never get to "roll their own".=C2=A0 The channe= l is responsible for producing its CB data.=C2=A0 We know how to construct = CB for other channel types...=C2=A0 We just haven't registered them yet= :)

--20cf3071c6fc0e850304a076d841-- From wmills@yahoo-inc.com Sat Apr 9 00:26:09 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C343A69E0 for ; Sat, 9 Apr 2011 00:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX5gMiujTJu1 for ; Sat, 9 Apr 2011 00:26:09 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id C98E93A69A9 for ; Sat, 9 Apr 2011 00:26:08 -0700 (PDT) Received: (qmail 48666 invoked by uid 60001); 9 Apr 2011 07:27:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302334071; bh=xVodZQ+OYx51XIbtnf1gPcURJDkfpG/BkDPlQqc8y9s=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=J4VP+EcRe8v8b6qNgpSB6Rbl63aDar0b9oOXsZdpVHjqJZcMPlsLO/1sR7L8/GWTkZtD3zxYqgAn8Zi8mTNMr0t7f5wwjW/8bRigZ8mRookkIFTbFcqTzr/NwPppr3HZ8WNdge20c2DhJqLjFhVHs3ERCl8OqCVUVcX+R7pRqg8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=qVrA17rJA9pz6auEofqcFZMLpY0gbX+mbbQdT/XqvUoa0t/zJ+vo5zWZXpK/AUCU+iyFMeuaQBCb24PL7zGuAReHB6Fv0XMjiOsC/gHsIEyv+lnyUF1Uuit7kLaW5ltXQNOT+/MDAcp2gH0qPr56OJ0AZunIT1zzq94c8bzO0Dk=; Message-ID: <878377.41252.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: FqfoYhYVM1nXJB2Tx8hjcUpkBhxPACM326l48_QjnlsSiFr KyR5gpbPfHlw1TGbMpxXlC6MpgYc120jhlYVIE2VI0DZnl73bJMyMtLjk5LI tvPaehsWivfWc9bFP3AT8EN.TB6AXYakVYT_A7iqkqCCuLGgV1.t7sIUrYx9 .oLa5_w0tPCkNa7qaO6f1.VqpmrX1x3MQr8IMEHW6NOTfh871_5cV8wxtvWh ETugYhXn3GwmAEewCDz7v5xzTGmkI7TqYT0pPr2mCxbLV9yqvJWhnQSW_2Be wc08WG1uTNXVtuJvKIdt_jf3lJRyQ7nFig._I6wDDOERXuDRSRHF0IB1fweS gm2mbqgaFWhDLaHnl_EFtnYJOf5Nws2hp Received: from [209.131.62.115] by web32303.mail.mud.yahoo.com via HTTP; Sat, 09 Apr 2011 00:27:51 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> Date: Sat, 9 Apr 2011 00:27:51 -0700 (PDT) From: "William J. Mills" To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1643223748-1302334071=:41252" Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 07:26:09 -0000 --0-1643223748-1302334071=:41252 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable So, I think the way to go in this mechanism is to send the channel binding = type identifier and a SHA-1 hash of the channel binding data.=A0 If the CB = data is short I suppose we could optimise it, but I like simple for this. = =0A=0A=0AI'll add that change to the draft.=0A=0A=0A=0A____________________= ____________=0AFrom: Nico Williams =0ATo: William J.= Mills =0ACc: "kitten@ietf.org" =0AS= ent: Friday, April 8, 2011 11:54 PM=0ASubject: Re: [kitten] CB data charact= eristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth= -02=0A=0A=0AOn Apr 8, 2011 10:06 PM, "William J. Mills" wrote:=0A>=0A> Ah, so it would be valid for me to specify a cryptograph= ic hash of the channel binding data and send the hash?=0AYes, very much so.= =A0 Keyed hashes (MACs) are better, if you can swing that, but a hash will = do. --0-1643223748-1302334071=:41252 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
So, I think the way to go in this mechanism is to send the channel bindin= g type identifier and a SHA-1 hash of the channel binding data.  If th= e CB data is short I suppose we could optimise it, but I like simple for th= is.

I'll add that c= hange to the draft.

From: Nico Williams <nico@cryptonector.com>To: William J. Mills <= ;wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Friday, April 8, 2011 11:54 PM
Subject: Re: [kitten] CB data characteri= stics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02=

=0A
On Apr 8, 2011 10:06 PM, "William J. Mill= s" <wmills@yahoo-inc.com&g= t; wrote:
=0A>
=0A> Ah, so it would be valid for me to specify = a cryptographic hash of the channel binding data and send the hash?
= =0A
Yes, very much so.  Keyed hashes (MACs) are better, if you can= swing that, but a hash will do.
=0A


--0-1643223748-1302334071=:41252-- From nico@cryptonector.com Sat Apr 9 01:02:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB89D3A69A9 for ; Sat, 9 Apr 2011 01:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6GovgogCmSU for ; Sat, 9 Apr 2011 01:02:31 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id B1F993A68AA for ; Sat, 9 Apr 2011 01:02:30 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 8EC87584058 for ; Sat, 9 Apr 2011 01:04:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Q8Hlj/ljrvY/LbU6n4t4v 6f9ZfN/luKEr+Ch62V9GLwgbdljAJphHbzKxFrLOwkizt5je2O4ZcHLFjPpRNnW9 22Kxg3YjzIWgOVFB2hhq454VpBiJifYhJyWTV9OhKCweftsRZQmFD8/wDQ09WBIw rMbzZD6T1KJabO9pPtR1JA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=C9ry4XKGgV9Y/FOlCpkH +Ui8eSo=; b=N4baMI5+F4onUBYYBZKiOI1ZrCZ4UulP+iqvsbkMzMQfI1UkqusH z1bkmMexQidCXqXK1xiC5eNUrHfnMQGWYI+RuG8H/0Iz1uB4XUUrRwZ8z3/WSKHp q0YnxlwkJnmbx94Axe0S8mJlXmrw2X+6svNaoZSRMSDiRQU74YI2feE= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 681FB584057 for ; Sat, 9 Apr 2011 01:04:15 -0700 (PDT) Received: by vws12 with SMTP id 12so3945776vws.31 for ; Sat, 09 Apr 2011 01:04:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.1 with SMTP id eu1mr1339137vdb.174.1302336254746; Sat, 09 Apr 2011 01:04:14 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Sat, 9 Apr 2011 01:04:14 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Sat, 9 Apr 2011 01:04:14 -0700 (PDT) In-Reply-To: <878377.41252.qm@web32303.mail.mud.yahoo.com> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> <878377.41252.qm@web32303.mail.mud.yahoo.com> Date: Sat, 9 Apr 2011 03:04:14 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: multipart/alternative; boundary=20cf3071c6fcd7a1eb04a077c900 Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 08:02:31 -0000 --20cf3071c6fcd7a1eb04a077c900 Content-Type: text/plain; charset=UTF-8 On Apr 9, 2011 2:27 AM, "William J. Mills" wrote: > > So, I think the way to go in this mechanism is to send the channel binding type identifier and a SHA-1 hash of the channel binding data. If the CB data is short I suppose we could optimise it, but I like simple for this. Uh, so i did tell you one thing wrong earlier: CB data will generally be small. The TLS CB types are small... If you assume they'll be small then you can dispense with the hash and any hash algorithm agility issues. Sorry about that! Nico -- --20cf3071c6fcd7a1eb04a077c900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 9, 2011 2:27 AM, "William J. Mills" <wmills@yahoo-inc.com> wrote:
>
> So, I think the way to go in this mechanism is to send the channel bin= ding type identifier and a SHA-1 hash of the channel binding data.=C2=A0 If= the CB data is short I suppose we could optimise it, but I like simple for= this.

Uh, so i did tell you one thing wrong earlier: CB data will generally be= small.=C2=A0 The TLS CB types are small...=C2=A0 If you assume they'll= be small then you can dispense with the hash and any hash algorithm agilit= y issues.=C2=A0 Sorry about that!

Nico
--

--20cf3071c6fcd7a1eb04a077c900-- From alexey.melnikov@isode.com Sat Apr 9 14:49:47 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372133A696F for ; Sat, 9 Apr 2011 14:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I9Bh+6nCaNm for ; Sat, 9 Apr 2011 14:49:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E09383A6958 for ; Sat, 9 Apr 2011 14:49:45 -0700 (PDT) Received: from [188.29.15.207] (188.29.15.207.threembb.co.uk [188.29.15.207]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 9 Apr 2011 22:51:30 +0100 Message-ID: <4DA0D494.6050304@isode.com> Date: Sat, 09 Apr 2011 22:50:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: kitten@ietf.org References: <4D94377D.5040508@oracle.com> In-Reply-To: <4D94377D.5040508@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 21:49:47 -0000 Shawn M Emery wrote: > This message officially starts the Kitten Working Group Last Call for > the following document: > > A SASL and GSS-API Mechanism for SAML > http://tools.ietf.org/html/draft-ietf-kitten-sasl-saml-02 > > The Working Group Last Call for this document starts today on Thursday, > March 31st and will end on Thursday, April 14th. > > Please send any comments to the Kitten mailing list or directly to the > chairs. Feed-back from reviews that found no issues are also welcome. While some of the generic issues are the same for this document and for the OpenID one, this draft is in a better shape, IMHO. At least I think this is actually implementable without relying on some abstract definition of a browser. Below are some specific comments: 1. Introduction Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] is a modular specification that provides various means for a user to be identified to a relying party (RP) through the exchange of (typically signed) assertions issued by an identity provider (IdP). It includes a number of protocols, protocol bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles [OASIS.saml-profiles-2.0-os] designed for different use cases. Is any protocol binding mandatory-to-implement for interoperability? The SAML mechanism described in this memo aims to re-use the available SAML deployment to a maximum extent and therefore does not establish a separate authentication, integrity and confidentiality mechanism. The mechanisms assumes a security layer, such as Transport Layer Security (TLS), to protect against some attacks. An Informative reference to TLS is needed here. 3. Applicability for non-HTTP Use Cases 2. The RP sends an HTTP redirect as described in Section 10.3 of [RFC2616] to the browser to the Identity Provider (IdP) or an IdP discovery service with an authentication request that contains the name of resource being requested, some sort of a cookie and a return URL, "URL" needs a reference. 3. The Relying Party transmits an authentication request encoded using a Universal Resource Identifier (URI) as described in RFC 3986 [RFC3986] and a redirect to the IdP corresponding to the domain Is this always an HTTP/HTTPS URI? 7. The IdP will convey information about the success or failure of the authentication back to the the RP in the form of an Authentication Statement or failure, using a indirect response via the client browser or the handler. This step happens out of band from SASL. I think we need a mandatory to implement SAML protocol mapping here, otherwise this is not really implementable on the server side. Also, the document should be clear that the SASL server (==RP) needs to be able to talk HTTP/HTTPS. Please note: What is described here is the case in which the client has not previously authenticated. If the client can handle SAML internally it is possible that the client already holds a valid SAML authentication token so that the user does not need to be involved in the process anymore, but that would still be external to SASL. Would the client need to talk to RP using an HTTP/HTTPS connection? I think a bit more details here would help. Later in this section: I think an explicit statement about the need to correlate the original TCP connection with the SAML authentication is needed. Also explaining how this is done in the section with an XMPP example would help as well. 6. Channel Binding The "gs2-cb-flag" MUST use "n" because channel binding data cannot be integrity protected by the SAML negotiation. FIXME: Transfer channel binding in SAML assertion? Yes, this needs to be decided before the document goes to IETF LC. 8.1. Man in the middle and Tunneling Attacks This mechanism is vulnerable to man in the middle and tunneling attacks unless a client always verify the server identity before proceeding with authentication. Typically TLS is used to provide a secure channel with server authentication. Should this provide some details on TLS server identity verification, e.g. via an RFC 6125 reference? 10.1. Normative References I think this section need a Normative reference to HTTPS. From cantor.2@osu.edu Sat Apr 9 14:59:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0415C3A696F for ; Sat, 9 Apr 2011 14:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.035 X-Spam-Level: X-Spam-Status: No, score=-3.035 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUywstacx1JB for ; Sat, 9 Apr 2011 14:59:23 -0700 (PDT) Received: from defang8.it.ohio-state.edu (defang8.it.ohio-state.edu [128.146.216.89]) by core3.amsl.com (Postfix) with ESMTP id 5F9173A696B for ; Sat, 9 Apr 2011 14:59:23 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang8.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p39M18Y3021689; Sat, 9 Apr 2011 18:01:08 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::cd73:7784:284f:8055%13]) with mapi; Sat, 9 Apr 2011 17:57:16 -0400 From: "Cantor, Scott E." To: Alexey Melnikov , "kitten@ietf.org" Thread-Topic: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL73rllNXs9yl9Dk6ScWT87tVCLJRWZEwA//+/TZA= Date: Sat, 9 Apr 2011 22:01:03 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007AC2037@CIO-KRC-D1MBX01.osuad.osu.edu> References: <4D94377D.5040508@oracle.com> <4DA0D494.6050304@isode.com> In-Reply-To: <4DA0D494.6050304@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.89 Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 21:59:24 -0000 > While some of the generic issues are the same for this document and for > the OpenID one, this draft is in a better shape, IMHO. At least I think > this is actually implementable without relying on some abstract > definition of a browser. Then that's a difference in text, not reality. There's nothing whatsoever t= hat constrains a browser-based interface to a SAML IdP. > I think we need a mandatory to implement SAML protocol mapping here, > otherwise this is not really implementable on the server side. The reference needs to be to the SAML Browser SSO profile (given the goal o= f reusing that implementation). -- Scott From wmills@yahoo-inc.com Sat Apr 9 16:12:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 264E13A6977 for ; Sat, 9 Apr 2011 16:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wk4JBZLKEM7I for ; Sat, 9 Apr 2011 16:12:11 -0700 (PDT) Received: from web32303.mail.mud.yahoo.com (web32303.mail.mud.yahoo.com [68.142.207.151]) by core3.amsl.com (Postfix) with SMTP id 29BEA3A698F for ; Sat, 9 Apr 2011 16:12:11 -0700 (PDT) Received: (qmail 10094 invoked by uid 60001); 9 Apr 2011 23:13:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302390834; bh=8WKVPt3dH0flqdjHexJNYpr6k2fJPryCcAFKM98/0r8=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fpY1eF/OhSD7SwpZojfuElMvTnkQy86dZzGrQjVKDJDhKFyVtzhYRHknNkNQS468qlovUjqznoyZxLc+XWiviSen8S2csC1ZbOYvJhQTjQM8S7ikBrNLCMn09KosPKO4ba3xZfUwPnXKR4J2h/Sm9FToKdHJHlyHD3lsbPcEbtU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SftAdYuZvJTGQP3RutnhekOKkIaZw7/kJIxKcY1QB1w0VVFAqha/k6aNJ5pjXoTVov88WmuWGbFWVqrwY16vGtgXLOgv6RKEpRqxTLL+dNdMhdNuH/n5Eg8BRFj3X6Z+LD6liuiXX7j4DjFq82ol8HUJ6pUvRXSDNhOzeGLM7NA=; Message-ID: <800503.74700.qm@web32303.mail.mud.yahoo.com> X-YMail-OSG: qB.RBhsVM1l1ThXFlHHh.L9W1WAMPfziFrRf_7sruqfXTb5 fsqRiWCyUxnfRhCuRZLijRbosV92uXF9cXa_u0BMmxwwTMK.a7ywB7qbHRLO WLlKqFqLK3qSXY4Zn0.pBvos89BPBozQRZcpvBNN92sA6ZqeBgAr6omrb3e7 8EZxZe5IBL3b5.RojSRxFibcFP0ossOFet1zTDeWSqIYqAegRv0A.qQvcW1e jl9G_UomdkVlxST_17wlungKgCtoqNg_wG8M1xRMtWnXBHs.lNv4gWjU8JRO gBFjIP9Q89FM26u71.IYiNX70.fT7TmreW24lykmQRRgx20D8b0rMS.C.ibp YizhgpN7I3F6w Received: from [99.31.212.42] by web32303.mail.mud.yahoo.com via HTTP; Sat, 09 Apr 2011 16:13:54 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> <878377.41252.qm@web32303.mail.mud.yahoo.com> Date: Sat, 9 Apr 2011 16:13:54 -0700 (PDT) From: "William J. Mills" To: Nico Williams In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-671118622-1302390834=:74700" Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 23:12:12 -0000 --0-671118622-1302390834=:74700 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Well perhaps I'll get just fancy enough to say if the CB source data is > t= han 500 bytes then SHA-1 hash and pass the hash. =0A=0A=0AI'm stuffing this= in an HTML query parameter, and I don't want to end up with problems in cl= ient or servers that assume maximum lengths.=0A=0A=0A=0A___________________= _____________=0AFrom: Nico Williams =0ATo: William J= . Mills =0ACc: "kitten@ietf.org" =0A= Sent: Saturday, April 9, 2011 1:04 AM=0ASubject: Re: [kitten] CB data chara= cteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oau= th-02=0A=0A=0AOn Apr 9, 2011 2:27 AM, "William J. Mills" wrote:=0A>=0A> So, I think the way to go in this mechanism is to send = the channel binding type identifier and a SHA-1 hash of the channel binding= data.=A0 If the CB data is short I suppose we could optimise it, but I lik= e simple for this. =0AUh, so i did tell you one thing wrong earlier: CB dat= a will generally be small.=A0 The TLS CB types are small...=A0 If you assum= e they'll be small then you can dispense with the hash and any hash algorit= hm agility issues.=A0 Sorry about that!=0ANico=0A-- --0-671118622-1302390834=:74700 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Well perhaps I'll get just fancy enough to say if the CB source data is &= gt; than 500 bytes then SHA-1 hash and pass the hash.

I'm stuffing this in an HTML query param= eter, and I don't want to end up with problems in client or servers that as= sume maximum lengths.

From: Nico Williams <nico@cryptonector.com>=
To: William J. Mills &= lt;wmills@yahoo-inc.com>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Sent: Saturday, April 9, 2011 1:04 AM
Subject: Re: [kitten] CB data characteri= stics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02=

=0A
On Apr 9, 2011 2:27 AM, "William J. Mills"= <wmills@yahoo-inc.com> w= rote:
=0A>
=0A> So, I think the way to go in this mechanism is = to send the channel binding type identifier and a SHA-1 hash of the channel= binding data.  If the CB data is short I suppose we could optimise it= , but I like simple for this.
=0A=0A
Uh, so i did tell you one th= ing wrong earlier: CB data will generally be small.  The TLS CB types = are small...  If you assume they'll be small then you can dispense wit= h the hash and any hash algorithm agility issues.  Sorry about that!=0A=0A
Nico
=0A--
=0A


--0-671118622-1302390834=:74700-- From nico@cryptonector.com Sat Apr 9 16:16:33 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9890A3A6977 for ; Sat, 9 Apr 2011 16:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-6gOY94WUX7 for ; Sat, 9 Apr 2011 16:16:32 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id E6AAC3A68CB for ; Sat, 9 Apr 2011 16:16:32 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 3635D508071 for ; Sat, 9 Apr 2011 16:18:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=TeeTSrXFu3SKuN3cFFs/z Xowa4CyhqOArnoX0M5MWfHqVMyfmC789T5ok8bBZrxkrsWl7RFPnIcO1kfhO2E7U WZWiqb9wdi16uI30OI7BjhMAesSJ50Z4XsVg0fuqAZ2qbB0VosABCA25RnTHg90c RY+lBRnceMkMsnXiD5fN3c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JDLVSKgxV6RsgmoY8d6z 3bHdEQ0=; b=j6Sy3dig5hFK6INF/ymUAGf7HsoTosOtznk8A3Lado9BXKiMBxd2 p8+kzIQBf+131xfbVjx9nLvXE1PO0Qb4smTkR+zrYkPtKSmBxPm5kuV+EPFe51Nb x78uGh9x8y8BusCtdUZDHxt5X9sMahBMFENINobMhq9+p8RaWAuWupo= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 13A4450806D for ; Sat, 9 Apr 2011 16:18:19 -0700 (PDT) Received: by vxg33 with SMTP id 33so4236230vxg.31 for ; Sat, 09 Apr 2011 16:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.66.163 with SMTP id g3mr5395463vdt.94.1302391098412; Sat, 09 Apr 2011 16:18:18 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Sat, 9 Apr 2011 16:18:18 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Sat, 9 Apr 2011 16:18:18 -0700 (PDT) In-Reply-To: <800503.74700.qm@web32303.mail.mud.yahoo.com> References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> <878377.41252.qm@web32303.mail.mud.yahoo.com> <800503.74700.qm@web32303.mail.mud.yahoo.com> Date: Sat, 9 Apr 2011 18:18:18 -0500 Message-ID: From: Nico Williams To: "William J. Mills" Content-Type: multipart/alternative; boundary=20cf307f3ba6c78cf304a0848ee4 Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Apr 2011 23:16:33 -0000 --20cf307f3ba6c78cf304a0848ee4 Content-Type: text/plain; charset=UTF-8 On Apr 9, 2011 6:13 PM, "William J. Mills" wrote: > > Well perhaps I'll get just fancy enough to say if the CB source data is > than 500 bytes then SHA-1 hash and pass the hash. > > I'm stuffing this in an HTML query parameter, and I don't want to end up with problems in client or servers that assume maximum lengths. That will do. --20cf307f3ba6c78cf304a0848ee4 Content-Type: text/html; charset=UTF-8

On Apr 9, 2011 6:13 PM, "William J. Mills" <wmills@yahoo-inc.com> wrote:
>
> Well perhaps I'll get just fancy enough to say if the CB source data is > than 500 bytes then SHA-1 hash and pass the hash.
>
> I'm stuffing this in an HTML query parameter, and I don't want to end up with problems in client or servers that assume maximum lengths.

That will do.

--20cf307f3ba6c78cf304a0848ee4-- From lukeh@padl.com Sat Apr 9 22:56:58 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A67173A69D6 for ; Sat, 9 Apr 2011 22:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rvfCKMyuGCM for ; Sat, 9 Apr 2011 22:56:56 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 01FC53A69DA for ; Sat, 9 Apr 2011 22:56:54 -0700 (PDT) Received: by us.padl.com with ESMTP id p3A60END012051; Sun, 10 Apr 2011 02:00:21 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> Date: Sun, 10 Apr 2011 15:58:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <8DADE2FF-DE05-4325-99D0-D3CB05811141@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> <1302319231.10465.585.camel@t410> <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> To: Greg Hudson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.8 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 05:56:59 -0000 > Committed for Heimdal and MIT. Not tested yet. I'll try and do that = next week. Tested with MIT and OpenSSH. -- LUke= From shawn.emery@oracle.com Sun Apr 10 23:29:37 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D11F3A6A8A for ; Sun, 10 Apr 2011 23:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWcnFaLGe1sO for ; Sun, 10 Apr 2011 23:29:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 492FF3A6A81 for ; Sun, 10 Apr 2011 23:29:36 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3B6TYYK023173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Apr 2011 06:29:36 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p3B6TYA9015262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Apr 2011 06:29:34 GMT Received: from abhmt012.oracle.com (abhmt012.oracle.com [141.146.116.21]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3B6TYum008446 for ; Mon, 11 Apr 2011 01:29:34 -0500 Received: from [10.7.250.156] (/10.7.250.156) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 10 Apr 2011 23:29:33 -0700 Message-ID: <4DA29FCC.7010006@oracle.com> Date: Mon, 11 Apr 2011 00:29:32 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------090508080400000709090207" X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4DA29FCE.012E:SCFSTAT5015188,ss=1,fgs=0 Subject: [kitten] IETF 80 - Kitten Minutes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 06:29:37 -0000 This is a multi-part message in MIME format. --------------090508080400000709090207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We've uploaded the session minutes for Kitten here: http://www.ietf.org/proceedings/80/minutes/kitten.txt Please let us know if you have any updates before 4/29. Shawn. -- --------------090508080400000709090207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
We've uploaded the session minutes for Kitten here:

http://www.ietf.org/proceedings/80/minutes/kitten.txt

Please let us know if you have any updates before 4/29.

Shawn.
--
--------------090508080400000709090207-- From alexey.melnikov@isode.com Mon Apr 11 04:18:07 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B910E3A6B05 for ; Mon, 11 Apr 2011 04:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8KJ6An0dr8C for ; Mon, 11 Apr 2011 04:18:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E0CED3A6A7E for ; Mon, 11 Apr 2011 04:18:06 -0700 (PDT) Received: from [188.28.171.53] (188.28.171.53.threembb.co.uk [188.28.171.53]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 11 Apr 2011 12:18:05 +0100 Message-ID: <4DA2E333.4000502@isode.com> Date: Mon, 11 Apr 2011 12:17:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Simon Josefsson References: <87d3ltfw4t.fsf@latte.josefsson.org> <201104011900.p31J0BDm000246__39439.8072189235$1301684424$gmane$org@outgoing.mit.edu> <87aag9r9ab.fsf@latte.josefsson.org> <5B9F3A88-08BD-4067-9AD8-D795B3D15A84__5804.22167336128$1301776725$gmane$org@kth.se> <87r59j3io1.fsf@latte.josefsson.org> <2AC04CDE-E48A-4117-AFB8-C2D5F13E420C@padl.com> <87mxk73hoj.fsf@latte.josefsson.org> <9A83FB4F-4C2A-4F58-A3E2-C05EDE847905__13073.0196754032$1301816837$gmane$org@padl.com> <87aag73c8d.fsf@latte.josefsson.org> <8819952D-50A2-4FA7-A101-139E8044BFB7__14549.2997406565$1301827029$gmane$org@padl.com> <871v1j38eq.fsf@latte.josefsson.org> In-Reply-To: <871v1j38eq.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "" Subject: Re: [kitten] GSS-API additions? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:18:07 -0000 Simon Josefsson wrote: >Luke Howard writes: > > >>Looks good. Thanks for the acknowledgment! Now, should we do the same >>for naming extensions... (except MIT has shipped with the non const >>ones, but as Greg pointed out there are no ABI issues). >> > >Making the change elsewhere seems like a good idea to me. I wish we had >noticed the bug for the RFC 5801 interfaces as well. Possibly we could >submit an errata about it, and fix it in 5801bis? > Sure. >(..and RFC 2744..) > From info@gerd-stolpmann.de Mon Apr 11 07:24:04 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 397AD28C11C for ; Mon, 11 Apr 2011 07:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gZHV+GzjqT6 for ; Mon, 11 Apr 2011 07:24:03 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 2913C28C126 for ; Mon, 11 Apr 2011 07:24:00 -0700 (PDT) Received: from office1.lan.sumadev.de (dslb-094-219-215-025.pools.arcor-ip.net [94.219.215.25]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MXovv-1QMsWt3izP-00WkMr; Mon, 11 Apr 2011 16:23:37 +0200 Received: from [192.168.5.106] (dslb-094-219-215-025.pools.arcor-ip.net [94.219.215.25]) by office1.lan.sumadev.de (Postfix) with ESMTPA id 815E65F702; Mon, 11 Apr 2011 16:23:36 +0200 (CEST) From: Gerd Stolpmann To: Simon Josefsson In-Reply-To: <878vvnza9w.fsf_-_@latte.josefsson.org> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf__24773.333388339$1302102086$gmane$org@latte.josefsson.org> <878vvnza9w.fsf_-_@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Apr 2011 16:23:35 +0200 Message-ID: <1302531815.8429.1206.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:+W2gDDKVCs4IOgYM2WomRZqd43Ng2XGErBfUQzMiy2C vpGbug0oXjO6Y8g4hyfpAwoWBpTjyjPW2yRyPnmT9B4LVW6Rp/ Qi262FbCC7yUbhefXsvoG0ziGhs3ibZXAHchULTQ0AGTBvppJ2 J4Vbb58Lra7qxuYcutXRQZOxoRZMzu0e3k4mCJ6aDUvbIpGbVK NpVI4BemBc4r9IUU1tczA== Cc: kitten@ietf.org Subject: Re: [kitten] SCRAM as GSS mech X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 14:24:04 -0000 Am Mittwoch, den 06.04.2011, 17:09 +0200 schrieb Simon Josefsson: > Simon Josefsson writes: > > > This interface and password prompting are the two most important GSS-API > > additions that I'd like to see standardized. > > Password prompting is the main reason I have not implemented SCRAM as a > GSS-API mechanism. Has anyone implemented SCRAM for GSS-API in any way > that makes sense for a reasonable application? If so, how do you handle > password prompts on the client side, and password/verifier storage on > the server side? > > I have considered using a gnupg-agent/pinentry style approach to let the > GSS-API library directly query the user for a password on the client > side without the application knowing, but until I have figured out how > to resolve the same problem on the server side, I don't want to write > the implementation. I've recently implemented SCRAM for GSS-API, but not as a C library, so not the same limitations apply. I did it in Ocaml, and the GSS-API is here an object interface. This opens the additional possibility that one can pass down configurations at object instantiation time. This is of course non-standard, but GSS-API is here not in the role of a system-wide security provider, but merely as a "security plugin helper technology" for client/server applications. Anyway, at GSS-API instantiation time the caller specifies how to get the password (on the client), or how to check the credentials (on the server), just by providing additional callbacks. In some sense, these are examples of context parameters that were recently discussed (PGSSAPI). For the applications I have in mind, the client password would simply come from a config file. The server checks the credentials with an authentication database. Gerd > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------ From nico@cryptonector.com Mon Apr 11 08:08:51 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D853A6889 for ; Mon, 11 Apr 2011 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGUy5F4icjpv for ; Mon, 11 Apr 2011 08:08:50 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 925CD3A68D1 for ; Mon, 11 Apr 2011 08:08:50 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 968E4678063 for ; Mon, 11 Apr 2011 08:08:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nnsDmdM29KriZS9Ajkjc4 k/DQrW8b//G3mDZMVEmcm7G4uK/7OZwAQfCLVHYDACopyOjd0fSKJwPw4RAs6M6Y cvxT83qwL8GcpWI+56WVkb80/GwsGN15awN7Ubrd5cznnK/TypNhnQPWUcrtw9hr eN3nIoCIEXvAj7K6KauiFI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=77H5MnlFx/reqWxV44xl nErcu9w=; b=gNpVufHjDQhzEv4d4NMJJG4EknaFjGAih43rp5rF3N2lo5X7dHAm yYqJ/ZFEyiIak8IxyhEWffgSOfEIRb4KA3bPd99UqQfy/+TtksnsHV7+ibkoiWjk roIojKQGKivPKbW4Vuhu5nR0NGBhRCKr5vumBeH4reRQOojCDcwUoao= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id DBDB3678085 for ; Mon, 11 Apr 2011 08:08:30 -0700 (PDT) Received: by vxg33 with SMTP id 33so5212628vxg.31 for ; Mon, 11 Apr 2011 08:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.188.230 with SMTP id gd6mr2344353vdc.294.1302534509732; Mon, 11 Apr 2011 08:08:29 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 08:08:29 -0700 (PDT) In-Reply-To: <1302531815.8429.1206.camel@thinkpad> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <359CEB20-FE64-45E7-963B-22896B77E8F4@padl.com> <87fwpvzaon.fsf__24773.333388339$1302102086$gmane$org@latte.josefsson.org> <878vvnza9w.fsf_-_@latte.josefsson.org> <1302531815.8429.1206.camel@thinkpad> Date: Mon, 11 Apr 2011 10:08:29 -0500 Message-ID: From: Nico Williams To: Gerd Stolpmann Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] SCRAM as GSS mech X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:08:51 -0000 On Mon, Apr 11, 2011 at 9:23 AM, Gerd Stolpmann wrote: > Anyway, at GSS-API instantiation time the caller specifies how to get > the password (on the client), or how to check the credentials (on the > server), just by providing additional callbacks. In some sense, these > are examples of context parameters that were recently discussed > (PGSSAPI). Indeed. If we had a caller context handle on every call, or an implied one from name import time (the GSS-API really starts and ends with NAMEs), then it'd be trivial to add a function by which to set a callback on the caller context handle and presto: prompting without adding complex variants of gss_acquire_cred(), gss_init_sec_context(), gss_accept_sec_context(), ... Ditto for setting an I/O event loop entry point and callback data. Ditto for lots of things, really. > For the applications I have in mind, the client password would simply > come from a config file. The server checks the credentials with an > authentication database. The simplest thing to do on the client side for now (so that one can ship) is to have an externally primed cache of SCRAM passwords indexed by {[initiator name], acceptor name}. The next simplest thing is to add an out of band interaction facility (i.e., a GUI dialog, when there is an X11 display or what have you). The last thing to do, and the hardest, is to actually extend the GSS-API -- the hardest because we have so many different opinions as to how best to design such extensions :( My recommendation to SCRAM GSS mechanism implementors is to pursue the progression described above, including experimenting with GSS-API extensions. Eventually we'll have enough experience to standardize something. Nico -- From nico@cryptonector.com Mon Apr 11 08:13:29 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B98D3A69FF for ; Mon, 11 Apr 2011 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngngDQXVKJQb for ; Mon, 11 Apr 2011 08:13:28 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id CDD883A697E for ; Mon, 11 Apr 2011 08:13:28 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 49FF821DE59 for ; Mon, 11 Apr 2011 08:13:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=QgU2xqwOLiqoiExznLrqR kv76uUJYwaA+k2W6w4S5KGaK35qckCxCu4TcDMAdcqX39YWN8DUoF5KEyHdbU10C +bQpq1c3PHQkeQjHHeeVflW1KnnOgd6D8eqPdj1yyAqTb0ir7HjtGrs52c8NuyG7 QDxEZqkkEkaJ1uZVxwobdg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=lw0U3Dv0V8ZikSQk9n+Y r88FLog=; b=ACeo7xP+EQysyM66ZOA0hXQ2E2ClOOC/WdUQ0Xw0MUTuLTgQLQ3y vOn2RxQT8+NGfRtOJ95MUMMmLKELCB4fFR3508lB8f3tVdHg7CRg4wD0/CshftfV jAfukaroO4FbRPsYAMi6O71SLZmFRJggMgWLN8zCh6bnSPOeDuqsDP8= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 0DDDB21DE58 for ; Mon, 11 Apr 2011 08:13:28 -0700 (PDT) Received: by vws12 with SMTP id 12so5250898vws.31 for ; Mon, 11 Apr 2011 08:13:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr2264338vdb.174.1302534808375; Mon, 11 Apr 2011 08:13:28 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 08:13:28 -0700 (PDT) In-Reply-To: <8DADE2FF-DE05-4325-99D0-D3CB05811141@padl.com> References: <201104051841.p35IfnaF018157@outgoing.mit.edu> <201104071545.p37Fja2u007767@outgoing.mit.edu> <1302273997.10465.569.camel@t410> <1302319231.10465.585.camel@t410> <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> <8DADE2FF-DE05-4325-99D0-D3CB05811141@padl.com> Date: Mon, 11 Apr 2011 10:13:28 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:13:29 -0000 On Fri, Apr 8, 2011 at 5:54 PM, Luke Howard wrote: > Sorry it's not quite 2lname. > > OM_uint32 > gss_pname_to_uid(OM_uint32 *minor, > const gss_name_t pname, > const gss_OID mech_type, > uid_t *uidp) Ah, yes. Excuse my poor memory (and laziness -- I could have checked OpenSolaris source to refresh my memory). Anyways, we can't use uid_t in a standards-track API. We should do something else, say: OM_uint32 gss_get_localname(OM_uint32 *minor, const gss_name_t pname, gss_buffer_t localname); Or maybe we want to output a non-MN gss_name_t, just like the new userok API will use such a thing as a local name: OM_uint32 gss_get_localname(OM_uint32 *minor, const gss_name_t pname, gss_name_t *localname); Nico -- From wmills@yahoo-inc.com Mon Apr 11 12:14:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0062A3A6AF4 for ; Mon, 11 Apr 2011 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlVoAvWDtAzN for ; Mon, 11 Apr 2011 12:14:33 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by core3.amsl.com (Postfix) with SMTP id 3AD703A6A47 for ; Mon, 11 Apr 2011 12:14:33 -0700 (PDT) Received: (qmail 58930 invoked by uid 60001); 11 Apr 2011 19:14:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302549270; bh=HuSJkGIGgV11j8j/qQshrlj/yyXOhgeCw5+QG8yQnbk=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FHQZkyGi7qpLLS72Vy8xGQJwyaMwY9hczesIhNM2cM5Sig9BpJv7prjFYlb12PDhhBEbqNuVVVB/Lj0jkS9U9Ftm94o/zRZ5hSz2fwiaZo5JiokaJ1h7WKL5Eb6Bf0p53u+CxZ8M/xe/CEh6km0ImEPRvRJEamsLN3Fegw/Dc58= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rL4kk7Pq9vod7YsgrtE8MWGKYb9gibSKmJVQjMatBD//KO3bD+6CDUe1Ds3/4kZ256Uo/Y7ZnVATroXzHJ7PQxgQ9adAczUT2WhN9+0Uv3P4FvuolIVXj8tsvta6AMNYzfXeibrU1wmHnaWzDzsNr4spx3KmDDeLijblxi9bmIw=; Message-ID: <427427.50871.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: Nhvrn7EVM1maiEhVhk0IU666QLrFlH92mM8GOWHD91sFHnN aF.2TZUJGN8WNWv0Pb2jU_sHqCXW2NCf9tO_MhTm4Aj48rLikfu1obgy37Wm c0ruc3bDb7ybBq0mkzVwRTAPaMBjy2DoN.IpDz4WHOnvGGk79K7nLhXy0_Re Iu466nvd1sowo_ZmTcqbtShWvxKiJRJS6MKKLlgKF2CkV.5zZBGWnjC3obPU px5AScRS5UGm9kzfi2KcdWY.NV7dp3BrpczqRuuHwLyHGckSSo6vW31LKp2R UOzYfgEEdD8YM0Eo_oz55xfCLDEfEBaPz80OE_9vEFmobxy2gA04QVoM7mmv eqfMj8_7vM6dLIQFvef_9btQPq2wDpCxgv9AhSZ9hqoAu Received: from [216.145.52.206] by web32314.mail.mud.yahoo.com via HTTP; Mon, 11 Apr 2011 12:14:30 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> <878377.41252.qm@web32303.mail.mud.yahoo.com> <800503.74700.qm@web32303.mail.mud.yahoo.com> Date: Mon, 11 Apr 2011 12:14:30 -0700 (PDT) From: "William J. Mills" To: "kitten@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1940959363-1302549270=:50871" Subject: [kitten] Is a workign session needed? Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 19:14:34 -0000 --0-1940959363-1302549270=:50871 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AIs a working group session needed in Quebec for this spec?=A0 My i= mpression is that this is getting pretty close to wrapping up.=A0 If it is = I'd like to make sure to get my travel all sorted and approved before the l= ast minute.=0A=0AThanks,=0A=0A-bill=0A --0-1940959363-1302549270=:50871 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Is a working group session needed in Quebec for this spec?  My impre= ssion is that this is getting pretty close to wrapping up.  If it is I= 'd like to make sure to get my travel all sorted and approved before the la= st minute.

Thanks,

-bill
--0-1940959363-1302549270=:50871-- From mrex@sap.com Mon Apr 11 16:58:32 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E45D9E06B5 for ; Mon, 11 Apr 2011 16:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEFnSRMcx50n for ; Mon, 11 Apr 2011 16:58:32 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 38F1EE06B0 for ; Mon, 11 Apr 2011 16:58:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3BNwO9r025301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 01:58:24 +0200 (MEST) From: Martin Rex Message-Id: <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> To: lukeh@padl.com (Luke Howard) Date: Tue, 12 Apr 2011 01:58:24 +0200 (MEST) In-Reply-To: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> from "Luke Howard" at Apr 9, 11 01:42:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 23:58:33 -0000 Luke Howard wrote: > > typedef OM_uint32 GSSAPI_CALLCONV _gss_authorize_localname_t ( > OM_uint32 *, /* minor_status */ > const gss_name_t, /* name */ > gss_const_buffer_t, /* user */ > gss_const_OID, /* user_name_type */ > int * /* user_ok */ > ); > > OK, now it looks like: > > OM_uint32 > gss_authorize_localname(OM_uint32 *minor, > const gss_name_t name, > const gss_name_t user); Just an observation: what you're trying to accomplish here is actually within the definition and scope of the combination of the two existing GSS-API calls gss_import_name() + gss_compare_name() http://tools.ietf.org/html/rfc2743#page-70 And for the local account name you could use any one of these generic nametypes: GSS_C_NT_MACHINE_UID_NAME or GSS_C_NT_STRING_UID_NAME GSS_C_NT_USER_NAME The former might result in a "more local" resolution than the latter. -Martin From nico@cryptonector.com Mon Apr 11 17:20:34 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D4D07E0705 for ; Mon, 11 Apr 2011 17:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf+QQOjFDyeS for ; Mon, 11 Apr 2011 17:20:34 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfc.amsl.com (Postfix) with ESMTP id 3233FE06EC for ; Mon, 11 Apr 2011 17:20:33 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id E82E0428078 for ; Mon, 11 Apr 2011 17:20:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mtV4Bwh5VARpedLEOkuQdMWC18KVfEKLja8g43zXJ/CN UlJ9nGwyoUp/DiTkdWcQzCnUqcN9VQhQhd8bLfPPNQ+F4NqDKgimRQ2n6uaQ6hcz 4B7x8swNsK/mdNCNeBezmyfuU2UudHP8ENiOC/+hM3lnVyecdDF6V4r742c6rY0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=14cXWM8oSTPobkFlP+2ikAJzoWg=; b=m6EAcUj+Rcc gaij91fVm9UkN5w9z0pC83Wzf75ochQKL9AOHQoNuZTl+GxEPYTNUdmbxmp79xmz Ircy4lQMZOb12WnxiVeI6u6LzHxrVFXe6sypuDlgf1g6WhdFmXMmyMWah8j3Abpi koFKlZnlZttJKgbyB+2s/nwgrJpu9Gzk= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id B5AFF42806E for ; Mon, 11 Apr 2011 17:20:30 -0700 (PDT) Received: by vws12 with SMTP id 12so5784480vws.31 for ; Mon, 11 Apr 2011 17:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr2993820vdb.174.1302567630149; Mon, 11 Apr 2011 17:20:30 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 17:20:30 -0700 (PDT) In-Reply-To: <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> References: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> Date: Mon, 11 Apr 2011 19:20:30 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:20:35 -0000 On Mon, Apr 11, 2011 at 6:58 PM, Martin Rex wrote: > Luke Howard wrote: >> OM_uint32 >> gss_authorize_localname(OM_uint32 *minor, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 const gss_name_t name, >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 const gss_name_t user); > > Just an observation: what you're trying to accomplish here is actually > within the definition and scope of the combination of the two > existing GSS-API calls > > gss_import_name() + gss_compare_name() Martin, Yes, we could all just implement the kind of logic that krb5_kuserok() implements (roughly: scan a file associated with the given username looking for a match for the given principal name) using the GSS-API and at the application layer -- nothing new is needed. And yet, that would be a lot of duplication. Yes, gss_authorize_localname() is a pure utility function, but a very, very useful one. And it's useful to have the mechglue implement it. And it's useful even for the mechglue to dispatch it to the mechanisms for which 'name' is an MN. Iit's useful to be able to have many apps share the same implementation of this function, and to be able to change the implementation at run-time (by changing system configuration, for example). And, as you know, some utility functions really belong in libraries. This is one of those. There are others in the GSS-API too, so it's not like we're setting some sort of awful precedent. Cheers, Nico -- From mrex@sap.com Mon Apr 11 17:33:27 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 03C51E06A0 for ; Mon, 11 Apr 2011 17:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.118 X-Spam-Level: X-Spam-Status: No, score=-10.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOiqIgLGRxsC for ; Mon, 11 Apr 2011 17:33:26 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id AA861E06BC for ; Mon, 11 Apr 2011 17:33:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3C0X96V029088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 02:33:09 +0200 (MEST) From: Martin Rex Message-Id: <201104120033.p3C0X8Vj022241@fs4113.wdf.sap.corp> To: wmills@yahoo-inc.com Date: Tue, 12 Apr 2011 02:33:08 +0200 (MEST) In-Reply-To: <800503.74700.qm@web32303.mail.mud.yahoo.com> from "William J. Mills" at Apr 9, 11 04:13:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] CB data characteristics Re: Fw: New Version X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:33:27 -0000 > > Well perhaps I'll get just fancy enough to say if the CB source data is > than 500 bytes then SHA-1 hash and pass the hash. > > I'm stuffing this in an HTML query parameter, and I don't want to > end up with problems in client or servers that assume maximum lengths. The tls-unique channel bindings is usually relatively small. It is 12 octets by default for TLSv1.0/TLSv1.1/TLSv1.2 and it is 36 octets for SSLv3. So hashing the tls-unique channel bindings with SHA-1 will expand the size for TLSv1.x. AND tls-unique is pure binary and looks like random noise -- so if you want to transfer it within URLs, you will need to base64 encode it. -Martin From wmills@yahoo-inc.com Mon Apr 11 17:39:11 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F01D7E067F for ; Mon, 11 Apr 2011 17:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyKPHjAGJJXG for ; Mon, 11 Apr 2011 17:39:11 -0700 (PDT) Received: from web32314.mail.mud.yahoo.com (web32314.mail.mud.yahoo.com [68.142.207.162]) by ietfc.amsl.com (Postfix) with SMTP id A7207E0613 for ; Mon, 11 Apr 2011 17:39:10 -0700 (PDT) Received: (qmail 87862 invoked by uid 60001); 12 Apr 2011 00:39:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1302568745; bh=xi0KaYXzky48fYZwTsZiUPLGkQH6FNF1D7Cd5VXGMYo=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Y35ZPbYUsKNEuecIRqLJPLnN8PCddUETdXHysORNnkffVnTR3ciHclU7omNLe8UiaX2vZVtS7MVVXY2crye1y2rKdUGS1M164hKXCJjVvcltVuXlU3SD/HtAbeER/pb+7l0GtMQKYB38dt4+JXLTwW/VZ6wKzBMsGbJoW38tVyk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KH7sKSU40Tijn1EoyuQCclzJl7RXcpx+Oql8/bsT2Lkz7BtH6baBur67nVS+enbdvuKsAXItUe++qQH1+S5tITyf+RniwO7vgg0184mzpPj5s5Y6waiXIrUmzxWC41UXRmFtQjRl3oCvJakaGrzmZsW6ZEvqEFHSDKncBcXHn5Q=; Message-ID: <540180.77441.qm@web32314.mail.mud.yahoo.com> X-YMail-OSG: .j7Brh0VM1lXjREWAWqgEM0KgeN1keBxQrWaRUHwy3tmlVS v08PIIVo2vgn9RNLwUuW_xKFW00skYr.nVLR0erSiN2z_hEaBXZW7B2EjlKy jgE0MCFwmCdjhpXyp.eZPK8PS14oBe3IGEqry_CR98eZCRhvz6ydkbjJN8b9 8uZ_znhlLTe.hIs1CurxKyPvR3EPSC2H1ofDmzwfTKcW_n_nPXm5DJJJwUM5 SiYoVVeXnjfNpsmWD8Pdd0qApoChm4V6XOcMxRbmWxvD_LMDUcdk8NHlTdN5 Zo.fCAGYipylzXl.oq_lqFMNKlBTEjLT5MT__edvuK4yf1kkMLJ.dC_JN.g8 hnCK7OJcpAALl5.H8s63YV6pKNo552MNyFcj0Xvw- Received: from [216.145.52.206] by web32314.mail.mud.yahoo.com via HTTP; Mon, 11 Apr 2011 17:39:05 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.110.299900 References: <800503.74700.qm@web32303.mail.mud.yahoo.com> from "William J. Mills" at Apr 9, 11 04:13:54 pm <201104120033.p3C0X8Vj022241@fs4113.wdf.sap.corp> Date: Mon, 11 Apr 2011 17:39:05 -0700 (PDT) From: "William J. Mills" To: "mrex@sap.com" In-Reply-To: <201104120033.p3C0X8Vj022241@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-253914946-1302568745=:77441" Cc: "kitten@ietf.org" Subject: Re: [kitten] CB data characteristics Re: Fw: New Version X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "William J. Mills" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:39:12 -0000 --0-253914946-1302568745=:77441 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable That agrees with what I've heard and read so far.=A0 The text I have at the= moment is:=0A=0A=A0 The channel binding data is computed by the client bas= ed on it's choice of=0A=A0 preferred channel binding type.=A0=A0 As specifi= ed in the=0A=A0 channel binding information must= start with the channel binding unique prefix followed=0A=A0 by a colon (AS= CII 0x3A), this is followed by base64 encoded channel binding=0A=A0 payload= .=A0 The channel binding payload is the raw data from the channel binding= =0A=A0 type if the raw channel binding data is less than 500 bytes, if 500 = bytes or=0A=A0 larger the channel binding payload is a SHA-1 hash of=0A=A0 the raw channel binding data. =0A=0A=0AI dod n= ot know the tls-unique sizes though.=A0 Makes sense that they look random, = they are cryptographically generated, if they did not look random there wou= ld be a big problem.=0A=0A=0AThanks!=0A=0A-bill=0A=0A=0A=0A________________= ________________=0AFrom: Martin Rex =0ATo: wmills@yahoo-inc.c= om=0ACc: nico@cryptonector.com; kitten@ietf.org=0ASent: Monday, April 11, 2= 011 5:33 PM=0ASubject: Re: [kitten] CB data characteristics Re: Fw: New Ver= sion=0A=0A> =0A> Well perhaps I'll get just fancy enough to say if the CB s= ource data is=0A> than 500 bytes then SHA-1 hash and pass the hash. =0A>=0A= > I'm stuffing this in an HTML query parameter, and I don't want to=0A> end= up with problems in client or servers that assume maximum lengths.=0A=0ATh= e tls-unique channel bindings is usually relatively small.=0AIt is 12 octet= s by default for TLSv1.0/TLSv1.1/TLSv1.2 =0Aand it is 36 octets for SSLv3. = So hashing the tls-unique channel=0Abindings with SHA-1 will expand the siz= e for TLSv1.x.=0A=0AAND tls-unique is pure binary and looks like random noi= se=0A-- so if you want to transfer it within URLs, you will need to=0Abase6= 4 encode it.=0A=0A-Martin --0-253914946-1302568745=:77441 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
That agrees with what I've heard and read so far.  The text I have a= t the moment is:

  = The channel binding data is computed by the client based on it's choice of<= br>  preferred channel binding type.   As specified in <x= ref target=3D"RFC5056"/> the
  channel binding information must = start with the channel binding unique prefix followed
  by a colon = (ASCII 0x3A), this is followed by base64 encoded channel binding
  = payload.  The channel binding payload is the raw data from the channel= binding
  type if the raw channel binding data is less than 500 by= tes, if 500 bytes or
  larger the channel binding payload is a SHA-= 1 <xref target=3D"RFC3174"/> hash of
  the raw channel binding data.

I dod not know the tls-= unique sizes though.  Makes sense that they look random, they are cryp= tographically generated, if they did not look random there would be a big p= roblem.

Thanks!

-bill=

From:<= /b> Martin Rex <mrex@sap.com>
Cc: nico@cryptonector.com; kitten@ietf.org
Sent: Monday, April 11, 2011 5:33 PM
= Subject: Re: [kitten] CB d= ata characteristics Re: Fw: New Version

=0A>
> Well pe= rhaps I'll get just fancy enough to say if the CB source data is
> th= an 500 bytes then SHA-1 hash and pass the hash.
>
> I'm stuffi= ng this in an HTML query parameter, and I don't want to
> end up with= problems in client or servers that assume maximum lengths.

The tls-= unique channel bindings is usually relatively small.
It is 12 octets by = default for TLSv1.0/TLSv1.1/TLSv1.2
and it is 36 octets for SSLv3. So h= ashing the tls-unique channel
bindings with SHA-1 will expand the size f= or TLSv1.x.

AND tls-unique is pure binary and looks like random nois= e
-- so if you want to transfer it within URLs, you will need to
base= 64 encode it.

-Martin


--0-253914946-1302568745=:77441-- From mrex@sap.com Mon Apr 11 17:59:21 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 26135E0688 for ; Mon, 11 Apr 2011 17:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.021 X-Spam-Level: X-Spam-Status: No, score=-10.021 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XlcWUtjtDhQ for ; Mon, 11 Apr 2011 17:59:19 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 9B332E0613 for ; Mon, 11 Apr 2011 17:58:53 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3C0wl73002056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 02:58:47 +0200 (MEST) From: Martin Rex Message-Id: <201104120058.p3C0wkii023769@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Tue, 12 Apr 2011 02:58:46 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 11, 11 07:20:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:59:21 -0000 Nico Williams wrote: > > On Mon, Apr 11, 2011 at 6:58 PM, Martin Rex wrote: > > Luke Howard wrote: > >> OM_uint32 > >> gss_authorize_localname(OM_uint32 *minor, > >>                         const gss_name_t name, > >>                         const gss_name_t user); > > > > Just an observation: what you're trying to accomplish here is actually > > within the definition and scope of the combination of the two > > existing GSS-API calls > > > > gss_import_name() + gss_compare_name() > > Yes, we could all just implement the kind of logic that krb5_kuserok() > implements (roughly: scan a file associated with the given username > looking for a match for the given principal name) using the GSS-API > and at the application layer -- nothing new is needed. > > And yet, that would be a lot of duplication. Yes, > gss_authorize_localname() is a pure utility function, but a very, very > useful one. And it's useful to have the mechglue implement it. And > it's useful even for the mechglue to dispatch it to the mechanisms for > which 'name' is an MN. Iit's useful to be able to have many apps > share the same implementation of this function, and to be able to > change the implementation at run-time (by changing system > configuration, for example). > > And, as you know, some utility functions really belong in libraries. > This is one of those. There are others in the GSS-API too, so it's > not like we're setting some sort of awful precedent. It was not and is not my intent to keep you from standardizing this function. And I previously indicated that I do not consider the function to be "fully generic", so I'm fine with a new function with clearly defined semantics for the purpose that you're envisioning. However, I believe it is appropriate to document the limited applicability of such a function to specific usage scenarios, and it's likely dependence of a close integration of the gssapi mechanism with the underlying OS. As far as Kerberos 5 is concerned: is the Microsoft Kerberos implementation and platform, which seems to clearly distinguish "network login" from "interactive login", completely out-of-scope? -Martin From nico@cryptonector.com Mon Apr 11 19:02:43 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D9C1DE066E for ; Mon, 11 Apr 2011 19:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGQGpzyIGICY for ; Mon, 11 Apr 2011 19:02:43 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfc.amsl.com (Postfix) with ESMTP id 3F067E0672 for ; Mon, 11 Apr 2011 19:02:43 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 48A421F0081 for ; Mon, 11 Apr 2011 19:02:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=oa2dNlSnAkr6or1LAnqFQ 8YL1K2C6IzDleylkUwv1UiwQTj6OF4e+vdd7hbcBrLbHdXngrxD6NPP2XTpBhBIV HKuW6U/RFB3EgYy3A22hqW+gRHwTN4c/u74GPSMzIeR49nTvvbkIeg6dhFZK45IO MzXOlvikToEd3wTdNoqJIs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yHZL+wsnd3lVCbbwFU27 Tfi1r8Q=; b=MRsq3jY09yqFK+W9g4wLWS8BMTWOfskWGn43HXTrvWQQeg/dybag FzOx7nyxdd2W7z1BTr/zZ+g6P3DzsokSZlQ4B/rkIvXtOE43gYMPmjdFBYPiSkgj i0EiWAFEhCNSLaPUnPNHJTMikCLnB2PhNjyctYr60O3MnsHGPae5KzM= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id E48F51F007C for ; Mon, 11 Apr 2011 19:02:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so5601428vxg.31 for ; Mon, 11 Apr 2011 19:02:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.92.38 with SMTP id cj6mr1184394vdb.254.1302573761304; Mon, 11 Apr 2011 19:02:41 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 19:02:41 -0700 (PDT) Received: by 10.52.166.42 with HTTP; Mon, 11 Apr 2011 19:02:41 -0700 (PDT) In-Reply-To: <201104120058.p3C0wkii023769@fs4113.wdf.sap.corp> References: <201104120058.p3C0wkii023769@fs4113.wdf.sap.corp> Date: Mon, 11 Apr 2011 21:02:41 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: multipart/alternative; boundary=bcaec50162c556199b04a0af16d2 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 02:02:44 -0000 --bcaec50162c556199b04a0af16d2 Content-Type: text/plain; charset=UTF-8 I'd be OK with adding a flag to distinguish between interactive and non-interactive logins. And a gss_name_t for the service performing the login. And... well, we have to draw a line somewhere. Here's the thing: I don't see a real security distinction to be made here, or, if this distinction matters, then.so do many others (remote vs. local, service type -difficult to ascertain in the case of SSHv2-, and many things for which we have no GSS analogs). I'm for the KISS principle. We can always add another function. But if others want this... Nico -- --bcaec50162c556199b04a0af16d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd be OK with adding a flag to distinguish between interactive and = non-interactive logins.=C2=A0 And a gss_name_t for the service performing t= he login.=C2=A0 And...=C2=A0 well, we have to draw a line somewhere.=C2=A0 = Here's the thing: I don't see a real security distinction to be mad= e here, or, if this distinction matters, then.so do many others (remote vs.= local, service type -difficult to ascertain in the case of SSHv2-, and man= y things for which we have no GSS analogs).

I'm for the KISS principle.=C2=A0 We can always add another function= .=C2=A0 But if others want this...

Nico
--

--bcaec50162c556199b04a0af16d2-- From shawn.emery@oracle.com Tue Apr 12 15:25:04 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9868AE085E for ; Tue, 12 Apr 2011 15:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVTPxdeE5iXC for ; Tue, 12 Apr 2011 15:25:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfc.amsl.com (Postfix) with ESMTP id E35C0E07BE for ; Tue, 12 Apr 2011 15:25:03 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3CMP1gX009881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Apr 2011 22:25:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p3CMP0SM010541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Apr 2011 22:25:00 GMT Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3CMNxVS030305 for ; Tue, 12 Apr 2011 17:24:00 -0500 Received: from [129.148.19.121] (/129.148.19.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Apr 2011 15:23:59 -0700 Message-ID: <4DA4D0FE.306@oracle.com> Date: Tue, 12 Apr 2011 16:23:58 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------030906000601090608090300" X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4DA4D13C.00D3:SCFSTAT5015188,ss=1,fgs=0 Subject: [kitten] WG Adoptions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 22:25:04 -0000 This is a multi-part message in MIME format. --------------030906000601090608090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As discussed during the kitten WG sessions in Prague, the chairs are starting a WG consensus call on adopting the following drafts: SASL-SAML-EC http://tools.ietf.org/html/draft-cantor-ietf-kitten-saml-ec SASL-OAuth: http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth In order to prevent clutter on the list, please reply to me directly on whether you are in favor or not in adopting the above individual submissions as WG work items. This call expires on 4/26/11. Shawn. kitten co-chair -- --------------030906000601090608090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As discussed during the kitten WG sessions in Prague, the chairs are starting a WG consensus call on adopting the following drafts:

SASL-SAML-EC
http://tools.ietf.org/html/draft-cantor-ietf-kitten-saml-ec

SASL-OAuth:
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth

In order to prevent clutter on the list, please reply to me directly on whether you are in favor or not in adopting the above individual submissions as WG work items.

This call expires on 4/26/11.

Shawn.
kitten co-chair
--
 --------------030906000601090608090300-- From shawn.emery@oracle.com Tue Apr 12 15:29:07 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94D8DE0883 for ; Tue, 12 Apr 2011 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksaccWRE-a-i for ; Tue, 12 Apr 2011 15:29:07 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfc.amsl.com (Postfix) with ESMTP id DE7F8E07BE for ; Tue, 12 Apr 2011 15:29:06 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3CMT4Mj016736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Apr 2011 22:29:06 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p3CMT4Pv020138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 22:29:04 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3CMT4HP013950; Tue, 12 Apr 2011 17:29:04 -0500 Received: from [129.148.19.121] (/129.148.19.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Apr 2011 15:29:03 -0700 Message-ID: <4DA4D22E.6030001@oracle.com> Date: Tue, 12 Apr 2011 16:29:02 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "William J. Mills" References: <20110408070506.12ECB3A6A4C@core3.amsl.com> <416848.75882.qm__16525.0710481361$1302247955$gmane$org@web32314.mail.mud.yahoo.com> <87hba9b13i.fsf@latte.josefsson.org> <754979.46407.qm@web32303.mail.mud.yahoo.com> <7EE86E89365CA94F8E7B8251F926071007AC12BC@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AC141F@CIO-KRC-D1MBX01.osuad.osu.edu> <991228.73942.qm@web32303.mail.mud.yahoo.com> <277844.39554.qm@web32314.mail.mud.yahoo.com> <878377.41252.qm@web32303.mail.mud.yahoo.com> <800503.74700.qm@web32303.mail.mud.yahoo.com> <427427.50871.qm@web32314.mail.mud.yahoo.com> In-Reply-To: <427427.50871.qm@web32314.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------050303040102000907090005" X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4DA4D230.00DF:SCFSTAT5015188,ss=1,fgs=0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Is a workign session needed? Re: Fw: New Version Notification for draft-mills-kitten-sasl-oauth-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 22:29:07 -0000 This is a multi-part message in MIME format. --------------050303040102000907090005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/11/11 01:14 PM, William J. Mills wrote: > Hi, > > Is a working group session needed in Quebec for this spec? My > impression is that this is getting pretty close to wrapping up. If it > is I'd like to make sure to get my travel all sorted and approved > before the last minute. Thank you for working with the group on this draft. As a result, I don't foresee any controversy if the WG adopts this draft. Even if there is we could always set up a WebEx or Skype session during the conference. Shawn. kitten co-chair -- --------------050303040102000907090005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/11/11 01:14 PM, William J. Mills wrote:
Hi,

Is a working group session needed in Quebec for this spec?  My impression is that this is getting pretty close to wrapping up.  If it is I'd like to make sure to get my travel all sorted and approved before the last minute.

Thank you for working with the group on this draft.  As a result, I don't foresee any controversy if the WG adopts this draft.  Even if there is we could always set up a WebEx or Skype session during the conference.

Shawn.
kitten co-chair
--
--------------050303040102000907090005-- From lukeh@padl.com Wed Apr 13 03:39:20 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A317CE06C1 for ; Wed, 13 Apr 2011 03:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEr9xNnN+TKJ for ; Wed, 13 Apr 2011 03:39:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfc.amsl.com (Postfix) with ESMTP id CB89FE0678 for ; Wed, 13 Apr 2011 03:39:19 -0700 (PDT) Received: by us.padl.com with ESMTP id p3DAar3O009296; Wed, 13 Apr 2011 06:39:54 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Wed, 13 Apr 2011 12:37:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CAE7887-3515-42D8-9021-AD3B4F18D07B@padl.com> References: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.9 Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 10:39:20 -0000 > Yes, we could all just implement the kind of logic that krb5_kuserok() > implements (roughly: scan a file associated with the given username > looking for a match for the given principal name) using the GSS-API > and at the application layer -- nothing new is needed. Well, if I understand Martin correctly, we could also implement it at = the GSS layer using gss_compare_name() and a name type that implied the = mapping performed by krb5_kuserok(). -- Luke= From ghudson@mit.edu Wed Apr 13 07:47:53 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DCE0E0796 for ; Wed, 13 Apr 2011 07:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NInZvZ7c-w5c for ; Wed, 13 Apr 2011 07:47:52 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by ietfc.amsl.com (Postfix) with ESMTP id 68E75E0793 for ; Wed, 13 Apr 2011 07:47:52 -0700 (PDT) X-AuditID: 1209190f-b7cf3ae0000046b8-af-4da5b794d758 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7C.15.18104.497B5AD4; Wed, 13 Apr 2011 10:47:49 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p3DElpJL022050; Wed, 13 Apr 2011 10:47:51 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p3DElWML005740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Apr 2011 10:47:50 -0400 (EDT) From: Greg Hudson To: Luke Howard In-Reply-To: <6CAE7887-3515-42D8-9021-AD3B4F18D07B@padl.com> References: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> <6CAE7887-3515-42D8-9021-AD3B4F18D07B@padl.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 13 Apr 2011 10:47:31 -0400 Message-ID: <1302706051.10465.673.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42IR4hRV1p26famvQcNtZoujm1exWNy99J/d gcljyZKfTB5zP0xjCWCK4rJJSc3JLEst0rdL4MrYsH8lY8FdoYo1uy8xNjCu5O9i5OSQEDCR eNffxw5hi0lcuLeerYuRi0NIYB+jxKt5s9ghnA2MEi3XVjJBOPeYJE6umsYK0iIsoCDxfdZ2 RhCbTUBZ4uDZbywgtghQfPL+tcwgNrOAusTR501sIDangI3Ey641zBCDbjNKTLy9gQWiSFOi dftvsDtYBFQlFt1dCzSUg4NXQFdierMQhCko8XeHMMSl0hJfJzxhguiUl9j+dg7zBEbBWUgG zULomIWkagEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzg8JXk38H47aDS IUYBDkYlHt5335f4CrEmlhVX5h5ilORgUhLl3bxtqa8QX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed4TVUDlvCmJlVWpRfkwKWkOFiVx3lmS6r5CAumJJanZqakFqUUwWRkODiUJ3hRgnAoJFqWm p1akZeaUIKSZODhBhvMADZcFqeEtLkjMLc5Mh8ifYjTm2NO/fx8jx/8th/YxCrHk5eelSonz eoKUCoCUZpTmwU2DpaBXjOJAzwnz6oBU8QDTF9y8V0CrmIBWvT4L8kdxSSJCSqqBUc7X75cM J8/29xW3rApSXIvOP6ztqv8ZvF1kq/7bpWFZ/72nP7UV89lVL/Dpw+GKB+HO32y4mU2Zdh5X fGfm+/lBVbjAwqqtx0x/3PH8Ul3osLg3esJR0weV4k9Ph/Pkaup6lAbwZJ41DLi1cd2apOCT Ggq3Avv+fA0//0iwv+7MkmM5vRdNlFiKMxINtZiLihMB5QwzdRwDAAA= Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:47:53 -0000 On Wed, 2011-04-13 at 06:37 -0400, Luke Howard wrote: > Well, if I understand Martin correctly, we could also implement it at > the GSS layer using gss_compare_name() and a name type that implied > the mapping performed by krb5_kuserok(). I considered that interpretation too, but it seems like a bit of a stretch. If ghudson@ATHENA.MIT.EDU is listed in /home/buildbot/.k5login on a machine, does that mean that the MN ghudson@ATHENA.MIT.EDU and the internal name GSS_C_NT_USERNAME/buildbot "refer to the same entity" (RFC 2743 2.4.3)? The first is authorized to perform arbitrary actions as the second, but the reverse is not necessarily true. Martin wrote: > As far as Kerberos 5 is concerned: is the Microsoft Kerberos implementation > and platform, which seems to clearly distinguish "network login" from > "interactive login", completely out-of-scope? The simple answer is that, from my perspective, a remote/local distinction is out of scope at this time, and I don't know what impact that would have on someone trying to implement this for Microsoft Kerberos. The immediate use case is to make sshd more useful for GSS-EAP without adding mechanism-specific logic to sshd (and in fact, taking the krb5 mechanism-specific logic out). The people involved have a strong understanding of the mechanism-specific login authorization policies used on Unix login agents, but not necessarily for Windows. Should this extension become a standard, the issue would definitely bear further study. For instance, does the MS Kerberos policy decompose into something like (MN X lname) -> is-authorized and (lname X is-remote) -> is-authorized? Is it possible to guess with confidence whether a login is remote/local based on global process state, as it is on Unix using the tty name? Does it make sense to use GSSAPI acceptor logic in a Windows protocol implementation interfacing with system accounts, and if so, does it only make sense for remote access, or for local access as well? If the remote/local distinction does turn out to be in scope, would it be best represented as a flag parameter to gss_authorize_name, or an attribute on the MN or local name? I'm not qualified the answer these questions at the moment, and I'd rather bear the cost of possibly choosing a new function name later than of adding possibly misguided complexity now. From nico@cryptonector.com Wed Apr 13 08:35:03 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 06589E075C for ; Wed, 13 Apr 2011 08:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+ogMtOyFoWL for ; Wed, 13 Apr 2011 08:35:02 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfc.amsl.com (Postfix) with ESMTP id CCDC9E06BB for ; Wed, 13 Apr 2011 08:35:01 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id CEF5367C074 for ; Wed, 13 Apr 2011 08:35:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=EAlAZGPBFQ5Qgnb9VEdY4Q26VKUk2XU104+L4j9r4xv5 sukZRC8Dbw3PfJPAkd0GfnDiVTdlFlbJRxfdrQKmd5U3l9emy3OWhqCVy1dYLet2 75V1qCQ9yzStaepOB4e/c9S8zaEyWwbSGnLR1qWdXjKN8qysR+Zq2B4+U4t4imc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=oW5PIyo6MEd75U16qPxxKJml7Kw=; b=ZsT3XZVNNL/ p1p0svN8H3JDTIKQVZ9aHjYCb+VY1nwd0y/BbZ2Y5gC8rF6aHHznufbSgvryMweJ Io3s+XFyjsFEQoxTw0/trR37K9bikF9nk27NxEn5zB3gK9cuBB+zYgQV7N/Agr4h a7YbMfCczg6xPkxBTWySMSvSfjHH8LIo= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id AC31567C073 for ; Wed, 13 Apr 2011 08:35:00 -0700 (PDT) Received: by vxg33 with SMTP id 33so677627vxg.31 for ; Wed, 13 Apr 2011 08:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.130 with SMTP id l2mr50443vdv.14.1302708900112; Wed, 13 Apr 2011 08:35:00 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Wed, 13 Apr 2011 08:34:59 -0700 (PDT) In-Reply-To: <1302706051.10465.673.camel@t410> References: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> <6CAE7887-3515-42D8-9021-AD3B4F18D07B@padl.com> <1302706051.10465.673.camel@t410> Date: Wed, 13 Apr 2011 10:34:59 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:35:03 -0000 On Wed, Apr 13, 2011 at 9:47 AM, Greg Hudson wrote: > On Wed, 2011-04-13 at 06:37 -0400, Luke Howard wrote: >> Well, if I understand Martin correctly, we could also implement it at >> the GSS layer using gss_compare_name() and a name type that implied >> the mapping performed by krb5_kuserok(). > > I considered that interpretation too, but it seems like a bit of a > stretch. =C2=A0If ghudson@ATHENA.MIT.EDU is listed in /home/buildbot/.k5l= ogin > on a machine, does that mean that the MN ghudson@ATHENA.MIT.EDU and the > internal name GSS_C_NT_USERNAME/buildbot "refer to the same entity" (RFC > 2743 2.4.3)? =C2=A0The first is authorized to perform arbitrary actions a= s > the second, but the reverse is not necessarily true. I thought that Martin meant that the application ought to implement what krb5_kuserok() does using GSS' naming functions -- as opposed to us specifying this function. That's the only interpretation of Martin's comment that made any sense. But I want a portable API because I don't want apps to duplicate this code, and I want the algorithm to be able to change at runtime. > Martin wrote: >> As far as Kerberos 5 is concerned: is the Microsoft Kerberos implementat= ion >> and platform, which seems to clearly distinguish "network login" from >> "interactive login", completely out-of-scope? > > The simple answer is that, from my perspective, a remote/local > distinction is out of scope at this time, and I don't know what impact > that would have on someone trying to implement this for Microsoft > Kerberos. It wouldn't be hard. My problem is where do we stop? I want to stop here. It costs little to add new functions. Well, _this_ thread is so long that the cost is not as low as I'd like it to be, but it's still much lower than the cost of trying to figure out the Ultimate API (tm) right now. It would be nice if we could lower the cost of each addition somewhat more without completely sacrificing review -we did get useful review here, so this thread is not as bad as I just made it sound-, but hey, c'est la vie. The IANA registry will help! (Right, I gotta get on that.) I think it's fair enough to say that we have consensus on the specific function prototype(s) and to move forward. All we need is an I-D and a track to aim for. Informational will do, yes? Proposed Standard would be nice, but de facto will do for me. Nico -- From mrex@sap.com Wed Apr 13 08:42:51 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 36E8EE06C5 for ; Wed, 13 Apr 2011 08:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id flBtt8oFUos4 for ; Wed, 13 Apr 2011 08:42:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 72144E0690 for ; Wed, 13 Apr 2011 08:42:50 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3DFgjYt026516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 17:42:45 +0200 (MEST) From: Martin Rex Message-Id: <201104131542.p3DFgjjT005813@fs4113.wdf.sap.corp> To: lukeh@padl.com (Luke Howard) Date: Wed, 13 Apr 2011 17:42:44 +0200 (MEST) In-Reply-To: <6CAE7887-3515-42D8-9021-AD3B4F18D07B@padl.com> from "Luke Howard" at Apr 13, 11 12:37:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:42:51 -0000 Luke Howard wrote: > > > > Yes, we could all just implement the kind of logic that krb5_kuserok() > > implements (roughly: scan a file associated with the given username > > looking for a match for the given principal name) using the GSS-API > > and at the application layer -- nothing new is needed. > > Well, if I understand Martin correctly, we could also implement it at > the GSS layer using gss_compare_name() and a name type that implied > the mapping performed by krb5_kuserok(). I did _not_ mean to suggest that you should use the existing calls. I actually wrote in a followup: = = It was not and is not my intent to keep you from standardizing = this function. And I previously indicated that I do not consider = the function to be "fully generic", so I'm fine with a new function with = clearly defined semantics for the purpose that you're envisioning. I just made an observation that there could already be implementations of gss-api mechanisms doing what you want to do with gss_import_name() + gss_compare_name(), and, while not being obvious, it would be perfectly within the defined semantics of these functions. -Martin From mrex@sap.com Wed Apr 13 08:53:32 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id ADA44E0803 for ; Wed, 13 Apr 2011 08:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.983 X-Spam-Level: X-Spam-Status: No, score=-9.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n88E92+-zv6z for ; Wed, 13 Apr 2011 08:53:32 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id DC1C5E07FD for ; Wed, 13 Apr 2011 08:53:31 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3DFrUwW027576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2011 17:53:30 +0200 (MEST) From: Martin Rex Message-Id: <201104131553.p3DFrTx0006197@fs4113.wdf.sap.corp> To: ghudson@MIT.EDU (Greg Hudson) Date: Wed, 13 Apr 2011 17:53:29 +0200 (MEST) In-Reply-To: <1302706051.10465.673.camel@t410> from "Greg Hudson" at Apr 13, 11 10:47:31 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 15:53:32 -0000 Greg Hudson wrote: > > On Wed, 2011-04-13 at 06:37 -0400, Luke Howard wrote: > > Well, if I understand Martin correctly, we could also implement it at > > the GSS layer using gss_compare_name() and a name type that implied > > the mapping performed by krb5_kuserok(). > > I considered that interpretation too, but it seems like a bit of a > stretch. If ghudson@ATHENA.MIT.EDU is listed in /home/buildbot/.k5login > on a machine, does that mean that the MN ghudson@ATHENA.MIT.EDU and the > internal name GSS_C_NT_USERNAME/buildbot "refer to the same entity" (RFC > 2743 2.4.3)? The first is authorized to perform arbitrary actions as > the second, but the reverse is not necessarily true. But now you're describing a behaviour that is completely different from the previous discussion (I have no idea what krb5_kuserok() does). What you're describing looks extremely app-specific, and not a result of a tight integration of a gssapi mechanism with the underlying OS. > > Martin wrote: > > As far as Kerberos 5 is concerned: is the Microsoft Kerberos implementation > > and platform, which seems to clearly distinguish "network login" from > > "interactive login", completely out-of-scope? > > The simple answer is that, from my perspective, a remote/local > distinction is out of scope at this time, and I don't know what impact > that would have on someone trying to implement this for Microsoft > Kerberos. While I can perfectly understand anyone's reluctance to describe behaviour for environments and platforms one is not familiar with, the Microsoft Windows platform is probably the largest installed base of an implementation of Kerberos 5 and it might really be interesting to e.g. the Cygwin32 folks how to implement gss_userok() for this environment. Could we get some comments/thoughts from Larry Zhu on this? -Martin From ghudson@mit.edu Wed Apr 13 09:45:02 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EECCCE0809 for ; Wed, 13 Apr 2011 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBk2iEzVYyHF for ; Wed, 13 Apr 2011 09:45:02 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfc.amsl.com (Postfix) with ESMTP id 0832BE07EB for ; Wed, 13 Apr 2011 09:45:01 -0700 (PDT) X-AuditID: 1209190d-b7c48ae000004826-dd-4da5d304b14b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id A5.55.18470.403D5AD4; Wed, 13 Apr 2011 12:44:52 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p3DGj00E019085; Wed, 13 Apr 2011 12:45:00 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p3DGiv2U006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Apr 2011 12:44:59 -0400 (EDT) From: Greg Hudson To: "mrex@sap.com" In-Reply-To: <201104131553.p3DFrTx0006197@fs4113.wdf.sap.corp> References: <201104131553.p3DFrTx0006197@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Wed, 13 Apr 2011 12:44:57 -0400 Message-ID: <1302713097.10465.735.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42IRYrdT12W5vNTX4PozcYujm1exWPT+3sHs wOSxZMlPJo8pn7cyBjBFcdmkpOZklqUW6dslcGU0dl5lL9ghWvGnvYG9gfGQYBcjJ4eEgInE xt+v2CBsMYkL99YD2VwcQgL7GCWmL94K5WxglLh+6SwThHOPSeLe+S/MIC3CAgoS32dtZwSx 2QSUJQ6e/cYCYosIKErcap/GDmIzC6hLHH3eBLaCU8BOovnPaaBBHECDbCVe38+FKNGUaN3+ G6ycRUBV4urG82BjeAV0Je7sO8sIUs4rICjxd4cwxKHSEl8nPGGCaJWX2P52DvMERsFZSCbN QuiYhaRqASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjKDg5ZTk3cH47qDS IUYBDkYlHt7bp5b6CrEmlhVX5h5ilORgUhLl3XMBKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE 90TVEl8h3pTEyqrUonyYlDQHi5I470xJdV8hgfTEktTs1NSC1CKYrAwHh5IEr8oloKGCRanp qRVpmTklCGkmDk6Q4TxAw7nOA9XwFhck5hZnpkPkTzEac+zp37+PkeP/lkP7GIVY8vLzUqXE eY1BxgmAlGaU5sFNgyWgV4ziQM8JQyzlASYvuHmvgFYxAa16fRbkj+KSRISUVAPjqRrzOYWX N80vZGeaHJPQ2KD3qWNV8D+Zj5HpT+WWyXWyr7hXvOPUFoH3j58qaXWtVK3xsdVw3BO6uGpL 4ff/LVlqPcLmFxdq1t4+WvLbbL3t2durnvLZ/t5Wm8v1cbqGxsXlv7a78E5WzWJvupRRNO1h DNdyS4np9wpCZLR/twYtSvq8aqmXEktxRqKhFnNRcSIAblzdoBsDAAA= Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:45:03 -0000 On Wed, 2011-04-13 at 11:53 -0400, Martin Rex wrote: > > I considered that interpretation too, but it seems like a bit of a > > stretch. If ghudson@ATHENA.MIT.EDU is listed in /home/buildbot/.k5login > > on a machine, does that mean that the MN ghudson@ATHENA.MIT.EDU and the > > internal name GSS_C_NT_USERNAME/buildbot "refer to the same entity" (RFC > > 2743 2.4.3)? The first is authorized to perform arbitrary actions as > > the second, but the reverse is not necessarily true. > But now you're describing a behaviour that is completely different > from the previous discussion (I have no idea what krb5_kuserok() does). Which part of the previous discussion? I probably didn't frame the extension clearly enough when I started the thread. The immediate goal of this extension is to make sshd useful with GSS-EAP by replacing sshd's current call to krb5_kuserok() with a mechanism-neutral API. For Kerberos MNs and a Unix-ish krb5 implementation, this API should result into a call to krb5_kuserok(). How krb5_kuserok is implemented isn't really all that important, except to note that it consults files and configuration rather than just comparing pieces of the principal name and username. > What you're describing looks extremely app-specific, and not a result > of a tight integration of a gssapi mechanism with the underlying OS. sshd certainly didn't invent krb5_kuserok(). It was originally invented (as I understand it) for the krb5-enabled versions of rlogin/rsh/rcp and telnet. I've already discussed the narrow applicability of this extension, at least for unadorned GSS_C_NT_USERNAME lnames. To want to use it, you need to (1) be in the business of providing system account access to authenticated entities, and (2) be implementing a protocol where the initiator identifies a target username. Right now that roughly translates into being sshd or gssftpd. SMB and NFS servers would be candidate users except (as I understand it) the initiator doesn't identify a target username in those protocols, so for those you need an MN-to-lname mapping facility instead. krb5 has one of those too, and maybe people will some day want a mechanism-neutral interface for that as well. But that's out of scope for now. My primary goal in starting this thread was to coordinate the specification of this extension across the MIT krb5, Solaris, Heimdal, and Gnu GSS mechglues, as there was a conflict in the first pass. A secondary goal was choosing a specification which might be extensible to related use cases and which might be appropriate to standardize (while still minimizing complexity). It won't particularly bother me if the secondary goal doesn't come to light. From nico@cryptonector.com Wed Apr 13 10:06:21 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5C8D9E0806 for ; Wed, 13 Apr 2011 10:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqNiq-KCP+qL for ; Wed, 13 Apr 2011 10:06:20 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfc.amsl.com (Postfix) with ESMTP id 856DEE07E9 for ; Wed, 13 Apr 2011 10:06:20 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 75A94674088 for ; Wed, 13 Apr 2011 10:06:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=p4HFv1ahrPuaHAtoAhRtGZ5k17j8SqcgyBYwdmsfghBB vHR9SqzQwu35/BN6W0z2pKblIDCrXXmbsFM3g58g5c65shJh4bIRUkWIzNL17wp1 ufCM1W11hOSUEDJ8TEB+eJgOD8dHOz6fdEDxZEYGFZN1D4KynoH4s7YihK2PwD0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=hYmVFtk63TWydJvkyKpc6f9cfLY=; b=JWYEmLZRnFK huK26N6AwatgICF/le2Hz2WTXk+Cw8hR9zJnlBxnmhopGFH28En2T8mfL1ie0+2h ivMUrFl7CrKipjj+QLb9u9XSgGrzC8TmVjGew8NtzdyYTEHhK3Q1xk2GQicWqiqF OD2Wf/D57FC0oG0j1mLiwOFw3DL6e0As= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id E48A96740A4 for ; Wed, 13 Apr 2011 10:04:46 -0700 (PDT) Received: by vxg33 with SMTP id 33so768749vxg.31 for ; Wed, 13 Apr 2011 10:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.101.168 with SMTP id fh8mr5764006vdb.134.1302714274607; Wed, 13 Apr 2011 10:04:34 -0700 (PDT) Received: by 10.52.163.228 with HTTP; Wed, 13 Apr 2011 10:04:34 -0700 (PDT) In-Reply-To: <1302713097.10465.735.camel@t410> References: <201104131553.p3DFrTx0006197@fs4113.wdf.sap.corp> <1302713097.10465.735.camel@t410> Date: Wed, 13 Apr 2011 12:04:34 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 17:06:21 -0000 On Wed, Apr 13, 2011 at 11:44 AM, Greg Hudson wrote: > My primary goal in starting this thread was to coordinate the > specification of this extension across the MIT krb5, Solaris, Heimdal, > and Gnu GSS mechglues, as there was a conflict in the first pass. =C2=A0A > secondary goal was choosing a specification which might be extensible to > related use cases and which might be appropriate to standardize (while > still minimizing complexity). =C2=A0It won't particularly bother me if th= e > secondary goal doesn't come to light. As long as it ends up on the upcoming IANA registry, I don't care if an RFC is even published. I don't want to see any further collisions occurring as a result of implementors shipping extensions not registered anywhere. I would prefer that an RFC be published and I don't see why there would be any obstacle to that at this point, certainly not for an Informational RFC. I don't see a problem with making this a Proposed Standard either -- every OS has a notion of username, and ones that don't can just implement a stub for this function. From lear@cisco.com Thu Apr 14 05:09:45 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 54A24E089D for ; Thu, 14 Apr 2011 05:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.481 X-Spam-Level: X-Spam-Status: No, score=-109.481 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqj4bu-a85mW for ; Thu, 14 Apr 2011 05:09:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 70D16E06FA for ; Thu, 14 Apr 2011 05:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=9704; q=dns/txt; s=iport; t=1302782983; x=1303992583; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RBdrePTE4F+3Rc+APbHJPL3nr4Sa3qhxtI+S+LJGOQA=; b=B7H8+4Q8huHfM9LmxlTL8fYLCbt7OltmDrszy7q+leoMwtSYOcPq9p5c EEBbqON5hKMo5wGJ9M/Oa8uPUzruqRai1WHi3kG5UgfH4/5k1yZtIEsGp c8ZsQrhdqOZZyQ28p9gEpCTY+zlfyUdIiyxqmaXtA6edtAoQ4DoxyNCHJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisEAAXjpk2Q/khMgWdsb2JhbACETKEpFAEBFiYliG+bdotQkSeBKYFWgXd4BI1v X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="83570674" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2011 12:09:42 +0000 Received: from dhcp-144-254-50-88.cisco.com (dhcp-144-254-50-88.cisco.com [144.254.50.88]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3EC9gW2028123; Thu, 14 Apr 2011 12:09:42 GMT Message-ID: <4DA6E3E1.6090301@cisco.com> Date: Thu, 14 Apr 2011 14:09:05 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alexey Melnikov References: <4D772586.60409@oracle.com> <4D9F6D8C.3080409@isode.com> In-Reply-To: <4D9F6D8C.3080409@isode.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-openid-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:09:45 -0000 Alexey, Please see below regarding each of your suggestions: > 1. Introduction > > Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is > used by application protocols such IMAP, POP and XMPP, with the goal > > Strictly speaking all of these need Informative references. Added. > > The OpenID mechanism described in this memo aims to re-use the > available OpenID specification to a maximum extent and therefore does > not establish a separate authentication, integrity and > confidentiality mechanism. It is anticipated that existing security > layers, such as Transport Layer Security (TLS), will continued to be > > An Informative reference is missing here. Added. > > Because this mechanism transports information that should not be > controlled by an attacker, the OpenID mechanism MUST only be used > over channels protected by TLS [RFC5246], and the client MUST > successfully validate the server certificate, or similar integrity > > Are references to RFC 5280 and RFC 6125 missing here? Added. > > protected and authenticated channels. > > > 2. Applicability for non-HTTP Use Cases > > OpenID was originally envisioned for HTTP/HTML based communications, > > Informative references are missing. Added. > > Is any specific version of HTML required here? 4.01. Added. > > > 2. The client initiates a SASL authentiation and transmits the > > typo: authentication > Fixed. > User-Supplied Identifier as well as an optional return_to > parameter. > > From the description later in the document, the return_to parameter is > only > generated by the server. So I think something is wrong in the document > (either here, or elsewhere). > > 3. After normalizing the User-Supplied Identifier, > > How? Added reference to OpenID spec (and section). > 4. The Relying Party and the OP optionally establish an association > -- a shared secret established using Diffie-Hellman Key > Exchange. > > Where is this described normatively? The text seems fairly informative. Added reference to OpenID spec and section. > 8. Next the client optionally authenticates to the OP and then > approves or disapproves authentication to the Relying Party. > The manner in which the end user is authenticated to their > respective OP and any policies surrounding such authentication > is out of scope of OpenID and and hence also out of scope for > this specification. This step happens out of band from SASL. > > Hmm, this suggests that one can't implement this mechanism interoperably > on the client side. I think this is a problem. This is the nature of federated authentication through the web. How the IdP/OP authenticates the user (and visa versa) is passed by OpenID to control of the OP for all intents and purposes. > > > ----- = SASL > - - - = HTTP or SSL > > Did you mean "HTTP over TLS"? (Avoiding a use of the term "SSL", as > SSL 2.0 > is deprecated and 3.0 might follow the same path.) Changed to HTTP or HTTPS. > > > 2.1. Binding SASL to OpenID in the Relying Party > > To ensure that a specific request is bound, and in particular to ease > interprocess communication, it may be necessary for the relying party > to encode some sort of nonce in the URIs it transmits through the > client for success or failure. This can be done in any number of > ways. > > Isn't this necessary to implement? Yes, and it is described below. > > Examples would include making changes to the base URI or > otherwise including an additional fragment. > > Can you provide expanded examples? There is an example included. > > 2.2. Discussion > > As mentioned above OpenID is primarily designed to interact with web- > based applications. Portions of the authentication stream are only > defined in the crudest sense. That is, when one is prompted to > approve or disapprove an authentication, anything that one might find > on a browser is allowed, including JavaScript, fancy style-sheets, > etc. Because of this lack of structure, implementations will need to > invoke a fairly rich browser in order to insure that the > authentication can be completed. > > This is not well defined. I have doubts that that is implementable > without invoking a browser. If that was never the intent, I think a clear > applicability statement upfront is needed. Added. > > I also have a more general issue with this: are you saying that this > mechanism > is only implementable by invoking one of the 5 major (and some number > of less > deployed) browsers? Are certain features required from a browser being > invoked? > > 3.2. Initiation > > initial-response = gs2-header Auth-Identifier > Auth-Identifier = Identifier ; authentication identifier > Identifier = URI | XRI ; Identifer is specified in > > typo: Identifier (in the comment) Fixed. > > ; Sec. 7.2 of the OpenID 2.0 spec. > > ABNF should be using "/", not "|" to delimit alternatives. Fixed. > > > 3.3. Authentication Request > > The SASL Server sends an OpenID message that contains an openid.mode > of either "checkid_immediate" or "checkid_setup", as specified in > Section 9.1 of the OpenID 2.0 specification. > > As part of this request, the SASL server MUST append a unique > transaction id to the "e;return_to" portion of the request. The > > Typo in the source XML (""e;")? Fixed. > > The client now sends that request via an HTTP GET to the OP, as if > redirected to do so from an HTTP server. > > What does such request include as far as HTTP operation is concerned? > I.e. which header fields are required? Is Referer header field required? No specific header fields are required, and no referrer is required. > > > The client MUST handle both user authentication to the OP and > confirmation or rejection of the authentiation of the RP. > > Is this process fully prescribed by the OpenID spec? Yes. > > After all authentication has been completed by the OP, and after the > response has been sent to the client, the client will relay the > response to the Relying Party via HTTP or SSL. > > HTTP and SSL are not interchangeable, so I don't know what this means. Changed to HTTPS (meant to encompass current forms of communication). Also added specific normative recommendation to clarify which URIs should be allowed. > > Also, I am a bit confused at this point: what is the corresponding > section 2 > step number for this operation? If this is the step 9, then I don't > understand > why the client is involved in this at all? Figure 1 doesn't seem to show > this interaction path. Extraneous text removed. > > > 3.4. Server Response > > sreg_word = 1* ( unreserved / pct-encoded ) > ; pct-encoded from Section 2.1 of RFC 3896 > ; unreserved from Section 2.3 of RFC 3896 > > s/3896/3986 (twice) Fixed (twice). > > If the application protocol allows, openid.error and > openid.error_code and any other useful diagnostic information SHOULD > be included in authentication failures. > > Why wouldn't it allow? (This doesn't read normative and I think it > should.) This issue remains opened for now. There is no specific means to communicate additional information as part of SASL. That doesn't mean people don't, but it's not there in the libsasl.a or in dovecot, and so IMHO making it mandatory would be a bit excessive. > > > In Section 5: > > IMAP and SASL-IR need Informative references. Added. > > Should HTTP/HTTPS be mandatory to implement URI schemes for such > responses? Yes. Added in security considerations. > > > 7. Room for Improvement > > We note one area where there is possible room for improvement over > existing OpenID implementations. Because SASL is often implemented > atop protocols that have required some amount of provisioning, it may > be possible for the SASL client to signal the browser that it should > increase scrutiny of invalid credentials. How this would be done is > beyond the scope of this specification, but may be the subject of > future updates. For instance, the browser may wish to fail the > request entirely if the certificate is invalid and has not been > accessed prior to this point. One thing that this would require > would be the exposure of a "return_to" URL by the SASL server in case > > Exposure to which entity? This text has been rewritten. There was room for improvement. > > of such failures, so that the authentication is not left hanging. > > > Other comments: > > I am missing some text saying that a SASL authorization identity can > be used with this mechanism. This follows from the definition of the GS2 > bridge, but I think it would be worth stating that explicitly. > > This SASL mechanism is using 3 round trips! I am wondering if we can > do better. > (I haven't though too much on this question, so maybe the answer is "no") Nature of the beast. Control needs to pass to the SASL server to indicate success or failure, but the actual transaction continues through the browser with information that the server itself had to provide. Assuming people are comfortable with the above, if we can close the one open issue on diagnostics, then I'll publish an updated draft. Eliot From lukeh@padl.com Thu Apr 14 05:17:07 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4C96BE06BA for ; Thu, 14 Apr 2011 05:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMzIoy0UwnJz for ; Thu, 14 Apr 2011 05:17:06 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfc.amsl.com (Postfix) with ESMTP id C7049E06E4 for ; Thu, 14 Apr 2011 05:17:06 -0700 (PDT) Received: by us.padl.com with ESMTP id p3ECHeAv009540; Thu, 14 Apr 2011 08:17:44 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1302706051.10465.673.camel@t410> Date: Thu, 14 Apr 2011 14:17:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F444AA2-B371-423A-9CCC-1BE02B075FA4@padl.com> References: <20FFD3B7-E7E2-4003-AC48-C7FBCF149E17@padl.com> <201104112358.p3BNwO35020382@fs4113.wdf.sap.corp> <6CAE7887-3515-42D8-9021-AD3B4F18D07B@padl.com> <1302706051.10465.673.camel@t410> To: Greg Hudson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, FH_HELO_EQ_D_D_D_D, HELO_DYNAMIC_IPADDR2, RDNS_NONE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 0.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_userok X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:17:07 -0000 > Should this extension become a standard, the issue would definitely = bear > further study. For instance, does the MS Kerberos policy decompose = into > something like (MN X lname) -> is-authorized and (lname X is-remote) = -> > is-authorized? Is it possible to guess with confidence whether a = login > is remote/local based on global process state, as it is on Unix using > the tty name? Does it make sense to use GSSAPI acceptor logic in a > Windows protocol implementation interfacing with system accounts, and = if > so, does it only make sense for remote access, or for local access as > well? If the remote/local distinction does turn out to be in scope, > would it be best represented as a flag parameter to = gss_authorize_name, > or an attribute on the MN or local name? If we were doing an SSPI implementation of a new mechanism then we'd = need a PAC anyway (at least for any service that wanted to do = impersonation), and at that point we have enough information to delegate = the authorization to Windows. -- Luke= From simon@josefsson.org Thu Apr 14 08:58:21 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 44E78E0765 for ; Thu, 14 Apr 2011 08:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvwpxtt2k4nN for ; Thu, 14 Apr 2011 08:58:19 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfc.amsl.com (Postfix) with ESMTP id CCDB9E0762 for ; Thu, 14 Apr 2011 08:58:18 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3EFw0qN007153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 14 Apr 2011 17:58:02 +0200 From: Simon Josefsson To: kitten@ietf.org References: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> <87wrkhbybl.fsf@latte.josefsson.org> <87fwr3kkq0.fsf__30668.2908013046$1299249964$gmane$org@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110414:kitten@ietf.org::pjosb97MSIuitKB0:Qqd6 X-Hashcash: 1:22:110414:hartmans-ietf@mit.edu::nZ8YW30BOHv8sF2R:EQ/X Date: Thu, 14 Apr 2011 17:58:00 +0200 In-Reply-To: <87fwr3kkq0.fsf__30668.2908013046$1299249964$gmane$org@latte.josefsson.org> (Simon Josefsson's message of "Fri, 04 Mar 2011 15:45:43 +0100") Message-ID: <87wriw7rlj.fsf_-_@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Subject: [kitten] GFD.24 and draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:58:21 -0000 All, One way to reduce the problem with the normative reference to an external experimental document is to clarify which parts of the external document is required by the naming extensions document. I propose to add text like this (to naming-exts) to clarify the relationship: The normative reference to GFD.24 is for the buffer set functions defined in section 2.5 and the associated buffer set C types defined in section 6 (namely gss_buffer_set_desc, gss_buffer_set_t, gss_create_empty_buffer_set, gss_add_buffer_set_member, gss_release_buffer_set). Nothing else from GFD.24 is required to implement this document. In particular, that document specify changes in behaviour existing GSS-API functions in section 3: implementing those changes are not required to implement this document. The GFD.24 section 3 changes to existing GSS-API functions are problematic for me. I don't want to implement that part and I see no reason to do so in order to support naming extensions. Modifications to IETF standardized functions should go through the IETF in my opinion. Without something like my text above, it is unclear whether naming extensions requires that change or not. When reviewing GFD.24 I also noticed that the the generic GSS-API functions are poorly named: they are using C-style names rather than GSS-API-cased names used in RFC 2743. For example, GFD.24's function "gss_create_empty_buffer_set" should be called "GSS_Create_empty_buffer_set" for consistency. Also there are no documentation on how the C functions should behave, compare RFC 2744 for how proper C function definitions for GSS-API bindings should look like. I can probably guess what the intended meaning of GFD.24 is, but I think the document is underspecified and does not permit interoperable implementations without guesswork and/or access to external information. /Simon From ghudson@mit.edu Sat Apr 16 11:07:22 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B3DC2E0735 for ; Sat, 16 Apr 2011 11:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOtLF3OgrsEk for ; Sat, 16 Apr 2011 11:07:18 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfc.amsl.com (Postfix) with ESMTP id 18688E0708 for ; Sat, 16 Apr 2011 11:07:18 -0700 (PDT) X-AuditID: 12074423-b7b8eae000003d4f-3f-4da9dada435d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.92.15695.ADAD9AD4; Sat, 16 Apr 2011 14:07:22 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p3GI7H7d013839 for ; Sat, 16 Apr 2011 14:07:17 -0400 Received: from localhost (EQUAL-RITES.MIT.EDU [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p3GI7G9a004221 for ; Sat, 16 Apr 2011 14:07:16 -0400 (EDT) Date: Sat, 16 Apr 2011 14:07:16 -0400 (EDT) From: ghudson@MIT.EDU Message-Id: <201104161807.p3GI7G9a004221@outgoing.mit.edu> To: kitten@ietf.org X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42IR4hRV1r11a6WvweET+hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsvPd8wF/1gqLq17yNLA2MrSxcjJISFgIrFkwWt2CFtM4sK9 9WxdjFwcQgL7GCWWXpnDDuEcY5Q48P8zC4TTxyTRteQQWDuLgLbEu2u7mUFsNgFRiQ8fLrCC 2LwCVhI75ywEs0UEhCV2b30HViMsoCGxZvsKlgmMXAsYGVYxyqbkVunmJmbmFKcm6xYnJ+bl pRbpmunlZpbopaaUbmIE+Y/dRXkH45+DSocYBTgYlXh4i6+s9BViTSwrrsw9xCjJwaQkyst+ EyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPfqUaAcb0piZVVqUT5MSpqDRUmcd66kuq+QQHpi SWp2ampBahFMVoaDQ0mCdy/IUMGi1PTUirTMnBKENBMHJ8hwHqDh126ADC8uSMwtzkyHyJ9i 1OWY+PnNPkYhlrz8vFQpcd6zIIMEQIoySvPg5sDi7hWjONBbwrxBwCgU4gHGLNykV0BLmICW 3GxYDrKkJBEhJdXA6K3k4NqrHSlf57ikgD96U7nZi7J+iU3hfCefBSyTvLDm2clZOuu/tqmo VJjmfU7ymL3Y5I6HltRRl+2Nsxr4YlkOG+x2UPmt66zC/i7x3qGgsCkPXZzUN6hIpa9b/HlS 9pk4gbeFf9SqNkQxLDZkiJWXSbU74K4eKXhnWdqDXu2fV5TvFy1QYinOSDTUYi4qTgQAqnT0 a5YCAAA= Subject: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:07:22 -0000 I just had occasion to look at the specification of gss_oid_equal() in http://tools.ietf.org/html/draft-josefsson-gss-capsulate-04, and I ran into this text: "The value GSS_C_NO_OID will not match any OID, including GSS_C_NO_OID itself." That seems peculiar to me; I'm not familiar with any other comparison operator for a nullable type in any language which makes null not equal to itself. Is there a specific reason why this behavior is convenient? The behavior has already shipped in Heimdal and Gnu GSS, so I guess it's probably too late to change, but I would like to at least know the rationale in hindsight. From nico@cryptonector.com Sat Apr 16 11:30:24 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 52A46E0681 for ; Sat, 16 Apr 2011 11:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsDJaT35KTmk for ; Sat, 16 Apr 2011 11:30:23 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfc.amsl.com (Postfix) with ESMTP id 75A65E0678 for ; Sat, 16 Apr 2011 11:30:23 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 24BEF2C8058 for ; Sat, 16 Apr 2011 11:30:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=O8ACBCcCuE02/RnqaVj3y X5bhHXlrXiQfngZi1Y8a7LMm0cti6mFnvYEw42kKxLdqIikcZ0ibMzEGnQBYz9oU krABHw0zl4sfXpyODE0yRjx6zs7kRLS5Xu0g8amBXCo77ZAtofDByX03hH3P0VQG QwKWzeWvQ1Jo/TLay0hLz8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=fd0NLCENzjlf+yg6vCGP I6zFNdY=; b=tNGaZ3RMX4Q+hpXfcSKb28P7rbelZM64gbGpgv0himROYtqZZW+8 8Tv4vVvcK5oL7LrcoUXD5bXfTYFsApdUU7rErwHnTzcQ5Wr4h43Lp+GlxmvcYCj8 3u7OgPsnrqVh8q8iTQ8G8K3sA6zsUBxQgLj1AbpAH+6RyGB4rgOUoiQ= Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id C28DF2C8057 for ; Sat, 16 Apr 2011 11:30:21 -0700 (PDT) Received: by wwa36 with SMTP id 36so2876925wwa.13 for ; Sat, 16 Apr 2011 11:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.6 with SMTP id n6mr9049947wer.40.1302978620268; Sat, 16 Apr 2011 11:30:20 -0700 (PDT) Received: by 10.216.64.74 with HTTP; Sat, 16 Apr 2011 11:30:20 -0700 (PDT) Received: by 10.216.64.74 with HTTP; Sat, 16 Apr 2011 11:30:20 -0700 (PDT) In-Reply-To: <201104161807.p3GI7G9a004221@outgoing.mit.edu> References: <201104161807.p3GI7G9a004221@outgoing.mit.edu> Date: Sat, 16 Apr 2011 13:30:20 -0500 Message-ID: From: Nico Williams To: ghudson@mit.edu Content-Type: multipart/alternative; boundary=e0cb4e43cd31cfa04004a10d599f Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 18:30:24 -0000 --e0cb4e43cd31cfa04004a10d599f Content-Type: text/plain; charset=UTF-8 On Apr 16, 2011 1:07 PM, wrote: > > I just had occasion to look at the specification of gss_oid_equal() in > http://tools.ietf.org/html/draft-josefsson-gss-capsulate-04, and I ran > into this text: > > "The value GSS_C_NO_OID will not match any OID, including > GSS_C_NO_OID itself." > > That seems peculiar to me; I'm not familiar with any other comparison > operator for a nullable type in any language which makes null not > equal to itself. Is there a specific reason why this behavior is > convenient? SQL does this sort of thing also. --e0cb4e43cd31cfa04004a10d599f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 16, 2011 1:07 PM, <ghudson@= mit.edu> wrote:
>
> I just had occasion to look at the specification of gss_oid_equal() in=
> http://tools.ietf.org/html/draft-josefsson-gss-capsulate-04, and I ra= n
> into this text:
>
> =C2=A0"The value GSS_C_NO_OID will not match any OID, including > =C2=A0GSS_C_NO_OID itself."
>
> That seems peculiar to me; I'm not familiar with any other compari= son
> operator for a nullable type in any language which makes null not
> equal to itself. =C2=A0Is there a specific reason why this behavior is=
> convenient?

SQL does this sort of thing also.

--e0cb4e43cd31cfa04004a10d599f-- From simon@josefsson.org Sun Apr 17 01:00:49 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6B0E2E0695 for ; Sun, 17 Apr 2011 01:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk2BFjmBlTwi for ; Sun, 17 Apr 2011 01:00:48 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfc.amsl.com (Postfix) with ESMTP id 8784BE0682 for ; Sun, 17 Apr 2011 01:00:48 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3H80be8024289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 Apr 2011 10:00:39 +0200 From: Simon Josefsson To: ghudson@MIT.EDU References: <201104161807.p3GI7G9a004221__46838.2861734883$1302977253$gmane$org@outgoing.mit.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110417:kitten@ietf.org::j8YOyn3gaD+y8zph:5dbP X-Hashcash: 1:22:110417:ghudson@mit.edu::OHwfIxF9agZByK8Y:eNDq Date: Sun, 17 Apr 2011 10:00:37 +0200 In-Reply-To: <201104161807.p3GI7G9a004221__46838.2861734883$1302977253$gmane$org@outgoing.mit.edu> (ghudson@mit.edu's message of "Sat, 16 Apr 2011 14:07:16 -0400 (EDT)") Message-ID: <874o5x2tp6.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2011 08:00:49 -0000 ghudson@MIT.EDU writes: > I just had occasion to look at the specification of gss_oid_equal() in > http://tools.ietf.org/html/draft-josefsson-gss-capsulate-04, and I ran > into this text: > > "The value GSS_C_NO_OID will not match any OID, including > GSS_C_NO_OID itself." > > That seems peculiar to me; I'm not familiar with any other comparison > operator for a nullable type in any language which makes null not > equal to itself. Is there a specific reason why this behavior is > convenient? I don't recall a strong rationale. If it was intentional, it was as a pre-caution to make sure the function would not return true if you had received GSS_C_NO_OID from two different code paths and were expecting them to be real OIDs with some security-important meaning and wanted to compare them for equality. For example two security policy OIDs or something. If the function would return true for two GSS_C_NO_OID inputs, the caller would have to compare the parameters against GSS_C_NO_OID manually to make sure it wasn't in a "don't know" state which would typically not be OK. The same argument could be made the other way around too, but since it is easy and inexpensive to compare two NULL OIDs (as oppoosed to comparing two non-NULL OIDs which has the possibility of BER encoding differences) the behaviour for NULL inputs doesn't seem like a major issue to me. /Simon From nico@cryptonector.com Sun Apr 17 21:57:05 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E805DE0783 for ; Sun, 17 Apr 2011 21:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QMNULOtZrHU for ; Sun, 17 Apr 2011 21:57:05 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfc.amsl.com (Postfix) with ESMTP id F0F76E06A5 for ; Sun, 17 Apr 2011 21:57:04 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 7CF5B508071 for ; Sun, 17 Apr 2011 21:57:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=vRomxVgXC/QBW0KLmrQPSt+pSxOka9klxkNd7pStYUPc EyYvybeiFogr9BqyrnxcqqnsfSnJlGva5uoMC5ZkGTw0wjRQIF3GINJ6i3i8n2L/ QgypZOOTfFrcO5KCYtchSrVF3HdezR283vAs8tUm86Rb4eC7Cf8FujpjApCU3UE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=/iWXvNonQ3tXohiAyTWDFNG0Pd0=; b=xY8s3KfPzhD oYjinsA7LTbfKDZvBZ6PYI/FAR6rjOqTyhCayB94twRUvGQXem6d0hJrT8cVfKSF qzpvrlCnjNLBvNL/S5X+vk4lScETLza2TIcyAVIlmVrNC898ePHZqU/2IoT6X5lq rBSrH80tRtDHeqa/wZ4cKgWswJzFJhDk= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 5AB5750806D for ; Sun, 17 Apr 2011 21:57:03 -0700 (PDT) Received: by vws12 with SMTP id 12so4078048vws.31 for ; Sun, 17 Apr 2011 21:57:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.225 with SMTP id el1mr3206143vdb.174.1303102622699; Sun, 17 Apr 2011 21:57:02 -0700 (PDT) Received: by 10.52.167.103 with HTTP; Sun, 17 Apr 2011 21:57:02 -0700 (PDT) In-Reply-To: <874o5x2tp6.fsf@latte.josefsson.org> References: <201104161807.p3GI7G9a004221__46838.2861734883$1302977253$gmane$org@outgoing.mit.edu> <874o5x2tp6.fsf@latte.josefsson.org> Date: Sun, 17 Apr 2011 23:57:02 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 04:57:06 -0000 On Sun, Apr 17, 2011 at 3:00 AM, Simon Josefsson wrot= e: > I don't recall a strong rationale. =C2=A0If it was intentional, it was as= a > pre-caution to make sure the function would not return true if you had > received GSS_C_NO_OID from two different code paths and were expecting > them to be real OIDs with some security-important meaning and wanted to > compare them for equality. =C2=A0For example two security policy OIDs or > something. =C2=A0If the function would return true for two GSS_C_NO_OID > inputs, the caller would have to compare the parameters against > GSS_C_NO_OID manually to make sure it wasn't in a "don't know" state > which would typically not be OK. I think it's a fair fail-safe feature. Note that gss_display_name() is allowed to return GSS_C_NO_OID as the output name type in some cases, and so far this is the only case that RFCs 2743 and 2744 envision where the API can return GSS_C_NO_OID: If input_name was created by a call to gss_import_name, specifying GSS_C_NO_OID as the name-type, implementations that employ lazy conversion between name types may return GSS_C_NO_OID via the output_name_type parameter. (And, of course, apps should not really be comparing non-MNs... but it could happen.) But future extensions might add new cases. And then there's APIs layered above the GSS-API. Having an OID comparison function work like SQL's three-valued logic (where (NULL =3D NULL) is NULL, not true) seems like the right thing to do. > The same argument could be made the other way around too, but since it > is easy and inexpensive to compare two NULL OIDs (as oppoosed to > comparing two non-NULL OIDs which has the possibility of BER encoding > differences) the behaviour for NULL inputs doesn't seem like a major > issue to me. Any one OID has one and only one possible encoding in DER (and even BER). If a pair of OIDs' encodings differ it's because the OIDs themselves differ. (Though I've not sat down to figure out if memcmp() happens to define a useful collation for encoded OIDs... But I'd not bet on it. If you want to sort OIDs by canonical order then I bet you'll need to decode arcs as you compare.) Nico -- From mrex@sap.com Mon Apr 18 08:29:18 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B9EADE06DD for ; Mon, 18 Apr 2011 08:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.993 X-Spam-Level: X-Spam-Status: No, score=-9.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmCM7XrEnl36 for ; Mon, 18 Apr 2011 08:29:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id A5250E068E for ; Mon, 18 Apr 2011 08:29:15 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3IFTA7Y008383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2011 17:29:10 +0200 (MEST) From: Martin Rex Message-Id: <201104181529.p3IFT9XT000970@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Mon, 18 Apr 2011 17:29:09 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 17, 11 11:57:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, simon@josefsson.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:29:18 -0000 Nico Williams wrote: > > On Sun, Apr 17, 2011 at 3:00 AM, Simon Josefsson wrote: > > I don't recall a strong rationale.  If it was intentional, it was as a > > pre-caution to make sure the function would not return true if you had > > received GSS_C_NO_OID from two different code paths and were expecting > > them to be real OIDs with some security-important meaning and wanted to > > compare them for equality.  For example two security policy OIDs or > > something.  If the function would return true for two GSS_C_NO_OID > > inputs, the caller would have to compare the parameters against > > GSS_C_NO_OID manually to make sure it wasn't in a "don't know" state > > which would typically not be OK. > > I think it's a fair fail-safe feature. I do have two different implementations of a compare_oid function in two different projects of mine. The 16-year old implementation returns FALSE when comparing two GSS_C_NO_OIDs, the other (part of gsskrb5.dll) returns TRUE. I don't see a need to change either of them. So looking at my own implementations, I probably think the result of comparing two GSS_C_NO_OID should be implementation defined. > > Note that gss_display_name() > is allowed to return GSS_C_NO_OID as the output name type in some > cases, and so far this is the only case that RFCs 2743 and 2744 > envision where the API can return GSS_C_NO_OID: > > If input_name was created by a call to gss_import_name, specifying > GSS_C_NO_OID as the name-type, implementations that employ lazy > conversion between name types may return GSS_C_NO_OID via the > output_name_type parameter. Comparing the outputs of gss_display_name() is not a good idea, and while it may work most of the time with Kerberos-based gssapi mechanisms, it often fails with PKI/X.509 based gssapi mechanisms: http://tools.ietf.org/html/rfc2743#page-14 GSS_Import_name() implementations can, where appropriate, support more than one printable syntax corresponding to a given namespace (e.g., alternative printable representations for X.500 Distinguished Names), allowing flexibility for their callers to select among alternative representations. GSS_Display_name() implementations output a printable syntax selected as appropriate to their operational environments; this selection is a local matter. Callers desiring portability across alternative printable syntaxes should refrain from implementing comparisons based on printable name forms and should instead use the GSS_Compare_name() call to determine whether or not one internal-format name matches another. > > > The same argument could be made the other way around too, but since it > > is easy and inexpensive to compare two NULL OIDs (as oppoosed to > > comparing two non-NULL OIDs which has the possibility of BER encoding > > differences) the behaviour for NULL inputs doesn't seem like a major > > issue to me. > > Any one OID has one and only one possible encoding in DER (and even > BER). If a pair of OIDs' encodings differ it's because the OIDs > themselves differ. In theory, the ASN.1 BER encoding rules require canonical encodings for Object Identifiers Elements (X.690, Section 8.19.2 last sentence): The subidentifier shall be encoded in the fewest possible octets, that is, the leading octet of the subidentifier shall not have the value 80(base16) In practice, ASN.1 decoders do not necessarily implement this as a hard failure and apps might, under certain circumstances (depending on the internal representation of OIDs created by the ASN.1 decoder), treat the following OIDs as equal (in other places than GSS-API gss_OID): rfc-1964 Kerberos (BER&DER) { 9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02" } (non-canonical) { 10, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x80\x82" } The problem is much with non-canonical UTF8 in strcmp() comparisons, ASCII&canonical UTF8 "\x41\x42\x43" = "ABC" non-canonical UTF8 "\xc1\x81\x42\x43" = "ABC" -Martin From mrex@sap.com Mon Apr 18 08:33:29 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 598F7E06DD for ; Mon, 18 Apr 2011 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTKH3+UF7ofG for ; Mon, 18 Apr 2011 08:33:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 9198EE068E for ; Mon, 18 Apr 2011 08:33:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3IFXDuV007976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2011 17:33:18 +0200 (MEST) From: Martin Rex Message-Id: <201104181533.p3IFXDVG001122@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Mon, 18 Apr 2011 17:33:13 +0200 (MEST) In-Reply-To: <201104181529.p3IFT9XT000970@fs4113.wdf.sap.corp> from "Martin Rex" at Apr 18, 11 05:29:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, simon@josefsson.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:33:29 -0000 Ooops, sorry. Typo in the non-canonical (not correctly formed ASN.1 DER) oid (corrected below, final octet 0x02 insted of 0x82). Martin Rex wrote: > > Nico Williams wrote: > > > > Any one OID has one and only one possible encoding in DER (and even > > BER). If a pair of OIDs' encodings differ it's because the OIDs > > themselves differ. > > In theory, the ASN.1 BER encoding rules require canonical encodings > for Object Identifiers Elements (X.690, Section 8.19.2 last sentence): > > The subidentifier shall be encoded in the fewest possible octets, > that is, the leading octet of the subidentifier shall not have > the value 80(base16) > > In practice, ASN.1 decoders do not necessarily implement this as a hard > failure and apps might, under certain circumstances (depending on the internal > representation of OIDs created by the ASN.1 decoder), treat the > following OIDs as equal (in other places than GSS-API gss_OID): > > rfc-1964 Kerberos (BER&DER) > { 9, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x02" } > (non-canonical) > { 10, "\x2a\x86\x48\x86\xf7\x12\x01\x02\x80\x02" } > > > The problem is much worse with non-canonical UTF8 in strcmp() comparisons: > > ASCII&canonical UTF8 "\x41\x42\x43" = "ABC" > non-canonical UTF8 "\xc1\x81\x42\x43" = "ABC" From simon@josefsson.org Mon Apr 18 09:24:57 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 13BC3E0776 for ; Mon, 18 Apr 2011 09:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzDYMW2kCX2i for ; Mon, 18 Apr 2011 09:24:56 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfc.amsl.com (Postfix) with ESMTP id D6D7DE06D9 for ; Mon, 18 Apr 2011 09:24:55 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3IGOhR8018173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Apr 2011 18:24:44 +0200 From: Simon Josefsson To: mrex@sap.com References: <201104181529.p3IFT9XT000970__4326.74634871564$1303140571$gmane$org@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110418:nico@cryptonector.com::GME+H1OzV92489Wp:XZh X-Hashcash: 1:22:110418:mrex@sap.com::yWDUJMdaSmSI2Q56:xU4 X-Hashcash: 1:22:110418:kitten@ietf.org::DFirGdbecTNo+c3B:EDG9 Date: Mon, 18 Apr 2011 18:24:42 +0200 In-Reply-To: <201104181529.p3IFT9XT000970__4326.74634871564$1303140571$gmane$org@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 18 Apr 2011 17:29:09 +0200 (MEST)") Message-ID: <87fwpfv86t.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:24:57 -0000 Martin Rex writes: > Nico Williams wrote: >> >> On Sun, Apr 17, 2011 at 3:00 AM, Simon Josefsson wrote: >> > I don't recall a strong rationale.  If it was intentional, it was as a >> > pre-caution to make sure the function would not return true if you had >> > received GSS_C_NO_OID from two different code paths and were expecting >> > them to be real OIDs with some security-important meaning and wanted to >> > compare them for equality.  For example two security policy OIDs or >> > something.  If the function would return true for two GSS_C_NO_OID >> > inputs, the caller would have to compare the parameters against >> > GSS_C_NO_OID manually to make sure it wasn't in a "don't know" state >> > which would typically not be OK. >> >> I think it's a fair fail-safe feature. > > I do have two different implementations of a compare_oid function in two > different projects of mine. The 16-year old implementation returns > FALSE when comparing two GSS_C_NO_OIDs, the other (part of gsskrb5.dll) > returns TRUE. I don't see a need to change either of them. > > So looking at my own implementations, I probably think the result > of comparing two GSS_C_NO_OID should be implementation defined. Oh please no! What's the point in that? An application would then have to always check the GSS_C_NO_OID case specially, regardless of which behaviour it wanted. /Simon From mrex@sap.com Mon Apr 18 09:42:38 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE8F2E0820 for ; Mon, 18 Apr 2011 09:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.703 X-Spam-Level: X-Spam-Status: No, score=-9.703 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFmYH5Sy9vz2 for ; Mon, 18 Apr 2011 09:42:38 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id D66E4E0839 for ; Mon, 18 Apr 2011 09:42:37 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3IGgWZc020281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2011 18:42:32 +0200 (MEST) From: Martin Rex Message-Id: <201104181642.p3IGgV65005291@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Mon, 18 Apr 2011 18:42:31 +0200 (MEST) In-Reply-To: <87fwpfv86t.fsf@latte.josefsson.org> from "Simon Josefsson" at Apr 18, 11 06:24:42 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:42:39 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > > Nico Williams wrote: > >> > >> On Sun, Apr 17, 2011 at 3:00 AM, Simon Josefsson wrote: > >> > I don't recall a strong rationale.  If it was intentional, it was as a > >> > pre-caution to make sure the function would not return true if you had > >> > received GSS_C_NO_OID from two different code paths and were expecting > >> > them to be real OIDs with some security-important meaning and wanted to > >> > compare them for equality.  For example two security policy OIDs or > >> > something.  If the function would return true for two GSS_C_NO_OID > >> > inputs, the caller would have to compare the parameters against > >> > GSS_C_NO_OID manually to make sure it wasn't in a "don't know" state > >> > which would typically not be OK. > >> > >> I think it's a fair fail-safe feature. > > > > I do have two different implementations of a compare_oid function in two > > different projects of mine. The 16-year old implementation returns > > FALSE when comparing two GSS_C_NO_OIDs, the other (part of gsskrb5.dll) > > returns TRUE. I don't see a need to change either of them. > > > > So looking at my own implementations, I probably think the result > > of comparing two GSS_C_NO_OID should be implementation defined. > > Oh please no! What's the point in that? An application would then have > to always check the GSS_C_NO_OID case specially, regardless of which > behaviour it wanted. What does ISO-C say about memcmp(NULL,NULL,0) or memcmp(NULL, something, 0) Having to special-case the absence of some value is not unusual. In GSS-API GSS_C_NO_OID indicates the _absence_ of an OID value. -Martin From simon@josefsson.org Mon Apr 18 09:56:17 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C4EB5E06DE for ; Mon, 18 Apr 2011 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LcT8915bEh4 for ; Mon, 18 Apr 2011 09:56:17 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfc.amsl.com (Postfix) with ESMTP id E00E1E0694 for ; Mon, 18 Apr 2011 09:56:15 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3IGtwBx019741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Apr 2011 18:56:00 +0200 From: Simon Josefsson To: mrex@sap.com References: <87fwpfv86t.fsf@latte.josefsson.org> <201104181642.p3IGgV65005291__48933.9311294772$1303144977$gmane$org@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110418:mrex@sap.com::nR5YHc5eqZWItN1h:EgAd X-Hashcash: 1:22:110418:kitten@ietf.org::9Fvng9YIXujW6iKK:ks0u Date: Mon, 18 Apr 2011 18:55:58 +0200 In-Reply-To: <201104181642.p3IGgV65005291__48933.9311294772$1303144977$gmane$org@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 18 Apr 2011 18:42:31 +0200 (MEST)") Message-ID: <87bp03v6qp.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 16:56:17 -0000 Martin Rex writes: >> Oh please no! What's the point in that? An application would then have >> to always check the GSS_C_NO_OID case specially, regardless of which >> behaviour it wanted. > > What does ISO-C say about memcmp(NULL,NULL,0) or memcmp(NULL, something, 0) > Having to special-case the absence of some value is not unusual. That doesn't necessarily make it a good idea. ISO C leaves some things to implementers because traditional implementations were behaving differently and the standard came later and couldn't rule existing implementations non-compliant -- but we are not in that situation. The implementation-specific stuff in ISO C has big costs associated with it if you try to write portable code -- for example, you can't assume signed integers are two-complement, that there aren't "holes" in the integer values, or that NULL is an all-0 object. > In GSS-API GSS_C_NO_OID indicates the _absence_ of an OID value. Right. But we can still specify what it means to compare something against that value. /Simon From mrex@sap.com Mon Apr 18 13:13:21 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9C487E0883 for ; Mon, 18 Apr 2011 13:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.702 X-Spam-Level: X-Spam-Status: No, score=-9.702 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJPL7BT4POLM for ; Mon, 18 Apr 2011 13:13:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfc.amsl.com (Postfix) with ESMTP id 72942E0721 for ; Mon, 18 Apr 2011 13:13:20 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p3IKDHnD016653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Apr 2011 22:13:17 +0200 (MEST) From: Martin Rex Message-Id: <201104182013.p3IKDHbn018482@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Mon, 18 Apr 2011 22:13:17 +0200 (MEST) In-Reply-To: <87bp03v6qp.fsf@latte.josefsson.org> from "Simon Josefsson" at Apr 18, 11 06:55:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 20:13:21 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > >> Oh please no! What's the point in that? An application would then have > >> to always check the GSS_C_NO_OID case specially, regardless of which > >> behaviour it wanted. > > > > What does ISO-C say about memcmp(NULL,NULL,0) or memcmp(NULL, something, 0) > > Having to special-case the absence of some value is not unusual. > > That doesn't necessarily make it a good idea. > > ISO C leaves some things to implementers because traditional > implementations were behaving differently and the standard came later > and couldn't rule existing implementations non-compliant -- but we are > not in that situation. The implementation-specific stuff in ISO C has > big costs associated with it if you try to write portable code -- for > example, you can't assume signed integers are two-complement, that there > aren't "holes" in the integer values, or that NULL is an all-0 object. > > > In GSS-API GSS_C_NO_OID indicates the _absence_ of an OID value. > > Right. But we can still specify what it means to compare something > against that value. I am not convinced that it is sensible to define this, because the "correct" answer is context sensitive and even there potentially debatable. As I said, I implemented the answer to this question twice, the answers differ, and I don't feel a need to change either implementation. -Martin From nico@cryptonector.com Mon Apr 18 16:05:54 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2639DE08A9 for ; Mon, 18 Apr 2011 16:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtWs4LxM36BX for ; Mon, 18 Apr 2011 16:05:52 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfc.amsl.com (Postfix) with ESMTP id 1AF24E08A2 for ; Mon, 18 Apr 2011 16:05:52 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 2078E58406E for ; Mon, 18 Apr 2011 16:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=qCAe9QqmcaV9FeCN8OlDb C+qQRcrvAfd1aWgtIHtCZao1a84Q906BJQFvBFRIWA/iGQptskongmyHDDE/sS2B oQBT9TFN9CAnM2nmqykltbYnBl193crjn5SmrWxm1B+jpifuN3X7CDsBfbVpkDCQ YNSHctsjSCQGWcpInbJc4U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=l5ByBvWT82t2tepUxVgY Czf6bqg=; b=PLXwm1ugqYECQOl4e0i0hy41Dx8L6VwMrPHMzZcXRZTF9pk1VtRj jK6dhMT2i4gKkS1ShAWw46p0s/etRAxLed/EKOLEzsX57jXWGxaSKWEAt9LT9UMx VPEXIebBMmMwxjymTj2396Cz1ll+vwMvmFG0T3rEOU9ovIikZxVDUCs= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id E87BF58406A for ; Mon, 18 Apr 2011 16:05:50 -0700 (PDT) Received: by vws12 with SMTP id 12so4884815vws.31 for ; Mon, 18 Apr 2011 16:05:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.36 with SMTP id q4mr912168vdv.134.1303167949943; Mon, 18 Apr 2011 16:05:49 -0700 (PDT) Received: by 10.52.167.103 with HTTP; Mon, 18 Apr 2011 16:05:49 -0700 (PDT) Received: by 10.52.167.103 with HTTP; Mon, 18 Apr 2011 16:05:49 -0700 (PDT) In-Reply-To: <201104182013.p3IKDHbn018482@fs4113.wdf.sap.corp> References: <87bp03v6qp.fsf@latte.josefsson.org> <201104182013.p3IKDHbn018482@fs4113.wdf.sap.corp> Date: Mon, 18 Apr 2011 18:05:49 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: multipart/alternative; boundary=bcaec5016695bd320304a1396e50 Cc: kitten@ietf.org, Simon Josefsson Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 23:05:54 -0000 --bcaec5016695bd320304a1396e50 Content-Type: text/plain; charset=UTF-8 On Apr 18, 2011 4:13 PM, "Martin Rex" wrote: > I am not convinced that it is sensible to define this, because the > "correct" answer is context sensitive and even there potentially debatable. > As I said, I implemented the answer to this question twice, the answers > differ, and I don't feel a need to change either implementation. I understand the desire to avoid changing either implementation that you have. A reasonable compromise would be to say that this I-D documents a historically available function and to pick one behavior as RECOMMENDED (SHOULD) instead of REQUIRED. I would much prefer REQUIREing a single behavior though. Similay regarding memcmp() vs decoding the arcs and properly implementing an OID collation. I understand it's much simpler to memcmp()... I'd rather we have a REQUIRED behavior, but in a pinch will settle for RECOMMENDED -- after all, we can all write autoconf macros, but surely we all hate having to! (Dont't forget, it's the apps developers who will have to put up with choices of convenience for implementors.) Nico -- --bcaec5016695bd320304a1396e50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 18, 2011 4:13 PM, "Martin Rex" <mrex@sap.com> wrote:
> I am not convinced that it is sensible to define this, because the
> "correct" answer is context sensitive and even there potenti= ally debatable.
> As I said, I implemented the answer to this question twice, the answer= s
> differ, and I don't feel a need to change either implementation.

I understand the desire to avoid changing either implementation that you= have.=C2=A0 A reasonable compromise would be to say that this I-D document= s a historically available function and to pick one behavior as RECOMMENDED= (SHOULD) instead of REQUIRED.

I would much prefer REQUIREing a single behavior though.

Similay regarding memcmp() vs decoding the arcs and properly implementin= g an OID collation.=C2=A0 I understand it's much simpler to memcmp()...= =C2=A0 I'd rather we have a REQUIRED behavior, but in a pinch will sett= le for RECOMMENDED -- after all, we can all write autoconf macros, but sure= ly we all hate having to!=C2=A0 (Dont't forget, it's the apps devel= opers who will have to put up with choices of convenience for implementors.= )

Nico
--

--bcaec5016695bd320304a1396e50-- From simon@josefsson.org Mon Apr 18 23:39:56 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CCCBE068B for ; Mon, 18 Apr 2011 23:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oC4e9VvZf4vb for ; Mon, 18 Apr 2011 23:39:55 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfc.amsl.com (Postfix) with ESMTP id 74589E0680 for ; Mon, 18 Apr 2011 23:39:55 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3J6diHD025842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Apr 2011 08:39:49 +0200 From: Simon Josefsson To: mrex@sap.com References: <87bp03v6qp.fsf@latte.josefsson.org> <201104182013.p3IKDHbn018482__17396.3698129684$1303157612$gmane$org@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110419:kitten@ietf.org::RuHC4kkhhgEqia+n:CSjd X-Hashcash: 1:22:110419:mrex@sap.com::d++Fl0jtp+0QvfCc:q8vX Date: Tue, 19 Apr 2011 08:39:43 +0200 In-Reply-To: <201104182013.p3IKDHbn018482__17396.3698129684$1303157612$gmane$org@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 18 Apr 2011 22:13:17 +0200 (MEST)") Message-ID: <87tyduu4ls.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 06:39:56 -0000 Martin Rex writes: > I am not convinced that it is sensible to define this, because the > "correct" answer is context sensitive and even there potentially debatable. > As I said, I implemented the answer to this question twice, the answers > differ, and I don't feel a need to change either implementation. You don't have to -- presumably you didn't call your function gss_oid_equal and exported it. (Which implementation is this, btw? Is it possible to evaluate it?) If the application needs to do some comparison itself in order to get a well-defined result, I'd almost rather have it do all comparison (and don't standardize this function) than having a standard function that doesn't have well-defined meaning. /Simon From ghudson@mit.edu Tue Apr 19 08:59:20 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C8AAE06F8 for ; Tue, 19 Apr 2011 08:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chf6CTH1cFdw for ; Tue, 19 Apr 2011 08:59:19 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfc.amsl.com (Postfix) with ESMTP id 5983EE07A3 for ; Tue, 19 Apr 2011 08:59:11 -0700 (PDT) X-AuditID: 1209190e-b7c80ae0000047dd-f2-4dadb155109d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 29.99.18397.551BDAD4; Tue, 19 Apr 2011 11:59:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p3JFx9iN019749; Tue, 19 Apr 2011 11:59:09 -0400 Received: from [18.111.99.23] ([18.111.99.23]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p3JFx6Nj012953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Apr 2011 11:59:09 -0400 (EDT) From: Greg Hudson To: Simon Josefsson In-Reply-To: <87tyduu4ls.fsf@latte.josefsson.org> References: <87bp03v6qp.fsf@latte.josefsson.org> <201104182013.p3IKDHbn018482__17396.3698129684$1303157612$gmane$org@fs4113.wdf.sap.corp> <87tyduu4ls.fsf@latte.josefsson.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 19 Apr 2011 11:59:06 -0400 Message-ID: <1303228746.2235.7.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1g3duNbXYMJ6LYujm1exWNzbcond gcljyZKfTB4zz1xkD2CK4rJJSc3JLEst0rdL4MqY+DmgYA1rxfVpZQ2Ma1i6GDk5JARMJL72 v2CEsMUkLtxbz9bFyMUhJLCPUaJv3TRWCGcDo8SrO7NZIJyNTBIrX/wBauHgEBYwlThzA6yb TUBZ4uDZbywgYREBTYm57RkgYWYBdYmjz5vYQGxOAUOJ3gs7oBZsYZT4/eA7E0SRpkTr9t/s IDaLgKrEn/snwa7jFdCS6Lzdwwwyk1dAUOLvDmGIQ6Ulvk54AtUqL7H97RzmCYyCs5BMmoXQ MQtJ1QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBgSvJt4Px60GlQ4wC HIxKPLx316z1FWJNLCuuzD3EKMnBpCTKy7ceKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV2QZ UI43JbGyKrUoHyYlzcGiJM47U1LdV0ggPbEkNTs1tSC1CCYrw8GhJMF7aANQo2BRanpqRVpm TglCmomDE2Q4D9Dw8FUgw4sLEnOLM9Mh8qcYjTkmfn6zj5Gj6ef7fYxCLHn5ealS4rxTQcYJ gJRmlObBTYMln1eM4kDPCfNuAKniASYuuHmvgFYxAa2KtVkDsqokESEl1cA4v/9ri/Y3jUmx X/MjvMyCVDbINViGhThe+3LC4LGqjPn32LUPj5+z7BT8qX1ppcJ525b0JT0L6s8KKL4rivqT cyLDcennMG673bsMrpzY+HKO4bswcbPqbf9ajyscV1TidHJmluEq8PcK/Nmy0zXvqv90dsOJ kuuTXQ/zlVlMWasRN1/8UqUSS3FGoqEWc1FxIgDtYkPlGQMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 15:59:20 -0000 On Tue, 2011-04-19 at 02:39 -0400, Simon Josefsson wrote: > If the application needs to do some comparison itself in order to get a > well-defined result, I'd almost rather have it do all comparison (and > don't standardize this function) than having a standard function that > doesn't have well-defined meaning. I agree with Simon. If there are multiple shipping GSSAPI implementations with exported symbols named gss_oid_equal() with different behaviors, then we should pick a new name. If there aren't, we should go with the behavior in Heimdal/Gnu GSS. Either way, the behavior should be fully specified if the arguments are valid OID values or GSS_C_NO_OID. From mrex@sap.com Tue Apr 19 09:48:41 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 91ECAE07F0 for ; Tue, 19 Apr 2011 09:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.384 X-Spam-Level: X-Spam-Status: No, score=-9.384 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3DUI-0mw9qX for ; Tue, 19 Apr 2011 09:48:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 0EE62E07B2 for ; Tue, 19 Apr 2011 09:48:39 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3JGmbIl024625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Apr 2011 18:48:37 +0200 (MEST) From: Martin Rex Message-Id: <201104191648.p3JGmbYP029983@fs4113.wdf.sap.corp> To: nico103@gmail.com (Nico Williams) Date: Tue, 19 Apr 2011 18:48:37 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 18, 11 05:59:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, simon@josefsson.org Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 16:48:41 -0000 Nico Williams wrote: > > On Apr 18, 2011 4:13 PM, "Martin Rex" wrote: > > I am not convinced that it is sensible to define this, because the > > "correct" answer is context sensitive and even there potentially > > debatable. > > As I said, I implemented the answer to this question twice, the answers > > differ, and I don't feel a need to change either implementation. > > I understand the desire to avoid changing either implementation that you > have. A reasonable compromise would be to say that this I-D documents a > historically available function and to pick one behavior as RECOMMENDED > (SHOULD) instead of REQUIRED. > > I would much prefer REQUIREing a single behavior though. I think I'm OK with this proposal picking a particular implementation choice and REQUREing that. Personally, I do hate the "undefined" behaviour with several ISO-C calls as shipped by several vendors. e.g. there are platforms crashing on strncpy(valid dest, NULL, 0) memcpy(valid dest, NULL, 0) sprintf(valid buffer, "%.*s", 0, NULL) although they actually MUST not crash on this, because dereferencing any of the source pointer would be accessing contents of an array outside of the array boundaries, which ISO-C clearly prohibits. However, I would really appreciate a guidance that callers of gss_compare_oid() must decide in a context-specific fashion, whether the answer this function provides if at least one of the arguments is a NULL OID is appropriate/correct in the given situation. In many situations, an explicit error handling might be more appropriate. -Martin From simon@josefsson.org Wed Apr 20 03:18:42 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D01BFE06CD for ; Wed, 20 Apr 2011 03:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx3kzPXdPS1p for ; Wed, 20 Apr 2011 03:18:42 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfc.amsl.com (Postfix) with ESMTP id 679C8E0682 for ; Wed, 20 Apr 2011 03:18:40 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p3KAIT16006413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Apr 2011 12:18:31 +0200 From: Simon Josefsson To: mrex@sap.com References: <201104191648.p3JGmbYP029983__48691.7257578627$1303231892$gmane$org@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110420:nico103@gmail.com::t1pd5nj9JwuWajjN:2+0u X-Hashcash: 1:22:110420:kitten@ietf.org::9bNMDqi+3Q4eB3jE:3jV7 X-Hashcash: 1:22:110420:mrex@sap.com::d5vnVZm42N9ZgHnQ:679r Date: Wed, 20 Apr 2011 12:18:29 +0200 In-Reply-To: <201104191648.p3JGmbYP029983__48691.7257578627$1303231892$gmane$org@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 19 Apr 2011 18:48:37 +0200 (MEST)") Message-ID: <87hb9tp6oa.fsf@latte.josefsson.org> User-Agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, Nico Williams Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 10:18:42 -0000 Martin Rex writes: > However, I would really appreciate a guidance that callers of > gss_compare_oid() must decide in a context-specific fashion, > whether the answer this function provides if at least one of the > arguments is a NULL OID is appropriate/correct in the given situation. What kind of text are you looking for? The document now says that GSS_C_NO_OID does not compare positively to itself or anything else. Is that not sufficient? Perhaps it is easier to move forward by considering some concrete text that you would like to see added. > In many situations, an explicit error handling might be more appropriate. To me that means every caller has to work harder to use the interface. /Simon From mrex@sap.com Thu Apr 21 09:48:34 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D7832E073A for ; Thu, 21 Apr 2011 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHs31qctgqeY for ; Thu, 21 Apr 2011 09:48:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfc.amsl.com (Postfix) with ESMTP id 14DD5E06AF for ; Thu, 21 Apr 2011 09:48:33 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3LGmUsf006157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2011 18:48:30 +0200 (MEST) From: Martin Rex Message-Id: <201104211648.p3LGmUmR014704@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Thu, 21 Apr 2011 18:48:30 +0200 (MEST) In-Reply-To: <87hb9tp6oa.fsf@latte.josefsson.org> from "Simon Josefsson" at Apr 20, 11 12:18:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org, nico103@gmail.com Subject: Re: [kitten] gss_oid_equal and null equality X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:48:35 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > > However, I would really appreciate a guidance that callers of > > gss_compare_oid() must decide in a context-specific fashion, > > whether the answer this function provides if at least one of the > > arguments is a NULL OID is appropriate/correct in the given situation. > > What kind of text are you looking for? The document now says that > GSS_C_NO_OID does not compare positively to itself or anything else. Is > that not sufficient? Perhaps it is easier to move forward by > considering some concrete text that you would like to see added. OK, I'll try to come up with some text. > > > In many situations, an explicit error handling might be more appropriate. > > To me that means every caller has to work harder to use the interface. Nope. The functionality itself is sufficiently trivial that similar to any of the oid_set call *I* would never attempty trying to call an external library for them. And if the external library doesn't provide them, because these are new and optional calls, your code will have to provide them itself anyway. GSS_C_NO_OID is *undefined* for mechanism OIDs as inputs, and means "no OID returned" on output. For nametype OIDs, GSS_C_NO_OID indicates a "request for default" on input, while on output it also means "no OID returned" -- it does not mean "default nametype" on output! So the situation that one is comparing OIDs where one is a GSS_C_NO_OID does not really make operational sense. And when you want to explicitly compare some OID to GSS_C_NO_OID, the currently specified behaviour gss_compare_oid(GSS_C_NO_OID,GSS_C_NO_OID)==FALSE precludes that -- the caller will have to special case this to clearly recognize this situation. -Martin From hartmans@mit.edu Fri Apr 22 04:52:39 2011 Return-Path: X-Original-To: kitten@ietfc.amsl.com Delivered-To: kitten@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E849AE06B1 for ; Fri, 22 Apr 2011 04:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.698 X-Spam-Level: X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dslsr-VppI0e for ; Fri, 22 Apr 2011 04:52:39 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 97C78E0664 for ; Fri, 22 Apr 2011 04:52:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 42C5620239; Fri, 22 Apr 2011 07:49:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0C8624541; Fri, 22 Apr 2011 07:52:34 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <4D6DFA7C.1080401__858.060739892785$1299053205$gmane$org@oracle.com> <87wrkhbybl.fsf@latte.josefsson.org> <87fwr3kkq0.fsf__30668.2908013046$1299249964$gmane$org@latte.josefsson.org> <87wriw7rlj.fsf_-_@latte.josefsson.org> Date: Fri, 22 Apr 2011 07:52:34 -0400 In-Reply-To: <87wriw7rlj.fsf_-_@latte.josefsson.org> (Simon Josefsson's message of "Thu, 14 Apr 2011 17:58:00 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] GFD.24 and draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 11:52:40 -0000 I strongly support the adoption of Simon's text or similar text in naming extensions. From nico@cryptonector.com Tue Apr 26 12:51:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9BDE0767 for ; Tue, 26 Apr 2011 12:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3i3PYE5oTyw for ; Tue, 26 Apr 2011 12:51:45 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADA0E0763 for ; Tue, 26 Apr 2011 12:51:45 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 106B1778070 for ; Tue, 26 Apr 2011 12:51:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=bYlwzqU1dDG8q0gTTqQhPlYm+eDywj8LVoZEa8PNIolJ JsPNNUT40zcDMRCHbZpXinB4rHKaQ+IoLx05JDWIkzyfice/TWmNWnQbcNCZIZOA eaqvnJhaiS29CgoIMhaEQPOKguzE8LwA+hhgFyfGmAs7tM8SkcXh5V44M6kZpFk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=GaWwNYCcdwPaD4cXia+blOUdsXs=; b=wO/j/2YNuce AXq8m5FyIIupAZLmyBgav2Dorelq0eGRyjtZLQYNrCcYuXwZUF3KxJSHHO1uZprz 5bYUdZlHgeeR+jo33GN1OIPiABRm+KO/3ESWL6XTYgBNpwKJbbmrYezXKCeTXeOW PG+tNB8upNIUf6W/tCcYc91iOTAQs1o4= Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 8F59D77806E for ; Tue, 26 Apr 2011 12:51:44 -0700 (PDT) Received: by wwa36 with SMTP id 36so754905wwa.13 for ; Tue, 26 Apr 2011 12:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.197.168 with SMTP id t40mr1202589wen.55.1303847503152; Tue, 26 Apr 2011 12:51:43 -0700 (PDT) Received: by 10.216.36.9 with HTTP; Tue, 26 Apr 2011 12:51:43 -0700 (PDT) Date: Tue, 26 Apr 2011 14:51:43 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 19:51:46 -0000 I've been looking for ways to minimize the need to have replay caching of AP-REQs/Authenticators in the Kerberos V5 mechanism. I've come up with a few methods that generalize (there are other mechanism designs which might require replay caching). Here's one based on the fact that most GSS-API applications do not make use of PROT_READY _and_ have the initiator send the first per-message token: - Add a req_flag named GSS_C_PROT_READY_NOT_USED, to be used by initiator applications that know they will not make use of PROT_READY. - [OPTIONAL] Add a supplementary major status code GSS_S_PROT_READY_USED to be returned by GSS_Unwrap() and GSS_VerifyMIC(). How it works: - Raw Kerberos implementations should reject AP-REQs whose Authenticators' checksum fields have a "checksum" of type 0x8003 which appears to have the GSS_C_PROT_READY_NOT_USED flag set. This prevents cut-n-paste attacks that steal AP-REQs from initial context tokens for the krb5 mech and play them to raw krb5 apps. - krb5 mech acceptors will delay use of a replay cache such that if the initiator's first per-message token uses the acceptor-asserted sub-session key, then the replay cache will not be used at all, else it will be. (The acceptor has to be sure that the first per-message token received has the expected initial sequence number. Also, it may be possible to allow PROT_READY MIC tokens and still avoid the need for a replay cache, but this needs careful analysis.) - [OPTIONAL] Applications that expect the peer to not use PROT_READY should check for and react accordingly (e.g., terminate the connection) to the presence of the GSS_S_PROT_READY_USED supplementary status code in major status values returned by GSS_Unwrap() and GSS_VerifyMIC(). The Kerberos V5 mechanism can make this work reliably only when using RFC4121 (i.e., newer enctypes), since use of the acceptor's sub-key is critical to preventing replays. Existing GSS applications that *do* make use of PROT_READY will be affected IFF we include the supplementary code mentioned above and they are coded to not accept per-message tokens which yielded GSS_S_COMPLETE and a supplementary status code. I suspect that there are not very many such applications, and, indeed, I believe there ought to be none since applications should check for supplementary status codes. I think it's reasonable to believe that supplementary status codes were intended to be non-critical and to allow for future additions, though this is debatable, and I look forward to hearing your opinions on this, and am open to being convinced of the opposite (particularly since a new supplementary status code is not strictly necessary). Deployment on systems that have multiple Kerberos implementations may be difficult, since it is critical to first deploy the change that prevents cut-n-paste attacks on systems that use GSS and raw krb5 for the same acceptor/service principals. However, I believe it may still be worthwhile. Also, note that this extension generalizes to other mechanisms. Consider Solaris' mech_dh, for example. mech_dh uses DH public keys published in a directory to obtain a shared secret key before any tokens have even been exchanged -- a design that lends itself quite well to the same 1/2 and 1 round-trip options that Kerberos V5 offers, and which too would require replay caching when those 1/2 and 1 round-trip options are used. The mech_dh design also can avoid replay caching by using "DCE style" 3/2 round-trip security token exchanges, like the Kerberos V5 mechanism. Extensions to negotiate the use of 3/2 round-trips are another avenue for replay cache avoidance, and I have a proposal to make along those lines, but it has the problematic feature of requiring that the KDC know whether a service is able to use such an extension. I do believe that it is possible to build very high-performance, secure replay caches by making certain trade-offs regarding maximum allowable client clock skew into the future, and by reducing the maximum allowable client clock skew into the past after reboots. Indeed, I have implemented such a thing. And yet I believe it would be simpler and better if we just avoid replay caches altogether. I would very much like to explore replay cache avoidance. Comments? Nico -- From lukeh@padl.com Tue Apr 26 13:41:42 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5FE0813 for ; Tue, 26 Apr 2011 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIPyKaaRWupJ for ; Tue, 26 Apr 2011 13:41:41 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id AB381E06A6 for ; Tue, 26 Apr 2011 13:41:41 -0700 (PDT) Received: by us.padl.com with ESMTP id p3QKf4bA019702; Tue, 26 Apr 2011 16:41:38 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 26 Apr 2011 22:41:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 20:41:42 -0000 > The mech_dh design also can avoid replay caching by using "DCE style" > 3/2 round-trip security token exchanges, like the Kerberos V5 > mechanism. Extensions to negotiate the use of 3/2 round-trips are > another avenue for replay cache avoidance, and I have a proposal to > make along those lines, but it has the problematic feature of > requiring that the KDC know whether a service is able to use such an > extension. I didn't read through this all in detail so please excuse the possibly = dumb question. Why does the KDC need to know if DCE_STYLE is available? The initiator could try (and fallback to non-DCE style) or another OID = could be used and it negotiated via SPNEGO. -- Luke= From nico@cryptonector.com Tue Apr 26 14:13:38 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD3E07FC for ; Tue, 26 Apr 2011 14:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dexGuVBmcBQu for ; Tue, 26 Apr 2011 14:13:37 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id B9455E076F for ; Tue, 26 Apr 2011 14:13:37 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 5D355678063 for ; Tue, 26 Apr 2011 14:13:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=gl1kFVBu8gmv+j0YNn7zvjHoKTj79gBc6n1uBD8au5XE GIbPTXYQ4lHA7+CbIAZA619A+isvj3RTHgOljKIQxf4HgWOk1q6YP1tAzXBiM6Tj qHwbU4/dYqyl4AgBhOfh+VLPBIQISUP3OqmeuS+FfiuaZl5z96q3RJ4ncLPebSg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=M3la+0yLAO/BaiDUYAYI7y2gYCc=; b=bEPK5VcywgS oSXbkz+jDVJIsBUAQHod5cqOmcRigII1kYUGkwy9ymTr9usgwBiu8Eimrqg4YNnf /jTT/BSAEkqX9n/NYTf527Da44+2IQ+L9kA+rsj+9QSrpcnqhsrBYsoJpQsFQ7UB Oqm7dLQahNTLpBeccVqWG4MxAi4Ph/Y8= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 1C387678083 for ; Tue, 26 Apr 2011 14:13:36 -0700 (PDT) Received: by vxg33 with SMTP id 33so924536vxg.31 for ; Tue, 26 Apr 2011 14:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.108.233 with SMTP id hn9mr1858132vdb.249.1303852416336; Tue, 26 Apr 2011 14:13:36 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Tue, 26 Apr 2011 14:13:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 16:13:36 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:13:38 -0000 On Tue, Apr 26, 2011 at 3:41 PM, Luke Howard wrote: >> The mech_dh design also can avoid replay caching by using "DCE style" >> 3/2 round-trip security token exchanges, like the Kerberos V5 >> mechanism. =C2=A0Extensions to negotiate the use of 3/2 round-trips are >> another avenue for replay cache avoidance, and I have a proposal to >> make along those lines, but it has the problematic feature of >> requiring that the KDC know whether a service is able to use such an >> extension. > > I didn't read through this all in detail so please excuse the possibly du= mb question. Why does the KDC need to know if DCE_STYLE is available? Great question. Maybe I misunderstand DCE style (I hope so!), but IIUC: there's no way for the acceptor to indicate that it understood the initiator's request to engage in DCE style, so there's no way for the initiator to know if the acceptor will be expecting one more context token or not. > The initiator could try (and fallback to non-DCE style) or another OID co= uld be used and it negotiated via SPNEGO. Another OID has the same problem, only worse. As for SPNEGO, if the app protocol in question wasn't already using it, then you have the same problem as with a new OID. Now, DCE style would always remove the need for a replay cache. My solution doesn't always eliminate the rcache, just often (i.e., when using AES) and for most apps, hopefully often enough -- and without negotiation. There is an acceptor-side local configuration issue in my proposal: the acceptor must not skip the rcache unless configured to because other raw krb5 apps also implement the check I mentioned. Nico -- From nico@cryptonector.com Tue Apr 26 14:41:21 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1FE078F for ; Tue, 26 Apr 2011 14:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZgZa40IfsK8 for ; Tue, 26 Apr 2011 14:41:19 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id CC919E0780 for ; Tue, 26 Apr 2011 14:41:19 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id AC720678062 for ; Tue, 26 Apr 2011 14:41:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=dAUX9kUssm/ijdu2vFeW1 aXObmdoisS4pzZgSFyJIC3yZKdlebDRbFguC8uauUoaZS58mokNWRAaLJPCgSn31 QtORdFR9Tv+Qc6H1+V55yO2/HFep87M3FMotyLpzcPrEZ1RQ2wRTktrNd6j0SOBy nQDkLYa2MZ7PuJLW50atbA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=dw5LDsC+iJm8pXytpAfyJwc Qb6M=; b=lFF/sv5sUI9LSDmEBG8KO0wTrlAavPIF2j62Rd//UJRj6o6tTTk4zKs FxWIZJ5qEiekc4C6FYKo2He5CUE7P7Z+1ziMTkSjagUq7Y9sO6F/J0hHzzvfMODu 2hXWI3gUlrCs426CrSbMEmDalCQ87woQGcwbzqU7sWMMoeUdoqnI= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 64797678057 for ; Tue, 26 Apr 2011 14:41:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so944186vxg.31 for ; Tue, 26 Apr 2011 14:41:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.72.103 with SMTP id c7mr317018vdv.89.1303854068392; Tue, 26 Apr 2011 14:41:08 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Tue, 26 Apr 2011 14:41:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Apr 2011 16:41:08 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:41:21 -0000 My proposal does have a flaw for apps that use neither channel binding nor per-message tokens. But then, such apps should not exist, as they are not secure. I'm willing to live with that as an acceptor-side configuration parameter. From mrex@sap.com Tue Apr 26 16:25:22 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4026CE07A3 for ; Tue, 26 Apr 2011 16:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.943 X-Spam-Level: X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b49r9oL746aw for ; Tue, 26 Apr 2011 16:25:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 73106E06AA for ; Tue, 26 Apr 2011 16:25:21 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p3QNPG0h027085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Apr 2011 01:25:16 +0200 (MEST) From: Martin Rex Message-Id: <201104262325.p3QNPGJu015439@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Wed, 27 Apr 2011 01:25:15 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 26, 11 04:41:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 23:25:22 -0000 Nico Williams wrote: > > My proposal does have a flaw for apps that use neither channel binding > nor per-message tokens. But then, such apps should not exist, as they > are not secure. I'm willing to live with that as an acceptor-side > configuration parameter. Those apps do exist. They're implementations of rfc-4559 "HTTP Negotiate", prior to the use of channel bindings. I don't know whether TLS channel bindings for rfc-4559 were retrofitted into Kerberos&SChannel&MSIE for Windows XP. If not, then it about 50% of the installed base doing this (all versions of MSIE on XP). Your scheme also does not work for apps that (for whatever reason) do not request MUTUAL_AUTH at the GSS-API level--which results in a 1-token security context establishment equivalent to PROT_READY, and with the same app-side rationale as for using PROT_READY. An initiator is not limited to sending only a single protected message with PROT_READY. It could transfer millions of protected messages before processing the context token response from the server. -Martin From nico@cryptonector.com Tue Apr 26 18:46:36 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C125E06AE for ; Tue, 26 Apr 2011 18:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QzcV6ZX++74 for ; Tue, 26 Apr 2011 18:46:35 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 43373E0680 for ; Tue, 26 Apr 2011 18:46:35 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 121EB350072 for ; Tue, 26 Apr 2011 18:46:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=tJL35JlyuPXdYxQml1FkxmRU/J16if9QDCpH93nbdsUX 0D9NiQrKTFNyJyXuuj0cbGH1epFlLc02n5rrVr9f70tCDK9jcJHQY+1uweWJHKIb xhcFxOCdbhtLn/1x7oba+a2grE5oc6MqfhCHz7IkcG+NZsBuf6B8yZLJGIQEDlE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=QYShh3gQQ82D0owjGqYr7e/oHEc=; b=Dz2siWDhPCf mQye+napNccq70+QcoEjio6g+Wn3N/Aq1DzKz0hx1WYIfByC3PzHbdtgFhhsyPBT wZXNlWPe6EvKRQFnVLGQv60mLAn7nt0OQF1MCOqtCDchLN26VnUZcTO548XdyaPe G6bCJFE4y8JApSfgSifvwbWLJAajKLUE= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id E2259350063 for ; Tue, 26 Apr 2011 18:46:34 -0700 (PDT) Received: by vxg33 with SMTP id 33so1081700vxg.31 for ; Tue, 26 Apr 2011 18:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.164 with SMTP id m4mr2242150vdv.169.1303868794180; Tue, 26 Apr 2011 18:46:34 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Tue, 26 Apr 2011 18:46:34 -0700 (PDT) In-Reply-To: <201104262325.p3QNPGJu015439@fs4113.wdf.sap.corp> References: <201104262325.p3QNPGJu015439@fs4113.wdf.sap.corp> Date: Tue, 26 Apr 2011 20:46:34 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 01:46:36 -0000 On Tue, Apr 26, 2011 at 6:25 PM, Martin Rex wrote: > Nico Williams wrote: >> My proposal does have a flaw for apps that use neither channel binding >> nor per-message tokens. =C2=A0But then, such apps should not exist, as t= hey >> are not secure. =C2=A0I'm willing to live with that as an acceptor-side >> configuration parameter. > > Those apps do exist. =C2=A0They're implementations of rfc-4559 > "HTTP Negotiate", prior to the use of channel bindings. Not really. Prior to CB HTTP/Negotiate did not do mutual auth, so replay caches are unavoidable. And if using CB then we have to use a replay cache too (because we don't know if the CB type is tls-unique or something else that isn't unique). (Also, because HTTP/Negotiate uses the "HTTP" service name one could always hardcode or configure the acceptor to always use a replay cache for HTTP.) To avoid replay caching in protocols that use CB really does require a 3-legged security context token exchange (or longer). > Your scheme also does not work for apps that (for whatever reason) > do not request MUTUAL_AUTH at the GSS-API level--which results > in a 1-token security context establishment equivalent to PROT_READY, > and with the same app-side rationale as for using PROT_READY. I know I didn't mention non-mutual auth apps, but I figured it'd be clear that the replay cache is not avoidable in those. I'm trying to avoid replay caches in a common sub-set of cases, not all. (Though I'd rather never have to use a replay cache either -- don't get me wrong. It's just that it's not possible to avoid a replay cache and have a 1/2 round-trip sec context token exchange. > An initiator is not limited to sending only a single protected message > with PROT_READY. =C2=A0It could transfer millions of protected messages > before processing the context token response from the server. Of course. But if the initiator's first per-message token (by sequence number!) is not a PROT_READY token then it can act as the confirmation of the acceptor's sub-session key -- that's the trick. Nico -- From hartmans@mit.edu Thu Apr 28 08:03:07 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76163E070A for ; Thu, 28 Apr 2011 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.432 X-Spam-Level: X-Spam-Status: No, score=-104.432 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTwKMI1zSrgO for ; Thu, 28 Apr 2011 08:03:07 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0B43FE070C for ; Thu, 28 Apr 2011 08:03:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E3833203B1; Thu, 28 Apr 2011 10:59:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9E3974792; Thu, 28 Apr 2011 11:03:00 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Thu, 28 Apr 2011 11:03:00 -0400 In-Reply-To: (Nico Williams's message of "Tue, 26 Apr 2011 14:51:43 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:03:07 -0000 How well does this work for mechanisms like GS2 that never send a per-message token? From hartmans@mit.edu Thu Apr 28 08:22:49 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E862EE069F for ; Thu, 28 Apr 2011 08:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nL-zHwkocNjz for ; Thu, 28 Apr 2011 08:22:49 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 775D6E0670 for ; Thu, 28 Apr 2011 08:22:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 98BB920265; Thu, 28 Apr 2011 11:19:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 51D844792; Thu, 28 Apr 2011 11:22:45 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <201104262325.p3QNPGJu015439@fs4113.wdf.sap.corp> Date: Thu, 28 Apr 2011 11:22:45 -0400 In-Reply-To: (Nico Williams's message of "Tue, 26 Apr 2011 20:46:34 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:22:50 -0000 Note that in practice no one actually uses replay caches for HTTP. Make what you will of the security. (Well IIS may, although I doubt it, but no one else does.) From nico@cryptonector.com Thu Apr 28 08:31:11 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9C5E06E4 for ; Thu, 28 Apr 2011 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ15GmgdPP-o for ; Thu, 28 Apr 2011 08:31:10 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id BCA21E0685 for ; Thu, 28 Apr 2011 08:31:10 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 580FD202022 for ; Thu, 28 Apr 2011 08:31:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Q2EiRO9nKn7AoypKoujdz Ecfvz65iO7CfVcSyV5IZfPcRJa13nvu1qWthcpr4AEE1PNds359ebYxDga9QUvI5 vtRMtTfvwsraDEZCPkyf+R7nH+j1wgmQqhBGzodWM6XPN3jlfnFm9BlH1OOrlwqV KAKHbYR64klGBHUdBEDeyw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=47b5lIySD/BItP3Q7F8U OWTeM50=; b=j1OS8bDWvskGBeJLKewYmDhBO/E2McwqHc8mFHCoKNI8JPxS5OMq dzGoWMAhGoz1Y65H0FLpqBbaec9tK8oYMbSFYKW6M83I8ytytoe7f3facDZDv59n Y4jc8RNcLl868wdzayTfMU30jiJpWuDgCNv44MdWZrKK9W0Xed5aW5Q= Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id CEB4C202018 for ; Thu, 28 Apr 2011 08:31:09 -0700 (PDT) Received: by wwa36 with SMTP id 36so2202692wwa.13 for ; Thu, 28 Apr 2011 08:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.157.146 with SMTP id o18mr3463854wek.109.1304004668315; Thu, 28 Apr 2011 08:31:08 -0700 (PDT) Received: by 10.216.241.200 with HTTP; Thu, 28 Apr 2011 08:31:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Apr 2011 10:31:08 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:31:11 -0000 On Thu, Apr 28, 2011 at 10:03 AM, Sam Hartman wrote: > How well does this work for mechanisms like GS2 that never send a > per-message token? As I initially proposed, it doesn't. If we add some API by which the acceptor app can tell GSS that this protocol doesn't need a replay cache, that might be a lot better. I was trying to avoid having to add new functions, but it seems unavoidable. From nico@cryptonector.com Thu Apr 28 09:39:39 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798AFE0698 for ; Thu, 28 Apr 2011 09:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEwmaYJQ0tAC for ; Thu, 28 Apr 2011 09:39:39 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 52C18E0669 for ; Thu, 28 Apr 2011 09:39:39 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id F1657584058 for ; Thu, 28 Apr 2011 09:39:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=QwnyAXwb/M6cu1eHC+VdllzGRXrGv1jX2/uV+z19MStx QLBgsKUdRol+utTC9qrKq79rXokVa+vwPxWEhLI1he9CLphwAmqK1ZzJKlXiNo6J ulpcaOswCYTcuSIEYdeSaGoQuTVV6FXJSpgLnPj8XFKETXJuUV/Ds0STL36j1PM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=8faNT+eJtthWr7wJJf/BFJw89gs=; b=QvGbF5lXxe7 3ijt9SuMt8FX0UHCi/oM3Voj9rgtQv04DlPrVbIs4zjqnN1+cktJ+zjJjUPWjsqZ jnlkVEJXIAlHwc4lpuxI1IH2SpB/5MIzMCqJSxKY/isPgyHWrrQW+0kvbm9BT6Nd SAipSuhhlRcsmB36z0l6fcIIau7KFZZ4= Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id A479D584057 for ; Thu, 28 Apr 2011 09:39:38 -0700 (PDT) Received: by wwa36 with SMTP id 36so2260167wwa.13 for ; Thu, 28 Apr 2011 09:39:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.22.79 with SMTP id s57mr7452047wes.94.1304008777420; Thu, 28 Apr 2011 09:39:37 -0700 (PDT) Received: by 10.216.241.200 with HTTP; Thu, 28 Apr 2011 09:39:37 -0700 (PDT) Date: Thu, 28 Apr 2011 11:39:37 -0500 Message-ID: From: Nico Williams To: kitten@ietf.org, ietf-krb-wg@anl.gov Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:39:39 -0000 I see two ways to negotiate DCE style (3-legged AP exchange): a) the KDC knows whether the service supports it and announces it to the client via a ticket option (which, incidentally, gets recorded in ccaches, which is very nice); b) the initiator sets a flag in the authenticator (either as a GSS flag or as an authz-data element, since we can't use auth-options, since that's not authenticated) and if the acceptor understands it then it will respond with a new form of AP-REP (mainly in that there would be new fields in the enc part), and if not, well, then the mech does the standard one round-trip thing. I'm quite partial to (b), actually. I don't really like the idea that the KDC has to know about specific features supported by a principal. Nico -- From metze@samba.org Thu Apr 28 11:48:29 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CCCE06A8 for ; Thu, 28 Apr 2011 11:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtyBBDBTNf0O for ; Thu, 28 Apr 2011 11:48:28 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 101BBE0670 for ; Thu, 28 Apr 2011 11:48:27 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.9] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (jimi mo48) (RZmta 25.17) with ESMTPA id R00407n3SIINHS ; Thu, 28 Apr 2011 20:48:19 +0200 (MEST) Message-ID: <4DB9B66F.1060209@samba.org> Date: Thu, 28 Apr 2011 20:48:15 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1554A4954E58BA5534B05110" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 18:48:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1554A4954E58BA5534B05110 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nico, > I see two ways to negotiate DCE style (3-legged AP exchange): >=20 > a) the KDC knows whether the service supports it and announces it to > the client via a ticket option (which, incidentally, gets recorded in > ccaches, which is very nice); >=20 > b) the initiator sets a flag in the authenticator (either as a GSS > flag or as an authz-data element, since we can't use auth-options, > since that's not authenticated) and if the acceptor understands it > then it will respond with a new form of AP-REP (mainly in that there > would be new fields in the enc part), and if not, well, then the mech > does the standard one round-trip thing. >=20 > I'm quite partial to (b), actually. I don't really like the idea that > the KDC has to know about specific features supported by a principal. Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_STYL= E) See http://www.ietf.org/rfc/rfc4757.txt. I think there's no reason to redesign this, as it wouldn't be needed at all... metze --------------enig1554A4954E58BA5534B05110 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk25tnAACgkQm70gjA5TCD/XawCfQh9jBHuEJdWYDtn+9WKSNIkP xB8AoJDuQgNI2R4DPmDWAGft/l3sq/Z7 =04Jc -----END PGP SIGNATURE----- --------------enig1554A4954E58BA5534B05110-- From nico@cryptonector.com Thu Apr 28 11:53:08 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B53E06A8 for ; Thu, 28 Apr 2011 11:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YE7sr724HL2W for ; Thu, 28 Apr 2011 11:53:08 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 758D8E0670 for ; Thu, 28 Apr 2011 11:53:08 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 447FC2C806C for ; Thu, 28 Apr 2011 11:53:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=anT0evwy/4v95KqTcVidl zGOUMMrxHVkN+3Z28G70Vv9w2fhur5LN4fgmfATMstWKQBKkvwo6DxNjzgvFLNKJ 6p++LesM4GLFdF8c7v8Dq+JfpKQBuk7Wt/c6Ff8FnWmqnG2v9/Q0ItWyvnHIqK0W eM8Ul6AO98t949W06H55Xg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0/ZLd2bhvPRknjzGN3iT scx7N/w=; b=ordR4RkcDFYhcI7khrvf6C2rHkjmGMUCTBYTY7qlEECsFN2cPRvR YVruSvlLouE1tcYh9sZy/wt7KHlT2YL5SOLBpAoEcmHrIySvhJkZ4A0aldJFENLR 888kek414kiYzDfXYi4vyPl9lU68fy7SCzEAl6Yw072W1Fjz2AK1guk= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 0A1F12C806B for ; Thu, 28 Apr 2011 11:53:07 -0700 (PDT) Received: by vws12 with SMTP id 12so2656726vws.31 for ; Thu, 28 Apr 2011 11:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.116.33 with SMTP id jt1mr3513311vdb.249.1304016787452; Thu, 28 Apr 2011 11:53:07 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Thu, 28 Apr 2011 11:53:07 -0700 (PDT) In-Reply-To: <4DB9B66F.1060209@samba.org> References: <4DB9B66F.1060209@samba.org> Date: Thu, 28 Apr 2011 13:53:07 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 18:53:09 -0000 On Thu, Apr 28, 2011 at 1:48 PM, Stefan (metze) Metzmacher wrote: > Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_STYLE) > > See http://www.ietf.org/rfc/rfc4757.txt. > > I think there's no reason to redesign this, as it wouldn't be needed at > all... RFC4757 does not describe something that's negotiable. If the acceptor doesn't support this flag then things should fail if the initiator tries to use it. From hbhotz@dslextreme.com Thu Apr 28 12:57:27 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F6E071F for ; Thu, 28 Apr 2011 12:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZVP7Tsjz+8D for ; Thu, 28 Apr 2011 12:57:27 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2DE070D for ; Thu, 28 Apr 2011 12:57:27 -0700 (PDT) Received: by pzk5 with SMTP id 5so2244004pzk.31 for ; Thu, 28 Apr 2011 12:57:27 -0700 (PDT) Received: by 10.68.36.234 with SMTP id t10mr3987165pbj.361.1304020646910; Thu, 28 Apr 2011 12:57:26 -0700 (PDT) Received: from dhcp-137-79-176-177.jpl.nasa.gov (dhcp-137-79-176-177.jpl.nasa.gov [137.79.176.177]) by mx.google.com with ESMTPS id m5sm1402556pbh.70.2011.04.28.12.57.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Apr 2011 12:57:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Thu, 28 Apr 2011 12:57:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81A6F68F-66C6-486A-8F66-32C607973E96@oxy.edu> References: <201104262325.p3QNPGJu015439@fs4113.wdf.sap.corp> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Henry B. Hotz" List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 19:57:27 -0000 On Apr 28, 2011, at 8:22 AM, Sam Hartman wrote: > Note that in practice no one actually uses replay caches for HTTP. > Make what you will of the security. > (Well IIS may, although I doubt it, but no one else does.) Always intended to try it. The original reasons for that are supposed = to have been fixed. My fear is that bugs in the replay cache code will = break complex web sites. In other words, it won't work. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From metze@samba.org Thu Apr 28 21:28:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281A3E06AE for ; Thu, 28 Apr 2011 21:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGXQ5+Rr3fI0 for ; Thu, 28 Apr 2011 21:28:54 -0700 (PDT) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.180]) by ietfa.amsl.com (Postfix) with ESMTP id D5C27E062B for ; Thu, 28 Apr 2011 21:28:53 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.9] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (klopstock mo48) (RZmta 25.17) with ESMTPA id R0648fn3T44vkG ; Fri, 29 Apr 2011 06:28:46 +0200 (MEST) Message-ID: <4DBA3E74.7030702@samba.org> Date: Fri, 29 Apr 2011 06:28:36 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <4DB9B66F.1060209@samba.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE874C1B7BD5737BA0A7F1901" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 04:28:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE874C1B7BD5737BA0A7F1901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Nico, > On Thu, Apr 28, 2011 at 1:48 PM, Stefan (metze) Metzmacher > wrote: >> Why are you thinking about that? It's (b) with a GSS flag (GSS_C_DCE_S= TYLE) >> >> See http://www.ietf.org/rfc/rfc4757.txt. >> >> I think there's no reason to redesign this, as it wouldn't be needed a= t >> all... >=20 > RFC4757 does not describe something that's negotiable. If the > acceptor doesn't support this flag then things should fail if the > initiator tries to use it. The acceptor has to support it if implementing DCERPC authtype 16 or offer krb5 via spnego (authtype 9). And it should be used only for DCERPC (and only because existing clients and servers use it). metze --------------enigE874C1B7BD5737BA0A7F1901 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk26PnQACgkQm70gjA5TCD8puACcD3zwabs3QpRBbkmIMLY9WVFG oCUAnR7CrhiCpfBC6GJxMX6Nj9aaXjlC =mS1H -----END PGP SIGNATURE----- --------------enigE874C1B7BD5737BA0A7F1901-- From nico@cryptonector.com Thu Apr 28 22:03:31 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FED4E065B for ; Thu, 28 Apr 2011 22:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHNd3q-LgVFP for ; Thu, 28 Apr 2011 22:03:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6C310E0680 for ; Thu, 28 Apr 2011 22:03:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 24C7A6B0078 for ; Thu, 28 Apr 2011 22:03:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ZBF76ln6WnPwQB5MAefLA GmOYevZagjCVzKDQhD4ozrkyVT8LAKWZry/4MBMu2m/oJhMdknagRflZv3HKF7Mm V4g5a9LCwaSifAQ4YIKcxj6tt38YW4qHRU10T/jEubrZfMO7NSbJdUc5ZiuGMWjv 6PRoBDN1TT4hhQcq38n0k8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4gmZ/rM2SY/yG3ljfJkz VWbO5/8=; b=Epqh+5biN0jTXtSgU61wpid+ly8J9nFXyNNWc15c1OcGz7dFcGeG Krc+yHFf2uUvMfQbR0qFWS/lMv0QKl/Tb8oN9DKA3Y/fvCezTyp3Cl2PM7oqYfTZ fizWVyUJWinOzIWQ2aPzNAkI1Iq468ZedrqSIlIG2NI8rwO6l5q2qFg= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id E8F6A6B0070 for ; Thu, 28 Apr 2011 22:03:26 -0700 (PDT) Received: by vws12 with SMTP id 12so2929780vws.31 for ; Thu, 28 Apr 2011 22:03:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.111.71 with SMTP id ig7mr1258074vdb.209.1304053406286; Thu, 28 Apr 2011 22:03:26 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Thu, 28 Apr 2011 22:03:26 -0700 (PDT) Received: by 10.52.163.71 with HTTP; Thu, 28 Apr 2011 22:03:26 -0700 (PDT) In-Reply-To: <4DBA3E74.7030702@samba.org> References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> Date: Fri, 29 Apr 2011 00:03:26 -0500 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: multipart/alternative; boundary=bcaec547cae10cc30604a2079877 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 05:03:31 -0000 --bcaec547cae10cc30604a2079877 Content-Type: text/plain; charset=UTF-8 On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" wrote: > The acceptor has to support it if implementing DCERPC authtype 16 > or offer krb5 via spnego (authtype 9). And it should be used only for > DCERPC (and only because existing clients and servers use it). Right. I want to use it for other protocols. So a new flag and a AP-REP enc part extension. --bcaec547cae10cc30604a2079877 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" <metze@samba.org> wrote:
> The acceptor has to support it if implementing DCERPC authtype 16
> or offer krb5 via spnego (authtype 9). And it should be used only for<= br> > DCERPC (and only because existing clients and servers use it).

Right. I want to use it for other protocols.=C2=A0 So a new flag and a A= P-REP enc part extension.

--bcaec547cae10cc30604a2079877-- From metze@samba.org Fri Apr 29 00:48:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC53E06B2 for ; Fri, 29 Apr 2011 00:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDTcYLq9Se1H for ; Fri, 29 Apr 2011 00:48:31 -0700 (PDT) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33CE0678 for ; Fri, 29 Apr 2011 00:48:30 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.9] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (fruni mo8) (RZmta 25.17) with ESMTPA id f0669en3T6mYcf ; Fri, 29 Apr 2011 09:48:25 +0200 (MEST) Message-ID: <4DBA6D44.6050604@samba.org> Date: Fri, 29 Apr 2011 09:48:20 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Nico Williams References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C97573A45073846CC898746" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 07:48:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C97573A45073846CC898746 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 29.04.2011 07:03, schrieb Nico Williams: > On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" = > wrote: >> The acceptor has to support it if implementing DCERPC authtype 16 >> or offer krb5 via spnego (authtype 9). And it should be used only for >> DCERPC (and only because existing clients and servers use it). >=20 > Right. I want to use it for other protocols. So a new flag and a AP-RE= P enc > part extension. Why? It just adds complexity for no gain. metze --------------enig3C97573A45073846CC898746 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk26bUQACgkQm70gjA5TCD8BzQCg0JaZbFY9Iya0tcbsjOrtRhda mH0An1RXqcvXQ9TwweN9WYwjzKrbmpnd =w+JF -----END PGP SIGNATURE----- --------------enig3C97573A45073846CC898746-- From lukeh@padl.com Fri Apr 29 01:02:28 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14D6E06B2 for ; Fri, 29 Apr 2011 01:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgey6+ORlJh1 for ; Fri, 29 Apr 2011 01:02:28 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 296C5E0678 for ; Fri, 29 Apr 2011 01:02:28 -0700 (PDT) Received: by us.padl.com with ESMTP id p3T82IFg005383; Fri, 29 Apr 2011 04:02:22 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4DBA6D44.6050604@samba.org> Date: Fri, 29 Apr 2011 10:02:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> <4DBA6D44.6050604@samba.org> To: Stefan (metze) Metzmacher X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 08:02:28 -0000 On 29/04/2011, at 9:48 AM, Stefan (metze) Metzmacher wrote: > Am 29.04.2011 07:03, schrieb Nico Williams: >> On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" = >> wrote: >>> The acceptor has to support it if implementing DCERPC authtype 16 >>> or offer krb5 via spnego (authtype 9). And it should be used only = for >>> DCERPC (and only because existing clients and servers use it). >>=20 >> Right. I want to use it for other protocols. So a new flag and a = AP-REP enc >> part extension. >=20 > Why? It just adds complexity for no gain. You can do away with the replay cache. -- Luke= From metze@samba.org Fri Apr 29 01:10:35 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631FFE064A for ; Fri, 29 Apr 2011 01:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoJ6tQiQahwU for ; Fri, 29 Apr 2011 01:10:35 -0700 (PDT) Received: from mo-p05-ob6.rzone.de (mo-p05-ob6.rzone.de [IPv6:2a01:238:20a:202:53f5::1]) by ietfa.amsl.com (Postfix) with ESMTP id 128F3E06E9 for ; Fri, 29 Apr 2011 01:10:33 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.9] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (jimi mo32) (RZmta 25.17) with ESMTPA id V0733cn3T70du8 ; Fri, 29 Apr 2011 10:10:28 +0200 (MEST) Message-ID: <4DBA7270.9000702@samba.org> Date: Fri, 29 Apr 2011 10:10:24 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Luke Howard References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> <4DBA6D44.6050604@samba.org> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DC734BBECB1797D2B1A8E41" Cc: kitten@ietf.org, ietf-krb-wg@anl.gov Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 08:10:35 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DC734BBECB1797D2B1A8E41 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 29.04.2011 10:02, schrieb Luke Howard: >=20 > On 29/04/2011, at 9:48 AM, Stefan (metze) Metzmacher wrote: >=20 >> Am 29.04.2011 07:03, schrieb Nico Williams: >>> On Apr 28, 2011 11:28 PM, "Stefan (metze) Metzmacher" >>> wrote: >>>> The acceptor has to support it if implementing DCERPC authtype 16 >>>> or offer krb5 via spnego (authtype 9). And it should be used only fo= r >>>> DCERPC (and only because existing clients and servers use it). >>> >>> Right. I want to use it for other protocols. So a new flag and a AP-= REP enc >>> part extension. >> >> Why? It just adds complexity for no gain. >=20 >=20 > You can do away with the replay cache. Can you explain that? In anyway I think the GSS_C_DCE_STYLE flag should not be used, as it also has impact on the PDU encoding. If you need to 3 legs, please add a completely new feature and don't mix it with existing stuff. metze --------------enig2DC734BBECB1797D2B1A8E41 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk26cnAACgkQm70gjA5TCD/dJwCeI35TMTVn/p0zP12qYhxKvLXc UZwAoL7x3I4zjX8JEhJJoPX/czVvgkvj =nwS7 -----END PGP SIGNATURE----- --------------enig2DC734BBECB1797D2B1A8E41-- From ghudson@mit.edu Fri Apr 29 07:06:50 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFF7E0710 for ; Fri, 29 Apr 2011 07:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGS1FsnJXjMz for ; Fri, 29 Apr 2011 07:06:50 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id E81AAE06FC for ; Fri, 29 Apr 2011 07:06:49 -0700 (PDT) X-AuditID: 1209190e-b7c80ae0000047dd-87-4dbac60025f5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 12.81.18397.006CABD4; Fri, 29 Apr 2011 10:06:56 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p3TE6mx2025401; Fri, 29 Apr 2011 10:06:48 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p3TE6iqF006692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Apr 2011 10:06:47 -0400 (EDT) From: Greg Hudson To: "Stefan (metze) Metzmacher" In-Reply-To: <4DBA7270.9000702@samba.org> References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> <4DBA6D44.6050604@samba.org> <4DBA7270.9000702@samba.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 29 Apr 2011 10:06:43 -0400 Message-ID: <1304086003.2034.5.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0WU4tsvX4NkNWYvJJycwWRzdvIrF 4uKynywOzB4n17xl81iy5CeTx9xdfYwBzFFcNimpOZllqUX6dglcGYcX3GMquMVW8fRbO3sD 4ybWLkZODgkBE4nOV/NYIGwxiQv31rN1MXJxCAnsY5TYtGUJO4SzgVHi2YIzUJl7TBJb53Ww gbQIC2hLHDq1AsxmE1CWOHj2G9goEQFDiYtf3zN2MXJwMAvES5zZrggS5hTQlDh47x8zxJzH TBLvX8wHq2cGSrRu/80OYrMIqEqseXQY7DxeAS2J91PPgs3hFRCU+LtDGOJSaYnZPf+YIFrl Jba/ncM8gVFwFpJJsxA6ZiGpWsDIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0 EyMopDkl+XYwfj2odIhRgINRiYdXbslOXyHWxLLiytxDjJIcTEqivPMO7fIV4kvKT6nMSCzO iC8qzUktPsQowcGsJMJ76h1QOW9KYmVValE+TEqag0VJnHempLqvkEB6YklqdmpqQWoRTFaG g0NJgrf8KNBQwaLU9NSKtMycEoQ0EwcnyHAeoOGLQGp4iwsSc4sz0yHypxh1OZatOrufUYgl Lz8vVUqctwWkSACkKKM0D24OLBW9YhQHekuYNw2kigeYxuAmvQJawgS05H4RyAfFJYkIKakG xpTExdnL+1WvPXqq93LGde0XTw8xiyxK13lm2Ttr8/KzzFaBe1O6TfQiptknZHfdO9XWFmqb Yagga8L19JCZvPSDxFVBP3mUmqq2td74XJb9fm580c+newWqq7YJ7mg++iRZRKpRgtsuOetn S1isgQZ3iH/uOhufOSaLjvyb/vvc3LMv5WtslViKMxINtZiLihMBPGVpFiADAAA= Cc: "kitten@ietf.org" , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:06:50 -0000 On Fri, 2011-04-29 at 04:10 -0400, Stefan (metze) Metzmacher wrote: > > You can do away with the replay cache. > > Can you explain that? The first client->server leg of the exchange establishes the client identity, but could be replayed. The second leg establishes the server identity and creates a fresh acceptor subkey (at least for modern enctypes and implementations). The third leg proves that the client was able to decode the acceptor subkey and use it. If the client is going to send a wrapped message or use channel bindings, the third leg is sort of unnecessary, depending on the app. But the app would still see a complete gss_accept_sec_context() after the second leg, before the client has proved that it's not just a replay, and in some circumstances the mere ability to fake a successful authentication is a problem. From metze@samba.org Fri Apr 29 07:10:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335E4E075B for ; Fri, 29 Apr 2011 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmQ4dRrx7iGg for ; Fri, 29 Apr 2011 07:10:55 -0700 (PDT) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by ietfa.amsl.com (Postfix) with ESMTP id 89A47E074D for ; Fri, 29 Apr 2011 07:10:55 -0700 (PDT) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JiYXs/HrEl2yUn8V3w== X-RZG-CLASS-ID: mo05 Received: from [172.30.123.9] (dvm01.metzemix.de [85.214.18.123]) by post.strato.de (mrclete mo39) (RZmta 25.17) with ESMTPA id q00a69n3TDZlym ; Fri, 29 Apr 2011 16:10:48 +0200 (MEST) Message-ID: <4DBAC6E4.2060201@samba.org> Date: Fri, 29 Apr 2011 16:10:44 +0200 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Greg Hudson References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> <4DBA6D44.6050604@samba.org> <4DBA7270.9000702@samba.org> <1304086003.2034.5.camel@t410> In-Reply-To: <1304086003.2034.5.camel@t410> X-Enigmail-Version: 1.1.2 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1C450BBF2AF8F58BA90E6D6" Cc: "kitten@ietf.org" , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:10:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1C450BBF2AF8F58BA90E6D6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 29.04.2011 16:06, schrieb Greg Hudson: > On Fri, 2011-04-29 at 04:10 -0400, Stefan (metze) Metzmacher wrote: >>> You can do away with the replay cache. >> >> Can you explain that? >=20 > The first client->server leg of the exchange establishes the client > identity, but could be replayed. The second leg establishes the server= > identity and creates a fresh acceptor subkey (at least for modern > enctypes and implementations). The third leg proves that the client wa= s > able to decode the acceptor subkey and use it. >=20 > If the client is going to send a wrapped message or use channel > bindings, the third leg is sort of unnecessary, depending on the app. > But the app would still see a complete gss_accept_sec_context() after > the second leg, before the client has proved that it's not just a > replay, and in some circumstances the mere ability to fake a successful= > authentication is a problem. Ok, got it. metze --------------enigF1C450BBF2AF8F58BA90E6D6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk26xuQACgkQm70gjA5TCD/SewCdE0smVBGHeZen3I43dkpxVTQz prAAn2/N5fNKxFOYokVpoArkusiCjWw9 =NlEh -----END PGP SIGNATURE----- --------------enigF1C450BBF2AF8F58BA90E6D6-- From lukeh@padl.com Fri Apr 29 07:43:14 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F62AE0761 for ; Fri, 29 Apr 2011 07:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VlUCpQb-+aJ for ; Fri, 29 Apr 2011 07:43:13 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C8E0693 for ; Fri, 29 Apr 2011 07:43:12 -0700 (PDT) Received: by us.padl.com with ESMTP id p3TEh5nC011578; Fri, 29 Apr 2011 10:43:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1304086003.2034.5.camel@t410> Date: Fri, 29 Apr 2011 16:43:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7496B2FB-B526-42E9-A5A2-586EC9C2B62D@padl.com> References: <4DB9B66F.1060209@samba.org> <4DBA3E74.7030702@samba.org> <4DBA6D44.6050604@samba.org> <4DBA7270.9000702@samba.org> <1304086003.2034.5.camel@t410> To: Greg Hudson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "kitten@ietf.org" , "ietf-krb-wg@anl.gov" Subject: Re: [kitten] Negotiating DCE style X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 14:43:14 -0000 > The first client->server leg of the exchange establishes the client > identity, but could be replayed. The second leg establishes the = server > identity and creates a fresh acceptor subkey (at least for modern > enctypes and implementations). The third leg proves that the client = was > able to decode the acceptor subkey and use it. Just to add to this, my understanding is that the acceptor subkey is = always used for GSS_C_DCE_STYLE, regardless of enctype. -- Luke= From paulle@microsoft.com Fri Apr 29 11:53:33 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1C1E0711 for ; Fri, 29 Apr 2011 11:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqbseVgtMKPo for ; Fri, 29 Apr 2011 11:53:32 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 9B357E06C8 for ; Fri, 29 Apr 2011 11:53:28 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Apr 2011 11:53:25 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 29 Apr 2011 11:53:24 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.30]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Fri, 29 Apr 2011 11:53:24 -0700 From: Paul Leach To: Nico Williams , "kitten@ietf.org" Thread-Topic: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY Thread-Index: AQHMBEtm4/6RIRV60ketKjW0Q6QFopR1MnkA Date: Fri, 29 Apr 2011 18:53:24 +0000 Message-ID: <526415708D2AD940845C43B7A6BE7CE80B06270C@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 18:53:33 -0000 I don't see in principal how, in a protocol whose authenticator is a signe= d timestamp supplied in the initial protocol message, one can ever avoid ne= eding to detect replay of the signed timestamp. Hence, the description in t= he post in terms of Kerb protocol details fails to convince -- just leaves = me feeling I can't find a flaw that must exist.=20 -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= Nico Williams Sent: Tuesday, April 26, 2011 12:52 PM To: kitten@ietf.org Subject: [kitten] GSS extension to minimize need for replay caching: indica= tion of use/non-use of PROT_READY From paulle@microsoft.com Fri Apr 29 12:10:05 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE445E06AF for ; Fri, 29 Apr 2011 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG90oT1nBW8u for ; Fri, 29 Apr 2011 12:10:05 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id A0224E0761 for ; Fri, 29 Apr 2011 12:10:00 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 29 Apr 2011 12:09:55 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 29 Apr 2011 12:09:55 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.30]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Fri, 29 Apr 2011 12:09:55 -0700 From: Paul Leach To: Paul Leach , Nico Williams , "kitten@ietf.org" Thread-Topic: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY Thread-Index: AQHMBEtm4/6RIRV60ketKjW0Q6QFopR1MnkAgAAGHnA= Date: Fri, 29 Apr 2011 19:09:54 +0000 Message-ID: <526415708D2AD940845C43B7A6BE7CE80B062786@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <526415708D2AD940845C43B7A6BE7CE80B06270C@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <526415708D2AD940845C43B7A6BE7CE80B06270C@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] GSS extension to minimize need for replay caching: indication of use/non-use of PROT_READY X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 19:10:05 -0000 Never mind. I realize I asked myself a trick question: the answer is that y= ou don't need replay detection for the authenticator when the authenticator= isn't used in any essential way in the authentication. E.g., if the only t= hing that matters is proving knowledge of the (sub)session key in the ticke= t on each (app protocol) message after authentication completes. -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= Paul Leach Sent: Friday, April 29, 2011 11:53 AM To: Nico Williams; kitten@ietf.org Subject: Re: [kitten] GSS extension to minimize need for replay caching: in= dication of use/non-use of PROT_READY I don't see in principal how, in a protocol whose authenticator is a signe= d timestamp supplied in the initial protocol message, one can ever avoid ne= eding to detect replay of the signed timestamp. Hence, the description in t= he post in terms of Kerb protocol details fails to convince -- just leaves = me feeling I can't find a flaw that must exist.=20