From shawn.emery@oracle.com Wed May 5 14:39:46 2010 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 1DAFC3A6D1A; Wed, 5 May 2010 14:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_50=0.001, 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 D7bPyBHsbv7z; Wed, 5 May 2010 14:39:45 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AF70D3A6B0F; Wed, 5 May 2010 14:39:43 -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.1) with ESMTP id o45LdSrh025802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 May 2010 21:39:30 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45LdRLb012904; Wed, 5 May 2010 21:39:27 GMT Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 240481351273095497; Wed, 05 May 2010 14:38:17 -0700 Received: from [129.150.48.45] (/129.150.48.45) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 14:38:17 -0700 Message-ID: <4BE1E547.5030103@oracle.com> Date: Wed, 05 May 2010 15:38:15 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: kitten@ietf.org, sasl@ietf.org Subject: SASL and KITTEN-WG Merger Content-Type: multipart/alternative; boundary="------------020108090802020903040506" X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090207.4BE1E592.009F:SCFMA922111,ss=1,fgs=0 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, 05 May 2010 21:39:46 -0000 This is a multi-part message in MIME format. --------------020108090802020903040506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry for any cross-posting, but this is unavoidable given the subject line. During IETF 77, the security ADs suggested that we merge the KITTEN and SASL WGs. This has some potential benefits: 1. ensure efforts of any new work items/extensions 2. both WGs have expertise in security interface design 3. analyze proposed security mechanisms for both set of interfaces Please respond to both lists if you have any objections to such a merger. The time-out for objections is two weeks from this posting. Thank you, Shawn KITTEN co-chair -- --------------020108090802020903040506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Sorry for any cross-posting, but this is unavoidable given the subject line.

During IETF 77, the security ADs suggested that we merge the KITTEN and SASL WGs.  This has some potential benefits:

1. ensure efforts of any new work items/extensions
2. both WGs have expertise in security interface design
3. analyze proposed security mechanisms for both set of interfaces

Please respond to both lists if you have any objections to such a merger.  The time-out for objections is two weeks from this posting.

Thank you,

Shawn KITTEN co-chair
--

--------------020108090802020903040506-- From alexey.melnikov@isode.com Wed May 5 14:43:20 2010 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 388423A6B92; Wed, 5 May 2010 14:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW+1fLV9Y1C2; Wed, 5 May 2010 14:43:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4F8813A6AD0; Wed, 5 May 2010 14:43:19 -0700 (PDT) Received: from [92.40.16.136] (92.40.16.136.sub.mbb.three.co.uk [92.40.16.136]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 May 2010 22:43:05 +0100 Message-ID: <4BE1E64F.8090101@isode.com> Date: Wed, 05 May 2010 22:42:39 +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: Shawn Emery Subject: Re: SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> In-Reply-To: <4BE1E547.5030103@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 21:43:21 -0000 Shawn Emery wrote: > Sorry for any cross-posting, but this is unavoidable given the subject > line. > > During IETF 77, the security ADs suggested that we merge the KITTEN > and SASL WGs. This has some potential benefits: > > 1. ensure efforts of any new work items/extensions > 2. both WGs have expertise in security interface design > 3. analyze proposed security mechanisms for both set of interfaces > > Please respond to both lists if you have any objections to such a > merger. The time-out for objections is two weeks from this posting. (Speaking as an individual): I have No Objections. I suggest the SASL WG should be closed and Kitten should rechater. The SASL WG mailing list should stay open though. > Thank you, > > Shawn KITTEN co-chair From Nicolas.Williams@oracle.com Thu May 6 09:48:05 2010 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 93B3E3A6917; Thu, 6 May 2010 09:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, UNPARSEABLE_RELAY=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 G1qhuRxosFUl; Thu, 6 May 2010 09:48:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AF6223A6921; Thu, 6 May 2010 09:48:04 -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.1) with ESMTP id o46GlnrI010610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 May 2010 16:47:51 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o465rq7P013811; Thu, 6 May 2010 16:47:47 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 220127231273164393; Thu, 06 May 2010 09:46:33 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 09:46:33 -0700 Date: Thu, 6 May 2010 11:46:31 -0500 From: Nicolas Williams To: Shawn Emery Subject: Re: SASL and KITTEN-WG Merger Message-ID: <20100506164630.GU9429@oracle.com> References: <4BE1E547.5030103@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE1E547.5030103@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4BE2F2B7.0172:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 16:48:05 -0000 On Wed, May 05, 2010 at 03:38:15PM -0600, Shawn Emery wrote: > Sorry for any cross-posting, but this is unavoidable given the subject line. :) > During IETF 77, the security ADs suggested that we merge the KITTEN > and SASL WGs. This has some potential benefits: > > 1. ensure efforts of any new work items/extensions > 2. both WGs have expertise in security interface design > 3. analyze proposed security mechanisms for both set of interfaces Note that KITTEN never had mechanism standardization as a responsibility. Now its successor will? This means that the new WG's charter can't just be a union of the KITTEN and SASL charters. > Please respond to both lists if you have any objections to such a > merger. The time-out for objections is two weeks from this posting. No objections here. I would like to see the proposed charter, of course. I'm also curious as to the name of the new WG. I'd be fine with keeping either of KITTEN or SASL as the name for the new WG. I'd also be happy with a new name. Nico -- From lear@cisco.com Sat May 8 04:57:40 2010 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 D97513A6A41; Sat, 8 May 2010 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.07 X-Spam-Level: X-Spam-Status: No, score=-3.07 tagged_above=-999 required=5 tests=[AWL=-2.331, BAYES_20=-0.74, 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 dnQyVGG7WhP1; Sat, 8 May 2010 04:57:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5E0093A6A10; Sat, 8 May 2010 04:57:39 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwBALvt5EuQ/uCWiWdsb2JhbACDGJsBFQEBAQoLEREGHKRDiHSQGoQnbgQ X-IronPort-AV: E=Sophos;i="4.52,352,1270425600"; d="scan'208,217";a="6981206" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 08 May 2010 11:19:46 +0000 Received: from dhcp-10-61-96-68.cisco.com (dhcp-10-61-96-68.cisco.com [10.61.96.68]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o48BvPXA021492; Sat, 8 May 2010 11:57:25 GMT Message-ID: <4BE5518B.7060101@cisco.com> Date: Sat, 08 May 2010 13:56:59 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100507 Lanikai/3.1pre MIME-Version: 1.0 To: Shawn Emery Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> In-Reply-To: <4BE1E547.5030103@oracle.com> Content-Type: multipart/alternative; boundary="------------070805090405080602040306" X-Mailman-Approved-At: Sat, 08 May 2010 09:00:25 -0700 Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 11:57:40 -0000 This is a multi-part message in MIME format. --------------070805090405080602040306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear everyone, I find it hard to have this discussion without understanding what the new charter would be. Is there a pointer somewhere? We had discussions relating to our SAML/OpenID SASL drafts being handled by the new group, but I don't know what would be in scope. Thanks, Eliot On 5/5/10 11:38 PM, Shawn Emery wrote: > > > Sorry for any cross-posting, but this is unavoidable given the subject > line. > > During IETF 77, the security ADs suggested that we merge the KITTEN > and SASL WGs. This has some potential benefits: > > 1. ensure efforts of any new work items/extensions > 2. both WGs have expertise in security interface design > 3. analyze proposed security mechanisms for both set of interfaces > > Please respond to both lists if you have any objections to such a > merger. The time-out for objections is two weeks from this posting. > > Thank you, > > Shawn KITTEN co-chair > -- > > > _______________________________________________ > sasl mailing list > sasl@ietf.org > https://www.ietf.org/mailman/listinfo/sasl --------------070805090405080602040306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Dear everyone,

I find it hard to have this discussion without understanding what the new charter would be.  Is there a pointer somewhere?  We had discussions relating to our SAML/OpenID SASL drafts being handled by the new group, but I don't know what would be in scope.

Thanks,

Eliot



On 5/5/10 11:38 PM, Shawn Emery wrote:


Sorry for any cross-posting, but this is unavoidable given the subject line.

During IETF 77, the security ADs suggested that we merge the KITTEN and SASL WGs.  This has some potential benefits:

1. ensure efforts of any new work items/extensions
2. both WGs have expertise in security interface design
3. analyze proposed security mechanisms for both set of interfaces

Please respond to both lists if you have any objections to such a merger.  The time-out for objections is two weeks from this posting.

Thank you,

Shawn KITTEN co-chair
--

_______________________________________________ sasl mailing list sasl@ietf.org https://www.ietf.org/mailman/listinfo/sasl
--------------070805090405080602040306-- From alexey.melnikov@isode.com Sat May 8 15:36:43 2010 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 073B23A685E; Sat, 8 May 2010 15:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 For+hG2cSYzE; Sat, 8 May 2010 15:36:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 217EC3A6812; Sat, 8 May 2010 15:36:42 -0700 (PDT) Received: from [92.40.175.111] (92.40.175.111.sub.mbb.three.co.uk [92.40.175.111]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 8 May 2010 23:36:29 +0100 Message-ID: <4BE5E729.50107@isode.com> Date: Sat, 08 May 2010 23:35:21 +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: Eliot Lear Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> In-Reply-To: <4BE5518B.7060101@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 22:36:43 -0000 Eliot Lear wrote: > Dear everyone, > > I find it hard to have this discussion without understanding what the > new charter would be. Is there a pointer somewhere? We had > discussions relating to our SAML/OpenID SASL drafts being handled by > the new group, but I don't know what would be in scope. Hi Eliot, There is no charter proposal for the merged WG, so at this point we are discussing things "in general". From simon@josefsson.org Sun May 9 08:15:14 2010 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 68DCC3A6A26; Sun, 9 May 2010 08:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KphPdJEdmRfn; Sun, 9 May 2010 08:15:13 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id AF7023A6A31; Sun, 9 May 2010 08:13:53 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o49FDYYs004102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 9 May 2010 17:13:35 +0200 From: Simon Josefsson To: Eliot Lear Subject: Re: SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100509:lear@cisco.com::BX5Sa9l0d39R6f10:3T72 X-Hashcash: 1:22:100509:sasl@ietf.org::2GFSd8DBOyP0rhQV:BCWW X-Hashcash: 1:22:100509:kitten@ietf.org::0myMqDPyZmQYyltl:KsR8 X-Hashcash: 1:22:100509:shawn.emery@oracle.com::PxftXpwjZLlWtNZm:PHCI Date: Sun, 09 May 2010 17:13:33 +0200 In-Reply-To: <4BE5518B.7060101@cisco.com> (Eliot Lear's message of "Sat, 08 May 2010 13:56:59 +0200") Message-ID: <87ljbtumzm.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 15:15:14 -0000 Eliot Lear writes: > Dear everyone, > > I find it hard to have this discussion without understanding what the > new charter would be. Is there a pointer somewhere? We had > discussions relating to our SAML/OpenID SASL drafts being handled by > the new group, but I don't know what would be in scope. To me, the SAML/OpenID mechanisms are perhaps the most important work item for a new working group, so I would be disappointed if it is not mentioned in the charter. /Simon From Nicolas.Williams@oracle.com Mon May 10 07:57:22 2010 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 27B783A6995; Mon, 10 May 2010 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 vpzvmNEeVCtU; Mon, 10 May 2010 07:57:21 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 253863A6951; Mon, 10 May 2010 07:57:21 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AEv4mS012486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 14:57:05 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AEuxAC028383; Mon, 10 May 2010 14:57:02 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 227879541273503417; Mon, 10 May 2010 07:56:57 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 07:56:56 -0700 Date: Mon, 10 May 2010 09:56:49 -0500 From: Nicolas Williams To: Simon Josefsson Subject: Re: [sasl] SASL and KITTEN-WG Merger Message-ID: <20100510145648.GO9429@oracle.com> References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ljbtumzm.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090208.4BE81EC2.0165:SCFMA4539811,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org, Eliot Lear 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, 10 May 2010 14:57:22 -0000 On Sun, May 09, 2010 at 05:13:33PM +0200, Simon Josefsson wrote: > Eliot Lear writes: > > I find it hard to have this discussion without understanding what the > > new charter would be. Is there a pointer somewhere? We had > > discussions relating to our SAML/OpenID SASL drafts being handled by > > the new group, but I don't know what would be in scope. > > To me, the SAML/OpenID mechanisms are perhaps the most important work > item for a new working group, so I would be disappointed if it is not > mentioned in the charter. I don't care if the work Eliot mentions goes in this WG or a separate WG as long as the work gets done :) To start, the proposal to merge these two WGs is fairly straightforward since merging the two charters presents only one minor conflict and since both the GSS-API and SASL have been converging to a large degree. The one minor conflict is that KITTEN was not chartered to work on mechanisms, but SASL did do work on mechanisms (SCRAM, MD5-DIGEST, ...). I think that is easy to resolve: let the new WG work on mechanisms in general, or else list the kinds of mechanisms that the new WG may work on, or, if we think we don't need any new mechanisms, then don't allow the new WG to work on any. Nico -- From Nicolas.Williams@oracle.com Mon May 10 08:11:06 2010 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 6690D3A69FE; Mon, 10 May 2010 08:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.535 X-Spam-Level: X-Spam-Status: No, score=-4.535 tagged_above=-999 required=5 tests=[AWL=2.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 M6YDM78M1kiA; Mon, 10 May 2010 08:11:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 846243A6403; Mon, 10 May 2010 08:11:03 -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.1) with ESMTP id o4AFAlaA013021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 15:10:48 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AFAgP4032665; Mon, 10 May 2010 15:10:42 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 251611521273504157; Mon, 10 May 2010 08:09:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 08:09:11 -0700 Date: Mon, 10 May 2010 10:09:07 -0500 From: Nicolas Williams To: Eliot Lear Subject: Re: [sasl] SASL and KITTEN-WG Merger Message-ID: <20100510150905.GQ9429@oracle.com> References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com> <4BE82041.9070507@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BE82041.9070507@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090205.4BE821F9.0015:SCFMA4539811,ss=1,fgs=0 Cc: kitten@ietf.org, Simon Josefsson , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 15:11:06 -0000 On Mon, May 10, 2010 at 05:03:29PM +0200, Eliot Lear wrote: > Thanks for your notes. I have no problem in principle with the > merger, and in fact think it makes a whole lot of sense. But I > always like to look at the detail. No problem. In fact, I asked to see the proposed charter before you did :) > Also, I'll just point out that > this is our opportunity for a new SASSY WG name (KITTEN-KABOODLE?) > ;-) Heh. It's been done too much now :) but I'm OK with that. Nico -- From lear@cisco.com Mon May 10 08:04:13 2010 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 5A94628C19E; Mon, 10 May 2010 08:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.917 X-Spam-Level: X-Spam-Status: No, score=-7.917 tagged_above=-999 required=5 tests=[AWL=2.682, BAYES_00=-2.599, 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 klFI8mqmuc3Q; Mon, 10 May 2010 08:04:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CE30C28C166; Mon, 10 May 2010 08:04:11 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkBAD+950uQ/uCWiWdsb2JhbACDF5sIFQEBAQoLEREGHKNZiHSQNIElgwFuBA X-IronPort-AV: E=Sophos;i="4.52,362,1270425600"; d="scan'208";a="60996382" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 May 2010 15:03:59 +0000 Received: from dhcp-10-55-86-118.cisco.com (dhcp-10-55-86-118.cisco.com [10.55.86.118]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4AF3xPc011457; Mon, 10 May 2010 15:03:59 GMT Message-ID: <4BE82041.9070507@cisco.com> Date: Mon, 10 May 2010 17:03:29 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100509 Lanikai/3.1pre MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com> In-Reply-To: <20100510145648.GO9429@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 May 2010 09:25:12 -0700 Cc: kitten@ietf.org, Simon Josefsson , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 15:04:13 -0000 Nico, all, Thanks for your notes. I have no problem in principle with the merger, and in fact think it makes a whole lot of sense. But I always like to look at the detail. Also, I'll just point out that this is our opportunity for a new SASSY WG name (KITTEN-KABOODLE?) ;-) Eliot From jhutz@cmu.edu Tue May 11 11:13:48 2010 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 B703628C200; Tue, 11 May 2010 11:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.019 X-Spam-Level: X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, 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 RUu+530zL3xs; Tue, 11 May 2010 11:13:40 -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 8036A3A6C0C; Tue, 11 May 2010 11:12:54 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4BICVQ3024023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 14:12:31 -0400 (EDT) Date: Tue, 11 May 2010 14:12:31 -0400 From: Jeffrey Hutzelman To: Eliot Lear , Nicolas Williams Subject: Re: [sasl] SASL and KITTEN-WG Merger Message-ID: <176E8F86825AF9BE457A43D2@minbar.fac.cs.cmu.edu> In-Reply-To: <11586_1273508712_o4AGPBeI021842_4BE82041.9070507@cisco.com> References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com> <11586_1273508712_o4AGPBeI021842_4BE82041.9070507@cisco.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, Simon Josefsson , sasl@ietf.org, jhutz@cmu.edu 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, 11 May 2010 18:13:48 -0000 --On Monday, May 10, 2010 05:03:29 PM +0200 Eliot Lear wrote: Also, I'll just point out that this is our > opportunity for a new SASSY WG name (KITTEN-KABOODLE?) ;-) Absolutely not. Working group acronyms containing dashes are a major pain. :-) From tony@att.com Tue May 11 13:29:58 2010 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 E821D3A67B5; Tue, 11 May 2010 13:29:58 -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 55dX-XL-HU4i; Tue, 11 May 2010 13:29:57 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9D71F3A69E4; Tue, 11 May 2010 13:28:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1273609679!55845038!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 21369 invoked from network); 11 May 2010 20:28:00 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 May 2010 20:28:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4BKSC2h027972; Tue, 11 May 2010 16:28:12 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4BKSBVQ027950; Tue, 11 May 2010 16:28:11 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4BKRvaC009722; Tue, 11 May 2010 16:27:57 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4BKRrZK009609; Tue, 11 May 2010 16:27:53 -0400 Received: from [135.25.190.148] (njcdtl02ga7127.ugd.att.com[135.25.190.148]) by maillennium.att.com (mailgw1) with ESMTP id <20100511202751gw100b8ilqe> (Authid: tony); Tue, 11 May 2010 20:27:53 +0000 X-Originating-IP: [135.25.190.148] Message-ID: <4BE9BDC6.7070303@att.com> Date: Tue, 11 May 2010 16:27:50 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jeffrey Hutzelman Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <4BE5518B.7060101@cisco.com> <87ljbtumzm.fsf@mocca.josefsson.org> <20100510145648.GO9429@oracle.com> <11586_1273508712_o4AGPBeI021842_4BE82041.9070507@cisco.com> <176E8F86825AF9BE457A43D2@minbar.fac.cs.cmu.edu> In-Reply-To: <176E8F86825AF9BE457A43D2@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 May 2010 13:38:27 -0700 Cc: kitten@ietf.org, Simon Josefsson , sasl@ietf.org, Eliot Lear 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, 11 May 2010 20:29:59 -0000 what's a good retronym for KABOODLE? On 5/11/2010 2:12 PM, Jeffrey Hutzelman wrote: > --On Monday, May 10, 2010 05:03:29 PM +0200 Eliot Lear > wrote: > > Also, I'll just point out that this is our >> opportunity for a new SASSY WG name (KITTEN-KABOODLE?) ;-) > > Absolutely not. Working group acronyms containing dashes are a major > pain. > :-) From tlyu@mit.edu Wed May 12 14:42:11 2010 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 18E353A690C; Wed, 12 May 2010 14:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.445 X-Spam-Level: X-Spam-Status: No, score=0.445 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3w4oLTRGYGv; Wed, 12 May 2010 14:42:10 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id F30453A69A4; Wed, 12 May 2010 14:41:55 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-5b-4beb2099cf3c Received: from mailhub-auth-4.mit.edu (MAILHUB-AUTH-4.MIT.EDU [18.7.62.39]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 87.5D.10290.9902BEB4; Wed, 12 May 2010 17:41:45 -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 o4CLfj7T025473; Wed, 12 May 2010 17:41:45 -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 o4CLfha7010200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 May 2010 17:41:44 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4CLfhwJ016412; Wed, 12 May 2010 17:41:43 -0400 (EDT) To: Nicolas Williams Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com> From: Tom Yu Date: Wed, 12 May 2010 17:41:43 -0400 In-Reply-To: <20100506164630.GU9429@oracle.com> (Nicolas Williams's message of "Thu, 6 May 2010 11:46:31 -0500") Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:42:11 -0000 Nicolas Williams writes: > I'm also curious as to the name of the new WG. I'd be fine with keeping > either of KITTEN or SASL as the name for the new WG. I'd also be happy > with a new name. I propose something like MOGGIES = Mechanisms Of Generating Generically Interoperable & Effective Security From lear@cisco.com Thu May 13 00:41:58 2010 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 2D1913A6936; Thu, 13 May 2010 00:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.009 X-Spam-Level: X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[AWL=2.590, BAYES_00=-2.599, 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 fPEDPLvaWHww; Thu, 13 May 2010 00:41:57 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 73AC63A67DB; Thu, 13 May 2010 00:41:56 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskBAH9J60uQ/uCWe2dsb2JhbACDF5sTFQEBFiIGHKIEiHSQRIEmgwFrBI89 X-IronPort-AV: E=Sophos;i="4.53,220,1272844800"; d="scan'208";a="61209408" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 May 2010 07:41:45 +0000 Received: from dhcp-10-61-96-203.cisco.com (dhcp-10-61-96-203.cisco.com [10.61.96.203]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4D7fjGs021256; Thu, 13 May 2010 07:41:45 GMT Message-ID: <4BEBAD17.10908@cisco.com> Date: Thu, 13 May 2010 09:41:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.5pre) Gecko/20100512 Lanikai/3.1pre MIME-Version: 1.0 To: Tom Yu Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 07:41:58 -0000 On 5/12/10 11:41 PM, Tom Yu wrote: > I propose something like > > MOGGIES = > Mechanisms Of Generating Generically Interoperable& Effective Security I like it! By the way, it sounds like if we're all having this excellent discussion over the name, we're all pretty much in agreement as to direction. Do I understand this to be correct? Eliot From shawn.emery@oracle.com Thu May 13 00:47:26 2010 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 E8FAB3A6B60; Thu, 13 May 2010 00:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_05=-1.11, 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 y6ol5jNjsAWz; Thu, 13 May 2010 00:47:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C7C7C3A6B6B; Thu, 13 May 2010 00:46:44 -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.1) with ESMTP id o4D7kVGv002329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 May 2010 07:46:33 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4D1kGdZ024662; Thu, 13 May 2010 07:46:30 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 261001751273736783; Thu, 13 May 2010 00:46:23 -0700 Received: from [129.150.12.66] (/129.150.12.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 May 2010 00:46:23 -0700 Message-ID: <4BEBAE4D.1050807@oracle.com> Date: Thu, 13 May 2010 01:46:21 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: Eliot Lear Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com> <4BEBAD17.10908@cisco.com> In-Reply-To: <4BEBAD17.10908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090205.4BEBAE59.016D:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org, Tom Yu 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, 13 May 2010 07:47:26 -0000 On 05/13/10 01:41 AM, Eliot Lear wrote: > > > On 5/12/10 11:41 PM, Tom Yu wrote: >> I propose something like >> >> MOGGIES = >> Mechanisms Of Generating Generically Interoperable& Effective Security > > I like it! > > By the way, it sounds like if we're all having this excellent > discussion over the name, we're all pretty much in agreement as to > direction. Do I understand this to be correct? I'm currently drafting charter text for the new WG and should be ready for review by KITTEN and SASL WG members some time next week. Shawn. -- From tony@att.com Thu May 13 05:00:40 2010 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 9DF5B3A69A8; Thu, 13 May 2010 05:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.921 X-Spam-Level: X-Spam-Status: No, score=-104.921 tagged_above=-999 required=5 tests=[AWL=-0.922, BAYES_50=0.001, 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 czKL7kv2grh7; Thu, 13 May 2010 05:00:40 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id AFFAA3A680D; Thu, 13 May 2010 05:00:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1273752027!48603704!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 391 invoked from network); 13 May 2010 12:00:28 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 May 2010 12:00:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4DC0eqm030463; Thu, 13 May 2010 08:00:40 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o4DC0Y1c030360; Thu, 13 May 2010 08:00:34 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4DC0K6k023832; Thu, 13 May 2010 08:00:20 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o4DC0Ejm023447; Thu, 13 May 2010 08:00:14 -0400 Received: from [135.70.233.3] (vpn-135-70-233-3.vpn.east.att.com[135.70.233.3]) by maillennium.att.com (mailgw1) with ESMTP id <20100513120014gw100b8itoe> (Authid: tony); Thu, 13 May 2010 12:00:14 +0000 X-Originating-IP: [135.70.233.3] Message-ID: <4BEBE9CA.8030902@att.com> Date: Thu, 13 May 2010 08:00:10 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: kitten@ietf.org, sasl@ietf.org Subject: Re: [sasl] SASL and KITTEN-WG Merger References: <4BE1E547.5030103@oracle.com> <20100506164630.GU9429@oracle.com> <4BEBAD17.10908@cisco.com> In-Reply-To: <4BEBAD17.10908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 13 May 2010 12:00:40 -0000 I haven't seen any nay-sayers. I'm in the "ok, fine by me" camp myself. Tony Hansen On 5/13/2010 3:41 AM, Eliot Lear wrote: > On 5/12/10 11:41 PM, Tom Yu wrote: >> I propose something like >> >> MOGGIES = >> Mechanisms Of Generating Generically Interoperable& Effective Security > > I like it! > > By the way, it sounds like if we're all having this excellent > discussion over the name, we're all pretty much in agreement as to > direction. Do I understand this to be correct? > > Eliot From mrex@sap.com Fri May 14 11:13:37 2010 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 870E43A67BD; Fri, 14 May 2010 11:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.717 X-Spam-Level: X-Spam-Status: No, score=-7.717 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_50=0.001, 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 zmbLTikBSuR3; Fri, 14 May 2010 11:13:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 574D53A67AE; Fri, 14 May 2010 11:13:35 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4EIDMfV004103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 20:13:22 +0200 (MEST) From: Martin Rex Message-Id: <201005141813.o4EIDLaP026201@fs4113.wdf.sap.corp> Subject: Re: [sasl] SASL and KITTEN-WG Merger To: lear@cisco.com (Eliot Lear) Date: Fri, 14 May 2010 20:13:21 +0200 (MEST) In-Reply-To: <4BEBAD17.10908@cisco.com> from "Eliot Lear" at May 13, 10 09:41:11 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: kitten@ietf.org, sasl@ietf.org, tlyu@MIT.EDU 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, 14 May 2010 18:13:37 -0000 Eliot Lear wrote: > > On 5/12/10 11:41 PM, Tom Yu wrote: > > I propose something like > > > > MOGGIES = > > Mechanisms Of Generating Generically Interoperable& Effective Security > > I like it! > > By the way, it sounds like if we're all having this excellent discussion > over the name, we're all pretty much in agreement as to direction. Do I > understand this to be correct? I'm fine with whatever active participants and chairs of both WGs seem fit. IIRC, SASL (rfc2222) was not a chartered work item of CAT, but instead an individual submission of John Myers. However, SASL was reviewed by active CAT participants and CAT meeting time was provided on IETF Meetings for presenting SASL progress. -Martin From hartmans@mit.edu Fri May 14 12:21:04 2010 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 34C6E28C160; Fri, 14 May 2010 12:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2cThnTUVrei; Fri, 14 May 2010 12:21:03 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9D9F03A6BFE; Fri, 14 May 2010 12:19:45 -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 76B7B20239; Fri, 14 May 2010 15:19:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8E89F43EE; Fri, 14 May 2010 15:19:34 -0400 (EDT) From: Sam Hartman To: saag@mit.edu Subject: Summary of Federated Authentication BOF at IETF 77 Date: Fri, 14 May 2010 15:19:34 -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, moonshot-community@jiscmail.ac.uk, emu@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:21:04 -0000 I'm told there were around 30 people in the room. That seemed like a good turn out for Thursday at 9 PM. Many of the participants had already read some or all of the proposed documents. I presented a problem statement based on providing federated authentication for non-web applications. Two solutions were presented. I presented work on Moonshot, a technology that combines EAP, GSS-API, RADIUS and SAML to solve the problem. Eliot Lear and Klaas Wierenga presented a simpler solution that uses browser-based SAML and Open ID. The sense of the room was that these solutions compliment each other. Moonshot requires more infrastructure and client configuration but provides several advantages. The browser-based solutions are something that requires fewer client changes. Volunteers were collected from the EAP, GSS and RADIUS communities who would be interested in working on these problems. Some of the work discussed, possibly especially including the Open ID and SAML browser-based solutions may be able to progress in kitten. I and I believe several of the other Moonshot proponents would prefer to focus the Moonshot work in one working group. Other solutions could also be progressed in that group, although we should be careful not to slow down work that could progress quickly in kitten by moving it into an as-yet-unchartered group. There seemed to be strong support for going forward. However, several things to address in a BOF were raised with regard to the Moonshot work. * Steve Bellovin pointed out that we need to be very aware of the operational impact and how this fits with the operational model of the technologies that are used/extended. * Klaas pointed out that Moonshot involves changes to a lot of different components. We need to make sure that there are incremental advantages to each of these changes so they will be deployed: a system where there is no benefit until the end when all the peaces fall together is much harder to deploy. * Klaas pointed out that we need to consider the operational security around how RADIUS federations are deployed. If network access is not considered sensitive today, people may be more lax in the security surrounding their RADIUS infrastructure. If we use that infrastructure to secure more sensitive resources we need to have practices that tighten up the security of the infrastructure sufficiently. * Someone brought up that this is another one of those authentication proposals where user-interface is critical. While we should not lay out dialogues in the IETF, we're going to need to describe the usability aspects of this enough to increase the probability of a good security solution. People specifically asked to look at the following: * Complexity * What can't be handled with simpler solutions * Is Moonshot broad enough in scope? * The UI questions Since the bar BOF, there has been a lot of traffic on the list and work continues. We're definitely going to put together a BOF request for IETF 78. From hartmans@mit.edu Fri May 14 12:23:04 2010 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 9B88D3A683F; Fri, 14 May 2010 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.285 X-Spam-Level: X-Spam-Status: No, score=-0.285 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyfWTvsIcCVO; Fri, 14 May 2010 12:23:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 021F928C154; Fri, 14 May 2010 12:22:04 -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 7A74220239; Fri, 14 May 2010 15:21:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A663743EE; Fri, 14 May 2010 15:21:52 -0400 (EDT) From: Sam Hartman To: saag@ietf.org Subject: Summary of Federated Authentication BOF at IETF 77 Date: Fri, 14 May 2010 15:19:34 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) X-Brightmail-Tracker: AAAAAA== MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:23:04 -0000 I'm told there were around 30 people in the room. That seemed like a good turn out for Thursday at 9 PM. Many of the participants had already read some or all of the proposed documents. I presented a problem statement based on providing federated authentication for non-web applications. Two solutions were presented. I presented work on Moonshot, a technology that combines EAP, GSS-API, RADIUS and SAML to solve the problem. Eliot Lear and Klaas Wierenga presented a simpler solution that uses browser-based SAML and Open ID. The sense of the room was that these solutions compliment each other. Moonshot requires more infrastructure and client configuration but provides several advantages. The browser-based solutions are something that requires fewer client changes. Volunteers were collected from the EAP, GSS and RADIUS communities who would be interested in working on these problems. Some of the work discussed, possibly especially including the Open ID and SAML browser-based solutions may be able to progress in kitten. I and I believe several of the other Moonshot proponents would prefer to focus the Moonshot work in one working group. Other solutions could also be progressed in that group, although we should be careful not to slow down work that could progress quickly in kitten by moving it into an as-yet-unchartered group. There seemed to be strong support for going forward. However, several things to address in a BOF were raised with regard to the Moonshot work. * Steve Bellovin pointed out that we need to be very aware of the operational impact and how this fits with the operational model of the technologies that are used/extended. * Klaas pointed out that Moonshot involves changes to a lot of different components. We need to make sure that there are incremental advantages to each of these changes so they will be deployed: a system where there is no benefit until the end when all the peaces fall together is much harder to deploy. * Klaas pointed out that we need to consider the operational security around how RADIUS federations are deployed. If network access is not considered sensitive today, people may be more lax in the security surrounding their RADIUS infrastructure. If we use that infrastructure to secure more sensitive resources we need to have practices that tighten up the security of the infrastructure sufficiently. * Someone brought up that this is another one of those authentication proposals where user-interface is critical. While we should not lay out dialogues in the IETF, we're going to need to describe the usability aspects of this enough to increase the probability of a good security solution. People specifically asked to look at the following: * Complexity * What can't be handled with simpler solutions * Is Moonshot broad enough in scope? * The UI questions Since the bar BOF, there has been a lot of traffic on the list and work continues. We're definitely going to put together a BOF request for IETF 78. From Nicolas.Williams@oracle.com Fri May 14 12:45:36 2010 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 B4BE23A6925; Fri, 14 May 2010 12:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 WaG0mmm3VknZ; Fri, 14 May 2010 12:45:35 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 7E8CC3A68DD; Fri, 14 May 2010 12:45:35 -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.1) with ESMTP id o4EJjJ6r005560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 14 May 2010 19:45:21 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4EI7kGx015373; Fri, 14 May 2010 19:45:16 GMT Received: from abhmt012.oracle.com by acsmt354.oracle.com with ESMTP id 266589741273866312; Fri, 14 May 2010 12:45:12 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 14 May 2010 12:45:12 -0700 Date: Fri, 14 May 2010 14:45:07 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [sasl] SASL and KITTEN-WG Merger Message-ID: <20100514194507.GI9429@oracle.com> References: <4BEBAD17.10908@cisco.com> <201005141813.o4EIDLaP026201@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005141813.o4EIDLaP026201@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4BEDA853.0188:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org, lear@cisco.com, tlyu@MIT.EDU 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, 14 May 2010 19:45:37 -0000 On Fri, May 14, 2010 at 08:13:21PM +0200, Martin Rex wrote: > IIRC, SASL (rfc2222) was not a chartered work item of CAT, but instead > an individual submission of John Myers. However, SASL was reviewed > by active CAT participants and CAT meeting time was provided on > IETF Meetings for presenting SASL progress. SASL and CAT/KITTEN go really together... SASL & KITTEN, sitting on a KRB k i s s i n g. Then a HIP XCON EMU ROLLed by and said "BFD, I can handle more peers than you two". From shawn.emery@oracle.com Mon May 17 22:13:05 2010 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 3F9423A6BF6; Mon, 17 May 2010 22:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.164 X-Spam-Level: X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_50=0.001, 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 cODgSy5KrY8s; Mon, 17 May 2010 22:12:59 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6DDAB3A6BFC; Mon, 17 May 2010 22:12:55 -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.1) with ESMTP id o4I5CiPL009887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 05:12:46 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4HNPG3d024917; Tue, 18 May 2010 05:12:41 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 273140181274159555; Mon, 17 May 2010 22:12:35 -0700 Received: from [129.150.48.63] (/129.150.48.63) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 May 2010 22:12:34 -0700 Message-ID: <4BF221C1.2090005@oracle.com> Date: Mon, 17 May 2010 23:12:33 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: kitten@ietf.org, sasl@ietf.org Subject: MOGGIES Proposed Charter Content-Type: multipart/mixed; boundary="------------000601080203050901040802" X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090204.4BF221CE.00FA:SCFMA922111,ss=1,fgs=0 Cc: Tim Polk , Sean Turner 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, 18 May 2010 05:13:05 -0000 This is a multi-part message in MIME format. --------------000601080203050901040802 Content-Type: multipart/alternative; boundary="------------020603040801080606000202" --------------020603040801080606000202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As discussed; attached is the proposed charter text for a new working group (MOGGIES) based on future direction in the GSS-API and SASL space. Please provide any feed-back to the lists by the end of May. Thank you, Shawn Emery and Tom Yu (co-chairs) -- --------------020603040801080606000202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As discussed; attached is the proposed charter text for a new working group (MOGGIES) based on future direction in the GSS-API and SASL space.  Please provide any feed-back to the lists by the end of May.

Thank you,

Shawn Emery and Tom Yu (co-chairs)
--
--------------020603040801080606000202-- --------------000601080203050901040802 Content-Type: text/plain; name="moggies-charter.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="moggies-charter.txt" MOGGIES (Mechanisms Of Generating Generically Interoperable & Effective Security) Description of Working Group: The Generic Security Services (GSS) API and Simple Authentication and Security Layer (SASL) provide various applications with a security framework for secure network communication. The purpose of the Mechanisms Of Generating Generically Interoperable & Effective Security (MOGGIES) working group (WG) is to develop extensions/improvements to the GSS-API, shepherd specific GSS-API security mechanisms, revise SASLprep with a stringprep profile from the NewPrep WG, and provide guidance for any new SASL-related submissions. This working is chartered to specify the following extensions and improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API: * Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials * Specify interface for asynchronous calls. * Define interfaces for better error message reporting. * Specify an interface for reporting the security strength of GSS-API mechanism. * Provide a more programmer friendly interface for application developers. This working group is also chartered to transition proposed SASL mechanisms as GSS-API mechanisms: * A SASL Mechanism for OpenID draft-lear-ietf-sasl-openid-00 * A SASL Mechanism for SAML draft-wierenga-ietf-sasl-saml-00 The transition from SASL to GSS-API mechanisms will allow a greater set of applications to utilize said mechanisms with SASL implementations that support the use of GSS-API mechanisms in SASL (RFC 5801). The working group shall also revise SASLprep with a stringprep profile developed by the NewPrep WG. This working group will review SASL related submissions as well, including any new SASL mechanisms proposed. Deliverables: * GSS-API: initializing credentials [editor: TBD] * GSS-API: iterating credentials [editor: TBD] * GSS-API: exporting/importing credentials [editor: TBD] * GSS-API: specification for asynchronous calls [editor: TBD] * GSS-API: interfaces/improvements for better error message reporting [editor: TBD] * GSS-API: reporting security strength [editor: TBD] * GSS-API: programmer friendly interfaces [editor: TBD] * GSS-API: transition SASL mechanism for OpenID [editor: TBD] * GSS-API: transition SASL mechanism for SAML [editor: TBD] * SASL: Revise SASLprep with stringprep from the NewPrep WG [editor: TBD] Goals and Milestones: July 2010 First Meeting TBD Listed Work Items --------------000601080203050901040802-- From simon@josefsson.org Mon May 17 22:51:40 2010 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 860F83A6B66; Mon, 17 May 2010 22:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, 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 QYmfJvi0FvMM; Mon, 17 May 2010 22:51:39 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id DC3EB3A6BD8; Mon, 17 May 2010 22:51:33 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4I5p41F031247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 May 2010 07:51:10 +0200 From: Simon Josefsson To: Shawn Emery Subject: Re: MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100518:kitten@ietf.org::xl9kTq9Obe2rLepy:Hce+ X-Hashcash: 1:22:100518:sasl@ietf.org::vqExf7YyssOAdaNy:J8hx X-Hashcash: 1:22:100518:turners@ieca.com::TOanfYWwe9y70wIH:OQ+A X-Hashcash: 1:22:100518:tim.polk@nist.gov::h4d+c5VQeK1kr3rA:X+f5 X-Hashcash: 1:22:100518:shawn.emery@oracle.com::GSOx6Clyi35F2dVo:O8rs Date: Tue, 18 May 2010 07:51:04 +0200 In-Reply-To: <4BF221C1.2090005@oracle.com> (Shawn Emery's message of "Mon, 17 May 2010 23:12:33 -0600") Message-ID: <87iq6lu59z.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, Tim Polk , Sean Turner , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 05:51:40 -0000 The charter looks fine to me. Do we have energy to also look at moving RFC 4422 from Proposed to Draft? Unless I'm missing something, that shouldn't be too complicated. I recall some implementation evaluation has already started. /Simon From leifj@sunet.se Tue May 18 07:03:43 2010 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 3376C3A6943 for ; Tue, 18 May 2010 07:03:43 -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 14BNB2mFulbf for ; Tue, 18 May 2010 07:03:42 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 8F3ED3A686E for ; Tue, 18 May 2010 07:03:36 -0700 (PDT) Received: from [192.36.125.216] (dhcp-216.pilsnet.sunet.se [192.36.125.216] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o4IE3OCG004034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 16:03:26 +0200 (CEST) Message-ID: <4BF29E2C.3070007@sunet.se> Date: Tue, 18 May 2010 16:03:24 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Shawn M Emery Subject: Feed draft-ietf-kitten-gssapi-naming-exts-07.txt to the IESG X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:03:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since we passwd WGLC I updated to 07 and bumped the expiration date. Feel free to start the publication process using this version at any time you like. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvyniwACgkQ8Jx8FtbMZneJRgCfboYZUj8JacAAu56sNUX2KExG s7MAnjJosuMMCXjEWmmgFierkR/I8gOd =UzQ4 -----END PGP SIGNATURE----- From root@core3.amsl.com Tue May 18 07:15:05 2010 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A89B43A6BDB; Tue, 18 May 2010 07:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-kitten-gssapi-naming-exts-07.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100518141504.A89B43A6BDB@core3.amsl.com> Date: Tue, 18 May 2010 07:15:02 -0700 (PDT) Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 14:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Kitten (GSS-API Next Generation) Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : N. Williams, L. Johansson Filename : draft-ietf-kitten-gssapi-naming-exts-07.txt Pages : 14 Date : 2010-05-18 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-naming-exts-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-18070153.I-D@ietf.org> --NextPart-- From alexey.melnikov@isode.com Tue May 18 09:28:11 2010 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 B10763A69B2; Tue, 18 May 2010 09:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 dGnb34om+zIY; Tue, 18 May 2010 09:28:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8D67B28C1E4; Tue, 18 May 2010 09:20:43 -0700 (PDT) Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 May 2010 17:20:35 +0100 Message-ID: <4BF2BE33.8010106@isode.com> Date: Tue, 18 May 2010 17:20:03 +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 Subject: Re: MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <87iq6lu59z.fsf@mocca.josefsson.org> In-Reply-To: <87iq6lu59z.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Sean Turner , sasl@ietf.org, Tim Polk 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, 18 May 2010 16:28:11 -0000 Simon Josefsson wrote: >The charter looks fine to me. Do we have energy to also look at moving >RFC 4422 from Proposed to Draft? Unless I'm missing something, that >shouldn't be too complicated. I recall some implementation evaluation >has already started. > I wouldn't object to this, as long as I don't need to write the implementation report. I can contribute necessary information for the Cyrus SASL though. From alexey.melnikov@isode.com Tue May 18 10:31:59 2010 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 8C0DB28C1F9; Tue, 18 May 2010 10:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1GR-24eZT1z; Tue, 18 May 2010 10:31:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 017F53A69AA; Tue, 18 May 2010 10:28:00 -0700 (PDT) Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 May 2010 18:27:51 +0100 Message-ID: <4BF2CDF2.2090600@isode.com> Date: Tue, 18 May 2010 18:27:14 +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: Shawn Emery Subject: Re: [sasl] MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> In-Reply-To: <4BF221C1.2090005@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:31:59 -0000 Shawn Emery wrote: > As discussed; attached is the proposed charter text for a new working > group (MOGGIES) based on future direction in the GSS-API and SASL > space. Please provide any feed-back to the lists by the end of May. Thanks for writing a proposal. My comments below (without my AD hat): > Thank you, > > Shawn Emery and Tom Yu (co-chairs) ------------------------------------------------- >MOGGIES (Mechanisms Of Generating Generically Interoperable & Effective >Security) > > >Description of Working Group: > >The Generic Security Services (GSS) API and Simple Authentication and Security >Layer (SASL) provide various applications with a security framework for secure >network communication. The purpose of the Mechanisms Of Generating Generically >Interoperable & Effective Security (MOGGIES) working group (WG) is to develop >extensions/improvements to the GSS-API, shepherd specific GSS-API security >mechanisms, revise SASLprep with a stringprep profile from the NewPrep WG, > I think that SASLPrep should be done in the proposed newprep WG. There might be some bits that might be done in MOGGIES, but at this point I am not convinced there are any. I am Ok with the rest of your list. >and provide guidance for any new SASL-related submissions. > >This working is chartered to specify the following extensions and improvements >(draft-yu-kitten-api-wishlist-00) to the GSS-API: > >* Provide new interfaces for credential management, which include the following: > initializing credentials > iterating credentials > exporting/importing credentials > >* Specify interface for asynchronous calls. > >* Define interfaces for better error message reporting. > >* Specify an interface for reporting the security strength of GSS-API mechanism. > >* Provide a more programmer friendly interface for application developers. > >This working group is also chartered to transition proposed SASL mechanisms as >GSS-API mechanisms: > > What does this mean? Do you mean that they become GS2 mechanisms? >* A SASL Mechanism for OpenID > draft-lear-ietf-sasl-openid-00 >* A SASL Mechanism for SAML > draft-wierenga-ietf-sasl-saml-00 > >The transition from SASL to GSS-API mechanisms will allow a greater set of >applications to utilize said mechanisms with SASL implementations that support >the use of GSS-API mechanisms in SASL (RFC 5801). > RFC 5801 hasn't been published yet. So I don't think we should reference it. >The working group shall also revise SASLprep with a stringprep profile developed >by the NewPrep WG. > > See above. >This working group will review SASL related submissions as well, including any >new SASL mechanisms proposed. > IMHO, this is a bit open ended for IESG. Should we restrict this to SASL mechanisms, or are we saying that updates to SASL protocol profiles are also in scope? I think the answer is probably "no", although they should be reviewed here. On a somewhat related note: is there still any interest in publish "DIGEST-MD5-to-historic" document, or should I request its publication outside of a Sec Area WG? >Deliverables: > >* GSS-API: initializing credentials >[editor: TBD] > >* GSS-API: iterating credentials >[editor: TBD] > >* GSS-API: exporting/importing credentials >[editor: TBD] > >* GSS-API: specification for asynchronous calls >[editor: TBD] > >* GSS-API: interfaces/improvements for better error message reporting >[editor: TBD] > >* GSS-API: reporting security strength >[editor: TBD] > >* GSS-API: programmer friendly interfaces >[editor: TBD] > >* GSS-API: transition SASL mechanism for OpenID >[editor: TBD] > >* GSS-API: transition SASL mechanism for SAML >[editor: TBD] > >* SASL: Revise SASLprep with stringprep from the NewPrep WG >[editor: TBD] > > >Goals and Milestones: > >July 2010 First Meeting > >TBD Listed Work Items > From simon@josefsson.org Tue May 18 10:48:59 2010 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 3EF113A6B8D; Tue, 18 May 2010 10:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, 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 gZdpH1+W5FQy; Tue, 18 May 2010 10:48:58 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4C85C3A6CA5; Tue, 18 May 2010 10:47:31 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4IHlDg9019562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 May 2010 19:47:16 +0200 From: Simon Josefsson To: Alexey Melnikov Subject: Re: MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <87iq6lu59z.fsf@mocca.josefsson.org> <4BF2BE33.8010106@isode.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100518:sasl@ietf.org::sZVw4Ecq2MXSMo8Y:4Zch X-Hashcash: 1:22:100518:alexey.melnikov@isode.com::M136F5gIYyRPevPC:1/ir X-Hashcash: 1:22:100518:kitten@ietf.org::An954q0RO6Zt0+eC:6A6W X-Hashcash: 1:22:100518:tim.polk@nist.gov::VlNABa7nVpABAyOf:7Thj Date: Tue, 18 May 2010 19:47:13 +0200 In-Reply-To: <4BF2BE33.8010106@isode.com> (Alexey Melnikov's message of "Tue, 18 May 2010 17:20:03 +0100") Message-ID: <877hn19k66.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:48:59 -0000 Alexey Melnikov writes: > Simon Josefsson wrote: > >>The charter looks fine to me. Do we have energy to also look at moving >>RFC 4422 from Proposed to Draft? Unless I'm missing something, that >>shouldn't be too complicated. I recall some implementation evaluation >>has already started. >> > I wouldn't object to this, as long as I don't need to write the > implementation report. I can contribute necessary information for the > Cyrus SASL though. I now recall one issue that was causing trouble earlier: SASLprep. It wasn't clear (at least not to me) whether it is a good idea to move RFC 4422 to Draft as long as it referenced SASLprep. Now, the references to SASLprep only affect other specifications, not implementations, thus we might be able to dodge this issue completely by explaining that. On the other hand, perhaps we should punt on moving SASL to Draft Standard until we have some clear vision for the future of i18n in SASL. The SASLprep replacement work the WG likely will be chartered to take on may result in an update to RFC 4422, and we could move that replacement document to Draft Standard instead of RFC 4422. /Simon From alexey.melnikov@isode.com Tue May 18 10:50:28 2010 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 595CA3A6AA6; Tue, 18 May 2010 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_20=-0.74] 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 mOi12qTJ1nrj; Tue, 18 May 2010 10:50:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4D81A3A6AC6; Tue, 18 May 2010 10:49:23 -0700 (PDT) Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 18 May 2010 18:49:14 +0100 Message-ID: <4BF2D2F9.20305@isode.com> Date: Tue, 18 May 2010 18:48:41 +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 Subject: Re: MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <87iq6lu59z.fsf@mocca.josefsson.org> <4BF2BE33.8010106@isode.com> <877hn19k66.fsf@mocca.josefsson.org> In-Reply-To: <877hn19k66.fsf@mocca.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:50:28 -0000 Simon Josefsson wrote: >Alexey Melnikov writes: > > > >>Simon Josefsson wrote: >> >> >>>The charter looks fine to me. Do we have energy to also look at moving >>>RFC 4422 from Proposed to Draft? Unless I'm missing something, that >>>shouldn't be too complicated. I recall some implementation evaluation >>>has already started. >>> >>> >>I wouldn't object to this, as long as I don't need to write the >>implementation report. I can contribute necessary information for the >>Cyrus SASL though. >> >> >I now recall one issue that was causing trouble earlier: SASLprep. It >wasn't clear (at least not to me) whether it is a good idea to move RFC >4422 to Draft as long as it referenced SASLprep. Now, the references to >SASLprep only affect other specifications, not implementations, thus we >might be able to dodge this issue completely by explaining that. > >On the other hand, perhaps we should punt on moving SASL to Draft >Standard until we have some clear vision for the future of i18n in SASL. >The SASLprep replacement work the WG likely will be chartered to take on >may result in an update to RFC 4422, and we could move that replacement >document to Draft Standard instead of RFC 4422. > > Good point. From simon@josefsson.org Tue May 18 11:02:48 2010 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 5BA753A689D; Tue, 18 May 2010 11:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 kvpEyjXQo94Q; Tue, 18 May 2010 11:02:47 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D6EA73A6A76; Tue, 18 May 2010 11:02:39 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4II2QQr019993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 May 2010 20:02:28 +0200 From: Simon Josefsson To: Alexey Melnikov Subject: Re: [sasl] MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <4BF2CDF2.2090600@isode.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100518:shawn.emery@oracle.com::SQYsuTufsYD8wSYD:51H X-Hashcash: 1:22:100518:sasl@ietf.org::s5kjjRDwjMOUX6yx:8K4Y X-Hashcash: 1:22:100518:kitten@ietf.org::9QCormhZdolh+fG1:Eayn X-Hashcash: 1:22:100518:tim.polk@nist.gov::CdOaJsibcOFkqGsn:Wi3W X-Hashcash: 1:22:100518:alexey.melnikov@isode.com::L5tMYHfAyvZ7Es2R:aOOd Date: Tue, 18 May 2010 20:02:26 +0200 In-Reply-To: <4BF2CDF2.2090600@isode.com> (Alexey Melnikov's message of "Tue, 18 May 2010 18:27:14 +0100") Message-ID: <87ljbh84wd.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, sasl@ietf.org, Tim Polk 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, 18 May 2010 18:02:48 -0000 Alexey Melnikov writes: > On a somewhat related note: is there still any interest in publish > "DIGEST-MD5-to-historic" document, or should I request its publication > outside of a Sec Area WG? I'd like to see publishing this in the charter. We shouldn't let people use DIGEST-MD5 without a big warning, and I believe we can establish WG consensus around that. /Simon From Nicolas.Williams@oracle.com Tue May 18 12:16:49 2010 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 9EF2028C181; Tue, 18 May 2010 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.173 X-Spam-Level: X-Spam-Status: No, score=-4.173 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 hUpMXR1PJxJh; Tue, 18 May 2010 12:16:47 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 898153A6AC0; Tue, 18 May 2010 12:16:47 -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.1) with ESMTP id o4IJGZCN004675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 19:16:37 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4IJGVVq022396; Tue, 18 May 2010 19:16:31 GMT Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 277283101274210127; Tue, 18 May 2010 12:15:27 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 12:15:26 -0700 Date: Tue, 18 May 2010 14:15:22 -0500 From: Nicolas Williams To: Shawn Emery Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <20100518191521.GL9429@oracle.com> References: <4BF221C1.2090005@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF221C1.2090005@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090203.4BF2E796.0097:SCFMA4539811,ss=1,fgs=0 Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 19:16:49 -0000 On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: > As discussed; attached is the proposed charter text for a new > working group (MOGGIES) based on future direction in the GSS-API and > SASL space. Please provide any feed-back to the lists by the end of > May. I don't love the name (I keep thinking "MOOGIES", which sounds like something gross :), but I'll live; I have no better suggestions. > * Specify an interface for reporting the security strength of GSS-API mechanism. I'd word that differently: * Specify an interface for enforcing security strength of GSS-API mechanisms. The reason is that "reporting the security strength" of something implies [to me] an absolute measure of security strength, and I don't think it's possible to degisn a good, _stable_, absolute measure of security strength. > This working group will review SASL related submissions as well, including any > new SASL mechanisms proposed. New SASL mechanisms? Why not new GSS-API mechanisms? Why not close the WG (and even SASL) to new non-GS2 mechanisms? Might there be conflicts with EMU? Nico -- From jaltman@secure-endpoints.com Tue May 18 12:29:56 2010 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 143EF3A699C for ; Tue, 18 May 2010 12:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.304 X-Spam-Level: X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_05=-1.11, 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 AoezH72MhaqF for ; Tue, 18 May 2010 12:29:55 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 146FA3A69D8 for ; Tue, 18 May 2010 12:29:53 -0700 (PDT) Received: from www.secure-endpoints.com (cpe-24-193-47-88.nyc.res.rr.com [24.193.47.88]) (user=jea31 mech=LOGIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id o4IJTiNN029854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 May 2010 15:29:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1274210938; x=1274815738; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=11AtvTbAEA1kGGg8FW S2SdkgER6o4xHg+hGdOP8dju4=; b=ICGqyP0XY/M1ZSxhhbsBe9VbMqXlg8n2f8 sctWWP1kg7Ax1heN8Y7jGrDx6YVlTxhZBOcxgX8CzvWYxKyexpXiQA3bhkmDigwp BBjO3u05m7gmEMwbV6TGDIOiP1e2HIHnMYwt2tBFN/UlJVyu0PY1hPPZ3SlYnHu1 z1eAfhS1s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=OnRzITKA/bJvcTWrAi2aVtFarLXcwRPEuslnaadmNdcub4dLvPbvHwWiPB1/ 1jxMOOd4W/65zzahzL4jiSgLzaT8zSI8B1DnhvYoqpTzSsJ/5+qwpj+h1 hAlCHmcafsrxUvSXnKHc+rHuOn0TMuINMsA8crKSKVVQYeKxOLutk8=; X-MDAV-Processed: www.secure-endpoints.com, Tue, 18 May 2010 15:28:58 -0400 Received: from [192.168.1.17] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v11.0.1) with ESMTP id md50000239362.msg for ; Tue, 18 May 2010 15:28:57 -0400 X-Spam-Processed: www.secure-endpoints.com, Tue, 18 May 2010 15:28:57 -0400 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <4BF2EAA2.2000600@secure-endpoints.com> Date: Tue, 18 May 2010 15:29:38 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4 MIME-Version: 1.0 To: kitten@ietf.org Subject: Re: [sasl] MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com> In-Reply-To: <20100518191521.GL9429@oracle.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030104060408020208060302" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 19:29:56 -0000 This is a cryptographically signed message in MIME format. --------------ms030104060408020208060302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/18/2010 3:15 PM, Nicolas Williams wrote: > On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: >> As discussed; attached is the proposed charter text for a new >> working group (MOGGIES) based on future direction in the GSS-API and >> SASL space. Please provide any feed-back to the lists by the end of >> May. >=20 > I don't love the name (I keep thinking "MOOGIES", which sounds like > something gross :), but I'll live; I have no better suggestions. I think the charter is fine but I too object to the name. Kitten was funny because the predecessor has the acronym of CAT. I don't think MOGGIES is funny. Perhaps if you figured out how to turn it into DOGGIES or PUPPIES. I would much prefer a working group name that had an easy to understand meaning at first glance. Jeffrey Altman --------------ms030104060408020208060302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEAMF9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoX DTEwMDgyODA0MDExOVowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDZNscYIvF6xzGSAfa/QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6 y0zlFqSbiFwgNM8m69K6m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWL kNdaXQKk6EZVW9pfV2A4Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iE jVhVzPobuZzwD2tuepY/bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1Zp Yh8Fx+9cqsG8O4nqo26SVfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOK ifHDyLZQC4qSsCUfP7vdwAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/Z cW3icObO9FIZCSmgFMt2Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAxcwggKAoAMCAQICEAMF 9RTCGOz151fTpHLih+cwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyODA0MDExOVoXDTEwMDgyODA0MDExOVow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDZNscYIvF6xzGSAfa/ QUIqiElyn0EUxL2b86eKiYqe91bj0gLr/MJoErLnb+OmokxqSAH6y0zlFqSbiFwgNM8m69K6 m/6YO+x3+5zBc+u6snwTWMEWygnhx3rQ/lMhoQOgArraL+/k9aWLkNdaXQKk6EZVW9pfV2A4 Lk4DoZGFjY8tJRWWDLlFkYnxDuIEpLYwJpwakv3QHOaq/G8KW0iEjVhVzPobuZzwD2tuepY/ bsClwqxz/gfAEpUvAn/lYTqnoT7RYljZlCIdbrgcG/HSYMxAy1ZpYh8Fx+9cqsG8O4nqo26S VfYZvrYhh8m6OqW8Vakdt7vBLCTa/QhIdJ4hAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOB gQBvbvJNXUJ4atv1CExIe0J38jZqoEUTttkXOfCDT9e3mSmVboOKifHDyLZQC4qSsCUfP7vd wAXjKtjak22HbfX2sEKCUgtnOkxRqXMM2V/NW/ESNVQZF0TO7L/ZcW3icObO9FIZCSmgFMt2 Al7VPfMQmaJNlqu9SLmXSwbRFJ5b4zCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIID bQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ AwX1FMIY7PXnV9OkcuKH5zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA1MTgxOTI5MzhaMCMGCSqGSIb3DQEJBDEWBBQKapt+ aWzZQM5z9zZNsGuIXw65PTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAhADBfUUwhjs9edX06Ry4ofnMIGHBgsqhkiG9w0BCRACCzF4oHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhADBfUUwhjs 9edX06Ry4ofnMA0GCSqGSIb3DQEBAQUABIIBACCQaxZ9GuvMQ/+kzUZ57Sl0BoL+JnF1ic0k xnu4rd1HXETAAeVW4WP9Ta2QqU7k9BcoZp+cGbqpiTJcLgbqodx+KgDSYx/YTPiWEMX7l3yC FACQORdCpMO+M/s2u4Eqtk82WEgPaqm7jQXd+44u9ObuC2CQBOGNBRpftywsnn8fcD970Eg+ sXJIXkUhgwm11La83Vn/FaogndDiiH8y4UzqOXaTw6TUoZIWBLGcolzxjnwKTEXRz6FhxJ3/ TP3zf/H9WQyL5Jk43D4rGExrwvzD6Cx4ju4FcfXWl3ggQDDyKgCIL8KpiC8wy3/IplqXgI46 Z1WckzWgW6+IWLhA2qAAAAAAAAA= --------------ms030104060408020208060302-- From Nicolas.Williams@oracle.com Tue May 18 12:48:13 2010 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 7C4703A6ADE for ; Tue, 18 May 2010 12:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.095 X-Spam-Level: X-Spam-Status: No, score=-4.095 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 eFdtpmyDE90O for ; Tue, 18 May 2010 12:48:12 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 882053A6AB4 for ; Tue, 18 May 2010 12:48:12 -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.1) with ESMTP id o4IJm2cI028871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 19:48:04 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4IJjLrb014108; Tue, 18 May 2010 19:48:02 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 277663751274212042; Tue, 18 May 2010 12:47:22 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 12:47:22 -0700 Date: Tue, 18 May 2010 14:47:17 -0500 From: Nicolas Williams To: Jeffrey Altman Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <20100518194717.GN9429@oracle.com> References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com> <4BF2EAA2.2000600@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BF2EAA2.2000600@secure-endpoints.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090205.4BF2EEF4.014C:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 19:48:13 -0000 On Tue, May 18, 2010 at 03:29:38PM -0400, Jeffrey Altman wrote: > On 5/18/2010 3:15 PM, Nicolas Williams wrote: > > On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: > >> As discussed; attached is the proposed charter text for a new > >> working group (MOGGIES) based on future direction in the GSS-API and > >> SASL space. Please provide any feed-back to the lists by the end of > >> May. > > > > I don't love the name (I keep thinking "MOOGIES", which sounds like > > something gross :), but I'll live; I have no better suggestions. > > I think the charter is fine but I too object to the name. > Kitten was funny because the predecessor has the acronym of CAT. > I don't think MOGGIES is funny. Perhaps if you figured out how to > turn it into DOGGIES or PUPPIES. KITTEN wasn't an acronym... A completely uncreative acronym: - SAGSS (Simple Authentication and GSS) Slightly more creative acronym: - 2PALS (Two Peer Application Layer Security) (This one is kinda neat, if I do say so myself, though it could be seen to conflict with TLS.) Funny WG names in the KITTEN tradition: - GASSS (Generic And Simple Security Services) - SASSY (not an acronym) - anything like TIGER, LION, ... (KITTEN, "growed up") - HELLO [KITTy] I like a fair number (four) of the above, and not just 'cause I came up with them :) Nico -- From jhutz@cmu.edu Tue May 18 14:09:28 2010 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 063A13A6ACE; Tue, 18 May 2010 14:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_40=-0.185, 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 QUiSEebDfNKm; Tue, 18 May 2010 14:09:27 -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 0E8363A6AD1; Tue, 18 May 2010 14:09:26 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IL9Hcc001108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 17:09:17 -0400 (EDT) Date: Tue, 18 May 2010 17:09:17 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Shawn Emery Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> In-Reply-To: <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org, jhutz@cmu.edu 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, 18 May 2010 21:09:28 -0000 --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams wrote: > On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: >> As discussed; attached is the proposed charter text for a new >> working group (MOGGIES) based on future direction in the GSS-API and >> SASL space. Please provide any feed-back to the lists by the end of >> May. > > I don't love the name (I keep thinking "MOOGIES", which sounds like > something gross :), but I'll live; I have no better suggestions. I don't even _understand_ the name. Or the expansion. Can't we have something that doesn't make me (and anyone not already familiar with what we're working on) go "Huh?" ? >> This working group will review SASL related submissions as well, >> including any new SASL mechanisms proposed. > > New SASL mechanisms? Why not new GSS-API mechanisms? Why not close the > WG (and even SASL) to new non-GS2 mechanisms? Might there be conflicts > with EMU? This WG should review proposals for new SASL and GSS-API mechanisms, and such work should be considered to fall within its general scope, but it should be constrained to actually work only on mechanisms specifically listed in the charter. If we want to work on a new mechanism, we can amend the charter. It should also be willing to provide advice and review on non-mechanism proposals such as defining use of SASL or GSS-API in a new or existing protocol. However, actual work on such proposals should be done in the relevant WG for the protocol in question, and _not_ in the new one. -- Jeff From Nicolas.Williams@oracle.com Tue May 18 14:39:13 2010 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 C65443A6A71; Tue, 18 May 2010 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.394 X-Spam-Level: X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=1.204, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 irZWgmOjDU49; Tue, 18 May 2010 14:39:12 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CF03B3A68FC; Tue, 18 May 2010 14:39:12 -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.1) with ESMTP id o4ILd0nD011485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 May 2010 21:39:01 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4IJStsQ032403; Tue, 18 May 2010 21:38:59 GMT Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 278280271274218726; Tue, 18 May 2010 14:38:46 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 May 2010 14:38:45 -0700 Date: Tue, 18 May 2010 16:38:40 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <20100518213840.GO9429@oracle.com> References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090203.4BF308F7.002B:SCFMA4539811,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org, Tim Polk 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, 18 May 2010 21:39:13 -0000 On Tue, May 18, 2010 at 05:09:17PM -0400, Jeffrey Hutzelman wrote: > >New SASL mechanisms? Why not new GSS-API mechanisms? Why not close the > >WG (and even SASL) to new non-GS2 mechanisms? Might there be conflicts > >with EMU? > > This WG should review proposals for new SASL and GSS-API mechanisms, > and such work should be considered to fall within its general scope, > but it should be constrained to actually work only on mechanisms > specifically listed in the charter. If we want to work on a new > mechanism, we can amend the charter. OK, which mechanisms, if any should the WG work on? We have SCRAM, we have GS2, we have RFC4121, and KRB-WG will work on IAKERB. That leaves only PKU2U, and that'd be up to Larry. > It should also be willing to provide advice and review on > non-mechanism proposals such as defining use of SASL or GSS-API in a > new or existing protocol. However, actual work on such proposals > should be done in the relevant WG for the protocol in question, and > _not_ in the new one. Indeed. From jhutz@cmu.edu Tue May 18 15:36:54 2010 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 9B58D3A6877; Tue, 18 May 2010 15:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVFvkYetTtEm; Tue, 18 May 2010 15:36:53 -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 ADD6C3A685F; Tue, 18 May 2010 15:36:53 -0700 (PDT) Received: from [192.168.1.109] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4IMag5p011570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 May 2010 18:36:44 -0400 (EDT) Date: Tue, 18 May 2010 18:36:42 -0400 From: Jeffrey Hutzelman To: Nicolas Williams Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <184AE5042EA2EBECF7E0D5EE@atlantis.pc.cs.cmu.edu> In-Reply-To: <20100518213840.GO9429@oracle.com> References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <20100518213840.GO9429@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, jhutz@cmu.edu, sasl@ietf.org, Tim Polk 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, 18 May 2010 22:36:54 -0000 --On Tuesday, May 18, 2010 04:38:40 PM -0500 Nicolas Williams wrote: > On Tue, May 18, 2010 at 05:09:17PM -0400, Jeffrey Hutzelman wrote: >> > New SASL mechanisms? Why not new GSS-API mechanisms? Why not close >> > the WG (and even SASL) to new non-GS2 mechanisms? Might there be >> > conflicts with EMU? >> >> This WG should review proposals for new SASL and GSS-API mechanisms, >> and such work should be considered to fall within its general scope, >> but it should be constrained to actually work only on mechanisms >> specifically listed in the charter. If we want to work on a new >> mechanism, we can amend the charter. > > OK, which mechanisms, if any should the WG work on? The ones already in the proposed charter. From simon@josefsson.org Tue May 18 23:32:04 2010 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 5F0B73A689E; Tue, 18 May 2010 23:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 W4CKyKgjLtqr; Tue, 18 May 2010 23:32:03 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4F8493A6964; Tue, 18 May 2010 23:32:01 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4J6VhOm004562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 May 2010 08:31:45 +0200 From: Simon Josefsson To: Jeffrey Hutzelman Subject: Re: MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100519:shawn.emery@oracle.com::3xEXT8jMoqgLCumM:0h2T X-Hashcash: 1:22:100519:jhutz@cmu.edu::gqW11CC0sR6l45q+:7DJ8 X-Hashcash: 1:22:100519:tim.polk@nist.gov::+QEdwUwVmg0Mmmlc:B41r X-Hashcash: 1:22:100519:kitten@ietf.org::WQmcHT2vBuGQayYg:EE/9 X-Hashcash: 1:22:100519:sasl@ietf.org::gJs7aqmsn8rZ0LGa:Efmm X-Hashcash: 1:22:100519:nicolas.williams@oracle.com::dwhTi0/5QfrMwQLQ:S9yO Date: Wed, 19 May 2010 08:31:43 +0200 In-Reply-To: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 18 May 2010 17:09:17 -0400") Message-ID: <878w7gv1v4.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 06:32:04 -0000 Jeffrey Hutzelman writes: > --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams > wrote: > >> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: >>> As discussed; attached is the proposed charter text for a new >>> working group (MOGGIES) based on future direction in the GSS-API and >>> SASL space. Please provide any feed-back to the lists by the end of >>> May. >> >> I don't love the name (I keep thinking "MOOGIES", which sounds like >> something gross :), but I'll live; I have no better suggestions. > > I don't even _understand_ the name. Or the expansion. > Can't we have something that doesn't make me (and anyone not already > familiar with what we're working on) go "Huh?" ? +1 I would prefer something self-explanatory, like SASLGSS. /Simon From abartlet@samba.org Wed May 19 01:26:20 2010 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 85D9A3A6C69; Wed, 19 May 2010 01:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 Y5dqZm7BUdMk; Wed, 19 May 2010 01:26:19 -0700 (PDT) Received: from lists.samba.org (fn.samba.org [216.83.154.106]) by core3.amsl.com (Postfix) with ESMTP id 78EC33A6BC8; Wed, 19 May 2010 01:21:13 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 6D035AD237; Wed, 19 May 2010 02:21:07 -0600 (MDT) Subject: Re: MOGGIES Proposed Charter From: Andrew Bartlett To: Simon Josefsson In-Reply-To: <878w7gv1v4.fsf@mocca.josefsson.org> References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <878w7gv1v4.fsf@mocca.josefsson.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-3leGN7Mk8uM3f7tTUtn0" Date: Wed, 19 May 2010 16:42:03 +1000 Message-ID: <1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 (2.30.1.2-2.fc13) Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org, Jeffrey Hutzelman 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, 19 May 2010 08:26:20 -0000 --=-3leGN7Mk8uM3f7tTUtn0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-05-19 at 08:31 +0200, Simon Josefsson wrote: > Jeffrey Hutzelman writes: >=20 > > --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams > > wrote: > > > >> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: > >>> As discussed; attached is the proposed charter text for a new > >>> working group (MOGGIES) based on future direction in the GSS-API and > >>> SASL space. Please provide any feed-back to the lists by the end of > >>> May. > >> > >> I don't love the name (I keep thinking "MOOGIES", which sounds like > >> something gross :), but I'll live; I have no better suggestions. > > > > I don't even _understand_ the name. Or the expansion. > > Can't we have something that doesn't make me (and anyone not already > > familiar with what we're working on) go "Huh?" ? >=20 > +1 >=20 > I would prefer something self-explanatory, like SASLGSS. Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun. =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-3leGN7Mk8uM3f7tTUtn0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBL84g6z4A8Wyi0NrsRAkXuAKCf1zbWv6/ZXqIw6UhmXGjBRBNjwACfdBpg sVXZ1l0iU4ys/Z9A5SEr3GU= =LJhW -----END PGP SIGNATURE----- --=-3leGN7Mk8uM3f7tTUtn0-- From alexey.melnikov@isode.com Wed May 19 02:01:24 2010 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 480EE3A687C; Wed, 19 May 2010 02:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 D8rWJ0CNvxo2; Wed, 19 May 2010 02:01:23 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BB1A53A6829; Wed, 19 May 2010 02:01:20 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 May 2010 10:01:12 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4BF3A8D5.8070905@isode.com> Date: Wed, 19 May 2010 10:01:09 +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: Jeffrey Hutzelman Subject: Re: [sasl] MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> In-Reply-To: <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 May 2010 09:01:24 -0000 Jeffrey Hutzelman wrote: > --On Tuesday, May 18, 2010 02:15:22 PM -0500 Nicolas Williams > wrote: > >> On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: > [...] >>> This working group will review SASL related submissions as well, >>> including any new SASL mechanisms proposed. >> >> New SASL mechanisms? Why not new GSS-API mechanisms? Why not close the >> WG (and even SASL) to new non-GS2 mechanisms? Might there be conflicts >> with EMU? > > This WG should review proposals for new SASL and GSS-API mechanisms, > and such work should be considered to fall within its general scope, > but it should be constrained to actually work only on mechanisms > specifically listed in the charter. If we want to work on a new > mechanism, we can amend the charter. +1. > It should also be willing to provide advice and review on > non-mechanism proposals such as defining use of SASL or GSS-API in a > new or existing protocol. However, actual work on such proposals > should be done in the relevant WG for the protocol in question, and > _not_ in the new one. I think I was quite clear on this in my reply, but in case I wasn't: +1. From alexey.melnikov@isode.com Wed May 19 02:37:12 2010 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 2476E3A6C1E; Wed, 19 May 2010 02:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.386, 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 MIT1AU2bUKsT; Wed, 19 May 2010 02:37:11 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C646D28C13F; Wed, 19 May 2010 02:31:37 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 19 May 2010 10:31:29 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4BF3AFEC.3030206@isode.com> Date: Wed, 19 May 2010 10:31:24 +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: Nicolas Williams Subject: Re: [sasl] MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com> In-Reply-To: <20100518191521.GL9429@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, sasl@ietf.org, Tim Polk 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, 19 May 2010 09:37:12 -0000 Nicolas Williams wrote: >On Mon, May 17, 2010 at 11:12:33PM -0600, Shawn Emery wrote: > > [...] >>This working group will review SASL related submissions as well, including any >>new SASL mechanisms proposed. >> >> >New SASL mechanisms? Why not new GSS-API mechanisms? Why not close the >WG (and even SASL) to new non-GS2 mechanisms? Might there be conflicts >with EMU? > > I don't think there is immediate overlap with EMU, although I think this needs a bit more investigation. From jhutz@cmu.edu Wed May 19 10:49:18 2010 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 08B053A6C32; Wed, 19 May 2010 10:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HVeFGzU8Bge; Wed, 19 May 2010 10:49:17 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 308DB3A6BDE; Wed, 19 May 2010 10:49:17 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4JHn6Ux004918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 May 2010 13:49:07 -0400 (EDT) Date: Wed, 19 May 2010 13:49:06 -0400 From: Jeffrey Hutzelman To: Andrew Bartlett , Simon Josefsson Subject: Re: MOGGIES Proposed Charter Message-ID: <581E1885DAD3191FAA4B0B8C@minbar.fac.cs.cmu.edu> In-Reply-To: <8205_1274257577_o4J8QGwT009700_1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net> References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <878w7gv1v4.fsf@mocca.josefsson.org> <8205_1274257577_o4J8QGwT009700_1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org, jhutz@cmu.edu 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, 19 May 2010 17:49:18 -0000 --On Wednesday, May 19, 2010 04:42:03 PM +1000 Andrew Bartlett wrote: >> I would prefer something self-explanatory, like SASLGSS. > > Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun. Again, huh? From alper.yegin@yegin.org Thu May 20 07:21:02 2010 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 9BCC13A6C1F; Thu, 20 May 2010 07:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.841 X-Spam-Level: ** X-Spam-Status: No, score=2.841 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449] 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 4ERZqeqb0nKo; Thu, 20 May 2010 07:21:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 089CB3A6D1E; Thu, 20 May 2010 07:18:30 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0McV0i-1NxRCR26oS-00ILjz; Thu, 20 May 2010 10:18:22 -0400 From: "Alper Yegin" To: "'Sam Hartman'" , References: In-Reply-To: Subject: RE: [Emu] Summary of Federated Authentication BOF at IETF 77 Date: Thu, 20 May 2010 17:18:03 +0300 Message-ID: <005901caf827$47550e50$d5ff2af0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcrzmpQtoe7feQCCSLaIZxkt3D10hAEieX7w X-Provags-ID: V01U2FsdGVkX1/mPFLphe2SPqjXDe021MnJkKkCUHZ4nAOUMrP hcVHFt1DfioBapz3SkNWtYt3RKfmiyWn3ctaColu6AsYd3FSTY 6mwrQ9uPvVE9jy5zfh44BntHk+wCvXY X-Mailman-Approved-At: Thu, 20 May 2010 09:15:19 -0700 Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 14:21:03 -0000 Hello, I have a comment about use of EAP in this context. Folks might remember the ICOS BoF held during IETF 62. Discussions at that meeting, around that era, and since then have been always pointing to the applicability statement of EAP and more-or-less blocking the use of EAP for anything other than network access. EAP RFC 3748: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. See the meeting notes at http://www.ietf.org/proceedings/62/icos.html, especially Sam's (SEC AD at that time): Sam: Although having a lot of EAP methods is complicated, deploying new credentials is also hard. I think the uses of EAP that were discussed here are close enough to network access that I could see the connection. But when EAP was expaned from PPP to other uses, a lot of new work was required; if we expand EAP to services in general, we need at least the same amount of work. We might want to check that there are no better solutions. So if you're using EAP for something totally else than network access authentication, please talk to me earlier rather than later. I'm not against using EAP for arbitrary applications. If this is where we are getting at in IETF, I'm hoping this gets proper consideration bridging where we were 5 years ago and today. Was this discussed? Is there a proposal to expand the applicability statement of EAP now? Where do we draw the new line now? Thanks in advance. Alper > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Friday, May 14, 2010 10:20 PM > To: saag@mit.edu > Cc: kitten@ietf.org; moonshot-community@jiscmail.ac.uk; emu@ietf.org > Subject: [Emu] Summary of Federated Authentication BOF at IETF 77 > > > > I'm told there were around 30 people in the room. That seemed like a > good turn out for Thursday at 9 PM. > > Many of the participants had already read some or all of the proposed > documents. > I presented a problem statement based on providing federated > authentication for non-web applications. > Two solutions were presented. I presented work on Moonshot, a > technology that combines EAP, GSS-API, RADIUS and SAML to solve the > problem. Eliot Lear and Klaas Wierenga presented a simpler solution > that uses browser-based SAML and Open ID. > > The sense of the room was that these solutions compliment each other. > Moonshot requires more infrastructure and client configuration but > provides several advantages. The browser-based solutions are something > that requires fewer client changes. > > Volunteers were collected from the EAP, GSS and RADIUS communities who > would be interested in working on these problems. Some of the work > discussed, possibly especially including the Open ID and SAML > browser-based solutions may be able to progress in kitten. I and I > believe several of the other Moonshot proponents would prefer to focus > the Moonshot work in one working group. Other solutions could also be > progressed in that group, although we should be careful not to slow > down > work that could progress quickly in kitten by moving it into an > as-yet-unchartered group. > > There seemed to be strong support for going forward. However, several > things to address in a BOF were raised with regard to the Moonshot > work. > > * Steve Bellovin pointed out that we need to be very aware of the > operational impact and how this fits with the operational model of > the > technologies that are used/extended. > > * Klaas pointed out that Moonshot involves changes to a lot of > different > components. We need to make sure that there are incremental > advantages to each of these changes so they will be deployed: a > system > where there is no benefit until the end when all the peaces fall > together is much harder to deploy. > > * Klaas pointed out that we need to consider the operational security > around how RADIUS federations are deployed. If network access is not > considered sensitive today, people may be more lax in the security > surrounding their RADIUS infrastructure. If we use that > infrastructure to secure more sensitive resources we need to have > practices that tighten up the security of the infrastructure > sufficiently. > > * Someone brought up that this is another one of those authentication > proposals where user-interface is critical. While we should not lay > out dialogues in the IETF, we're going to need to describe the > usability aspects of this enough to increase the probability of a > good > security solution. > > People specifically asked to look at the following: > * Complexity > * What can't be handled with simpler solutions > * Is Moonshot broad enough in scope? > * The UI questions > > Since the bar BOF, there has been a lot of traffic on the list and work > continues. > We're definitely going to put together a BOF request for IETF 78. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From mrex@sap.com Thu May 20 15:39:05 2010 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 ACE503A696C; Thu, 20 May 2010 15:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.75 X-Spam-Level: X-Spam-Status: No, score=-7.75 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_50=0.001, 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 l85ChN1nN8Zd; Thu, 20 May 2010 15:39:04 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 66BF83A6A20; Thu, 20 May 2010 15:38:31 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4KMcNZZ025561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 00:38:23 +0200 (MEST) From: Martin Rex Message-Id: <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> Subject: Re: [sasl] MOGGIES Proposed Charter To: Nicolas.Williams@oracle.com (Nicolas Williams) Date: Fri, 21 May 2010 00:38:22 +0200 (MEST) In-Reply-To: <20100518191521.GL9429@oracle.com> from "Nicolas Williams" at May 18, 10 02:15:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: kitten@ietf.org, sasl@ietf.org, tim.polk@nist.gov 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: Thu, 20 May 2010 22:39:05 -0000 Nicolas Williams wrote: > > > > * Specify an interface for reporting the security strength of > > GSS-API mechanism. > > I'd word that differently: > > * Specify an interface for enforcing security strength of GSS-API mechanisms. > > The reason is that "reporting the security strength" of something > implies [to me] an absolute measure of security strength, and I don't > think it's possible to design a good, _stable_, absolute measure of > security strength. I think that the comparable strength measured in "Bits of security" as used by NIST SP800-57 section 5.6.1 should be sufficiently stable. What changes over time is the amount of "strength" that one considers secure. fairly stable gradually fading Bits of characterisation of strength security <40 ridiculously weak 40 extremely weak 56 very weak 64 weak 80 mediocre 96 fair 112 good 128 strong >128 very strong -Martin From Nicolas.Williams@oracle.com Thu May 20 15:57:37 2010 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 3A9D83A6885; Thu, 20 May 2010 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.134 X-Spam-Level: X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 uYnWYJUb18ZU; Thu, 20 May 2010 15:57:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 521253A6875; Thu, 20 May 2010 15:57:36 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KMvQL6018957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 May 2010 22:57:28 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4KJg4Bv026693; Thu, 20 May 2010 22:57:26 GMT Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 255656301274396214; Thu, 20 May 2010 15:56:54 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 May 2010 15:56:54 -0700 Date: Thu, 20 May 2010 17:56:47 -0500 From: Nicolas Williams To: Martin Rex Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <20100520225647.GX9605@oracle.com> References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090208.4BF5BE58.0224:SCFMA4539811,ss=1,fgs=0 Cc: kitten@ietf.org, sasl@ietf.org, tim.polk@nist.gov 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, 20 May 2010 22:57:37 -0000 On Fri, May 21, 2010 at 12:38:22AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > I'd word that differently: > > > > * Specify an interface for enforcing security strength of GSS-API mechanisms. > > > > The reason is that "reporting the security strength" of something > > implies [to me] an absolute measure of security strength, and I don't > > think it's possible to design a good, _stable_, absolute measure of > > security strength. > > I think that the comparable strength measured in "Bits of security" > as used by NIST SP800-57 section 5.6.1 should be sufficiently stable. I don't. I'd much rather be able to ask for a credential or context that meets a given security profile, or to check what profiles a given credential or context meets. The profiles should be named Possible profile names and semantics: - FIPS-140-x -> obvious semantics (FIPS-140-x compliant cipher suites) - -> obvious semantics - Strong -> obvious-but-local semantics - Fast -> obvious-but-local semantics - Interoperable -> standard, per-mechanism semantics - Weak -> standard, per-mechanism semantics (basically: interoperable cipher suites + obsolete suites) - Local-* -> locally-defined profile names and semantics > What changes over time is the amount of "strength" that one considers > secure. Not only. Cryptanalysis progresses and the relative strengths of various algorithms can vary. I abhor anything remotely like a quantification of cryptographic strength, and will for the forseeable future. Nico -- From mrex@sap.com Fri May 21 14:54:38 2010 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 758E33A67F6; Fri, 21 May 2010 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.747 X-Spam-Level: X-Spam-Status: No, score=-7.747 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_50=0.001, 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 yHaHPqip-3Ib; Fri, 21 May 2010 14:54:37 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 656C73A659A; Fri, 21 May 2010 14:54:33 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o4LKBDNQ020669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 22:11:13 +0200 (MEST) Received: from fs4113.wdf.sap.corp (fs4113.wdf.sap.corp [10.21.76.84]) by mail.sap.corp (mail03-25) with ESMTP id o4LKBCuA006580 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 21 May 2010 22:11:13 +0200 (MEST) Received: (from d019080@localhost) by fs4113.wdf.sap.corp (8.13.4+Sun/8.13.4/Submit) id o4LKBBFk012803; Fri, 21 May 2010 22:11:11 +0200 (MEST) From: Martin Rex Message-Id: <201005212011.o4LKBBFk012803@fs4113.wdf.sap.corp> Subject: Re: MOGGIES Proposed Charter< To: simon@josefsson.org (Simon Josefsson) Date: Fri, 21 May 2010 22:11:11 +0200 (MEST) In-Reply-To: <878w7gv1v4.fsf@mocca.josefsson.org> from "Simon Josefsson" at May 19, 10 08:31:43 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org, jhutz@cmu.edu 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, 21 May 2010 21:54:38 -0000 Simon Josefsson wrote: > > Jeffrey Hutzelman writes: > > > > wrote: > > > [..."MOGGIES"...] > > > > > > I don't love the name (I keep thinking "MOOGIES", which sounds like > > > something gross :), but I'll live; I have no better suggestions. > > > > I don't even _understand_ the name. Or the expansion. > > Can't we have something that doesn't make me (and anyone not already > > familiar with what we're working on) go "Huh?" ? I had to look up the term MOGGIES in a dictionary. The meaning of the expansion appears a little weird/non-intuitive to me. > > I would prefer something self-explanatory, like SASLGSS. Do we need to rename Kitten at all? How about "KittenS" ? -Martin From tlyu@mit.edu Fri May 21 15:43:46 2010 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 4F1F23A6A59; Fri, 21 May 2010 15:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.867 X-Spam-Level: X-Spam-Status: No, score=-0.867 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpDtg10-ILUk; Fri, 21 May 2010 15:43:45 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU [18.7.68.36]) by core3.amsl.com (Postfix) with ESMTP id 02C1E3A6942; Fri, 21 May 2010 15:43:44 -0700 (PDT) X-AuditID: 12074424-b7b9dae000002832-1e-4bf70c9af6bc Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by dmz-mailsec-scanner-7.mit.edu (Symantec Brightmail Gateway) with SMTP id 65.0A.10290.A9C07FB4; Fri, 21 May 2010 18:43:38 -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 o4LMhblE031336; Fri, 21 May 2010 18:43:37 -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 o4LMhZgV020165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 May 2010 18:43:36 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4LMhZ5Q004255; Fri, 21 May 2010 18:43:35 -0400 (EDT) To: Nicolas Williams Subject: Re: [sasl] MOGGIES Proposed Charter References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> From: Tom Yu Date: Fri, 21 May 2010 18:43:35 -0400 In-Reply-To: <20100520225647.GX9605@oracle.com> (Nicolas Williams's message of "Thu, 20 May 2010 17:56:47 -0500") Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 22:43:46 -0000 Nicolas Williams writes: > On Fri, May 21, 2010 at 12:38:22AM +0200, Martin Rex wrote: > >> What changes over time is the amount of "strength" that one considers >> secure. > > Not only. Cryptanalysis progresses and the relative strengths of > various algorithms can vary. > > I abhor anything remotely like a quantification of cryptographic > strength, and will for the forseeable future. The meaning of "security strength" can be made fairly precise by definitions involving, for example, the base 2 logarithm of the time or space complexity of attacking an algorithm, e.g., NIST SP 800-57, Part 1, Section 5.6.1. That text gives the example of three-key triple DES, which has 168 bits of key material and has 112 bits of effective security strength. Yes, this means that you may have to revise the numeric "security strength" that you report for a given cryptographic association as new cryptanalytic attacks are discovered, but you would have to do that anyway with a non-numeric method of reporting "security strength". As I understand it, defeating an algorithm with a security strength of 128 bits approaches or exceeds reasonable information-theoretic bounds on the computational capacity of the universe, unless you consider quantum computing to be a credible threat. I expect that the amount of "strength" that we consider secure is unlikely to change unless tremendous advances occur in the realm of quantum computing. From Nicolas.Williams@oracle.com Fri May 21 16:11:07 2010 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 0A0F13A6A99; Fri, 21 May 2010 16:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.133 X-Spam-Level: X-Spam-Status: No, score=-4.133 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 eZYosepT0Q2B; Fri, 21 May 2010 16:11:05 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 41D883A6A95; Fri, 21 May 2010 16:11:05 -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.1) with ESMTP id o4LNAtqU011778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 23:10:57 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LMbYaK022976; Fri, 21 May 2010 23:10:55 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 289445551274483346; Fri, 21 May 2010 16:09:06 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 16:09:05 -0700 Date: Fri, 21 May 2010 18:09:00 -0500 From: Nicolas Williams To: Tom Yu Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <20100521230900.GF9605@oracle.com> References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4BF71302.002B:SCFMA922111,ss=1,fgs=0 Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 May 2010 23:11:07 -0000 On Fri, May 21, 2010 at 06:43:35PM -0400, Tom Yu wrote: > Yes, this means that you may have to revise the numeric "security > strength" that you report for a given cryptographic association as new > cryptanalytic attacks are discovered, but you would have to do that > anyway with a non-numeric method of reporting "security strength". Yes, but that way we get to also have policy names, both, standard and locally-defined, as the interface _for users_. Let me refine my problem with numeric measures of cryptographic strength in APIs. There are two. First, what's better in a UI (I'm betting API particulars will leak into UIs)? Second, do we want to encourage users and/or developers to make relative cipher suite strength comparisons? Looking at it from a UI perspective I'd rather have UI-friendly security strength indications than numeric ones. One might argue that numeric measures of strength are what users are used to, and there's no sense in trying to change that. Is anyone up for that argument? Nico -- From arnt@gulbrandsen.priv.no Sat May 22 02:22:37 2010 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 AADD23A6C4C; Sat, 22 May 2010 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZS8G-MoFB+NK; Sat, 22 May 2010 02:22:35 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by core3.amsl.com (Postfix) with ESMTP id 028923A6C3B; Sat, 22 May 2010 02:22:24 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id E60C1FA0008; Sat, 22 May 2010 09:22:22 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.3) with esmtpa id 1274520135-37716-37715/8/50; Sat, 22 May 2010 11:22:15 +0200 Message-Id: Date: Sat, 22 May 2010 11:22:32 +0200 From: Arnt Gulbrandsen To: Nicolas Williams Subject: Re: [sasl] MOGGIES Proposed Charter Organization: http://arnt.gulbrandsen.priv.no References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> <20100521230900.GF9605@oracle.com> In-Reply-To: <20100521230900.GF9605@oracle.com> Content-Type: text/plain; format=flowed Mime-Version: 1.0 X-Mailman-Approved-At: Sat, 22 May 2010 18:40:51 -0700 Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 09:22:37 -0000 Nicolas Williams writes: > Let me refine my problem with numeric measures of cryptographic > strength in APIs. There are two. First, what's better in a UI (I'm > betting API particulars will leak into UIs)? As (mostly former) UI-head: Numbers are better than magic constants. Magic constants have a way of getting into a fight with UI translation. There are good ways to handle magic constants, but errare humanum est, programmers are human, and my impression is that magic constants are associated with more UI snafus than numbers. > Second, do we want to encourage users and/or developers to make > relative cipher suite strength comparisons? Other than "Pick the best?" Arnt From Nicolas.Williams@oracle.com Sun May 23 21:37:26 2010 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 89C6C3A69A6; Sun, 23 May 2010 21:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.131 X-Spam-Level: X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 eps+2cel88Ay; Sun, 23 May 2010 21:37:24 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C61BC3A69A3; Sun, 23 May 2010 21:37:24 -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.1) with ESMTP id o4O4bCo2032643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 May 2010 04:37:14 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4O2mtuA000354; Mon, 24 May 2010 04:37:11 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 291863271274675820; Sun, 23 May 2010 21:37:00 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 May 2010 21:37:00 -0700 Date: Sun, 23 May 2010 23:36:55 -0500 From: Nicolas Williams To: Arnt Gulbrandsen Subject: Re: [sasl] MOGGIES Proposed Charter Message-ID: <20100524043655.GI9605@oracle.com> References: <20100518191521.GL9429@oracle.com> <201005202238.o4KMcML6028897@fs4113.wdf.sap.corp> <20100520225647.GX9605@oracle.com> <20100521230900.GF9605@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090201.4BFA027A.0158:SCFMA4539811,ss=1,fgs=0 Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 04:37:26 -0000 On Sat, May 22, 2010 at 11:22:32AM +0200, Arnt Gulbrandsen wrote: > Nicolas Williams writes: > >Let me refine my problem with numeric measures of cryptographic > >strength in APIs. There are two. First, what's better in a UI (I'm > >betting API particulars will leak into UIs)? > > As (mostly former) UI-head: Numbers are better than magic constants. > Magic constants have a way of getting into a fight with UI > translation. > > There are good ways to handle magic constants, but errare humanum > est, programmers are human, and my impression is that magic > constants are associated with more UI snafus than numbers. These wouldn't be constants though -- that's part of the point. > >Second, do we want to encourage users and/or developers to make > >relative cipher suite strength comparisons? > > Other than "Pick the best?" One could certainly have locally defined preference orders for cipher suites. Numeric sorting by "strength number" needn't enter into it. From Kurt.Zeilenga@Isode.com Tue May 25 07:58:59 2010 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 A8C943A6B54; Tue, 25 May 2010 07:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYHC3JU9YU5z; Tue, 25 May 2010 07:58:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BA6653A679C; Tue, 25 May 2010 07:58:30 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 25 May 2010 15:58:21 +0100 X-SMTP-Protocol-Errors: NORDNS Subject: Re: [sasl] MOGGIES Proposed Charter From: Kurt Zeilenga In-Reply-To: <4BF221C1.2090005@oracle.com> Date: Tue, 25 May 2010 07:58:18 -0700 Message-Id: References: <4BF221C1.2090005@oracle.com> To: Shawn Emery X-Mailer: Apple Mail (2.1078) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, Tim Polk , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 14:58:59 -0000 I am fine with the charter not specifically stating it will undertake = revision of RFC 4422. I see no burning need to undertake this work and = personally rather wait for SASLprep to be sorted. On the subject of SASLprep, I rather revision of RFC 4013 be worked in = NewPrep. The reason for this is two fold. 1) Expertise: I figure there = is better chance of getting both SASL (and general security expertise) = and Unicode/StringPrep expertise in the NewPrep forums than the MOGGIES = forums. 2) SASLprep is used not only by SASL mechanisms but in various = other systems, such as LDAP, I prefer a more neutral forum. On the subject of "interface for reporting the security strength of = GSS-API: I note that I once wrote an I-D which kinds of relates to = this. = . = Beyond that, I think this work item is a rat-hole and rather it not be = on the charter. Instead, I suggest folks pursue this on an = individual/independent basis if they think they can come up with = something useful here. -- Kurt= From hartmans@mit.edu Tue May 25 13:37:12 2010 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 E69353A6819 for ; Tue, 25 May 2010 13:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgt4o1o8G32r for ; Tue, 25 May 2010 13:37:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CBC433A680A for ; Tue, 25 May 2010 13:37:08 -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 F059C20239; Tue, 25 May 2010 16:36:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4B31243EF; Tue, 25 May 2010 16:36:30 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org,tim.polk@nist.gov Subject: review of draft-wierenga-ietf-sasl-saml-00 Date: Tue, 25 May 2010 16:36:30 -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: moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 20:37:13 -0000 [Tim copied because this document came up on a recent call] Hi. I've been promising the authors of the SASL SAML mechanism a review for a while and I realized that the only way it would happen is if I sit down and write it up. For those who haven't read the document, the idea is to permit the use of an existing SAML IDP for SASL authentication. The flow is as follows: 1) The server sends a URI to redirect to to the client. 2) The client pops up a browser and sends it to that URI 3) The client sends an empty response to the server 4) At some later point the server says authentication succeeded or failed. What's presumably happening behind the covers is that the client is interacting with a browser and an identity provider. Eventually if authentication is successful the client will be directed back to a URI on the server. Once the authentication is received over this URI then the server will respond that SASL has succeeded. I think this mechanism may be the best approach possible given the technical constraints, especially in the case where the IDP URI is provided by the server or where an IDP discovery mechanism is used. However the security properties of this mechanism are a lot closer to SASL plain or anonymous than more modern SASL mechanisms such as SCRAM. It's not as bad as plain: long-term secrets are not sent over the wire in the clear. However it seems vulnerable to the following attacks: 1) The client has no assurance provided by this mechanism that it is talking to the intended server. So, this mechanism provides no protection against man-in-the-middle attacks. 2) There is no channel binding or security layer provided. If this mechanism is used with TLS, there is no assurance that the endpoints of TLS are related to the endpoints of SASL. 3) The client has no to weak assurance that authentication actually happened. The server could return successful authentication at any point after the client sends the empty response. We've learned from discussion of phishing attacks that often it's valuable to force someone to believe they have authenticated to a site when they have not done so. They will be willing to enter confidential information--after all, they did manage to log in. 4) The fact that the server provides the IDP or IDP discovery URI opens the system to fairly classic phishing attacks. Some of these attacks are addressed by using TLS between the client and server. That's only true if certificates are validated and if the user does not accept invalid certificates. It's also important that the name in the certificate be properly checked. A mechanism similar to this could provide significantly better security guarantees if the client knew its own IDP URI. 1) Channel binding could be provided. In some portion of the authentication request covered by the signature, the SASL server includes the channel binding data for the channel. The client can verify that the correct channel binding data is included. The client cannot yet tell that there is no man in the middle. 2) The return URI should provide some space for the client to include some token. The client includes this token in the return URI as it passes the authentication request to the browser. The server echoes this returned token back to the client in the success message. Because the server has never seen this token before it provides some assurance that the server interacted with the IDP. Naturally this only provides value if the IDP is selected by the client rather than the server. I think that if these two additions can be fleshed out and if there are significant use cases where clients could know their IDP, then the mechanism should be modified to support these use cases. However, as I mentioned, I don't know how to do better than the current mechanism given the common requirement that the server provide an IDP discovery URI. I do understand that requirement is important. Any mechanism we publish in this space should have a clear applicability statement and a good explanation of these attacks in the security considerations section. From cantor.2@osu.edu Tue May 25 13:54:07 2010 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 336063A6BB1 for ; Tue, 25 May 2010 13:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=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 LQKbQggiWr8a for ; Tue, 25 May 2010 13:54:06 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id 6CE473A6D4F for ; Tue, 25 May 2010 13:46:47 -0700 (PDT) Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4PKkcI2018996; Tue, 25 May 2010 16:46:38 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4PKkbnB018810; Tue, 25 May 2010 16:46:38 -0400 From: "Scott Cantor" To: "'Sam Hartman'" , References: In-Reply-To: Subject: RE: review of draft-wierenga-ietf-sasl-saml-00 Date: Tue, 25 May 2010 16:46:39 -0400 Organization: The Ohio State University Message-ID: <077001cafc4b$603f0510$20bd0f30$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC05BVuIAA Content-Language: en-us X-CanIt-Geo: ip=128.146.216.86; 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.133 Cc: moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 20:54:07 -0000 > A mechanism similar to this could provide significantly better security > guarantees if the client knew its own IDP URI. ... > I think that if these two additions can be fleshed out and if there are > significant use cases where clients could know their IDP, then the > mechanism should be modified to support these use cases. That is in essence the reason I am still planning to propose an alternative design that makes direct use of the SAML profile that was designed for this basic scenario of a client that's been modified. It does not impose significant technical barriers to clients (they don't have to know much about SAML or create XML Signatures or any of the other common complaints). I believe the cost of deploying a client is such that it's absolutely essential to use that change to move discovery to it. I was hoping to have an I-D submitted by now, but I haven't found the time. Hopefully fairly soon. > However, as I mentioned, I don't know how to do better than the current > mechanism given the common requirement that the server provide an IDP > discovery URI. I do understand that requirement is important. I haven't seen a compelling argument for why it's important. It's actually been a problem for federation since its inception, and when you can avoid it, you really have to. It's something you can work around in cases in which the application relies on identifiers that resemble email addresses and can be used to perform an implicit kind of discovery, but that's not a generalized case, and it still results in the additional security issues you mentioned. -- Scott From hartmans@mit.edu Tue May 25 17:40:20 2010 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 E30953A6B2F; Tue, 25 May 2010 17:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmo09Aw0LFfN; Tue, 25 May 2010 17:40:04 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C44AC3A6C64; Tue, 25 May 2010 16:08: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 06D5120239; Tue, 25 May 2010 19:08:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 30B9743EF; Tue, 25 May 2010 19:07:40 -0400 (EDT) From: Sam Hartman To: mrex@sap.com Subject: Re: MOGGIES Proposed Charter< References: <201005212011.o4LKBBFk012803@fs4113.wdf.sap.corp> Date: Tue, 25 May 2010 19:07:40 -0400 In-Reply-To: <201005212011.o4LKBBFk012803@fs4113.wdf.sap.corp> (Martin Rex's message of "Fri, 21 May 2010 22:11:11 +0200 (MEST)") 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 , jhutz@cmu.edu, sasl@ietf.org, tim.polk@nist.gov 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, 26 May 2010 00:40:20 -0000 >>>>> "Martin" == Martin Rex writes: I join Martin. I think that closing sasl and rechartering is disruptive enough. I don't think it makes sense to change the name of two WGs. I definitely don't think that it makes sense to change to a new mailing list instead of one of the existing mailing lists. I don't think the new name or a desire to have a new name is sufficiently compelling to change the mailing list. so: 1) I strongly object to the new wg using a mailing list other than kitten@ietf.org the old SASL list. 2) I don't think it wise for the new WG to have a name that disagrees with its mailing list. As a result I fairly strongly believe the WG should be called kitten or SASL. From jhutz@cmu.edu Tue May 25 17:43:46 2010 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 4CD5F3A6AA6; Tue, 25 May 2010 17:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 WOUhH0xetEVn; Tue, 25 May 2010 17:43:45 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 938B63A6F26; Tue, 25 May 2010 16:43:06 -0700 (PDT) Received: from 174-146-39-7.pools.spcsdns.net (174-146-39-7.pools.spcsdns.net [174.146.39.7]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4PNgrw0020336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 19:42:55 -0400 (EDT) X-User-Agent: K-9 Mail for Android MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: MOGGIES Proposed Charter< From: Jeffrey Hutzelman Date: Tue, 25 May 2010 19:42:51 -0400 To: Sam Hartman , mrex@sap.com Message-ID: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, simon@josefsson.org, sasl@ietf.org, tim.polk@nist.gov 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, 26 May 2010 00:43:46 -0000 "Sam Hartman" wrote: >>>>>> "Martin" == Martin Rex writes: > > >I join Martin. I think that closing sasl and rechartering is disruptive >enough. I don't think it makes sense to change the name of two WGs. I >definitely don't think that it makes sense to change to a new mailing >list instead of one of the existing mailing lists. I don't think the >new name or a desire to have a new name is sufficiently compelling to >change the mailing list. > >so: > >1) I strongly object to the new wg using a mailing list other than >kitten@ietf.org the old SASL list. >2) I don't think it wise for the new WG to have a name that disagrees >with its mailing list. > >As a result I fairly strongly believe the WG should be called kitten or >SASL. I agree; I was wondering why we weren't just rechartering one group to absorb the other. I suggest having kitten absorb sasl, so we don't end up with a wg acronym that's only one of our protocols. From Nicolas.Williams@oracle.com Wed May 26 07:17:18 2010 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 7076F3A694F; Wed, 26 May 2010 07:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 64pHAZ4d6OWU; Wed, 26 May 2010 07:17:17 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 62B3F3A6930; Wed, 26 May 2010 07:17:17 -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.1) with ESMTP id o4QEH1xb005162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 May 2010 14:17:03 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4QCObhK024378; Wed, 26 May 2010 14:16:55 GMT Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 299543411274883398; Wed, 26 May 2010 07:16:38 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 May 2010 07:16:37 -0700 Date: Wed, 26 May 2010 09:16:32 -0500 From: Nicolas Williams To: Jeffrey Hutzelman Subject: Re: [sasl] MOGGIES Proposed Charter< Message-ID: <20100526141632.GW9605@oracle.com> References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4BFD2D61.00FB:SCFMA922111,ss=1,fgs=0 Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 14:17:18 -0000 On Tue, May 25, 2010 at 07:42:51PM -0400, Jeffrey Hutzelman wrote: > "Sam Hartman" wrote: > >1) I strongly object to the new wg using a mailing list other than > >kitten@ietf.org the old SASL list. > >2) I don't think it wise for the new WG to have a name that disagrees > >with its mailing list. > > > >As a result I fairly strongly believe the WG should be called kitten > >or SASL. > > I agree; I was wondering why we weren't just rechartering one group to > absorb the other. I suggest having kitten absorb sasl, so we don't > end up with a wg acronym that's only one of our protocols. +1 From klaas@cisco.com Wed May 26 07:17:46 2010 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 BAB5C3A683F for ; Wed, 26 May 2010 07:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv3kRYs1Bd3c for ; Wed, 26 May 2010 07:17:45 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0CB483A6960 for ; Wed, 26 May 2010 07:17:44 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAHbK/EuQ/uCWe2dsb2JhbACeIBUBARYiBhynNpl9glqCOQSPUw X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="7829460" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 May 2010 13:38:32 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QEHYeO022725; Wed, 26 May 2010 14:17:35 GMT Message-ID: <4BFD2D7E.4010204@cisco.com> Date: Wed, 26 May 2010 16:17:34 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sam Hartman Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 May 2010 07:40:31 -0700 Cc: kitten@ietf.org, tim.polk@nist.gov, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 14:17:46 -0000 Hi Sam,. Thanks for your review! I agree with most of your observations. To address your mitigating measures: - IdP discovery I don't think that in the use cases I am thinking of currently (jabber, imap etc.) IdP discovery is that important. I can very well live with having the client specify the IdP instead of relying on a discovery url provided by the server. I wanted to be as flexible as possible, but given your and others feedback I can change that. I see 2 options: introduce an "IdP hint" provided by the client and fall back to one provided by the server and discuss this in the security considerations or have the client always provide the IdP. I guess you prefer the latter, what do others think? - token provided by client Interesting idea. I had been toying with the idea of having the server provide a nonce, but that would not have helped. I have to think if/how that could be done. - channel binding How useful is channel binding if there is still a MITM possible? Thanks again, Klaas > [Tim copied because this document came up on a recent call] > > Hi. I've been promising the authors of the SASL SAML mechanism a review > for a while and I realized that the only way it would happen is if I sit > down and write it up. > > For those who haven't read the document, the idea is to permit the use > of an existing SAML IDP for SASL authentication. The flow is as > follows: > > 1) The server sends a URI to redirect to to the client. > > 2) The client pops up a browser and sends it to that URI > > 3) The client sends an empty response to the server > > 4) At some later point the server says authentication succeeded or > failed. > > What's presumably happening behind the covers is that the client is > interacting with a browser and an identity provider. Eventually if > authentication is successful the client will be directed back to a URI > on the server. Once the authentication is received over this URI then > the server will respond that SASL has succeeded. > > I think this mechanism may be the best approach possible given the > technical constraints, especially in the case where the IDP URI is > provided by the server or where an IDP discovery mechanism is used. > > However the security properties of this mechanism are a lot closer to > SASL plain or anonymous than more modern SASL mechanisms such as SCRAM. > It's not as bad as plain: long-term secrets are not sent over the wire > in the clear. However it seems vulnerable to the following attacks: > > 1) The client has no assurance provided by this mechanism that it is > talking to the intended server. So, this mechanism provides no > protection against man-in-the-middle attacks. > > 2) There is no channel binding or security layer provided. If this > mechanism is used with TLS, there is no assurance that the endpoints of > TLS are related to the endpoints of SASL. > > 3) The client has no to weak assurance that authentication actually > happened. The server could return successful authentication at any > point after the client sends the empty response. We've learned from > discussion of phishing attacks that often it's valuable to force someone > to believe they have authenticated to a site when they have not done > so. They will be willing to enter confidential information--after all, > they did manage to log in. > > 4) The fact that the server provides the IDP or IDP discovery URI opens > the system to fairly classic phishing attacks. > > Some of these attacks are addressed by using TLS between the client and > server. That's only true if certificates are validated and if the user > does not accept invalid certificates. It's also important that the name > in the certificate be properly checked. > > A mechanism similar to this could provide significantly better security > guarantees if the client knew its own IDP URI. > > > 1) Channel binding could be provided. In some portion of the > authentication request covered by the signature, the SASL server > includes the channel binding data for the channel. The client can > verify that the correct channel binding data is included. The client > cannot yet tell that there is no man in the middle. > > 2) The return URI should provide some space for the client to include > some token. The client includes this token in the return URI as it > passes the authentication request to the browser. The server echoes > this returned token back to the client in the success message. Because > the server has never seen this token before it provides some assurance > that the server interacted with the IDP. Naturally this only provides > value if the IDP is selected by the client rather than the server. > > I think that if these two additions can be fleshed out and if there are > significant use cases where clients could know their IDP, then the > mechanism should be modified to support these use cases. > > However, as I mentioned, I don't know how to do better than the current > mechanism given the common requirement that the server provide an IDP > discovery URI. I do understand that requirement is important. Any > mechanism we publish in this space should have a clear applicability > statement and a good explanation of these attacks in the security > considerations section. From klaas@cisco.com Wed May 26 07:23:35 2010 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 2E70D3A6956 for ; Wed, 26 May 2010 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=4.093, BAYES_40=-0.185, 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 qSXI66HJF3fm for ; Wed, 26 May 2010 07:23:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5D9063A6930 for ; Wed, 26 May 2010 07:23:20 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BADTL/EuQ/uCWe2dsb2JhbACeIBUBARYiBhynLpl/glqCOQSPUw X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="61825940" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 26 May 2010 14:23:10 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QENAMj024607; Wed, 26 May 2010 14:23:10 GMT Message-ID: <4BFD2ECE.5020600@cisco.com> Date: Wed, 26 May 2010 16:23:10 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Scott Cantor Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> In-Reply-To: <077001cafc4b$603f0510$20bd0f30$@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 May 2010 07:40:31 -0700 Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 14:23:35 -0000 On 5/25/10 10:46 PM, Scott Cantor wrote: Scott, >> A mechanism similar to this could provide significantly better security >> guarantees if the client knew its own IDP URI. > ... >> I think that if these two additions can be fleshed out and if there are >> significant use cases where clients could know their IDP, then the >> mechanism should be modified to support these use cases. > > That is in essence the reason I am still planning to propose an alternative > design that makes direct use of the SAML profile that was designed for this > basic scenario of a client that's been modified. It does not impose > significant technical barriers to clients (they don't have to know much > about SAML or create XML Signatures or any of the other common complaints). I am assuming you refer to the ECP profile. How different would this be from the SASL point of view? I.e. what difference would it make on the "SASL wire"? > > I believe the cost of deploying a client is such that it's absolutely > essential to use that change to move discovery to it. > > I was hoping to have an I-D submitted by now, but I haven't found the time. > Hopefully fairly soon. > >> However, as I mentioned, I don't know how to do better than the current >> mechanism given the common requirement that the server provide an IDP >> discovery URI. I do understand that requirement is important. > > I haven't seen a compelling argument for why it's important. It's actually > been a problem for federation since its inception, and when you can avoid > it, you really have to. There is no compelling argument other than that this is the way it is done in most identity federations today and I wanted to stay as close as possible to today's implementations and not fall into the trap of trying to introduce something new and at the same time try to fix all other problems in the world. > It's something you can work around in cases in which the application relies > on identifiers that resemble email addresses and can be used to perform an > implicit kind of discovery, but that's not a generalized case, and it still > results in the additional security issues you mentioned. Agreed. Klaas From cantor.2@osu.edu Wed May 26 08:08:38 2010 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 8F2F73A683F for ; Wed, 26 May 2010 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM9PpE0SufR3 for ; Wed, 26 May 2010 08:08:37 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by core3.amsl.com (Postfix) with ESMTP id 9901B3A6359 for ; Wed, 26 May 2010 08:08:37 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=Pm0qIGCwx3bIEOZlSg1a56K3RSwKBTW9sPEb+DFvEKk= c=1 sm=0 a=FNPjm8h7-gQA:10 a=0qYQvVkOOIcA:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=ZVL_7Xqr5YMxoD93R1wA:9 a=8kaPJNggRd5kbjln-7IA:7 a=x-tPcLOtnoXcFznNn-55bZjQSZoA:4 a=CjuIK1q_8ugA:10 a=rjC1WpulEXHb2dl-:21 a=GYJa4N8imfAWlNCz:21 a=/Wh0N9815gtYTLoiNwER9g==:117 X-Cloudmark-Score: 0 X-Originating-IP: 24.210.116.83 Received: from [24.210.116.83] ([24.210.116.83:21668] helo=SNOWDOG) by hrndva-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id AC/CC-23859-B693DFB4; Wed, 26 May 2010 15:08:28 +0000 From: "Scott Cantor" To: "'Klaas Wierenga'" References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> In-Reply-To: <4BFD2ECE.5020600@cisco.com> Subject: RE: review of draft-wierenga-ietf-sasl-saml-00 Date: Wed, 26 May 2010 11:08:29 -0400 Organization: The Ohio State University Message-ID: <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmaQPSUmgA== Content-Language: en-us Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 15:08:38 -0000 > I am assuming you refer to the ECP profile. How different would this be > from the SASL point of view? I.e. what difference would it make on the > "SASL wire"? Significantly different from yours, since there's no empty response and no callback communication between the SP and the IdP, but I believe it can be compatible with SAML ECP on the IdP side, and is essentially a direct mapping from using HTTP as a "container" for the SP/client SOAP envelopes to using the SASL messages. It suffers the same MITM issues that Sam mentioned, since that's what happens if you punt that to TLS without any channel bindings. I'm not in a position to address that without help, I just believe there's a better non-web flow here. It also creates a much more flexible field for phishing to be addressed, since the client/IdP exchange is not a browser and a web site. The only issue to address in translating the profile over to SASL is the fact that in a non-web case there's no real "responseURL" involved, which is something that's baked into the standard ECP profile, but I think it can be "emulated" with no particular effort in the interest of compatibility, or removed at the cost of same. > There is no compelling argument other than that this is the way it is > done in most identity federations today and I wanted to stay as close as > possible to today's implementations and not fall into the trap of trying > to introduce something new and at the same time try to fix all other > problems in the world. This makes sense if you're remaining compatible with something people *want* to deal with, but IdP discovery is the last thing anybody operating an SP *wants* to deal with. It's a gigantic usability problem, and arguably the biggest reason why federation has scaling issues. Anyway, it's on me to produce the draft, which I've started on (using yours as a starting point, which I hope is ok). -- Scott From klaas@cisco.com Wed May 26 08:42:14 2010 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 A45963A659A for ; Wed, 26 May 2010 08:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.43 X-Spam-Level: X-Spam-Status: No, score=-4.43 tagged_above=-999 required=5 tests=[AWL=-1.831, 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 on-iNjGLyyIg for ; Wed, 26 May 2010 08:42:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3C4093A66B4 for ; Wed, 26 May 2010 08:42:13 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAHXe/EuQ/uCWe2dsb2JhbACeHRUBARYiBhyoCZoAglqCOQSPUw X-IronPort-AV: E=Sophos;i="4.53,304,1272844800"; d="scan'208";a="7835152" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 26 May 2010 15:03:00 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4QFg3ps019581; Wed, 26 May 2010 15:42:03 GMT Message-ID: <4BFD414A.7070002@cisco.com> Date: Wed, 26 May 2010 17:42:02 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Scott Cantor Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> In-Reply-To: <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 15:42:14 -0000 On 5/26/10 5:08 PM, Scott Cantor wrote: >> I am assuming you refer to the ECP profile. How different would this be >> from the SASL point of view? I.e. what difference would it make on the >> "SASL wire"? > > Significantly different from yours, since there's no empty response and no > callback communication between the SP and the IdP, but I believe it can be > compatible with SAML ECP on the IdP side, and is essentially a direct > mapping from using HTTP as a "container" for the SP/client SOAP envelopes to > using the SASL messages. right, but that than comes at the expense of more complex SASL interaction, i.e. you are going to send the AuthenticationStatement as a response to the AuthentionRequest challenge over SASL, right? > > It suffers the same MITM issues that Sam mentioned, since that's what > happens if you punt that to TLS without any channel bindings. I'm not in a > position to address that without help, I just believe there's a better > non-web flow here. It also creates a much more flexible field for phishing > to be addressed, since the client/IdP exchange is not a browser and a web > site. > > The only issue to address in translating the profile over to SASL is the > fact that in a non-web case there's no real "responseURL" involved, which is > something that's baked into the standard ECP profile, but I think it can be > "emulated" with no particular effort in the interest of compatibility, or > removed at the cost of same. > >> There is no compelling argument other than that this is the way it is >> done in most identity federations today and I wanted to stay as close as >> possible to today's implementations and not fall into the trap of trying >> to introduce something new and at the same time try to fix all other >> problems in the world. > > This makes sense if you're remaining compatible with something people *want* > to deal with, but IdP discovery is the last thing anybody operating an SP > *wants* to deal with. It's a gigantic usability problem, and arguably the > biggest reason why federation has scaling issues. ok, fair point > > Anyway, it's on me to produce the draft, which I've started on (using yours > as a starting point, which I hope is ok). obviously! Looking forward to the draft. Klaas From cantor.2@osu.edu Wed May 26 08:55:32 2010 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 89CEC3A66B4 for ; Wed, 26 May 2010 08:55:32 -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 hQpz+ipuK9jD for ; Wed, 26 May 2010 08:55:31 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by core3.amsl.com (Postfix) with ESMTP id 8C7423A67DB for ; Wed, 26 May 2010 08:55:29 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=muTmBHIsIIrvj5np50lvqqEF3x9MmSj/zDSU9q1ni6E= c=1 sm=0 a=FNPjm8h7-gQA:10 a=0qYQvVkOOIcA:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=7xHUJE1NU49kgWwFEnEA:9 a=ej963Yy3zctA84nWFcwtFIR99AoA:4 a=CjuIK1q_8ugA:10 a=/Wh0N9815gtYTLoiNwER9g==:117 X-Cloudmark-Score: 0 X-Originating-IP: 24.210.116.83 Received: from [24.210.116.83] ([24.210.116.83:29913] helo=SNOWDOG) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id AA/15-22658-8644DFB4; Wed, 26 May 2010 15:55:20 +0000 From: "Scott Cantor" To: "'Klaas Wierenga'" References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <4BFD414A.7070002@cisco.com> In-Reply-To: <4BFD414A.7070002@cisco.com> Subject: RE: review of draft-wierenga-ietf-sasl-saml-00 Date: Wed, 26 May 2010 11:55:21 -0400 Organization: The Ohio State University Message-ID: <07f301cafceb$d9244f30$8b6ced90$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCs1lfWwKr/Y2zkBI5PBA= Content-Language: en-us Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 15:55:32 -0000 > right, but that than comes at the expense of more complex SASL > interaction, i.e. you are going to send the AuthenticationStatement as a > response to the AuthentionRequest challenge over SASL, right? It's a SAML Response (the statement is well buried), but why is that more complex than an empty response, running a web server to handle a SSO response, and then making a callback? I think it's a much simpler flow. Request, Response. I'm coming at this with probably insufficient SASL knowledge, though I'm trying to rectify that. Maybe I'm missing something. -- Scott From hartmans@mit.edu Wed May 26 11:27:12 2010 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 772083A69B9 for ; Wed, 26 May 2010 11:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1QnBDLRX-CD for ; Wed, 26 May 2010 11:27:11 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B34D63A68AA for ; Wed, 26 May 2010 11:27:11 -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 71511201F6; Wed, 26 May 2010 14:26:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F21EF43EF; Wed, 26 May 2010 14:26:30 -0400 (EDT) From: Sam Hartman To: "Scott Cantor" Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> Date: Wed, 26 May 2010 14:26:30 -0400 In-Reply-To: <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> (Scott Cantor's message of "Wed, 26 May 2010 11:08:29 -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, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:27:12 -0000 >>>>> "Scott" == Scott Cantor writes: >> I am assuming you refer to the ECP profile. How different would >> this be from the SASL point of view? I.e. what difference would >> it make on the "SASL wire"? Scott> It suffers the same MITM issues that Sam mentioned, since Scott> that's what happens if you punt that to TLS without any Scott> channel bindings. I'm not in a position to address that Scott> without help, I just believe there's a better non-web flow Scott> here. It also creates a much more flexible field for phishing Scott> to be addressed, since the client/IdP exchange is not a Scott> browser and a web site. Scott, I'm happy to work with you to figure out if channel binding support is possible in your approach. From hartmans@mit.edu Wed May 26 11:29:19 2010 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 8ABDA3A69B1 for ; Wed, 26 May 2010 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY-FmFXPhh6F for ; Wed, 26 May 2010 11:29:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9FCE23A68AA for ; Wed, 26 May 2010 11:29: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 D2E88201CA; Wed, 26 May 2010 14:29:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7822343EF; Wed, 26 May 2010 14:28:42 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> Date: Wed, 26 May 2010 14:28:42 -0400 In-Reply-To: <4BFD2ECE.5020600@cisco.com> (Klaas Wierenga's message of "Wed, 26 May 2010 16:23:10 +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, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:29:19 -0000 >>>>> "Klaas" == Klaas Wierenga writes: Klaas> right, so the server would have a list of realm to idp-url Klaas> mappings? In order for the proposal I made to work, the following must be true: 1) The IDP MUST verify that channel binding data is asserted by the expected RP and has been modified by no other party 2) The client MUST verify that the channel binding data corresponds to the channel that is in use. Those two are enough that the user will learn through the web browser if the connection is under attack. However, the that's not enough to defend against a server that fakes successful authentication or to learn at the SASL protocol level about a channel binding failure. 3) The client inserts a cookie into the return URL 4) The server or agents under the control of the server not see this cookie before succesful authentication 5) The server returns the cookie to the client. I'm not actually sure 3 is possible: I'm not sure whether the return URL is covered by the signature. Assuming it's possible, 4 means that the client must be able to verify that the IDP URL it goes to is one that it trusts. So, ultimately, the server can pick however you like, but it MUST pick from a list of *URLs* that the client trusts. Anything like the server mapping an IDP hint to a URL destroys the security property. Note that it's possible to have multiple modes of operation with different security properties. That creates UI challenges, but that is potentially doable. From cantor.2@osu.edu Wed May 26 11:41:44 2010 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 D5DCA3A692E for ; Wed, 26 May 2010 11:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcDHNpvo4Tf2 for ; Wed, 26 May 2010 11:41:44 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id EC7983A6915 for ; Wed, 26 May 2010 11:41:42 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QIfVva030254; Wed, 26 May 2010 14:41:31 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QIfUTp004960; Wed, 26 May 2010 14:41:30 -0400 From: "Scott Cantor" To: "'Sam Hartman'" References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> In-Reply-To: Subject: RE: review of draft-wierenga-ietf-sasl-saml-00 Date: Wed, 26 May 2010 14:41:32 -0400 Organization: The Ohio State University Message-ID: <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCs1lfWwFbRpYxkBzsvvA= Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; 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.133 Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:41:45 -0000 > Scott, I'm happy to work with you to figure out if channel binding > support is possible in your approach. I plan to take you up on it. To ease the process of comparing the approaches, I think it's easiest to produce a simple draft initially, which highlights some of the issues you mentioned, but leaves things as is for the same compatibility reasons that Klaas had. The result may be a merging of the proposals, or not. Related to this, for example, I'm in favor of supporting a way to tie the SAML assertion in the response to a key at the TLS layer (holder of key via client TLS, in other words). That's an addition to the SAML profile I'm basing this work on, which is why I'm not starting there, to simplify the compatibility story. I probably will go back to OASIS to get a HoK version of the ECP profile created, and then I can just reference it. I'm fairly far along since starting on this last night so I should have something soon. -- Scott From cantor.2@osu.edu Wed May 26 11:43:41 2010 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 29AE33A697A for ; Wed, 26 May 2010 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=1.550, 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 o0KLgtO5v8vc for ; Wed, 26 May 2010 11:43:39 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by core3.amsl.com (Postfix) with ESMTP id 4FB293A6998 for ; Wed, 26 May 2010 11:43:39 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QIhSEE028312; Wed, 26 May 2010 14:43:28 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QIhSa7015293; Wed, 26 May 2010 14:43:28 -0400 From: "Scott Cantor" To: "'Sam Hartman'" , "'Klaas Wierenga'" References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> In-Reply-To: Subject: RE: review of draft-wierenga-ietf-sasl-saml-00 Date: Wed, 26 May 2010 14:43:30 -0400 Organization: The Ohio State University Message-ID: <082601cafd03$561cfcf0$0256f6d0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCW31CfpAqh8xw Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; 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.81 Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 18:43:41 -0000 > I'm not actually sure 3 is possible: I'm not sure whether the return URL > is covered by the signature. The signature in a SAML redirect binding URL is over a defined set of parameters in a particular order, and is not perturbed by additional parameters (though of course they are not protected by it). -- Scott From simon@josefsson.org Wed May 26 12:59:11 2010 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 A72DF3A693D for ; Wed, 26 May 2010 12:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxqK+WZ3rF5u for ; Wed, 26 May 2010 12:59:10 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 679E63A66B4 for ; Wed, 26 May 2010 12:59:08 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4QJwoBM011259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 May 2010 21:58:52 +0200 From: Simon Josefsson To: "Scott Cantor" Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100526:cantor.2@osu.edu::4mUl+BzOxCUosyrh:0Wov X-Hashcash: 1:22:100526:hartmans-ietf@mit.edu::OmIuQrExQxZoj74s:4f07 X-Hashcash: 1:22:100526:draft-wierenga-ietf-sasl-saml@tools.ietf.org::ewt5bE+/ouv1u4Qd:8D8m X-Hashcash: 1:22:100526:kitten@ietf.org::N7SHP1pEIYT/OKiZ:UOsD X-Hashcash: 1:22:100526:moonshot-community@jiscmail.ac.uk::91rBAwA1NaEJ4Nw1:j8N3 Date: Wed, 26 May 2010 21:58:50 +0200 In-Reply-To: <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> (Scott Cantor's message of "Wed, 26 May 2010 14:41:32 -0400") Message-ID: <87fx1eo2o5.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 19:59:11 -0000 "Scott Cantor" writes: >> Scott, I'm happy to work with you to figure out if channel binding >> support is possible in your approach. > > I plan to take you up on it. To ease the process of comparing the > approaches, I think it's easiest to produce a simple draft initially, which > highlights some of the issues you mentioned, but leaves things as is for the > same compatibility reasons that Klaas had. The result may be a merging of > the proposals, or not. > > Related to this, for example, I'm in favor of supporting a way to tie the > SAML assertion in the response to a key at the TLS layer (holder of key via > client TLS, in other words). That's an addition to the SAML profile I'm > basing this work on, which is why I'm not starting there, to simplify the > compatibility story. I probably will go back to OASIS to get a HoK version > of the ECP profile created, and then I can just reference it. I would prefer if channel bindings is done in a GS2 compatible way, to allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well. By using the GS2 prefix, you also get support for authorization identities. If authors are interested here, I could help with the GS2 prefix part so that it causes minimal confusion for non-GSS-API people and still allows that variant. I made this suggestion for the OpenID SASL mechanism as well. /Simon From cantor.2@osu.edu Wed May 26 13:18:20 2010 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 0955C3A69CC for ; Wed, 26 May 2010 13:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=1.033, 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 oyFgy99XIR9a for ; Wed, 26 May 2010 13:17:59 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id 7009D3A69E5 for ; Wed, 26 May 2010 13:17:44 -0700 (PDT) Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QKHYfJ013122; Wed, 26 May 2010 16:17:34 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4QKHW3P027717; Wed, 26 May 2010 16:17:33 -0400 From: "Scott Cantor" To: "'Simon Josefsson'" References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> In-Reply-To: <87fx1eo2o5.fsf@mocca.josefsson.org> Subject: RE: review of draft-wierenga-ietf-sasl-saml-00 Date: Wed, 26 May 2010 16:17:34 -0400 Organization: The Ohio State University Message-ID: <084601cafd10$7b6633c0$72329b40$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmYCs1lfWwFbRpYxAjty4KIB2IJ2bY/8aGGQ Content-Language: en-us X-CanIt-Geo: ip=128.146.216.86; 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.133 Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 20:18:20 -0000 > I would prefer if channel bindings is done in a GS2 compatible way, to > allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well. > By using the GS2 prefix, you also get support for authorization > identities. > > If authors are interested here, I could help with the GS2 prefix part so > that it causes minimal confusion for non-GSS-API people and still allows > that variant. I made this suggestion for the OpenID SASL mechanism as > well. I'm completely open to any and all SASL/GSS-related suggestions and improvements. This is sort of a 5 year old work item for me that dates back to SAML 2's initial design work, which I intended to demonstrate as a fit for SASL and never got the time or the perceived interest to get done. I just want to get a proposal out that "fits" my original intention for how this would look, and then let the experts on the non-SAML parts whack it into shape once there's an understanding of the compatibility trade-offs. -- Scott From lear@cisco.com Thu May 27 02:44:05 2010 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 86CD63A67E5; Thu, 27 May 2010 02:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 qaQ4qU1mGNVf; Thu, 27 May 2010 02:44:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 452C63A67AF; Thu, 27 May 2010 02:44:04 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjICAIPb/UuQ/uCWe2dsb2JhbACDF5sBFQEBFiIGHKYTiQ2RCYElgwRqBINA X-IronPort-AV: E=Sophos;i="4.53,310,1272844800"; d="scan'208";a="7889328" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 27 May 2010 09:04:47 +0000 Received: from ams3-vpn-dhcp4135.cisco.com (ams3-vpn-dhcp4135.cisco.com [10.61.80.38]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4R9hoJq023824; Thu, 27 May 2010 09:43:51 GMT Message-ID: <4BFE3EAC.1010403@cisco.com> Date: Thu, 27 May 2010 15:13:08 +0530 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100524 Lanikai/3.1.1pre MIME-Version: 1.0 To: Nicolas Williams Subject: Re: [sasl] MOGGIES Proposed Charter< References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> In-Reply-To: <20100526141632.GW9605@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman , sasl@ietf.org, Jeffrey Hutzelman 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, 27 May 2010 09:44:05 -0000 I don't generally care about naming, and while I don't feel strongly about names, and was mostly joking with all of this when it began (and I apologize for that), there is a benefit about creating a new name, which is that kitten is known for GSS work and SASL is known for SASL work. Having a new name may actually lead to less confusion for those wondering what happens in the combined group. From alexey.melnikov@isode.com Thu May 27 02:48:28 2010 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 189733A684C; Thu, 27 May 2010 02:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nXzCOzMDn7v; Thu, 27 May 2010 02:48:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 4BA3E3A67AF; Thu, 27 May 2010 02:48:27 -0700 (PDT) Received: from [10.234.41.233] ((unknown) [217.41.234.44]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 27 May 2010 10:48:17 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4BFE3FE2.6060408@isode.com> Date: Thu, 27 May 2010 10:48:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Eliot Lear Subject: Re: [sasl] MOGGIES Proposed Charter< References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> In-Reply-To: <4BFE3EAC.1010403@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, tim.polk@nist.gov, sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 09:48:28 -0000 Eliot Lear wrote: > I don't generally care about naming, and while I don't feel strongly > about names, and was mostly joking with all of this when it began (and > I apologize for that), there is a benefit about creating a new name, > which is that kitten is known for GSS work and SASL is known for SASL > work. Having a new name may actually lead to less confusion for those > wondering what happens in the combined group. +1. (No opinion about use of MOGGIES or any other name.) From klaas@cisco.com Thu May 27 05:34:28 2010 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 7A38E3A6AA3 for ; Thu, 27 May 2010 05:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.972 X-Spam-Level: X-Spam-Status: No, score=-7.972 tagged_above=-999 required=5 tests=[AWL=2.627, BAYES_00=-2.599, 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 VRW2cm8vW+ib for ; Thu, 27 May 2010 05:34:26 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 44F723A68B3 for ; Thu, 27 May 2010 05:34:26 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYBAA8E/kuQ/uCWe2dsb2JhbACeGxUBARYiBhymSpoYhRMEj1g X-IronPort-AV: E=Sophos;i="4.53,311,1272844800"; d="scan'208";a="61900128" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 May 2010 12:34:15 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4RCYEVw018481; Thu, 27 May 2010 12:34:14 GMT Message-ID: <4BFE66C6.6060108@cisco.com> Date: Thu, 27 May 2010 14:34:14 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Scott Cantor Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <4BFD414A.7070002@cisco.com> <07f301cafceb$d9244f30$8b6ced90$@osu.edu> In-Reply-To: <07f301cafceb$d9244f30$8b6ced90$@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, 'Sam Hartman' , draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 12:34:28 -0000 On 5/26/10 5:55 PM, Scott Cantor wrote: >> right, but that than comes at the expense of more complex SASL >> interaction, i.e. you are going to send the AuthenticationStatement as a >> response to the AuthentionRequest challenge over SASL, right? > > It's a SAML Response (the statement is well buried), but why is that more > complex than an empty response, running a web server to handle a SSO > response, and then making a callback? > > I think it's a much simpler flow. Request, Response. > > I'm coming at this with probably insufficient SASL knowledge, though I'm > trying to rectify that. Maybe I'm missing something. No sorry, what I meant to say is that at the client it is easier to do "please open a browser with the following url" as opposed to "here is a saml assertion, deal with it and send me back your AuthenticationStatement", for the SASL interaction it is not more difficult indeed. Klaas From tlyu@mit.edu Thu May 27 06:17:56 2010 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 EB71E3A6A36; Thu, 27 May 2010 06:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7EGESSS9BYs; Thu, 27 May 2010 06:17:56 -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 BA5133A6AA3; Thu, 27 May 2010 06:17:55 -0700 (PDT) X-AuditID: 12074423-b7c0bae0000030f0-7b-4bfe70f91637 Received: from mailhub-auth-3.mit.edu (MAILHUB-AUTH-3.MIT.EDU [18.9.21.43]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id 93.D5.12528.9F07EFB4; Thu, 27 May 2010 09:17:45 -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 o4RDHi9h024792; Thu, 27 May 2010 09:17:44 -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 o4RDHfqj000330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 May 2010 09:17:42 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o4RDHfnq007524; Thu, 27 May 2010 09:17:41 -0400 (EDT) To: Eliot Lear Subject: Re: [sasl] MOGGIES Proposed Charter< References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> From: Tom Yu Date: Thu, 27 May 2010 09:17:41 -0400 In-Reply-To: <4BFE3EAC.1010403@cisco.com> (Eliot Lear's message of "Thu, 27 May 2010 15:13:08 +0530") Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 13:17:57 -0000 Eliot Lear writes: > I don't generally care about naming, and while I don't feel strongly > about names, and was mostly joking with all of this when it began (and > I apologize for that), there is a benefit about creating a new name, > which is that kitten is known for GSS work and SASL is known for SASL > work. Having a new name may actually lead to less confusion for those > wondering what happens in the combined group. I notice that Secretariat's expansion for "KITTEN" is "GSS-API Next Generation". If we change it to "Common Authentication Technology Next Generation", based on the old CAT WG name (and actually part of the current charter text!), it would imply a broader scope than GSS-API, encompassing SASL and more, so KITTEN could adopt the work of SASL by a change of charter. After all, Kerberos was a product of the CAT working group. Are there objections to adopting this approach? Is there likely to be confusion if we announce that the scope of KITTEN is expanding beyond GSS-API? From klaas@cisco.com Thu May 27 08:19:28 2010 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 53B643A6960 for ; Thu, 27 May 2010 08:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.185 X-Spam-Level: X-Spam-Status: No, score=-8.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 US3Asl+ZOx81 for ; Thu, 27 May 2010 08:19:27 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0C1883A6950 for ; Thu, 27 May 2010 08:19:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAYq/ktAZnwN/2dsb2JhbACeH3GnL5opgwoCggcEj1g X-IronPort-AV: E=Sophos;i="4.53,311,1272844800"; d="scan'208";a="115395057" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 May 2010 15:19:17 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4RFJGON017381; Thu, 27 May 2010 15:19:16 GMT Message-ID: <4BFE8D74.3090102@cisco.com> Date: Thu, 27 May 2010 17:19:16 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sam Hartman Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:19:28 -0000 On 5/26/10 8:28 PM, Sam Hartman wrote: Sam, Just to understand, what does channel binding buy you if you still can not prevent the MiTM? The SAML interactions can: - give you a return url to the Relying Party and a 'transaction id' - have you authenticate at your IdP - have the IdP verify that the RP is a 'trusted' one - have the (trusted) SP verify that it indeed issued that authentication request Klaas >>>>>> "Klaas" == Klaas Wierenga writes: > > Klaas> right, so the server would have a list of realm to idp-url > Klaas> mappings? > > In order for the proposal I made to work, the following must be true: > > 1) The IDP MUST verify that channel binding data is asserted by the > expected RP and has been modified by no other party > > 2) The client MUST verify that the channel binding data corresponds to > the channel that is in use. > > Those two are enough that the user will learn through the web browser if > the connection is under attack. However, the that's not enough to > defend against a server that fakes successful authentication or to learn > at the SASL protocol level about a channel binding failure. > > 3) The client inserts a cookie into the return URL > > 4) The server or agents under the control of the server not see this > cookie before succesful authentication > > 5) The server returns the cookie to the client. > > I'm not actually sure 3 is possible: I'm not sure whether the return URL > is covered by the signature. Assuming it's possible, 4 means that the > client must be able to verify that the IDP URL it goes to is one that it > trusts. So, ultimately, the server can pick however you like, but it > MUST pick from a list of *URLs* that the client trusts. Anything like > the server mapping an IDP hint to a URL destroys the security property. > > Note that it's possible to have multiple modes of operation with > different security properties. That creates UI challenges, but that is > potentially doable. From klaas@cisco.com Thu May 27 08:27:43 2010 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 D2CE83A6AA3 for ; Thu, 27 May 2010 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.498 X-Spam-Level: X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[AWL=2.101, BAYES_00=-2.599, 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 wcBgYxpZnR2R for ; Thu, 27 May 2010 08:27:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 722503A6950 for ; Thu, 27 May 2010 08:27:42 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYBAOcr/kuQ/uCWe2dsb2JhbACeHxUBARYiBhynOZonhRME X-IronPort-AV: E=Sophos;i="4.53,312,1272844800"; d="scan'208";a="61911324" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 27 May 2010 15:27:32 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8711.cisco.com [10.55.220.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4RFRV5N010823; Thu, 27 May 2010 15:27:31 GMT Message-ID: <4BFE8F63.5080802@cisco.com> Date: Thu, 27 May 2010 17:27:31 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Simon Josefsson Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> In-Reply-To: <87fx1eo2o5.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org, 'Sam Hartman' 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, 27 May 2010 15:27:44 -0000 On 5/26/10 9:58 PM, Simon Josefsson wrote: Hi Simon, > "Scott Cantor" writes: > >>> Scott, I'm happy to work with you to figure out if channel binding >>> support is possible in your approach. >> >> I plan to take you up on it. To ease the process of comparing the >> approaches, I think it's easiest to produce a simple draft initially, which >> highlights some of the issues you mentioned, but leaves things as is for the >> same compatibility reasons that Klaas had. The result may be a merging of >> the proposals, or not. >> >> Related to this, for example, I'm in favor of supporting a way to tie the >> SAML assertion in the response to a key at the TLS layer (holder of key via >> client TLS, in other words). That's an addition to the SAML profile I'm >> basing this work on, which is why I'm not starting there, to simplify the >> compatibility story. I probably will go back to OASIS to get a HoK version >> of the ECP profile created, and then I can just reference it. > > I would prefer if channel bindings is done in a GS2 compatible way, to > allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well. > By using the GS2 prefix, you also get support for authorization > identities. > > If authors are interested here, I could help with the GS2 prefix part so > that it causes minimal confusion for non-GSS-API people and still allows > that variant. I made this suggestion for the OpenID SASL mechanism as > well. Thanks for the kind offer! My concern is that one of the design goals I started out with was not having to touch the existing IdP's. I lack here knowledge (have to read up on GSS-API), but would that be possible? Klaas From hartmans@mit.edu Thu May 27 08:47:09 2010 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 EFF453A6359; Thu, 27 May 2010 08:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr4C7klzRv8M; Thu, 27 May 2010 08:47:05 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 36F5E3A6968; Thu, 27 May 2010 08:47:04 -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 15C40203C9; Thu, 27 May 2010 11:46:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E95043EF; Thu, 27 May 2010 11:46:23 -0400 (EDT) From: Sam Hartman To: Tom Yu Subject: Re: [sasl] MOGGIES Proposed Charter< References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> Date: Thu, 27 May 2010 11:46:23 -0400 In-Reply-To: (Tom Yu's message of "Thu, 27 May 2010 09:17:41 -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: simon@josefsson.org, Eliot Lear , tim.polk@nist.gov, kitten@ietf.org, Sam Hartman , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:47:09 -0000 >>>>> "Tom" == Tom Yu writes: Tom> Eliot Lear writes: >> I don't generally care about naming, and while I don't feel >> strongly about names, and was mostly joking with all of this when >> it began (and I apologize for that), there is a benefit about >> creating a new name, which is that kitten is known for GSS work >> and SASL is known for SASL work. Having a new name may actually >> lead to less confusion for those wondering what happens in the >> combined group. Tom> I notice that Secretariat's expansion for "KITTEN" is "GSS-API Tom> Next Generation". If we change it to "Common Authentication Tom> Technology Next Generation", based on the old CAT WG name (and Tom> actually part of the current charter text!), it would imply a Tom> broader scope than GSS-API, encompassing SASL and more, so Tom> KITTEN could adopt the work of SASL by a change of charter. Tom> After all, Kerberos was a product of the CAT working group. I think this is especially true since RFC 2222 was discussed (although I believe never adopted) by CAT. From Nicolas.Williams@oracle.com Thu May 27 08:54:55 2010 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 758423A696F; Thu, 27 May 2010 08:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 RLXKNwVfLXfZ; Thu, 27 May 2010 08:54:54 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8DE363A6B18; Thu, 27 May 2010 08:54:54 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RFsZ2O029216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 15:54:37 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4RE7Ah5012934; Thu, 27 May 2010 15:54:33 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 274137461274975671; Thu, 27 May 2010 08:54:31 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 May 2010 08:54:29 -0700 Date: Thu, 27 May 2010 10:54:21 -0500 From: Nicolas Williams To: Tom Yu Subject: Re: [sasl] MOGGIES Proposed Charter< Message-ID: <20100527155421.GR9605@oracle.com> References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090208.4BFE95C3.012B:SCFMA4539811,ss=1,fgs=0 Cc: simon@josefsson.org, Eliot Lear , tim.polk@nist.gov, kitten@ietf.org, Sam Hartman , sasl@ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:54:55 -0000 On Thu, May 27, 2010 at 09:17:41AM -0400, Tom Yu wrote: > Eliot Lear writes: > > > I don't generally care about naming, and while I don't feel strongly > > about names, and was mostly joking with all of this when it began (and > > I apologize for that), there is a benefit about creating a new name, > > which is that kitten is known for GSS work and SASL is known for SASL > > work. Having a new name may actually lead to less confusion for those > > wondering what happens in the combined group. > > I notice that Secretariat's expansion for "KITTEN" is "GSS-API Next > Generation". If we change it to "Common Authentication Technology > Next Generation", based on the old CAT WG name (and actually part of > the current charter text!), it would imply a broader scope than > GSS-API, encompassing SASL and more, so KITTEN could adopt the work of > SASL by a change of charter. After all, Kerberos was a product of the > CAT working group. I like this approach best. > Are there objections to adopting this approach? Is there likely to be None here. > confusion if we announce that the scope of KITTEN is expanding beyond > GSS-API? As Sam points out, although CAT's output was mostly related to the GSS-API, it did work on Kerberos and authentication in general -- just look at the CAT WG page: http://www.ietf.org/wg/concluded/cat.html Therefore it is logical that KITTEN, son-of-CAT, too should have as broad a scope as CAT did. Yeah, OK, few are likely to notice this, but maybe we can get the KITTEN WG charter page to link prominently to the CAT WG charter page. Nico -- From jhutz@cmu.edu Thu May 27 10:08:58 2010 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 BE96C3A6B57; Thu, 27 May 2010 10:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.493 X-Spam-Level: X-Spam-Status: No, score=-4.493 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_20=-0.74, 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 npppvk+XWgqK; Thu, 27 May 2010 10:08:58 -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 C746E3A6ABA; Thu, 27 May 2010 10:08:57 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o4RH8kOd001330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 May 2010 13:08:47 -0400 (EDT) Date: Thu, 27 May 2010 13:08:46 -0400 From: Jeffrey Hutzelman To: Nicolas Williams , Tom Yu Subject: Re: [sasl] MOGGIES Proposed Charter< Message-ID: <064EB81E3BE0FBF68E7034F3@lysithea.fac.cs.cmu.edu> In-Reply-To: <16096_1274975689_o4RFsmbb000306_20100527155421.GR9605@oracle.com> References: <783ac363-66a1-442d-9ffb-1f92792cf5e9@email.android.com> <20100526141632.GW9605@oracle.com> <4BFE3EAC.1010403@cisco.com> <16096_1274975689_o4RFsmbb000306_20100527155421.GR9605@oracle.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: simon@josefsson.org, tim.polk@nist.gov, kitten@ietf.org, Sam Hartman , sasl@ietf.org, jhutz@cmu.edu 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, 27 May 2010 17:08:58 -0000 --On Thursday, May 27, 2010 10:54:21 AM -0500 Nicolas Williams wrote: > On Thu, May 27, 2010 at 09:17:41AM -0400, Tom Yu wrote: >> Eliot Lear writes: >> >> > I don't generally care about naming, and while I don't feel strongly >> > about names, and was mostly joking with all of this when it began (and >> > I apologize for that), there is a benefit about creating a new name, >> > which is that kitten is known for GSS work and SASL is known for SASL >> > work. Having a new name may actually lead to less confusion for those >> > wondering what happens in the combined group. >> >> I notice that Secretariat's expansion for "KITTEN" is "GSS-API Next >> Generation". If we change it to "Common Authentication Technology >> Next Generation", based on the old CAT WG name (and actually part of >> the current charter text!), it would imply a broader scope than >> GSS-API, encompassing SASL and more, so KITTEN could adopt the work of >> SASL by a change of charter. After all, Kerberos was a product of the >> CAT working group. > > I like this approach best. Me too. From cantor.2@osu.edu Thu May 27 10:16:38 2010 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 7423A3A6B7B; Thu, 27 May 2010 10:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 yxHCh79YwE2R; Thu, 27 May 2010 10:16:37 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id BA6B63A6B57; Thu, 27 May 2010 10:16:36 -0700 (PDT) Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RHGPaL028357; Thu, 27 May 2010 13:16:25 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RHGPS8001177; Thu, 27 May 2010 13:16:25 -0400 From: "Scott Cantor" To: , Subject: SASL mech for SAML "Enhanced Clients" submitted Date: Thu, 27 May 2010 13:16:27 -0400 Organization: The Ohio State University Message-ID: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acr9v8V2TYDFQ2jZTIC4rmGhnCMSRg== Content-Language: en-us X-CanIt-Geo: ip=128.146.216.86; 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.133 Cc: moonshot-community@jiscmail.ac.uk 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, 27 May 2010 17:16:38 -0000 Klaas, WGs, My proposed SASL mechanism for SAML is here: http://www.ietf.org/id/draft-cantor-ietf-sasl-saml-ec-00.txt I used "EC" to differentiate it from Klaas' browser proposal. I believe some obvious steps would be: - address any questions about the differences between this and the browser proposal - consider whether to try to merge with Klaas' mechanism, proceed with both, etc. - obtain assistance from experts that have volunteered to incorporate GSS-related changes or improvements - consider how/whether to strengthen the security characteristics of the mechanism(s) -- Scott From mrex@sap.com Thu May 27 11:00:54 2010 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 9BCE03A6B89 for ; Thu, 27 May 2010 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.574 X-Spam-Level: X-Spam-Status: No, score=-7.574 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_50=0.001, 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 g2NB0kmsQ-c6 for ; Thu, 27 May 2010 11:00:53 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 87BF53A697B for ; Thu, 27 May 2010 11:00:53 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4RI0Bcm022005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 May 2010 20:00:11 +0200 (MEST) From: Martin Rex Message-Id: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp> Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 To: klaas@cisco.com (Klaas Wierenga) Date: Thu, 27 May 2010 20:00:09 +0200 (MEST) In-Reply-To: <4BFE8D74.3090102@cisco.com> from "Klaas Wierenga" at May 27, 10 05:19:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, hartmans-ietf@mit.edu, draft-wierenga-ietf-sasl-saml@tools.ietf.org 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: Thu, 27 May 2010 18:00:54 -0000 Klaas Wierenga wrote: > > On 5/26/10 8:28 PM, Sam Hartman wrote: > > > > 1) The IDP MUST verify that channel binding data is asserted by the > > expected RP and has been modified by no other party > > > > 2) The client MUST verify that the channel binding data corresponds to > > the channel that is in use. > > > > Those two are enough that the user will learn through the web browser if > > the connection is under attack. However, the that's not enough to > > defend against a server that fakes successful authentication or to learn > > at the SASL protocol level about a channel binding failure. > > Just to understand, what does channel binding buy you if you still can > not prevent the MiTM? That is a misunderstanding. (Cryptographic) channel bindings reliably protects you from MitM attacks. But it can not protect you from an attacker that can successfully impersonate a "trusted" server, and neither from an inappropriately trusted "rogue" server. Successfully impersonating a "trusted" server does not necessarily require a full compromise of that server. Being able to pass those few superficial checks that the client performs in order to verify the authentication of a server is perfectly sufficient -- and is usually much easier than breaking into the real server in order to get hold of its credentials. Think of PKI, X.509 certs, server endpoint identification similar to HTTP over TLS (rfc2818) and the problem of lots of software dealing with embedded NUL chars in names, or the problem of huge amounts of interchangeably-trusted root CAs. -Martin From hartmans@mit.edu Thu May 27 11:11:58 2010 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 26CAB3A6BB2 for ; Thu, 27 May 2010 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XymOOXL9NhFT for ; Thu, 27 May 2010 11:11:57 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2C6AB3A6BC4 for ; Thu, 27 May 2010 11:11:13 -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 ADA77202FB; Thu, 27 May 2010 14:11:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BA79443EF; Thu, 27 May 2010 14:10:34 -0400 (EDT) From: Sam Hartman To: mrex@sap.com Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp> Date: Thu, 27 May 2010 14:10:34 -0400 In-Reply-To: <201005271800.o4RI09Iu028320@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu, 27 May 2010 20:00:09 +0200 (MEST)") 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, moonshot-community@jiscmail.ac.uk, hartmans-ietf@mit.edu, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 18:11:58 -0000 >>>>> "Martin" == Martin Rex writes: Martin> Klaas Wierenga wrote: >> > On 5/26/10 8:28 PM, Sam Hartman wrote: > > > > 1) The IDP MUST verify that channel binding data is asserted by the >> > expected RP and has been modified by no other party >> > >> > 2) The client MUST verify that the channel binding data >> corresponds to > the channel that is in use. >> > >> > Those two are enough that the user will learn through the web >> browser if > the connection is under attack. However, the that's >> not enough to > defend against a server that fakes successful >> authentication or to learn > at the SASL protocol level about a >> channel binding failure. >> >> Just to understand, what does channel binding buy you if you >> still can not prevent the MiTM? Ah, I think I finally understand the question. So, the channel binding does detect the MITM, but the question is how is this communicated and to whom. the two changes above are sufficient that the user would get an authentication failure error in the browser. However it's not sufficient that the client application would be able to learn of this failure without somehow parsing the web page. The other changes I proposed were sufficient for both the web browser and the client application to learn of the attack. From Josh.Howlett@ja.net Thu May 27 12:39:56 2010 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 520F53A6BCF; Thu, 27 May 2010 12:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Skj1lHzMAgOI; Thu, 27 May 2010 12:39:55 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 8B9AD3A698A; Thu, 27 May 2010 12:37:34 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CBF184A6B64_BFEC9F3B; Thu, 27 May 2010 19:37:23 +0000 (GMT) Received: from uxsrvr20.atlas.ukerna.ac.uk (uxsrvr20.atlas.ukerna.ac.uk [193.62.83.209]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id A5F504A6B30_BFEC9EDF; Thu, 27 May 2010 19:37:17 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: SASL mech for SAML "Enhanced Clients" submitted Date: Thu, 27 May 2010 20:37:24 +0100 Message-ID: <6ED388AA006C454BA35B0098396B9BFB073A49D1@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SASL mech for SAML "Enhanced Clients" submitted Thread-Index: Acr9v8V2TYDFQ2jZTIC4rmGhnCMSRgAE6mRg References: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu> From: "Josh Howlett" To: "Scott Cantor" , , Cc: Josh Howlett , moonshot-community@jiscmail.ac.uk 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, 27 May 2010 19:39:56 -0000 Scott, > - address any questions about the differences between this=20 > and the browser proposal There seem to be two principal differences between your proposal and Klaas': 1. The use of the POAS binding within the SASL mechanism between the RP and the client. 2. The use of SOAP binding between the client and the IdP. Is that a reasonable summary? josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG From cantor.2@osu.edu Thu May 27 12:58:20 2010 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 AB2FC3A67E3; Thu, 27 May 2010 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_50=0.001, J_CHICKENPOX_23=0.6, 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 lHcNkWbQDiQ5; Thu, 27 May 2010 12:58:19 -0700 (PDT) Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by core3.amsl.com (Postfix) with ESMTP id 969443A68C2; Thu, 27 May 2010 12:58:18 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RJw8vd024238; Thu, 27 May 2010 15:58:08 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o4RJw8GV006032; Thu, 27 May 2010 15:58:08 -0400 From: "Scott Cantor" To: "'Josh Howlett'" , , References: <08e001cafdc0$577e8ce0$067ba6a0$@osu.edu> <6ED388AA006C454BA35B0098396B9BFB073A49D1@uxsrvr20.atlas.ukerna.ac.uk> In-Reply-To: <6ED388AA006C454BA35B0098396B9BFB073A49D1@uxsrvr20.atlas.ukerna.ac.uk> Subject: RE: SASL mech for SAML "Enhanced Clients" submitted Date: Thu, 27 May 2010 15:58:10 -0400 Organization: The Ohio State University Message-ID: <091c01cafdd6$eee0a990$cca1fcb0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHSVbfbXE0qxJnSkEB8xu69ySzZJwHTUv3Gkkhj5iA= Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; 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.134 Cc: moonshot-community@jiscmail.ac.uk 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, 27 May 2010 19:58:20 -0000 (Aside, I'm cc'ing both kitten and sasl, but if this is getting annoying, feel free to let me know which to drop. Cost of transition I guess.) > There seem to be two principal differences between your proposal and > Klaas': > > 1. The use of the POAS binding within the SASL mechanism between the RP > and the client. I wouldn't exactly call it PAOS (and I avoided referencing that binding), since that's specifically bound to HTTP. I'm reusing some PAOS headers in this draft to avoid making some changes to the original profile, but they don't add much and I'm not sure they're needed. As long as the IdP can operate in ignorance of the fact that it's not PAOS it shouldn't matter whether it is or isn't. What I wanted to do is make this a distinct profile that reused by inclusion specific sections of the original one so that the actual normative message definitions would come from the original one. For now at least (see below). > 2. The use of SOAP binding between the client and the IdP. > > Is that a reasonable summary? Pretty much, but the use of the SOAP binding is also an arbitrary choice designed for the purpose of reusing the ECP profile, and because it's the only client/IdP SAML binding in existence today that isn't browser-centric. The way to think about the difference from my point of view is like this: Klaas' Mechanism: - produce a URL equivalent to a Web SSO request from an SP - send back empty response - launch browser (explicitly or implicitly) and do Web SSO - route result of Web SSO behind the scenes at server to trigger SASL result Mine: - challenge client with SAML AuthnRequest for delivery to IdP - deliver AuthnRequest to IdP along with credentials to get Response for SP - respond to SP with Response to complete SASL exchange The messaging around those steps is essentially arbitrary to the conceptual model and the ECP conventions were chosen as a starting point for reuse and to save drafting time. -- Scott From simon@josefsson.org Thu May 27 23:34:48 2010 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 C5BC23A67AD for ; Thu, 27 May 2010 23:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1QVIw01e6yM for ; Thu, 27 May 2010 23:34:47 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id AE0C93A6A1E for ; Thu, 27 May 2010 23:19:47 -0700 (PDT) Received: from mocca (c80-216-25-148.bredband.comhem.se [80.216.25.148]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4S6JFCu000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 May 2010 08:19:18 +0200 From: Simon Josefsson To: Klaas Wierenga Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> <4BFE8F63.5080802@cisco.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100528:moonshot-community@jiscmail.ac.uk::W2s6GeWnB1HtutjY:3aSC X-Hashcash: 1:22:100528:klaas@cisco.com::FJTIIyo+M08vctY7:FRwk X-Hashcash: 1:22:100528:kitten@ietf.org::LtLE/kafvkmE+wOO:JhyD X-Hashcash: 1:22:100528:hartmans-ietf@mit.edu::EI4k0a+5E5k5tvro:IZ5w X-Hashcash: 1:22:100528:draft-wierenga-ietf-sasl-saml@tools.ietf.org::M8kk1iXUrCH3LTMd:m2cx Date: Fri, 28 May 2010 08:19:16 +0200 In-Reply-To: <4BFE8F63.5080802@cisco.com> (Klaas Wierenga's message of "Thu, 27 May 2010 17:27:31 +0200") Message-ID: <87pr0ga6qj.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, 'Sam Hartman' , moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 06:34:48 -0000 Klaas Wierenga writes: > On 5/26/10 9:58 PM, Simon Josefsson wrote: > > Hi Simon, > >> "Scott Cantor" writes: >> >>>> Scott, I'm happy to work with you to figure out if channel binding >>>> support is possible in your approach. >>> >>> I plan to take you up on it. To ease the process of comparing the >>> approaches, I think it's easiest to produce a simple draft initially, which >>> highlights some of the issues you mentioned, but leaves things as is for the >>> same compatibility reasons that Klaas had. The result may be a merging of >>> the proposals, or not. >>> >>> Related to this, for example, I'm in favor of supporting a way to tie the >>> SAML assertion in the response to a key at the TLS layer (holder of key via >>> client TLS, in other words). That's an addition to the SAML profile I'm >>> basing this work on, which is why I'm not starting there, to simplify the >>> compatibility story. I probably will go back to OASIS to get a HoK version >>> of the ECP profile created, and then I can just reference it. >> >> I would prefer if channel bindings is done in a GS2 compatible way, to >> allow a SAML SASL mechanism to be usable as a GSS-API mechanism as well. >> By using the GS2 prefix, you also get support for authorization >> identities. >> >> If authors are interested here, I could help with the GS2 prefix part so >> that it causes minimal confusion for non-GSS-API people and still allows >> that variant. I made this suggestion for the OpenID SASL mechanism as >> well. > > Thanks for the kind offer! My concern is that one of the design goals > I started out with was not having to touch the existing IdP's. I lack > here knowledge (have to read up on GSS-API), but would that be > possible? I am not certain. The important part is traditionally to make the client and server agree on the channel binding, and refuse connections when they don't match. I don't see any value in having the IdP also necessarily have to be involved in this negotiation. The transfer of the channel binding needs to be integrity protected, and it needs to be tied with the authentication. Thus, a simple way to achieve this would be for the client to include it in a attribute that it signs and sends to the server. I don't think the IdP would need to do anything with a field like that, but it needs to be preserved and presented to the server. I'm not enough of a SAML expert to tell whether this is easy to achieve or not? I do operate a SAML server for a company, and when we did the integration with some RPs, there were many places were you could put extension fields, so I strongly suspect the answer is "yes" but it needs to be confirmed. /Simon From hartmans@mit.edu Fri May 28 05:41:36 2010 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 6E7563A68A3 for ; Fri, 28 May 2010 05:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfZ4oqy2Ma-j for ; Fri, 28 May 2010 05:41:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9A6A23A6820 for ; Fri, 28 May 2010 05:41:34 -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 D0AFC202F3; Fri, 28 May 2010 08:41:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3AAA543EF; Fri, 28 May 2010 08:40:49 -0400 (EDT) From: Sam Hartman To: Simon Josefsson Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> <4BFE8F63.5080802@cisco.com> <87pr0ga6qj.fsf@mocca.josefsson.org> Date: Fri, 28 May 2010 08:40:49 -0400 In-Reply-To: <87pr0ga6qj.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 28 May 2010 08:19:16 +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' , moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 12:41:36 -0000 Simon, I think the IDP may end up involved in the channel binding discussion because the client and server may happen not to have another mechanism for an integrity protected channel. In cases where the client and server directly share a key or a key falls out of the SAML exchange, I agree with you, no IDP interaction is required. From simon@josefsson.org Sat May 29 02:35:22 2010 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 705EC3A6893 for ; Sat, 29 May 2010 02:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeViB8kpv79d for ; Sat, 29 May 2010 02:35:21 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4A27D3A67F8 for ; Sat, 29 May 2010 02:35:20 -0700 (PDT) Received: from mocca (m83-178-251-213.cust.tele2.se [83.178.251.213]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4T9YusE007424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 May 2010 11:35:02 +0200 From: Simon Josefsson To: Sam Hartman Subject: Re: review of draft-wierenga-ietf-sasl-saml-00 References: <077001cafc4b$603f0510$20bd0f30$@osu.edu> <4BFD2ECE.5020600@cisco.com> <07e801cafce5$4cf7f7b0$e6e7e710$@osu.edu> <082501cafd03$0fe0f250$2fa2d6f0$@osu.edu> <87fx1eo2o5.fsf@mocca.josefsson.org> <4BFE8F63.5080802@cisco.com> <87pr0ga6qj.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100529:hartmans-ietf@mit.edu::F+j98R89dn6nJfHo:Mz4 X-Hashcash: 1:22:100529:kitten@ietf.org::CJI+u10s6GusPlrC:2OXe X-Hashcash: 1:22:100529:draft-wierenga-ietf-sasl-saml@tools.ietf.org::orf1k3cvzAFa7LqE:ASA0 X-Hashcash: 1:22:100529:moonshot-community@jiscmail.ac.uk::UyvNh3bc9Cecb50I:FPao Date: Sat, 29 May 2010 11:34:49 +0200 In-Reply-To: (Sam Hartman's message of "Fri, 28 May 2010 08:40:49 -0400") Message-ID: <87k4qnxd8m.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, draft-wierenga-ietf-sasl-saml@tools.ietf.org X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 09:35:22 -0000 Sam Hartman writes: > Simon, I think the IDP may end up involved in the channel binding > discussion because the client and server may happen not to have another > mechanism for an integrity protected channel. In cases where the client > and server directly share a key or a key falls out of the SAML exchange, > I agree with you, no IDP interaction is required. Right. I think there is some advantage in having a key fall out of a SAML exchange, but it may also make a SAML SASL mechanism unnecessarily complex. I'm concerned that IDPs (and potentially other middle parties) can see the TLS Finished messages for connections between clients and servers though. /Simon From leifj@mnt.se Mon May 31 00:30:29 2010 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 7962D3A69D6 for ; Mon, 31 May 2010 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw1gX21RuOBl for ; Mon, 31 May 2010 00:30:17 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id C77C43A68BD for ; Mon, 31 May 2010 00:30:14 -0700 (PDT) Received: from [158.129.74.141] (wlan74-141.tnc2010.litnet.lt [158.129.74.141]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o4V7TuZH006389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 May 2010 09:29:59 +0200 (CEST) Message-ID: <4C036574.8090201@mnt.se> Date: Mon, 31 May 2010 09:29:56 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre MIME-Version: 1.0 To: kitten@ietf.org Subject: Re: [sasl] MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <20100518191521.GL9429@oracle.com> <4BF2EAA2.2000600@secure-endpoints.com> In-Reply-To: <4BF2EAA2.2000600@secure-endpoints.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 31 May 2010 07:30:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think the charter is fine but I too object to the name. > Kitten was funny because the predecessor has the acronym of CAT. > I don't think MOGGIES is funny. Perhaps if you figured out how to > turn it into DOGGIES or PUPPIES. Yeah MOGGIES sounds like a fetish of some kind... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwDZXMACgkQ8Jx8FtbMZncsTgCgqgclDZxuLFdjNm6qlSq4GWUm XqYAn1jH1SpsKEJ3sFwJkeUWY8S+l1pn =R39U -----END PGP SIGNATURE----- From leifj@mnt.se Mon May 31 00:31:20 2010 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 3045D3A6939 for ; Mon, 31 May 2010 00:31:20 -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 gZT59q+ZNEGD for ; Mon, 31 May 2010 00:31:13 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id E1CE63A69F3 for ; Mon, 31 May 2010 00:31:10 -0700 (PDT) Received: from [158.129.74.141] (wlan74-141.tnc2010.litnet.lt [158.129.74.141]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o4V7UrcK018390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 31 May 2010 09:30:56 +0200 (CEST) Message-ID: <4C0365AD.6070004@mnt.se> Date: Mon, 31 May 2010 09:30:53 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre MIME-Version: 1.0 To: kitten@ietf.org Subject: Re: MOGGIES Proposed Charter References: <4BF221C1.2090005@oracle.com> <22122_1274210205_o4IJGi7g000698_20100518191521.GL9429@oracle.com> <0653C22222CBEBDD0AD1CCFA@minbar.fac.cs.cmu.edu> <878w7gv1v4.fsf@mocca.josefsson.org> <1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net> In-Reply-To: <1274251323.4972.23.camel@naomi.s4.naomi.abartlet.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 31 May 2010 07:31:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I would prefer something self-explanatory, like SASLGSS. > > Yeah, but the CAT -> KITTEN -> MOGGIES theme is kind of fun. But what _is_ a moggy? Is it a feline? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwDZa0ACgkQ8Jx8FtbMZneFuACeKGksSTvG8fxMlPBD5wpWLiBF 3UAAn2bn0nlGH2upa1epZDZ+DcLjXlG/ =qxFJ -----END PGP SIGNATURE-----