From wwwrun@core3.amsl.com Tue Aug 3 11:29:07 2010 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1727A3A6AB7; Tue, 3 Aug 2010 11:29:06 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100803182907.1727A3A6AB7@core3.amsl.com> Date: Tue, 3 Aug 2010 11:29:07 -0700 (PDT) Cc: leifj@mnt.se, abfab@ietf.org, hartmans-ietf@mit.edu Subject: [abfab] New Non-WG Mailing List: abfab -- Application Bridging, Federated Authentication Beyond (the web) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 18:29:07 -0000 A new IETF non-working group email list has been created. List address: abfab@ietf.org Archive: http://www.ietf.org/mail-archive/web/abfab/ To subscribe: https://www.ietf.org/mailman/listinfo/abfab Description: This list is for charter and pre-WG technical discussion of the potential fabauth discussion. This list replaces moonshot-community@jiscmail.ac.uk for pre-BOF discussion. For additional information, please contact the list administrators. From leifj@mnt.se Thu Aug 5 06:40:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0263A69E0 for ; Thu, 5 Aug 2010 06:40:10 -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 cZwTf1rItggE for ; Thu, 5 Aug 2010 06:40:08 -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 40E133A6B2A for ; Thu, 5 Aug 2010 06:40:05 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o75DeVC6025691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Aug 2010 15:40:34 +0200 (CEST) Message-ID: <4C5ABF4F.9040909@mnt.se> Date: Thu, 05 Aug 2010 15:40:31 +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: abfab@ietf.org, Moonshot community list X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 05 Aug 2010 06:41:38 -0700 Subject: [abfab] new list X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 13:40:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Note that moonshot-community@jiscmail.ac.uk has been turned into a non-WG IETF list abfab@ietf.org. Hopefully the list archives can be moved aswell. The old list will be shut down soon so please update your email filters! I'm going to to collect and summarize the comments on the charter to the list so we can achieve consensus on a charter turning this into an IETF WG. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxav0YACgkQ8Jx8FtbMZndy8gCfQLxw+fLc46QT9c4xPW93IeWU rOQAn2odsrW3gU3W11GezZl7KeyYiGsp =1s/7 -----END PGP SIGNATURE----- From leifj@sunet.se Thu Aug 5 15:33:41 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16AB63A697A for ; Thu, 5 Aug 2010 15:33:41 -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 Ie-iUtVUX6WM for ; Thu, 5 Aug 2010 15:33:39 -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 5662C3A6993 for ; Thu, 5 Aug 2010 15:33:38 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o75MY53N027987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Aug 2010 00:34:08 +0200 (CEST) Message-ID: <4C5B3C5D.7000607@sunet.se> Date: Fri, 06 Aug 2010 00:34:05 +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: abfab@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 22:33:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, We're still working off of the version of the charter online at * http://www.project-moonshot.org/bof/charter Before and during the BoF session in Maastricht we had a few proposals and a few things have surfaced since then. Acting as one of the BoF chairs I'd like to kick off a discussion that will hopefully lead to a charter that both the community and the IESG likes. Here is what Sam sent to the moonshot list on 26/7: 1) cover descriptions of issues that may require changes such as user-interface in the architecture document; I think this is in the current charter text. 2) Explicitly call out that when thinking about user interface we need to consider the elements of information that will be required for user interface. For example Eliot gave the example of a banking interface that requires information of who you are paying, what you are paying for and how much you are paying. We'd need to explore which of these elements are needed where and do the same for other use cases. 3) Explicitly say that we want to hold to WG open to do a revision of the architecture based on ongoing work including ongoing user interface work throughout the industry. During the BoF session there was consensus (by my interpretation) around (2) at least. - From the excellent notes we have the following AIs: 1) Make privacy more explicit in moonshot related materials - including the charter. 2) Charter needs to specifically mention liaison with OASIS about the SAML RADIUS binding. 3) Order deliverables in the charter in a more logical fashion. 4) Charter needs use-cases and architectures as deliverables. 5) In the charter, change "within the GSS-API" to "within the application" on the 4th deliverable for broader applicability. There was also consensus on the moonshot list (by my interpretation) that the charter should explicitly make alternatives to GSS-API in scope for the WG. Finally Elliot has suggested a simplification of the introductory text in the charter - Elliot: could you send your latest version to the list? I'd be perfectly happy to attempt a new version of the charter based on this set of changes. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxbPFgACgkQ8Jx8FtbMZndI8wCfS5N+qjfab/sQQboQ7m3reGl9 JpsAnjqOSbgVW/hJ1WQTFTUEtF7YXOUH =A3L9 -----END PGP SIGNATURE----- From turners@ieca.com Thu Aug 5 15:40:44 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2E23A69E5 for ; Thu, 5 Aug 2010 15:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.322 X-Spam-Level: X-Spam-Status: No, score=-101.322 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001, 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 N1cc8UjhPEy8 for ; Thu, 5 Aug 2010 15:40:43 -0700 (PDT) Received: from smtp112.biz.mail.mud.yahoo.com (smtp112.biz.mail.mud.yahoo.com [209.191.68.77]) by core3.amsl.com (Postfix) with SMTP id 869D83A6891 for ; Thu, 5 Aug 2010 15:40:43 -0700 (PDT) Received: (qmail 4286 invoked from network); 5 Aug 2010 22:41:08 -0000 Received: from thunderfish.local (turners@96.231.126.45 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 05 Aug 2010 15:41:08 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: AK.bHz8VM1l8byud5buVMAWTC0FNrp9nCAfRpJIbIHaaBRK HKd78XiaFhwpXz.xGoDmu12OyCxEg5aHtZq6TqqHp0uCNdzhtQsYUReJBc5T z4tRU28u59e5ea_n4Y6sJZuF76tijc5XcDunJ0r6wjdoksUDqTG7ptRWI5Cy SYPGCOZASa7oADq1hVVCDrqBeebbjBHu5yFy3dcfWnHslo36lurg8GB_H6b1 wmAscDkvKYBFB8zP89MN_GeG.59ckBnSpEksMa7Q5bCYON_t8IxVu8GjdWPz Aqf8xkNI7m4zZ7cyhFqVzxg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5B3E03.1020403@ieca.com> Date: Thu, 05 Aug 2010 18:41:07 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [abfab] List Moderators X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 22:40:44 -0000 Leif Johansson and Klaas Wierenga have agreed to act as list moderators and to get the charter discussion going. Thanks guys! spt From Josh.Howlett@ja.net Fri Aug 6 03:39:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB3D3A6919 for ; Fri, 6 Aug 2010 03:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 MfjpGGk3GDAE for ; Fri, 6 Aug 2010 03:39:27 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id E96C43A689B for ; Fri, 6 Aug 2010 03:39:26 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CD13F4A6B1C_C5BE67CB; Fri, 6 Aug 2010 10:39:56 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id BF9EA4A6B67_C5BE67BF; Fri, 6 Aug 2010 10:39:55 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Fri, 6 Aug 2010 11:40:03 +0100 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] Getting the charter done Thread-Index: AQHLNO5kf3G4qejO30Oy1W6OQ2FWvZLUKXqQ Date: Fri, 6 Aug 2010 10:39:51 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> References: <4C5B3C5D.7000607@sunet.se> In-Reply-To: <4C5B3C5D.7000607@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 10:39:28 -0000 > There was also consensus on the moonshot list (by my interpretation) > that the charter should explicitly make alternatives to GSS-API in > scope for the WG. Related to this, during the BoF Glen stated there should be alternatives to= RADIUS for the AAA leg. I believe there was consensus that Diameter transp= ort must be supported and recommended within the architecture. =20 > I'd be perfectly happy to attempt a new version of the charter based > on this set of changes. Thanks! 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 gwz@net-zen.net Fri Aug 6 05:35:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D6973A68C1 for ; Fri, 6 Aug 2010 05:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPXCK5GokdWW for ; Fri, 6 Aug 2010 05:35:36 -0700 (PDT) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id F23223A68FB for ; Fri, 6 Aug 2010 05:35:35 -0700 (PDT) Received: (qmail 24758 invoked from network); 6 Aug 2010 12:36:06 -0000 Received: from unknown (195.46.229.98) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 06 Aug 2010 12:36:05 -0000 From: "Glen Zorn" To: "'Josh Howlett'" References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> In-Reply-To: <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> Date: Fri, 6 Aug 2010 14:35:57 +0200 Organization: Network Zen Message-ID: <005101cb3563$ece9f0a0$c6bdd1e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHLNO5kf3G4qejO30Oy1W6OQ2FWvZLUKXqQgAAxHMA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 12:35:37 -0000 Josh Howlett {mailto://Josh.Howlett@ja.net] writes: > > There was also consensus on the moonshot list (by my interpretation) > > that the charter should explicitly make alternatives to GSS-API in > > scope for the WG. > > Related to this, during the BoF Glen stated there should be alternatives > to RADIUS for the AAA leg. I believe there was consensus that Diameter > transport must be supported and recommended within the architecture. Actually, I'd really like to see a clear problem statement before anything else takes place. As I attempted to say in the meeting, the pieces of technology to be mutilated seem to have been chosen largely on the basis of convenience: "We have RADIUS servers and all these apps that support GSS, how shall we connect them? I know, let's hack on EAP, everybody else does!". Of course, I have no idea if this is actually the case and even if it were it is no condemnation of the project; it seems to me a very weak basis upon which to build a standard, however. > > > I'd be perfectly happy to attempt a new version of the charter based > > on this set of changes. > > Thanks! > > Josh. > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lear@cisco.com Fri Aug 6 06:56:35 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EEB73A6A72 for ; Fri, 6 Aug 2010 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 RMZA-7+2wUoP for ; Fri, 6 Aug 2010 06:56:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A3DFC3A6A77 for ; Fri, 6 Aug 2010 06:56:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABKxW0xAZnwN/2dsb2JhbACDFZ0pcahniU2RfYEmgUuBVnMEiTc X-IronPort-AV: E=Sophos;i="4.55,329,1278288000"; d="scan'208";a="144282896" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2010 13:57:05 +0000 Received: from dhcp-10-55-82-32.cisco.com (dhcp-10-55-82-32.cisco.com [10.55.82.32]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o76Dv42U015957; Fri, 6 Aug 2010 13:57:05 GMT Message-ID: <4C5C14BB.8010108@cisco.com> Date: Fri, 06 Aug 2010 15:57:15 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Glen Zorn References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> In-Reply-To: <005101cb3563$ece9f0a0$c6bdd1e0$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 13:56:35 -0000 On 8/6/10 2:35 PM, Glen Zorn wrote: > Josh Howlett {mailto://Josh.Howlett@ja.net] writes: > >>> There was also consensus on the moonshot list (by my interpretation) >>> that the charter should explicitly make alternatives to GSS-API in >>> scope for the WG. >> Related to this, during the BoF Glen stated there should be alternatives >> to RADIUS for the AAA leg. I believe there was consensus that Diameter >> transport must be supported and recommended within the architecture. > Actually, I'd really like to see a clear problem statement before anything > else takes place. I think the original proposed charter did this, but perhaps was a bit verbose. It's rather straight forward: there is a need to support federated identity in non-web applications. There is also a need to scale discovery of identity providers. Eliot From gwz@net-zen.net Fri Aug 6 07:37:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F783A6AC8 for ; Fri, 6 Aug 2010 07:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.689 X-Spam-Level: X-Spam-Status: No, score=-101.689 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_05=-1.11, 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 TDLDbmjO0q12 for ; Fri, 6 Aug 2010 07:37:35 -0700 (PDT) Received: from smtpauth11.prod.mesa1.secureserver.net (smtpauth11.prod.mesa1.secureserver.net [64.202.165.33]) by core3.amsl.com (Postfix) with SMTP id 4EB0F3A6ACC for ; Fri, 6 Aug 2010 07:37:34 -0700 (PDT) Received: (qmail 12690 invoked from network); 6 Aug 2010 14:38:05 -0000 Received: from unknown (195.46.229.98) by smtpauth11.prod.mesa1.secureserver.net (64.202.165.33) with ESMTP; 06 Aug 2010 14:38:04 -0000 From: "Glen Zorn" To: "'Eliot Lear'" References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> In-Reply-To: <4C5C14BB.8010108@cisco.com> Date: Fri, 6 Aug 2010 16:37:56 +0200 Organization: Network Zen Message-ID: <009101cb3574$f711f9e0$e535eda0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs1b0JKa04ixuV9RWWyl337Ix2TlwABMzxA Content-Language: en-us Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:37:36 -0000 Eliot Lear [mailto:lear@cisco.com] writes: ... > > Actually, I'd really like to see a clear problem statement before > anything > > else takes place. >=20 > I think the original proposed charter did this, but perhaps was a bit > verbose. =20 I'd kind of like to verify this but the original charter seems to be = missing from the proceedings. > It's rather straight forward: there is a need to support > federated identity in non-web applications. There is also a need to > scale discovery of identity providers. OK, I know this is an inside game but what does that mean _in this = context_. I can find at least half a dozen definitions of "federated = identity" w/at least that many commercial products claiming to support = it. Which one is this? >=20 > Eliot From turners@ieca.com Fri Aug 6 07:41:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256813A6AC1 for ; Fri, 6 Aug 2010 07:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, 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 BsGOFSRpXw-z for ; Fri, 6 Aug 2010 07:41:10 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id CFA163A6A94 for ; Fri, 6 Aug 2010 07:41:09 -0700 (PDT) Received: (qmail 16317 invoked from network); 6 Aug 2010 14:41:38 -0000 Received: from thunderfish.local (turners@96.241.5.250 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 06 Aug 2010 07:41:37 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: A746OPAVM1kmlwo8sNM.BlhqUcpfkDxHpbpESD4mbioIFyI VFNagdEzq X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5C1F20.4090809@ieca.com> Date: Fri, 06 Aug 2010 10:41:36 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> In-Reply-To: <009101cb3574$f711f9e0$e535eda0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:41:11 -0000 Glen Zorn wrote: > Eliot Lear [mailto:lear@cisco.com] writes: > > ... > >>> Actually, I'd really like to see a clear problem statement before >> anything >>> else takes place. >> I think the original proposed charter did this, but perhaps was a bit >> verbose. > > I'd kind of like to verify this but the original charter seems to be missing from the proceedings. Here's a link to originally proposed charter: http://www.project-moonshot.org/bof/charter spt >> It's rather straight forward: there is a need to support >> federated identity in non-web applications. There is also a need to >> scale discovery of identity providers. > > OK, I know this is an inside game but what does that mean _in this context_. I can find at least half a dozen definitions of "federated identity" w/at least that many commercial products claiming to support it. Which one is this? > >> Eliot > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From lear@cisco.com Fri Aug 6 07:43:31 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABDDD3A6AD2 for ; Fri, 6 Aug 2010 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 c+8m-jGyj2Em for ; Fri, 6 Aug 2010 07:43:17 -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 009E228C0DE for ; Fri, 6 Aug 2010 07:43:15 -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: Av0EAFO8W0xAZnwN/2dsb2JhbACDFZ0pcakjiU2SAYEmgUuBVnMEiTc X-IronPort-AV: E=Sophos;i="4.55,329,1278288000"; d="scan'208";a="144362138" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Aug 2010 14:43:47 +0000 Received: from dhcp-10-55-82-32.cisco.com (dhcp-10-55-82-32.cisco.com [10.55.82.32]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o76EhkkE003820; Fri, 6 Aug 2010 14:43:46 GMT Message-ID: <4C5C1FAD.2030605@cisco.com> Date: Fri, 06 Aug 2010 16:43:57 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Glen Zorn References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> In-Reply-To: <009101cb3574$f711f9e0$e535eda0$@net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 14:43:33 -0000 Glen, > OK, I know this is an inside game but what does that mean _in this context_. I can find at least half a dozen definitions of "federated identity" w/at least that many commercial products claiming to support it. Which one is this? > My apologies- I was a bit imprecise. Here I mean federated authentication and authorization, meaning (loosely) that someone is able to make use of a service by authenticating with another entity using a pre-existing set credentials. There are a whole lot of solutions around for web-based services, but very few for non-web. From gwz@net-zen.net Fri Aug 6 08:52:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8991328C0F3 for ; Fri, 6 Aug 2010 08:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKhDXubmmS4f for ; Fri, 6 Aug 2010 08:52:58 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id A2F0028C0F6 for ; Fri, 6 Aug 2010 08:52:58 -0700 (PDT) Received: (qmail 6093 invoked from network); 6 Aug 2010 15:53:29 -0000 Received: from unknown (195.46.229.98) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 06 Aug 2010 15:53:29 -0000 From: "Glen Zorn" To: "'Eliot Lear'" References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> In-Reply-To: <4C5C1FAD.2030605@cisco.com> Date: Fri, 6 Aug 2010 17:53:20 +0200 Organization: Network Zen Message-ID: <00b601cb357f$7fafd6a0$7f0f83e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs1dcmaD0bGhAZCQduE+7D2EN87uQACUTgA Content-Language: en-us Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 15:52:59 -0000 Eliot Lear [mailto:lear@cisco.com] writes: > Glen, > > OK, I know this is an inside game but what does that mean _in this > context_. I can find at least half a dozen definitions of "federated > identity" w/at least that many commercial products claiming to support > it. Which one is this? > > >=20 > My apologies- I was a bit imprecise. Here I mean federated > authentication and authorization, meaning (loosely) that someone is = able > to make use of a service by authenticating with another entity using a > pre-existing set credentials. There are a whole lot of solutions = around > for web-based services, but very few for non-web. Correct me if I'm wrong, but I could.ve sworn that one of those was = standardized in the IETF: Kerberos. It may be for various reasons = unpopular with the Moonshot folks, but is that a good reason to = rubberstamp theirs? From gwz@net-zen.net Fri Aug 6 09:10:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C833A6895 for ; Fri, 6 Aug 2010 09:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJNhvXVtoSXI for ; Fri, 6 Aug 2010 09:10:07 -0700 (PDT) Received: from smtpauth19.prod.mesa1.secureserver.net (smtpauth19.prod.mesa1.secureserver.net [64.202.165.30]) by core3.amsl.com (Postfix) with SMTP id 088EC3A679F for ; Fri, 6 Aug 2010 09:10:06 -0700 (PDT) Received: (qmail 15334 invoked from network); 6 Aug 2010 16:10:37 -0000 Received: from unknown (195.46.229.98) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 06 Aug 2010 16:10:37 -0000 From: "Glen Zorn" To: "'Sean Turner'" References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1F20.4090809@ieca.com> In-Reply-To: <4C5C1F20.4090809@ieca.com> Date: Fri, 6 Aug 2010 18:10:28 +0200 Organization: Network Zen Message-ID: <00ba01cb3581$e492f280$adb8d780$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs1dXrtQ12MRoQ9Ts6e27NzrAodlgADEorg Content-Language: en-us Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:10:08 -0000 Sean Turner [mailto:turners@ieca.com] writes: > Glen Zorn wrote: > > Eliot Lear [mailto:lear@cisco.com] writes: > > > > ... > > > >>> Actually, I'd really like to see a clear problem statement before > >> anything > >>> else takes place. > >> I think the original proposed charter did this, but perhaps was a bit > >> verbose. > > > > I'd kind of like to verify this but the original charter seems to be > missing from the proceedings. > > Here's a link to originally proposed charter: > http://www.project-moonshot.org/bof/charter Thanks! ... From klaas@cisco.com Fri Aug 6 09:23:49 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33683A6AE5 for ; Fri, 6 Aug 2010 09:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.925 X-Spam-Level: X-Spam-Status: No, score=-9.925 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 PYM6P-bGTyYq for ; Fri, 6 Aug 2010 09:23:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C00983A68EC for ; Fri, 6 Aug 2010 09:23:36 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIDUW0xAZnwM/2dsb2JhbACTUYxucaozm1KCcYJJBIk3 X-IronPort-AV: E=Sophos;i="4.55,329,1278288000"; d="scan'208";a="144309884" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2010 16:23:58 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o76GNwui005547 for ; Fri, 6 Aug 2010 16:23:58 GMT Message-ID: <4C5C371D.1090504@cisco.com> Date: Fri, 06 Aug 2010 18:23:57 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: abfab@ietf.org References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> In-Reply-To: <00b601cb357f$7fafd6a0$7f0f83e0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:23:49 -0000 Glen, >>> OK, I know this is an inside game but what does that mean _in >>> this >> context_. I can find at least half a dozen definitions of >> "federated identity" w/at least that many commercial products >> claiming to support it. Which one is this? >>> >> >> My apologies- I was a bit imprecise. Here I mean federated >> authentication and authorization, meaning (loosely) that someone is >> able to make use of a service by authenticating with another entity >> using a pre-existing set credentials. There are a whole lot of >> solutions around for web-based services, but very few for non-web. > > Correct me if I'm wrong, but I could.ve sworn that one of those was > standardized in the IETF: Kerberos. It may be for various reasons > unpopular with the Moonshot folks, but is that a good reason to > rubberstamp theirs? no, that is not a good reason ;-) I guess the argument here is that there is a large installed base of SAML-based federations and these guys would like to leverage their existing infrastructure for access to non-web applications. Given the uptake of SAML I think that makes sense, and applicability beyond this one community. In addition to that there are AAA-infrastructures that have proved to scale. I think that at least it makes sense to explore combining SAML and AAA in this way. The briefing document defines therefore: 1- an API to integrate fedauth into application protocols 2- a federation fabric 3- a mechanism to communicate credentials and other information between principal and IdP for 1, 2 and 3 they have initially chosen resp. GSS-API, AAA and EAP. It is my understanding that these choices are not yet carved in stone, but than that functionality needs to be provided by something else. Klaas From cantor.2@osu.edu Fri Aug 6 09:29:41 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2C43A6AC7 for ; Fri, 6 Aug 2010 09:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8RE4Y+i-6jd for ; Fri, 6 Aug 2010 09:29:40 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by core3.amsl.com (Postfix) with ESMTP id 216EA3A6AEB for ; Fri, 6 Aug 2010 09:29:40 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=6Y8H/nL8L93N+XbmwlK57FdrlxW9D5uKLQCRlCnhMcQ= c=1 sm=0 a=ZfgalxPVnr8A:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=-vDZn4grljNCHwfDMKIA:9 a=ojYyKn8IpkDtW_zp4FUA:7 a=JgdMIo0OezzePnZHDlzSzcK2P58A: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:3195] helo=SNOWDOG) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id 85/1F-04805-2983C5C4; Fri, 06 Aug 2010 16:30:10 +0000 From: "Scott Cantor" To: "'Klaas Wierenga'" , References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> In-Reply-To: <4C5C371D.1090504@cisco.com> Date: Fri, 6 Aug 2010 12:30:10 -0400 Organization: The Ohio State University Message-ID: <005701cb3584$a374ff20$ea5efd60$@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: AQJqfgFG2eagL7nIRkejD0awrJcJmgIJSOYnAbmRKwEDKJW/HwJz6boRAWWRJPsA2YRNDgKcd/inkSQ0ulA= Content-language: en-us Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:29:41 -0000 > > Correct me if I'm wrong, but I could.ve sworn that one of those was > > standardized in the IETF: Kerberos. It may be for various reasons > > unpopular with the Moonshot folks, but is that a good reason to > > rubberstamp theirs? > > no, that is not a good reason ;-) I think it is if the uptake of Kerberos for federation is non-existent, and it's certainly close to that. Another criteria might be whether the proposed approach is likely to exceed that adoption, and of course I can't answer that. If we'd like to talk about what needs to happen to make Kerberos better for federation, we can certainly do that somewhere too. > I guess the argument here is that there is a large installed base of > SAML-based federations and these guys would like to leverage their > existing infrastructure for access to non-web applications. I really think it's more pragmatically "HELP"! We need an answer. Kerberos today is not one. Using a browser hack is a popular one, and it's one I really, really don't like, as Klaas can attest. But if nothing else gets done, it's going to win. So any other suggestions? That's where the proposal is coming from, IMHO. -- Scott From Josh.Howlett@ja.net Fri Aug 6 09:40:45 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF913A68F8 for ; Fri, 6 Aug 2010 09:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.022 X-Spam-Level: X-Spam-Status: No, score=-101.022 tagged_above=-999 required=5 tests=[AWL=0.977, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnQL4r72Xuon for ; Fri, 6 Aug 2010 09:40:44 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id AA0B93A6895 for ; Fri, 6 Aug 2010 09:40:44 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2B8A84A6BB1_C5C3B2BB; Fri, 6 Aug 2010 16:41:15 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 19FB14A6BA8_C5C3B2AF; Fri, 6 Aug 2010 16:41:14 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Fri, 6 Aug 2010 17:41:22 +0100 From: Josh Howlett To: Glen Zorn , "abfab@ietf.org" Thread-Topic: [abfab] Getting the charter done Thread-Index: AQHLNO5kf3G4qejO30Oy1W6OQ2FWvZLUKXqQgAAxHMCAAAlWgIAAC14AgAABroCAABNjAIAAF5jQ Date: Fri, 6 Aug 2010 16:41:10 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E6051603@EXC001.atlas.ukerna.ac.uk> References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> In-Reply-To: <00b601cb357f$7fafd6a0$7f0f83e0$@net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 16:40:45 -0000 R2xlbiwNCg0KPiBDb3JyZWN0IG1lIGlmIEknbSB3cm9uZywgYnV0IEkgY291bGQudmUgc3dvcm4g dGhhdCBvbmUgb2YgdGhvc2Ugd2FzDQo+IHN0YW5kYXJkaXplZCBpbiB0aGUgSUVURjogS2VyYmVy b3MuICBJdCBtYXkgYmUgZm9yIHZhcmlvdXMgcmVhc29ucw0KPiB1bnBvcHVsYXIgd2l0aCB0aGUg TW9vbnNob3QgZm9sa3MsIGJ1dCBpcyB0aGF0IGEgZ29vZCByZWFzb24gdG8NCj4gcnViYmVyc3Rh bXAgdGhlaXJzPw0KDQpJTU8gS2VyYmVyb3MgaXMgYSBncmVhdCBwcm90b2NvbDsgdW5mb3J0dW5h dGVseSBpdCBqdXN0IGRvZXNuJ3QgYWRkcmVzcyB0aGUgdXNlLWNhc2VzIGF0IGhhbmQuDQoNCldl IGV4cGxpY2l0bHkgYXNrZWQgU2FtIHRvIGNvbXBhcmUgTW9vbnNob3Qgd2l0aCBvdGhlciBhbHRl cm5hdGl2ZXMgcHJlY2lzZWx5IHRvIGF2b2lkIHJlLWludmVudGluZyB0aGUgd2hlZWw7IHBsZWFz ZSBjaGVjayBvdXQgc2VjdGlvbiAxMCBvZiB0aGUgTW9vbnNob3QgJ0ZlYXNpYmlsaXR5IEFuYWx5 c2lzJyBmb3IgdGhpcyBkaXNjdXNzaW9uLg0KDQpodHRwOi8vd3d3LnByb2plY3QtbW9vbnNob3Qu b3JnL3NpdGVzL2RlZmF1bHQvZmlsZXMvbW9vbnNob3QtZmVhc2liaWxpdHktYW5hbHlzaXMucGRm DQoNCkJlc3QgcmVnYXJkcywgSm9zaC4NCgpKQU5FVChVSykgaXMgYSB0cmFkaW5nIG5hbWUgb2Yg VGhlIEpOVCBBc3NvY2lhdGlvbiwgYSBjb21wYW55IGxpbWl0ZWQKYnkgZ3VhcmFudGVlIHdoaWNo IGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCB1bmRlciBOby4gMjg4MTAyNCAKYW5kIHdob3NlIFJl Z2lzdGVyZWQgT2ZmaWNlIGlzIGF0IEx1bWVuIEhvdXNlLCBMaWJyYXJ5IEF2ZW51ZSwKSGFyd2Vs bCBTY2llbmNlIGFuZCBJbm5vdmF0aW9uIENhbXB1cywgRGlkY290LCBPeGZvcmRzaGlyZS4gT1gx MSAwU0cKCg== From klaas@cisco.com Fri Aug 6 11:20:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82B23A6A1F for ; Fri, 6 Aug 2010 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO0RSxWufvxR for ; Fri, 6 Aug 2010 11:20:37 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 8424F3A685E for ; Fri, 6 Aug 2010 11:20:36 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=[10.55.220.245]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OhRX7-0006cH-Fm; Fri, 06 Aug 2010 20:20:41 +0200 References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> Message-Id: <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> From: Klaas Wierenga To: Scott Cantor In-Reply-To: <005701cb3584$a374ff20$ea5efd60$@osu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Fri, 6 Aug 2010 20:21:37 +0200 X-Antivirus: no malware found Cc: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 18:20:37 -0000 Sent from my iPad On Aug 6, 2010, at 6:30 PM, "Scott Cantor" wrote: >>> Correct me if I'm wrong, but I could.ve sworn that one of those was >>> standardized in the IETF: Kerberos. It may be for various reasons >>> unpopular with the Moonshot folks, but is that a good reason to >>> rubberstamp theirs? >>=20 >> no, that is not a good reason ;-) >=20 > I think it is if the uptake of Kerberos for federation is = non-existent, and > it's certainly close to that. Another criteria might be whether the = proposed > approach is likely to exceed that adoption, and of course I can't = answer > that. >=20 > If we'd like to talk about what needs to happen to make Kerberos = better for > federation, we can certainly do that somewhere too. >=20 >> I guess the argument here is that there is a large installed base of >> SAML-based federations and these guys would like to leverage their >> existing infrastructure for access to non-web applications. >=20 > I really think it's more pragmatically "HELP"! But that is mainly for the idp discovery and metadata distribution part, = right? Not so much for the non-web aspect. >=20 > We need an answer. Kerberos today is not one. Using a browser hack is = a > popular one, and it's one I really, really don't like, as Klaas can = attest. Yes, I can ;-) Klaas > But if nothing else gets done, it's going to win. So any other = suggestions? >=20 > That's where the proposal is coming from, IMHO. >=20 > -- Scott >=20 >=20 From hartmans@painless-security.com Fri Aug 6 11:47:20 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67CAE3A67B2 for ; Fri, 6 Aug 2010 11:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 YT5z6bbq1gvh for ; Fri, 6 Aug 2010 11:47:19 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9CA243A69E4 for ; Fri, 6 Aug 2010 11:47:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dyn-209-2-234-118.dyn.columbia.edu [209.2.234.118]) (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 169342045C; Fri, 6 Aug 2010 14:47:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B8E384129; Fri, 6 Aug 2010 14:47:29 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> Date: Fri, 06 Aug 2010 14:47:29 -0400 In-Reply-To: <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> (Klaas Wierenga's message of "Fri, 6 Aug 2010 20:21:37 +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: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 18:47:20 -0000 I do find it telling that several of the major Kerberos contributors--myself, Nico--think that gss-eap is a better fit than Kerberos today. I think I've answered in enough detail for a charter discussion in the section on the feasability analysis. Ultimately, I think Kerberos is something to continue to think about, but several of us who are very familiar with Kerberos have tried to fit it into this model and failed. I actually think we'll be able to re-use much or all of this work if we do ever figure out how to make Kerberos part of the abfab ecosystem. I plan to continue those explorations but think we've gone down that path enough to conclude that we don't want to block abfab on its conclusions. --Sam From Nicolas.Williams@oracle.com Fri Aug 6 11:50:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA603A6898 for ; Fri, 6 Aug 2010 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=-0.652, 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 9Xx0DFHiFVJu for ; Fri, 6 Aug 2010 11:50:22 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 143E83A6885 for ; Fri, 6 Aug 2010 11:50:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o76IokZs005252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2010 18:50:49 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 o76IYtvI031262; Fri, 6 Aug 2010 18:50:46 GMT Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 491829141281112588; Fri, 06 Aug 2010 09:36:28 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Aug 2010 09:36:28 -0700 Date: Fri, 6 Aug 2010 11:36:23 -0500 From: Nicolas Williams To: Glen Zorn Message-ID: <20100806163623.GU5213@oracle.com> References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101cb3563$ece9f0a0$c6bdd1e0$@net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 18:50:23 -0000 On Fri, Aug 06, 2010 at 02:35:57PM +0200, Glen Zorn wrote: > Actually, I'd really like to see a clear problem statement before anything > else takes place. A clear problem statement is always a good thing, and here critical. > As I attempted to say in the meeting, the pieces of > technology to be mutilated seem to have been chosen largely on the basis of > convenience: Is there any better way to choose technologies to mutilate? I suppose if one is to mutilate technologies, then choosing them randomly might work well enough. More seriously: convenience is going to be critical to deployment. And in this case it seems to be driving the design. Observing that "these are the pieces we have" leads one to ask "how can we leverage them into solutions to bigger problems?" -- a much better question than "how do we replace them with a cleaner solution?" or worse, than just giving up on solving bigger problems. The real question is not "is this the best way to put a solution together?" but "will this work?" (for a value of "work" that includes "secure"). > "We have RADIUS servers and all these apps that support GSS, > how shall we connect them? I know, let's hack on EAP, everybody else > does!". Of course, I have no idea if this is actually the case and even if > it were it is no condemnation of the project; it seems to me a very weak > basis upon which to build a standard, however. What makes this "a very weak basis upon which to build a standard"? The use of other standards as construction blocks?? Surely not! I'd have thought that'd be commendable. Would you rather the proponents build a proprietary solution instead? Or did you mean that you see no way to build a secure solution using these particular building blocks? Such an objection I'd understand, but please be specific, not only as to claims, but also please provide at least a rough outline of how these building blocks make for a sub-par solution. Incidentally, this project violates my own sense of aesthetics, perhaps as much as it seems to yours. And I found your, er, "mutilation" of the proposal rather funny. But technical and economic issues trump aesthetics. I've long been a proponent of making it possible for users to use existing authentication infrastructure rather than forcing them to deploy specific authentication infrastructures in order to use this or that application. I see no reason why this case should be different. Nico -- From cantor.2@osu.edu Fri Aug 6 12:06:58 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E593A68CC for ; Fri, 6 Aug 2010 12:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.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 RMUyl3Zvq-IY for ; Fri, 6 Aug 2010 12:06:57 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by core3.amsl.com (Postfix) with ESMTP id 845663A68A7 for ; Fri, 6 Aug 2010 12:06:57 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=puNM1lMKksHKE6hmMqMstpyRmqXf+M/teYaxpNq+S3U= c=1 sm=0 a=ZfgalxPVnr8A:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=pGHlZd0SLpKiUMAMQ5cA:9 a=UXezlUZcJ11DeGcQXmixBIMcyhwA: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:3314] helo=SNOWDOG) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.2.39 r()) with ESMTP id A2/AF-24046-C6D5C5C4; Fri, 06 Aug 2010 19:07:24 +0000 From: "Scott Cantor" To: "'Klaas Wierenga'" References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> In-Reply-To: <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> Date: Fri, 6 Aug 2010 15:07:24 -0400 Organization: The Ohio State University Message-ID: <008b01cb359a$9ab3c720$d01b5560$@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: AQJqfgFG2eagL7nIRkejD0awrJcJmgIJSOYnAbmRKwEDKJW/HwJz6boRAWWRJPsA2YRNDgKcd/inAoMuyYsBzFXbDpEB5FgA Content-language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:06:58 -0000 > >> I guess the argument here is that there is a large installed base of > >> SAML-based federations and these guys would like to leverage their > >> existing infrastructure for access to non-web applications. > > > > I really think it's more pragmatically "HELP"! > > But that is mainly for the idp discovery and metadata distribution part, > right? Not so much for the non-web aspect. No, I think the telling fact is that in the face of some complexity, the Moonshot work has initially suggested dropping SAML from the base use case for scenarios in which additional attribute information can be handled by AAA. So if this was purely "how can we fit SAML in", that wouldn't be the case. On the SAML side, the wins are potentially all of those things (discovery, via an active client, some new ways to think about metadata verification, and the non-web applicability). Obviously, we can fit SAML into the non-web problem in other ways too, but the security will likely be weaker than these proposals. That makes for a good set of options to trade-off, I think. To speak to the "what exists now" argument, the alternative to this work today is not Kerberos, it's IMI/Infocard. -- Scott From Nicolas.Williams@oracle.com Fri Aug 6 12:11:19 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB6E3A6A6C for ; Fri, 6 Aug 2010 12:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 NbeUMsvIg3n4 for ; Fri, 6 Aug 2010 12:11:18 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 090293A6A6A for ; Fri, 6 Aug 2010 12:11: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.2) with ESMTP id o76JBjYe010606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2010 19:11:47 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 o76Ikhb0029599; Fri, 6 Aug 2010 19:11:43 GMT Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 491842311281112860; Fri, 06 Aug 2010 09:41:00 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Aug 2010 09:40:59 -0700 Date: Fri, 6 Aug 2010 11:40:50 -0500 From: Nicolas Williams To: Glen Zorn Message-ID: <20100806164049.GV5213@oracle.com> References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b601cb357f$7fafd6a0$7f0f83e0$@net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: 'Josh Howlett' , abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:11:19 -0000 On Fri, Aug 06, 2010 at 05:53:20PM +0200, Glen Zorn wrote: > Eliot Lear [mailto:lear@cisco.com] writes: > > > Glen, > > > OK, I know this is an inside game but what does that mean _in this > > context_. I can find at least half a dozen definitions of "federated > > identity" w/at least that many commercial products claiming to support > > it. Which one is this? > > > > > > > My apologies- I was a bit imprecise. Here I mean federated > > authentication and authorization, meaning (loosely) that someone is able > > to make use of a service by authenticating with another entity using a > > pre-existing set credentials. There are a whole lot of solutions around > > for web-based services, but very few for non-web. > > Correct me if I'm wrong, but I could.ve sworn that one of those was > standardized in the IETF: Kerberos. It may be for various reasons > unpopular with the Moonshot folks, but is that a good reason to > rubberstamp theirs? There's also PKI. But not everyone has a PKI or a Kerberos infrastructure deployed. Users should be able to use the authentication infrastructures that they already have unless they are woefully inadequate. Now, there are many ways that I could see to do this. One would be to extend Kerberos pre-authentication to support such other authentication infrastructures, thus leveraging them into a Kerberos infrastructure. I'll note too that Kerberos isn't quite a federated authentication system, but that's a matter of missing pieces rather than fundamental limitations (much the same applies to PKI). Nico -- From Nicolas.Williams@oracle.com Fri Aug 6 12:23:38 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A10B3A6971 for ; Fri, 6 Aug 2010 12:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.187 X-Spam-Level: X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 5n8Bh8rOva9Z for ; Fri, 6 Aug 2010 12:23:37 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5DCDB3A6900 for ; Fri, 6 Aug 2010 12:23:37 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o76JO6Ej029923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2010 19:24:08 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 o76IbvAW018956; Fri, 6 Aug 2010 19:24:06 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 492439811281122643; Fri, 06 Aug 2010 12:24:03 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Aug 2010 12:24:02 -0700 Date: Fri, 6 Aug 2010 14:23:57 -0500 From: Nicolas Williams To: Klaas Wierenga Message-ID: <20100806192356.GZ5213@oracle.com> References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5C371D.1090504@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 19:23:38 -0000 On Fri, Aug 06, 2010 at 06:23:57PM +0200, Klaas Wierenga wrote: > >Correct me if I'm wrong, but I could.ve sworn that one of those was > >standardized in the IETF: Kerberos. It may be for various reasons > >unpopular with the Moonshot folks, but is that a good reason to > >rubberstamp theirs? > > no, that is not a good reason ;-) I object to the notion of "rubberstamping", and to the notion that the IETF has or should have a single applicable standard. The popularity or not of with has been, is and should continue to be irrelevant at the IETF. The IETF has several standards-track authentication mechanisms, more than one of which allows for transitive trust and/or namespace delegation. One more wouldn't hurt. The thing that bothers me is that standard mechanisms are not really usable in web contexts. Moonshot doesn't have to help that problem, though I'd certainly like to see it helped. For me the guiding principle here is that whatever authentication infrastructure a user has, they should be able to use it in Internet protocols and web applications, as well as non-Internet protocols that use Internet protocols such as SASL and the GSS-API. (On a separate note, I'm concerned about how trust transitivity is used.) Nico -- From klaas@cisco.com Fri Aug 6 13:25:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7E83A6831 for ; Fri, 6 Aug 2010 13:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caA39YlhhLi5 for ; Fri, 6 Aug 2010 13:25:44 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 4966C3A67ED for ; Fri, 6 Aug 2010 13:25:44 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=[10.55.220.245]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OhTUE-00076d-Mh; Fri, 06 Aug 2010 22:25:50 +0200 References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> Message-Id: <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> From: Klaas Wierenga To: Nicolas Williams In-Reply-To: <20100806192356.GZ5213@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Fri, 6 Aug 2010 22:26:48 +0200 X-Antivirus: no malware found Cc: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 20:25:46 -0000 Sent from my iPad On Aug 6, 2010, at 9:24 PM, "Nicolas Williams" = wrote: > On Fri, Aug 06, 2010 at 06:23:57PM +0200, Klaas Wierenga wrote: >>> Correct me if I'm wrong, but I could.ve sworn that one of those was >>> standardized in the IETF: Kerberos. It may be for various reasons >>> unpopular with the Moonshot folks, but is that a good reason to >>> rubberstamp theirs? >>=20 >> no, that is not a good reason ;-) >=20 > I object to the notion of "rubberstamping", and to the notion that the > IETF has or should have a single applicable standard. The popularity = or > not of with has been, is and > should continue to be irrelevant at the IETF. I didn't mean to suggest that, what I was referring to was the 'because = it is unpopular' statement. I think it is good engineering practise to = first look at what is available and see whether that satisfies your = requirements before going on a new endeavor. I think the moonshot people = have investigated alternative approaches, and those don't satisfy the = requirements for different reasons, be it technical, commercial or lack = of uptake. They are not trying to rubber stamp whatever they came up = with but seek guidance from the IETF community, I think that that is = commendable. Otoh Glen's questions are justified imo, we should be = critical towards the chosen directions, and if there are better ways of = solving the problem we should be open to that. =20 >=20 > The IETF has several standards-track authentication mechanisms, more > than one of which allows for transitive trust and/or namespace > delegation. One more wouldn't hurt. >=20 > The thing that bothers me is that standard mechanisms are not really > usable in web contexts. Moonshot doesn't have to help that problem, > though I'd certainly like to see it helped. For me the guiding > principle here is that whatever authentication infrastructure a user > has, they should be able to use it in Internet protocols and web > applications, as well as non-Internet protocols that use Internet > protocols such as SASL and the GSS-API. >=20 > (On a separate note, I'm concerned about how trust transitivity is > used.) I am interested in your concerns here, do you care to comment on that? ( = perhaps in a separate mail ) Klaas > Nico > --=20 From Nicolas.Williams@oracle.com Fri Aug 6 14:32:02 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D57428B56A for ; Fri, 6 Aug 2010 14:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 xF-Nu9bqH9YI for ; Fri, 6 Aug 2010 14:32:01 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5165C28C1E2 for ; Fri, 6 Aug 2010 14:02:40 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o76L388R006135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2010 21:03:10 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 o76IYD2I027349; Fri, 6 Aug 2010 21:03:07 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 473659971281128478; Fri, 06 Aug 2010 14:01:18 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 06 Aug 2010 14:01:17 -0700 Date: Fri, 6 Aug 2010 16:01:11 -0500 From: Nicolas Williams To: Klaas Wierenga Message-ID: <20100806210111.GC5213@oracle.com> References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 21:32:02 -0000 On Fri, Aug 06, 2010 at 10:26:48PM +0200, Klaas Wierenga wrote: > On Aug 6, 2010, at 9:24 PM, "Nicolas Williams" wrote: > > On Fri, Aug 06, 2010 at 06:23:57PM +0200, Klaas Wierenga wrote: > >>> Correct me if I'm wrong, but I could.ve sworn that one of those was > >>> standardized in the IETF: Kerberos. It may be for various reasons > >>> unpopular with the Moonshot folks, but is that a good reason to > >>> rubberstamp theirs? > >> > >> no, that is not a good reason ;-) > > > > I object to the notion of "rubberstamping", and to the notion that the > > IETF has or should have a single applicable standard. The popularity or > > not of with has been, is and > > should continue to be irrelevant at the IETF. > > I didn't mean to suggest that, what I was referring to was the > 'because it is unpopular' statement. I think it is good engineering > practise to first look at what is available and see whether that > satisfies your requirements before going on a new endeavor. I think > the moonshot people have investigated alternative approaches, and > those don't satisfy the requirements for different reasons, be it > technical, commercial or lack of uptake. They are not trying to rubber > stamp whatever they came up with but seek guidance from the IETF > community, I think that that is commendable. Otoh Glen's questions are > justified imo, we should be critical towards the chosen directions, > and if there are better ways of solving the problem we should be open > to that. You're right, and my response (which was really intended for Glen) was a bit over the top. The point is that off-the-shelf solutions are always better, except when they aren't, and that it is possible for an off-the-shelf solution to fail to meet requirements without that being the result of a subjective popularity contest. The very fact that the IETF doesn't have one, but at least two security technologies that in many ways are equivalent (PKIX and Kerberos) is proof of that. Though, of course, there may well be examples of redundancy arising for bad reasons (perhaps SASL vs. the GSS-API is an example of that). It is necessary for the IETF to eliminate unnecessary redundancy for the simple reason that review capacity is limited. Nico -- From leifj@sunet.se Fri Aug 6 14:33:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B7F3A6959 for ; Fri, 6 Aug 2010 14:33:13 -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 tjy4fa9opZjO for ; Fri, 6 Aug 2010 14:33:12 -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 A2C3928C118 for ; Fri, 6 Aug 2010 14:10:01 -0700 (PDT) Received: from [90.236.238.205] (host-90-236-238-205.mobileonline.telia.com [90.236.238.205]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o76LARxZ013080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Aug 2010 23:10:32 +0200 (CEST) Message-ID: <4C5C7A42.20804@sunet.se> Date: Fri, 06 Aug 2010 23:10:26 +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: abfab@ietf.org References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <20100806163623.GU5213@oracle.com> In-Reply-To: <20100806163623.GU5213@oracle.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 21:33:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > More seriously: convenience is going to be critical to deployment. And > in this case it seems to be driving the design. Observing that "these > are the pieces we have" leads one to ask "how can we leverage them into > solutions to bigger problems?" -- a much better question than "how do we > replace them with a cleaner solution?" or worse, than just giving up on > solving bigger problems. I think you made _the_ critical observation Nico. The moonshot proposal isn't trying to build something from scratch but from available pieces. Perfect is often the enemy of the good (enough). Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxcekIACgkQ8Jx8FtbMZnfPZwCfZqHBuAjM/IAVbwukOsioTi+R BbAAn391F5X+qAR17yty0jXqpW1hGy4b =lh1W -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Mon Aug 9 11:11:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C1428C11D for ; Mon, 9 Aug 2010 11:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.119, 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 csliy8j96Qrx for ; Mon, 9 Aug 2010 11:10:50 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CD14E3A6B24 for ; Mon, 9 Aug 2010 11:10: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.2) with ESMTP id o79IAwNk023974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 18:11:01 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 o7907s6W013134; Mon, 9 Aug 2010 18:10:57 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 479970891281377433; Mon, 09 Aug 2010 11:10:33 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 11:10:32 -0700 Date: Mon, 9 Aug 2010 13:10:27 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100809181025.GD5217@oracle.com> References: <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@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) Cc: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:11:02 -0000 On Fri, Aug 06, 2010 at 02:47:29PM -0400, Sam Hartman wrote: > I do find it telling that several of the major Kerberos > contributors--myself, Nico--think that gss-eap is a better fit than > Kerberos today. It's worth noting that some of us are usual suspects in the Kerberos world. Sam and I, for example, have been active in the KRB-WG for about a decade (Sam probably for longer). And have authored or co-authored Kerberos RFCs and reviewed many more. And we are or have been implementors. Normally one would expect people to boost the technologies they are most familiar with. But that is not what's happening here. There's a reason for this: Kerberos isn't the solution to every security problem, not any more than PKI is. > I think I've answered in enough detail for a charter discussion in the > section on the feasability analysis. Ultimately, I think Kerberos is > something to continue to think about, but several of us who are very > familiar with Kerberos have tried to fit it into this model and failed. I think you have, but I'd like to explore a related angle. I hope this will help settle the desirability of Moonshot. Let's consider the range of possible solutions here. We have some authentication infrastructure that exists already but is neither PKI nor Kerberos. And we want this to be usable wherever SASL/GSS-API are usable, as well as in web and non-web HTTP applications (but allow me to ignore the HTTP apps for now[*]). I see two types of solutions: - Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs that issue short-lived certs) or Kerberos that uses the existing authentication infrastructure. - Type 2: Add a GSS-API (and therefore SASL/GS2) mechanism that uses the existing authentication infrastructure. Note that that type 2 is actually a... usable in type 1 solutions! That's because SACRED already uses SASL... And we could easily define a Kerberos pre-authentication method that uses the GSS-API... (in fact, I've proposed this in the past). Clearly, by far the the most general solution is type 2 + a generic variant of type 1 (i.e., where pre-authentication uses GSS mechanisms). In other words, if you want the most general solution you should want _both_. And you should want to start with type 2 solutions. Now, what does solution type 1 buy us over solution type 2? Ticketing, effectively, and the ability to combine multiple existing authentication infrastructures. If you have Radius... you can have Kerberos! Nice. But if you don't need ticketing and you don't already have Kerberos (or PKI) deployed, then solution type 1 simply adds overhead, signficant overhead. Enough overhead to make it unlikely to ever be deployed. Which gets me back to the principle that Internet protocols should support the authentication infrastructures that users have deployed. Internet protocols should absolutely NOT dictate which authentication infrastructures users must deploy. Exceptions for protocols like IKE should be allowed but only because we can define additional KE protocols such as KINK, though I'd really rather make IKE itself able to use a variety of authentication infrastructures by making it pluggable (it alread is or is becoming, via EAP, but IMO it also needs direct GSS-API support for non-VPN uses of IPsec). [*] Back to HTTP... For non-web apps I think HTTP/Negotiate will do. For web apps I think we need something more like a REST binding of the GSS-API, with channel binding to https via tls-server-end-point CB (though I can also see how to do it with tls-unique CB). Nico -- From hannes.tschofenig@nsn.com Mon Aug 9 11:23:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778803A6B16 for ; Mon, 9 Aug 2010 11:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USn2Ept++gpN for ; Mon, 9 Aug 2010 11:23:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DCB113A6B28 for ; Mon, 9 Aug 2010 11:23:05 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o79INdMb020222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 20:23:39 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o79INcSe020342; Mon, 9 Aug 2010 20:23:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 20:23:38 +0200 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 Date: Mon, 9 Aug 2010 21:23:37 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E233BE@FIESEXC015.nsn-intra.net> In-Reply-To: <20100809181025.GD5217@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Getting the charter done Thread-Index: Acs37la/lOXXySQHRniMgfO6AsDPowAAF7nQ References: <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk><005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com><009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com><00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com><005701cb3584$a374ff20$ea5efd60$@osu.edu><9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Nicolas Williams" , "Sam Hartman" X-OriginalArrivalTime: 09 Aug 2010 18:23:38.0455 (UTC) FILETIME=[FC955E70:01CB37EF] Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:23:07 -0000 Just trying to figure out what you mean:=20 > I see two types of solutions: >=20 > - Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs > that issue short-lived certs) Something like=20 http://tools.ietf.org/html/draft-ietf-sip-certs-14 ? (similar mechanisms have been developed for other protocols; for XMPP I suspect that this spec would be the right to reference http://xmpp.org/extensions/xep-0257.html) (Other SDOs have defined similar protocols; there is clearly no shortage on specs -- only on the deployment side...) > or Kerberos that uses the > existing authentication infrastructure. Something like=20 http://tools.ietf.org/id/draft-tschofenig-pana-bootstrap-kerberos-00.txt or more something like Appendix A of http://tools.ietf.org/id/draft-tschofenig-enroll-next-steps-00.txt The former is more attached to the network access authentication procedure than the latter.=20 Ciao Hannes PS: There are obviously lots of options but the question is which onces are most likely going to be successful from an implementation & deployment point of view.=20 From hannes.tschofenig@nsn.com Mon Aug 9 11:32:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4B83A6896 for ; Mon, 9 Aug 2010 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZ2bbVXxjYCw for ; Mon, 9 Aug 2010 11:32:05 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 05CEF3A67B3 for ; Mon, 9 Aug 2010 11:32:04 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o79IWcaH009069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Aug 2010 20:32:38 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o79IWbFx026586 for ; Mon, 9 Aug 2010 20:32:38 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 20:32:15 +0200 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 Date: Mon, 9 Aug 2010 21:32:14 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E233C0@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Which approach to choose? Thread-Index: Acs38TAuJYZiR6HkTmSBus48y3tU1A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 09 Aug 2010 18:32:15.0660 (UTC) FILETIME=[30DC96C0:01CB37F1] Subject: [abfab] Which approach to choose? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:32:07 -0000 This particular topic is quite a challenging one since the solution space is extremely large and there is a lot of prior work one could re-use (or build solutions on top of).=20 So, what to do?=20 I would actually take the OAuth experience since I consider it as a success story.=20 The opinion of those who contribute open source code (see http://oauth.net/code/) and deploy it should have more weight. Everyone can easily come up with new ideas for protocols in this area but without code and deployment the contribution is fairly useless.=20 Hence, the obvious question is: Who is going to write code and who will deploy?=20 Ciao Hannes From cantor.2@osu.edu Mon Aug 9 11:39:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16B6A3A69D1 for ; Mon, 9 Aug 2010 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.995, 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 nb78xW5Fq4rN for ; Mon, 9 Aug 2010 11:39:09 -0700 (PDT) Received: from defang2.it.ohio-state.edu (defang2.it.ohio-state.edu [128.146.216.82]) by core3.amsl.com (Postfix) with ESMTP id 77C863A683C for ; Mon, 9 Aug 2010 11:39:08 -0700 (PDT) Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang2.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79IdgUw009435; Mon, 9 Aug 2010 14:39:42 -0400 Received: from SNOWDOG (dhcp-128-146-28-22.osuwireless.ohio-state.edu [128.146.28.22]) by defang6.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79IdfQw023049; Mon, 9 Aug 2010 14:39:41 -0400 From: "Scott Cantor" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <3D3C75174CB95F42AD6BCC56E5555B4502E233C0@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E233C0@FIESEXC015.nsn-intra.net> Date: Mon, 9 Aug 2010 14:39:43 -0400 Organization: The Ohio State University Message-ID: <018601cb37f2$3c6d23f0$b5476bd0$@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: AQMLzxtXc26JH000/WUHRseq/f4z8JBYRWxA 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.82 Subject: Re: [abfab] Which approach to choose? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:39:10 -0000 > I would actually take the OAuth experience since I consider it as a > success story. A widely deployed solution that reduces security in the end has its own downsides. > The opinion of those who contribute open source code (see > http://oauth.net/code/) and deploy it should have more weight. Everyone > can easily come up with new ideas for protocols in this area but without > code and deployment the contribution is fairly useless. Yes, but it has to be the right people. "Everybody who might ever write a web app" should not be the audience for a security protocol, IMHO, but that is the benchmark people are shooting for today. I think there's a middle ground, but today the solutions are targeting the knowledge extremes, IMHO. -- Scott From hannes.tschofenig@nsn.com Mon Aug 9 11:52:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F8E3A6B16 for ; Mon, 9 Aug 2010 11:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-tASOySrwwt for ; Mon, 9 Aug 2010 11:52:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C4BE23A6940 for ; Mon, 9 Aug 2010 11:52:06 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o79IqYuA004718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 20:52:34 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o79IqWcu015048; Mon, 9 Aug 2010 20:52:32 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 20:52:31 +0200 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 Date: Mon, 9 Aug 2010 21:52:30 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E233C2@FIESEXC015.nsn-intra.net> In-Reply-To: <018601cb37f2$3c6d23f0$b5476bd0$@osu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Which approach to choose? Thread-Index: AQMLzxtXc26JH000/WUHRseq/f4z8JBYRWxAgAABvoA= References: <3D3C75174CB95F42AD6BCC56E5555B4502E233C0@FIESEXC015.nsn-intra.net> <018601cb37f2$3c6d23f0$b5476bd0$@osu.edu> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Scott Cantor" , X-OriginalArrivalTime: 09 Aug 2010 18:52:31.0576 (UTC) FILETIME=[059AA580:01CB37F4] Subject: Re: [abfab] Which approach to choose? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:52:08 -0000 Do I hear a bit of frustration in between the lines?=20 I saw a lot of people on the microphone during the BOF who wanted to work on a different solution. Knowing some of those persons from my IETF experience I also know that they neither write code nor decide about deployment.=20 Having web developers use good open source libraries is a good start (ignoring that this group works on non-web based applications). If nobody understands the result (because it is so complicated) or so difficult to use then something went wrong.=20 > > I would actually take the OAuth experience since I consider it as a > > success story. >=20 > A widely deployed solution that reduces security in the end=20 > has its own > downsides. .... in comparison to some other work that never got deployed and people continued passing their long-term secret to third parties? Hmmm? From cantor.2@osu.edu Mon Aug 9 12:11:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D963B3A67F2 for ; Mon, 9 Aug 2010 12:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.082, 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 NULkMnXgUXtP for ; Mon, 9 Aug 2010 12:11:06 -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 E8E7F3A68C5 for ; Mon, 9 Aug 2010 12:11:05 -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 o79JBdS3016446; Mon, 9 Aug 2010 15:11:39 -0400 Received: from SNOWDOG (dhcp-128-146-28-22.osuwireless.ohio-state.edu [128.146.28.22]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79JBdkS015654; Mon, 9 Aug 2010 15:11:39 -0400 From: "Scott Cantor" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <3D3C75174CB95F42AD6BCC56E5555B4502E233C0@FIESEXC015.nsn-intra.net> <018601cb37f2$3c6d23f0$b5476bd0$@osu.edu> <3D3C75174CB95F42AD6BCC56E5555B4502E233C2@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E233C2@FIESEXC015.nsn-intra.net> Date: Mon, 9 Aug 2010 15:11:42 -0400 Organization: The Ohio State University Message-ID: <019101cb37f6$b35e3810$1a1aa830$@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: AQMLzxtXc26JH000/WUHRseq/f4z8AG4vvNuAwUiCGCQMls/8A== 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 Subject: Re: [abfab] Which approach to choose? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:11:08 -0000 > Do I hear a bit of frustration in between the lines? Sure. And some fundamental disagreements, to which I'm entitled. > I saw a lot of people on the microphone during the BOF who wanted to > work on a different solution. Knowing some of those persons from my IETF > experience I also know that they neither write code nor decide about > deployment. That's fair, I'm just saying that asking app developers to do the work doesn't get you a good solution either. > Having web developers use good open source libraries is a good start > (ignoring that this group works on non-web based applications). If > nobody understands the result (because it is so complicated) or so > difficult to use then something went wrong. I agree, but there's a strong movement these days to require solutions be implementable without libraries, or in languages with constraints that make good solutions unrealistic, and I don't agree with that. > > A widely deployed solution that reduces security in the end > > has its own downsides. > > .... in comparison to some other work that never got deployed and people > continued passing their long-term secret to third parties? Hmmm? If that was all I thought it would get used for, I wouldn't be as concerned about it. -- Scott From Nicolas.Williams@oracle.com Mon Aug 9 12:12:12 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A43523A68C5 for ; Mon, 9 Aug 2010 12:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Go1IjgOMfO6h for ; Mon, 9 Aug 2010 12:12:10 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 02BAA3A67F2 for ; Mon, 9 Aug 2010 12:12:09 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o79JCgbY014217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 19:12:44 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 o79AeCOC012419; Mon, 9 Aug 2010 19:12:41 GMT Received: from abhmt005.oracle.com by acsmt353.oracle.com with ESMTP id 500058321281381139; Mon, 09 Aug 2010 12:12:19 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 12:12:18 -0700 Date: Mon, 9 Aug 2010 14:12:13 -0500 From: Nicolas Williams To: "Tschofenig, Hannes (NSN - FI/Espoo)" Message-ID: <20100809191213.GA5213@oracle.com> References: <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <3D3C75174CB95F42AD6BCC56E5555B4502E233BE@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E233BE@FIESEXC015.nsn-intra.net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:12:12 -0000 On Mon, Aug 09, 2010 at 09:23:37PM +0300, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Just trying to figure out what you mean: > > > I see two types of solutions: > > > > - Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs > > that issue short-lived certs) > > Something like > http://tools.ietf.org/html/draft-ietf-sip-certs-14 > ? > (similar mechanisms have been developed for other protocols; for XMPP I > suspect that this spec would be the right to reference > http://xmpp.org/extensions/xep-0257.html) No, I meant specifically SACRED, with a SASL mechanism that does the RADIUS EAP thing. (But I only read the abstract of draft-ietf-sip-certs.) > > or Kerberos that uses the > > existing authentication infrastructure. > > Something like > http://tools.ietf.org/id/draft-tschofenig-pana-bootstrap-kerberos-00.txt > or more something like Appendix A of > http://tools.ietf.org/id/draft-tschofenig-enroll-next-steps-00.txt Maybe, but I see nothing in draft-tschofenig-pana-bootstrap-kerberos about pre-authentication. > PS: There are obviously lots of options but the question is which onces > are most likely going to be successful from an implementation & > deployment point of view. Exactly. For me there's also a degree of generality. I'd like all GSS-API mechanisms to be usable in all of the following cases: - Application protocols using SASL (via GS2): - IMAP, SUBMIT, SMTP - LDAP - SACRED (and any related online CA protocols -- think kca, but with GSS-API instead of raw Kerberos for authenticating the requestor) - XMPP - ... - Application protocols using the GSS-API: - SSHv2 - NFSv4, FTP (and SFTP via SSHv2) - DNS GSS-TSIG (for DNS updates) - ... - non-browser HTTP apps (XMPP, *DAV) - browser HTTP apps - IKEv2 - Kerberos pre-authentication (preferably via the GSS-API) - I'd also like ways to use all the authentication mechanisms that we have in EAP applications as well. This degree of generality means users can use whatever authentication infrastructure they've already deployed. And it means we can bridge authentication infrastructures where necessary. Nico -- From cantor.2@osu.edu Mon Aug 9 14:23:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84B33A685B for ; Mon, 9 Aug 2010 14:23:01 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYCyG9tqm9Df for ; Mon, 9 Aug 2010 14:23:00 -0700 (PDT) Received: from defang2.it.ohio-state.edu (defang2.it.ohio-state.edu [128.146.216.82]) by core3.amsl.com (Postfix) with ESMTP id CE1093A6845 for ; Mon, 9 Aug 2010 14:22:59 -0700 (PDT) Received: from defang6.it.ohio-state.edu (defang6.it.ohio-state.edu [128.146.216.86]) by defang2.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79LNXSc000485; Mon, 9 Aug 2010 17:23:33 -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 o79LNXwb025484; Mon, 9 Aug 2010 17:23:33 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" References: <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> In-Reply-To: <20100809181025.GD5217@oracle.com> Date: Mon, 9 Aug 2010 17:23:35 -0400 Organization: The Ohio State University Message-ID: <01b201cb3809$20701ab0$61505010$@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: AQIJSOYnwl2FwwjQpEbftEaMtaJeFgG5kSsBAyiVvx8Cc+m6EQFlkST7ANmETQ4CnHf4pwKDLsmLAcxV2w4BW0akfgJFgrRGkbxwaDA= 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.82 Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 21:23:02 -0000 > [*] Back to HTTP... For non-web apps I think HTTP/Negotiate will do. > For web apps I think we need something more like a REST binding of > the GSS-API, with channel binding to https via tls-server-end-point > CB (though I can also see how to do it with tls-unique CB). I had the impression you meant "web" vs "non-web" as "browser" vs "non-browser", so I would think that's reversed, if anything. Browsers seem to support Negotiate already, at least somewhat. A REST approach would seem more in demand for all the clients out there that might be (unfortunately) one-offing HTTP. -- Scott From Nicolas.Williams@oracle.com Mon Aug 9 14:41:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BE13A6848 for ; Mon, 9 Aug 2010 14:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 BA08i4UiCXBW for ; Mon, 9 Aug 2010 14:41:58 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id AE1313A657C for ; Mon, 9 Aug 2010 14:41:58 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o79LgVVb001668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 21:42:32 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o79LgT6X007062; Mon, 9 Aug 2010 21:42:30 GMT Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 480583401281390085; Mon, 09 Aug 2010 14:41:25 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 14:41:25 -0700 Date: Mon, 9 Aug 2010 16:41:20 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20100809214120.GD5213@oracle.com> References: <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <01b201cb3809$20701ab0$61505010$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b201cb3809$20701ab0$61505010$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 21:41:59 -0000 On Mon, Aug 09, 2010 at 05:23:35PM -0400, Scott Cantor wrote: > > [*] Back to HTTP... For non-web apps I think HTTP/Negotiate will do. > > For web apps I think we need something more like a REST binding of > > the GSS-API, with channel binding to https via tls-server-end-point > > CB (though I can also see how to do it with tls-unique CB). > > I had the impression you meant "web" vs "non-web" as "browser" vs > "non-browser", so I would think that's reversed, if anything. Browsers seem > to support Negotiate already, at least somewhat. A REST approach would seem > more in demand for all the clients out there that might be (unfortunately) > one-offing HTTP. Do browsers support Negotiate with HTTPS and channel binding? If so, wow. If not, well, then I'd expect that the REST thing would work better, provided there's some JavaScript bindings for the GSS-API and/or a way to make authentication go from HTML. Nico -- From rafa@um.es Mon Aug 9 14:50:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825933A68CD for ; Mon, 9 Aug 2010 14:50:13 -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 yo0Q0MTXcvcH for ; Mon, 9 Aug 2010 14:50:12 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 88D1C3A6848 for ; Mon, 9 Aug 2010 14:50:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 4F0F44BC72; Mon, 9 Aug 2010 23:50:04 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XzUqW8cagL4o; Mon, 9 Aug 2010 23:50:03 +0200 (CEST) Received: from [192.168.1.65] (unknown [83.35.104.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id CC22C4BC52; Mon, 9 Aug 2010 23:49:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/mixed; boundary=Apple-Mail-93-288219876 From: Rafa Marin Lopez In-Reply-To: <20100809181025.GD5217@oracle.com> Date: Mon, 9 Aug 2010 23:50:14 +0200 Message-Id: <4ED04531-3291-49AE-A549-23417652CECE@um.es> References: <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 21:50:13 -0000 --Apple-Mail-93-288219876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Nico, related the two types of solutions you just mentioned, we sent a few = months ago a small set of very preliminary slides (you may find an = attached version in this e-mail) to the moonshot mailing list regarding = the next two alternatives: -- EAP-based Kerberos pre-authentication where KDC is acting as EAP = authenticator (and Kerberos protocol acting as EAP lower-layer). Then, = the KDC can interface with a backend AAA infrastructure. With the key = material obtained after EAP authentication (e.g. MSK) it would be = possible to generate a shared secret between Kerberos client and KDC.=20 -- a GSS-API based Kerberos pre-authentication where Kerberos uses = GSS-API to obtain pre-authentication data. In particular, the GSS TOKEN = could carry EAP as EAP-GSS approach specifies. (this could be the = generic variant of type 1?). So, if my understanding is correct, I think first option (EAP-based = Kerberos pre-authentication) is a Type 1 solution and second option = (GSS-API based Kerberos pre-authentication) is an example of type 2 use = in type 1 solution, right?.=20 Nevertheless, in terms of Kerberos, I believe that solutions which = bootstrap Kerberos credentials by means of some out-of-band mechanism = (so that they do not use Kerberos pre-authentication mechanism) may not = fit well in type 1 or type 2 solutions (as may happen with the Hannes' = I-D draft-tschofenig-pana-bootstrap-kerberos-00). Obviously, unless the = term "pre-authentication" in type 1 also includes an = "pre-authentication" mechanism different than Kerberos = pre-authentication. Do you refer to Kerberos pre-authentication in type = 1 or a more general "pre-authentication" mechanism?. Best regards. --Apple-Mail-93-288219876 Content-Disposition: inline; filename=eap_over_krb_saml_v01.pdf Content-Type: application/pdf; x-unix-mode=0644; name="eap_over_krb_saml_v01.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nH1Ty2rlMAzd5yu8LjQjKX4FgiHJvXcxu0JgFkN3fS3aQrvp71cPJ+nc 9g4BRbYlnaNjGVp0H82bA3cN7CYSG7zY93v358q9Nujke39sQA7cS8NB6j1LuJP/am33qXm40pLy cd60NBhTG1wHme1y536d0Pnsloe/AyBQ6QfowBfCAQJE/lJR1xcMA2ToYYTJojJMMMtBx6tyu/xu jktzcw6XkRsg79t4DncoyKWPcFIMhOKHjYBtYcGkSyRlxRQQ8CIWhb4lhym1ecWiqFjoIZQ4YCgE 3E25RqHMJqqbMNZNLxaT2lzPeqEy4lSz+gHnywxIGPi4d7syOBgC0o4D43ciP4ApPQuNu8VjJXmB Sopt73Jsu42INyKnDZRRWPKJPQKDFxeLlvWqFsm9bITJyIeSB+rsAHOdEMxkt0bBTiy4pswcN0Iu 4TwbO8s/cD53yWEqh5oqkp5o5WTklaKZQBcFQOx5xEPa57wqQH2hKDPNF0xMjYdcNRg3DSq5UFZN /mkJZeztDewsNUzK1KqjKZzrUhY0a42DSkFf8mWsO31X/2XBUzCv77BihL35G/cJ/jfnfAplbmRz dHJlYW0KZW5kb2JqCgozIDAgb2JqCjQzNwplbmRvYmoKCjUgMCBvYmoKPDwvTGVuZ3RoIDYgMCBS L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nDWMzQrCQAyE73mKORdak3S1CMuC25+Dt8KC B/GmrQcV7MXXd1ORgS+TZBKuBB96g1Fyto0at8643HAq8CKBaZmJbYEn5dDqHhaH1T9/0ztNxfrS lO9iIuVdpajFmK7YDALnkKaz154PHHkvzG2uTRDPXZDMPpSZQ6jZayuddRo1hks6Up9opBFfkQgn +AplbmRzdHJlYW0KZW5kb2JqCgo2IDAgb2JqCjE0MwplbmRvYmoKCjggMCBvYmoKPDwvTGVuZ3Ro IDkgMCBSL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nMV9y47lSJLdPr7irgVUiP52BwoB VNZDwOxG3YAWglYhzQiDSAHdm/l90e3hdoy8zGRkF2aqgEga7+FxPg6d5kZz4/YaHv/+8rfH9vhp 2xdbnH9Lnn///n8e/+O/PP7fS3jM///+ry/b/OHx9WUH0dLHhD/mv/qX1/7fl3/5Ly/ba9pGf2yv ZSt9/ttyCG3SpJxeyyNvcafi5TTyvlnKEZbDYXniFUPLwCNNCllvr8Oo29itRb6scLZou0kbzXog p2+mpdduzdSyW6uZZYWzRdutZth6IKdvpozXZs2UsFurmWWFJ9bcbjXD1gM5fTO5rGbyI6X2Wq2Z ZQX3W1jbrWbYeiAnNDM3DvvGq5k4YdwMWuFs0XbczLIeyOmbCW3feDWzjddszSwrnC3abjXD1gM5 fTPb/KvNxFFe02rGrHCyeLvVDFsP5HTNxD72jVczPWAzy5r/oqXbaTNiPZDTN9PKa7RmanvVGy6B Fc4WbbeaYeuBnNDM3DjsfctXtUrardXMssLZou24mWU9kNM3k5s1koY1kYZR4nJuhslNuhddj8Qp GXHMr0C9rHC2UoJdSEaf0oE+9NV7TWtb3Qpa4YnVV++1rAdy+ma2vHqv+AijvtrhmxXcb2Ftt5ph 64Gc0MzceFvdym71uLoVtMLZou24mWU9kNM30+rqVnar9tWtoBXOFm23mmHrgZy+mRpXt7JbJWMz ywpni7ZbzbD1QE7fTO6rW5nWtnovtKbi0dLtVjNsPZDTN5Py6lZ2K9bVrQSwwtmi7VYzbD2QE5qZ G2+rW9mtEFe3glY4W7QdN7OsB3L6ZrYKzYy+ehUwwtHgjVYbbD2Q0LUx4uq5wqPn1UC3KwKLhF77 EKXzSvYLMLe+eKv5K2CEo9H6ArW+mBvef4+atCt5FHNPghlukdCr4SS9SdL1izUP7Tke+54Iqy0G tzgMoIvC8PGyGNPyPfYHhnZEthhwMZUFWIvCIIwh5P0A2L3kZXYjQ0iwHA/L7EYyht1L45GDFzJx L8USF1LIlxXPlriXghSHEjl9M+JeiiUupGy8rHi2xL3UHUryWwYLmxH3Ui12IfeNYTm6X+LaajUi 7iQy+kbEudyt5T5SE2s54vLaQlDiYiKX0S+XkpbFaaTN1nL0y+Iu8g6wW2k8SCxOJC2Lm0gbreXo l8VBJIw4ksaDxOI2zmV1DOdGthzdsrqE3Di7jsYDxOoo8nIw4rUcdpmZFZcbyCh2F40JqcU5nFd8 LAdwXiy0wtkS51CQ4g4a42qCadk1FEvcP9l0WeFsiWuouxPktwQWNpObNZKGNSHL4bicm2Gy6n6g a6hkyYjF/ZPNlhXOVkqwC8noUzrQi2s4rb7cv7khWuFgjeUaKrKvHmt411CIxTVkS90/3tiscLLU NZRmxBlETteMuoZiifsnzSwrnC1xDXWHNu0owMJmxDUUS9w/2XhZ4WyJayhIcQaR0zcjrqFY4v7J xsuafShafbmGukNRuxCwsBlxDdXatPeZxMsKT6wu3UZcLKsZdA3nqrZcQ7HE/ZNmlhXOlriGghRn EDl9M+IaiiXun2y8rHC2xDXUHdpeozWDrqGsEteQLXEAedtlhKOhrqG0Ic4gEro2xDVko+tFqboY bG1Q9NqHKJ1Xsl8Wc2XXkBer+RNghKPR+gI1dQUquIZCllZnUtUN5I2WEY6GuIKyA2n5M9U5ibxG 3EQxAvAvI5yMgbDxansvvwB/Up9iGuIg8obLCEcjFYAldSuS/fKtyOV//28vf3vE120b6fHvj+3x T4/w+LeXGHfXdpu3/lxK7A785eWfd5Y4tjD2zfPYt580af+PaaZROtDUQPEzurnLJCKeuVQCBVq3 +cDDZUbYdtP7/Va7f/9XivLO//fFL399KX0O2vPeh5fHX//347/+Mcc8j7/+y//8Of7xln4O29tP 8ecY334KP29pLm/t7ad9/R9vP2X/a9l+Cf3tf/31n15+/+u+B08OL6VNDi6UTXZ9LvEBzb+2JNGw pEt8WH7f4xjTN3+y74l2bN+h9Lbv2S/bl7eQZf9jnnt+9yg+pYJEfcc+VuAxKFmJHxJ/ueaiS3Li yqTU3ul5Mgc//BTgk3DWX9tUf/sS6O8Zc83zViI0L38bX2ulAPvE1zoobPitfSl1dm488uJl4J9j t574WZw43p74mSpWdBY747QRLBLGqLRDAL7JzsOtac1l/iWu5cnxftEqkcowEuBfwSpul9nanlrk PhyaiWC5fQ/sPqQgy4vG0b+fmrat137roZAownS82Pp4qBWdFZ5QPW8mmT9CvV2P0sj0IxI9YSL5 sXPom8nqUwWrQfqtc18rW/XZCRub0M8+ZN4rcf83xFDq7M9az0k6AOKYw+bA93/U+38Lb/vtH+c9 Pu/6/W+eKwotVunGsKuCXmWe6fSclbcn7k6LY+8ipZlf5uIXWvyVjd98Z/itAwn9eZuT5K//9s2u aCeg85Yr9awxV1nezy0tF1jOvEx4XCYM8OjlXWRE/KrWHPPMjcZayrsoz81VeSIRlQK/ruUE+8jL 5bR8OA7gcfuYqcuN9ANbTJB3gRjt+6E53XLtI+/0dHpjnT4yWztUrOIs2hRpkB7YdE9n10w/TvpA FDxS2S2JuM3lOZyypuYv7JrrNuwRGZujjxzs24ffSaz9KSpWcNZGFm+Fy4QCNg36ASU3MMRK+5CJ fylreZK8XzRMpBL3A/hXsLrba7bqU4vik4dmOlhu3zeOWcoZnpYRRdfE+6l5Y1j7roczSXNpJL1I cLWCs7YnVM+biebnyiOaALOZKm9fIxGX+Vvq/GysAajkt0xBBt1O5IicN7va6Wvx/dCf9rX2h/pE 6m5/p97wj+uuNuVGwbwnpM+7WqOdTtv+d3fiZ28eyLUL+X6Pm7fLpn87dN7XHa+cx8ReWgnTwWBr OrFsNWdVsnQ7shZLc791ewwiMTfTxSohyy9hLTfyEJ43381DQPhXsLLbd7biU2tSHZvJYLl954dI 4TEXWUo0rwA28X5q3hjWvuvhECnFUtja4WI1Z9UnVM+bgTCIeK8EmM1QOkPie7OUSL9xv19Kd41G 6WCm8yfbSX+EnNLMPz/+9gj0OE5x7tnMupHMm3kTx/PqkOk0UtRl0p7Q6TF7F179EiSVYoYr0jPu /WFpzJus3AcyRHPAziFnXMxpxg331Y/Z1xyxjyx7PXnTHIGnOH2GunZtYefq6cst3nlnzNX98QTb d4phzPMZOFe3x1i7Buj26Ougd+ZMK/dBwfSnT+D6GHbUga71XL174mHtHsDLpKlGToO2OJ0QcnJP +PygeN/i3155d/bLmM9XhtanxR6HrJ1vls/XhtZnOwMh0iN6X78Pi+v5+tD6si7Rywzi0SV6hPbk Ck2OZtyFLtB8uITTcdLato5/Z850iTLFgM/XKFPQFuQdGb27buF8kWj99grnhdyiOLvNGM9XidYH O/4ZG6y0vjxiOl8lWh/h9gmDrtJUM520E346xIs90Kifjnjdtg49U1rgFgqVrhK5rO18lWh9tbMQ Ao154pTLPg4/XSda3+BWCpmv1CNtJ+xksBuJO0A6JSmc9UXrrRN60Vdq89yfrxKtD9AB0MuIuX72 fuerROsj3EvboKtEYbl8vkq0PsG9tJHXFzkN76wxzngzdnr6R8q1auerROsr9ARboauUaJR2vkq0 vr0Cf6bjoTM6zleJ1ne4nzbav0jvnU8K4zfWcD9RhGlf/6D8myP6QakBi3ke5+yMKBvvgKX10foA dvJI/TR0OsH7pFmHPzpdo3nT0WjwBG+TZt1Jg5zbSGHddr5EtN646VlDYS8a/5zAZZKsXmBkukDz WPI4XyBa3+0EDNbbPH1lO1+fSDFRu4sGpybO017iuQug9ZudgBFk9byaIMaxzbX7OpPQS+90ygNd icXcG+lh9mw5woXrNESJFGGL6yh7oXNFwfNoJ+ul0z1LnWhOcJid3Yd5e+aUTEKdHYV58+dUAM9O wTyqvMt2dV6N2fejzPYYfLTGR7SvXcyNH+jzHOVc7HgaP7w3EtwSSqN3/HEjXW128RsNN6n/zsW6 6Efj5+58os9LYq3y83X+nWOwxV/5STofIrnCA6l2WrsfZbWu6MHDRUqJzhUeAJWfgdu+1jrul0rP ujBv19xWl1vpHg7z9srNbrgHD+nDlFpu0M1VekaFQbeKdVAvhZ5F+/qpfuhYyrwqiZ5UuUc7okJP lzCdmtzhji70FAnzPORu9+ILu8v0MM4d7qOS+Kj2u8K4KcJKr47zAF+Pbqi5vlNsfnVbdF8migXm MeCW7nRM854oG7hH1EfM9fs4Z8vYX9Axza3KZk7JC/VYc/28p9EVpL41zDNUAjgC1HmmIGOntTbw Xu7r7LH7spJ/h8PSUI3cJc9c6AzMx7Dfk0ZrK+33UmPma9fkOI19SJvzOCOcXW4z0Vm0KxSkzZlk hVeU81ACXSPTS+Y25/WEK0eKJo9kXv0BKmq0vpNaTI3kYZJjmPu6p8sgXUyXM3e8jyjGSWc1d7zr grSaSet2l0ZpdT/SVuCeSdLqfqRt3et0Z861Yd537u6lVve7FHouumNTmEqa9/S6Lyr1xmFev1xt pPOY0TDyvGZ/gf1OpPWzP4J+t3HieKH+yPrFJG3O3gieoi1Lm/txlgBtMjrOntHOSmvS5uxfwcFs fBftLWZbx3dcpl4X9Nk3OoOZHufmeL90vqPnfZQTDBk63/303ijBndi5t8j0fIE7l+PyYWo5xwHP oyrtTs9lnfPepdX9SMlb1/VDWt2PNEZ8inKr+606wLmgcTWls+QALt1ItHbeoSf/h9fDmGFkWT1v XHMuDN4czaBws76aProF/E4dhD4ogh4Suy7jzL6vNx+CnqJh9ju5nlwxXg/jtDFo5ZQQ9FoLPB90 MATaNlk/xXVyIXk93HG7EykHGh7ZQgjAP8UIQ88t8pE+8jk8MdeCY80DBXJEN+jLBUvrcci8FVrb p0N8upzkn254nHzzU0cCd7/h5eXkwpPbxUGq0ymntRZLoCFHo/VzaAH9+cLTUMQGWNsg+VPnkF+P Piqvh75oZisEWj9zFO0uMvyM9uLQMMrRTufm5F9LiA0GNSHJ0c5WzuzTBYOjDfx4nVmJJ4eZ8hNx KMmPaE40NN9I0bR+4JHScIwTyM7DMV7f8UhpsEcxmVjP15XWNzxS7ggpFeQ8mOT1FY41sgsTOERw UiWth6dpiLw282v6E3t+ROjvAw//Ak/YOPcyPG8EVEkhhrk+PsgLPfHHR4TnRqA4ViL1hH7uZ+b6 uBm68rE+Qjt3M8QAxzmR80I730iwG4d94DiHrO/PAla8Hp5gEg4LG6WqnXsZWl/gOBN3+fOGD/Gs SVoP7DR4oLAf+GrAXh4BHgUzUy3Q+vwI21mTGwfzTJMchwzzsTHOkpyrwwaS5BBnmB3xkz2PD4yH cfA0TLOe+5lpNrj5OCg7s2nOfcz2wCgeTfBM1C3lU/9Cq2GoFmjqz1zdIQb8MHTHiHHg14HbvMuP J4NWQiQ6ZBqNb+zNHs8GrYbHiITKN+3/T9y4mueu7uczJ4qk5tE3Do7//V9fStmPhDrxmWIju8tZ JmAYSl8LfHezsTZbryDnLrRt7to+xhnV78JAprGYAicxCsbe9O6rCzkK+kJqP6Z9WGZ09IrZcSyj AGFBQn5VVvhNV99az0hYkLAgYZPXH0E0YJR1/29S7vKd1H3v5atwLjSwNmMNxknqNs79FNKbuJ0q P+Ek9OIMwEhnz1AZOTv5I0XeEvb9n+45M3DyC1Q1qmOF5MHYK3m4RS5VnxfdkTYkrUg6gBQPXjL6 ShwUI+wxlYiceOgoo6gykodsRE6+HwplB07OlovjfI3GGlFLUd51KQ7UlETiZb/y5TlrQdaMrM2x 9scpH5Pevu6k+x3dPGlHUtATXvuIekqio5J34RPnfnKRM6Ke4MqnV88Jekqio/26b3SZ9nszeE7Q U3p1rNWxYjKqXPQyr/5kpQ7NsTZkrcg6HCv0SUkue9klX5+zDmQFUeVXvEsTiirJFSp170aIdfZ8 wJpQVEy0jOxYUVRyPkvNdPmpq3KkBUkzkjZHipqS0zmPnzqpebc60o6koKkClNlpSo667NqnK0Vd K3Bm1BT0pcVpKjtN8TGXpsd+ogRJFZRUcZLKlnK4k8oOlvn4mKx7j5U9a0XWiqzdsaKkhK1MLRHr fAw41oGs3Virk1RxkhK2eeDUT9GDAFgLSqqipKqTVHGS2u9MeiTLv/3QTRWUVEVJVSep4iQ1dgEQ Kf97Ju1ICpJCyoqSyvR854Ft1yQWRC4+ZHNyqug+ZHps7nzCO09q8ZzgQTTUU3stjrUi63xwTtbp PEzW+Qh0rBVZC7J2xwp6yvSU21llnzs9BR3rQFbQU3d6aqinTE+kycr7fGJtqKeOeupOTw31lOnx MVnZw6PUe0dakDQjaXOkoKcsrmuVXe70yHasHVlBAtjvdyco8UUrPUP3gdt2cE86igp6/eFE1bGP yuzoVDkHg3xTRwl91EBNDaep7jQlfmmlh+hT1oqsBVm7Y0VNiWta5dSOw6Oko6QGSCpuTlLDSUp8 0yrndpDfC6wDJCVEy8iOFSUl3mkVz3yQx+JYC7JmZG2OFTUl3mnlazbIZXGkHUlNUhEOPzrXPIt3 WuWKHTkjuuYRDt655vRODjjZO630ZJqc/vFMaOMETcWAmqI3hotVB2BVVDDItXKsFVkLsnbHOpCV rk8VFQydboNgIAVNRdRUdO65jnMq3/qD/GkgRe9ceJaRHSlISgc6VaT1hLUga0bW5lg7srKDWulZ srNqkiSigRU0hdcfD16c0ypiHeSkAyMcO1z5hKMdepNvjOKYVtHqIJcSGVFPCUY7MnXccKgncUyr zLQa5FM61oqsBVm7Y0U9iWda5R54wjqQFQTlXPPoXHN1yZvcA4Mcf2BF1zyiax6dax6day4ueZNw xKBGHGlB0oykzZHCiEf95yYd32zDcTbkbMgJz70ITyh1dJtEJAY5/cCZkdGeerE4SWUnKXFMm9yp Z06UVEFJFScp55qrQ9rkVh10LhxrRdaCrN2xoqTEI20SkxjtcE7RNY/omkfnmkfnmqsT2aQDGHSW gRVd84iueXSueSzoTai716QTGHSeHWtG1oys1bE2ZGV3r0lg4glrQ9aKrKgquFZVHNQmncugIQpw VmQEVTWnKuegq6/XJC4xSA/IiapqqCrnoEdw0Gea8Tfq+31jpuq3Ji6eJnlmyZ+gp72lNdMEMrG4 T8ZcK7M4JZ7Cjup2Qxj4A15RDmP0FiNxR3T66O1ZsbFQfsC2ZgfMakM6OyCkOQdhzmx4S+nn+Ouc NxryW2gyw3TfnTinzsKqkMIXBqb0tiPyndkFpXLFNtZkoQBHlGlzalW+28XiWc66HVmLRZDACRn6 BZqhChRkFXqFOTeNsNwlQ//cPJTfQfhXsIbbd7byU6tLhj42E8Fy+87FeErgrFjJ0pFfimvi/dS8 McDsAj4c6g0bv30sfOuKVZ3VnlA9b6ZYf8wTPRgwm6F6GSNwT0a5IrtY5zJNtbIm6ZdOj0rdqouT Bow3p/WwfxdH/Oy0njX/pnx7NmVqtPfPGvjGbMpQA0/Q5r+d7iFqKQDol31T/o1ZaNYl/fl1Tcq8 PyGoU6r1aUfvTcHUU7+92vQ7tnRS1yy4gxY7e7odz4lTK7jfYJiBxDqRjS2evMZVfWzZJuEdm99w Ep7Bvy4r4r4+dFqdXw7n43Nsh71Oa+LgXF6Es6dd5O+HRnVLN+luZ6ep7vPBN5fn1EVejrCcPAES Aw/Mnpw/TdpOm/MzKzbuDZk4rT2j9a1TVyRbNJ4SpUxI3NizmlNCeZmnis7qR7bMty3jcZkwwAMT X414ukNszemukfJqdWnIxFffXDYFGPCrLFfbK1pqbqk8OYKy9hT2rq2Jw3NZaCgJgwnfXSOMcofH JTUGnV66HLJcYbm5jY+Ea8LbnN08f9gJ00ZXmN9kxjRnTHAoJ5KzKpvTep7tJVu0wFc4KsaIq1Rl ojQ4tnjG/LQGWk0m2xIJLDMK2KA2QHcNKCBQTvfcMMHykPoAp4aZVOsDGPyrWm3DvXx8yAQot3yg 5H1GNr/XLUjZhEzLi/C1Avn7oVHdEmoZEPt8THZZ/HjwIm0ii8FvjaxAoo9frgszK1nTjOp5Q5Dn vFHyEFcWo9mz3Aavr+x88BaUAP5hTDefuYUSguhm8U9EfqB9mY8yetBy5YJi9Qvmn/ArPfDIvq5h QG7vszZuPnXvVy6o9Uk7+ND82z4sgD2b8cpIs1kOO+ae6a79Ls66vgrY9I3q9C/mgPIZX/htMjkH APejbE/34+fw+52n/azHwmkBXBQjSuRVrDCcpZF+v0gYo3KVQIx9BvXY4rIh+7IuEcP78zaZEmuY MOArWMntMFvbUyuvWiDWTAQL95zy7LmGCS8rzXwzgQ28nxq37V0VkyhhXq5UEiVELJZsrBZtfKB6 2gwGmqnLDUMa4bJ6WaqT0GhI3sbxMViTXNOPfG/dTgJxxnizT+DnNUVy/sFKJt+8WwJF9p+1I3f+ H3ED777G8ImeoMwB55n7fg2TMMp6xhWx9IKFUZ3V1oPTL9f1ENXtQUnQgCyzIOdmCZbHEuex2eIf oQr4uqyG+7huFL9cz8fl2A773FdHMJcX4WsF8vdDo7qlu5FmyJceoVTdm5+bSTaRxe63RlYgWY9Q +oUeoLPwd9AH6MwvlbyzvFqg9WEkfYDO9VEeoAK5davwAIImTH7iVuFnXdufdbs2uBBYjPktfWPo uEPLG4w+L54koXFJ9Cc7RCPlKE9VetCGADWCbt9aXMnz3MTNsemc/81JJ3IJKwf21UrO0tdIfpEw RrUkGhfD12VFkaZSIPP7qVVj8DfWIlUruV1ObuN0ojo2s4F1aCa5ZuYtxoeZHna+ktvz5CjT4Tar GZ5XbOkTSjdWK7qjIuvl2IxxwvNK9ztKqdEOz6tQN3heWZP8G0dYZbva1vNKcfcqb3FF+3rSvN5d 33tkff4+vFeShY4kcKEfOXVaBles4Kxox++WCQVsvk+2BmRZxEDpkrbcTTSHZqGOEMK/gjXcPg8T +MnqJprVzAaW2/MojyutvD8WEf2FJt5PzRuDF3yQl9v0DAk8phUjoBGf8DxvA2Jes88JHJvip4Zm dNHzhCbC6XNGc2fpF0nZ5m22pt62gm7JnGu8Bkqp+5zO7XnDiN3hvKVfrko6xOOlihBDHF4ypCS3 GP1VS/IeDa3iHY1A+o6G/HOYSEakeTo06XMtUsG0c6tMp0GVhf1qRsDdZaM+MY5HhWxudzu/TdoN XhSGCQbm92Oba9O1s7L79P0Gmq8xuKdkQzYUo59YHD+yaZyT5jzQz5N/SrLza92U5qO78+LApub6 wU8B3mJwZB+47mqV5sWOmVnxxC8Ks1RWo/62SxnUXZQo4biclBjf4iaBBhqQs44hZvCNbh3knriW Vix3hD+/5SAxrkhztyQGJsYAQ6JmcwtYlFjU4gEFJWOeEXMyIr1DpdjZWhyioUN7GDgD7FcxKPKj e0aL3S96Mg3zVfsFdrSJ0PeOu4VFRUIX1nfflmzkj5ZrOs+xXuVSzXORo2u8GPy2J8ZqXTyXkJ5x Mp4WJ3GyQOUmGmeXBMpq5QZovcTJeAuJky2mu4Km6ejt7GM8FTTW4uTCc7/GQVL8hXTc7Jd/TPv2 Igx7+vtC51ewSR5plevzyENJrQ0tnVBU9cNlY73WVSRyytlF4tmMLtdQZH1eyxsp/2njTPkilAb/ qpZ8+8L2la10tpj45dhMAQv3fOOE0Rq48FCn/U3yS3dNvJ+aN4a179oqkRaeW86BN7F0Y7H6E6qn zeB0Ii6WzIDZDM1T3fitTS00u3jjTI9K7rY1ajOPP3Q7SWtAzrtj5I2nRs63Gc/CrHwHkd6/gMDB ++a7Jv66jyVoxe/Qzd9yZHiv+YX2V6psntbrbbWis6SWuWzH1czViu63ACcciGczNPV3sLiD/NLX chSxPGs+oFgM/hWs4va9iLSfWSwW30wAy+07p8dVjieSpUT0KSho4v3UvDGsfdfDobqOlV5oDQnN iBWdlZ5QPW8G0khnhg7/PBuhGoIc5amNPlvDy3ji6Bfx7WSL3iXXRzH33p8MSvMYT15u3BQ3lmy+ OarMj5Dp43LU7czlj4cuF1jmmsrZLZW1tOqKG82k5J+4kMYOf4Xl+UL8STNApMCva1k+x6d7JFZ8 YhV/FMCmLq38yNmWPB9MpusuwujI308NG8Ph4HkmTCK1sLXDxcrO4sRQT/W8GZiKMwvxDwHMZvJr k/qWkzjRb/IJ0TFco/ybfAhWtpMZC8B5t3IudfSByondl6v0u+GP+Fv83bJu2me7Yf4KQZB8PJ4g GyQpTq2BlmT1y3ZsLZaBv+GUkvl0UsBXsJrMHmYibOL92DwwLJ0EJBXL73t3G/cnVMejDGC5Zrpr hgsE0YtqqU6xyXrc9+5IO+67wTWFgS1NXNCN1XJX4bDv/pjbK/j7ce05JykEya2f6QtB5kRwWsNq kKJWnPpAW/B0UeC6rWyudHryz39U11fd8me+odK6fmMk6idG9PMps0+2Jf5R4J/OEC1U7+DJp0f2 PZ/5oH1+WQS/NRJ/ews/8/dIkrzB/7GvjOyPP0nN/wrLegDffXgWqmSWn4yqaDgT/3ijlx2pHa5X 2n5wf3OK8jbgKyzf3d9UqfxDbufe8zv7G65e2Mwbbr77T39WDsLMcIpPCb+ThBCpzN95Q5+FoPOV /L8UK6QHFcciZlypsvEhtafJ4C9005Q2XZz9Fy9SBtQLG1Qih7ajqp5EN5feH9wOz8vjsG2nbjHS NvNfInqnkrBBvt3ETUqEedDi2tv3Y0mDOze2O1rHa23xwa09+sCdXLutB/P+Ygf5gYcOp2OdpXc7 ex/+nNqZtivwjnv76b4l9OkCFsg9t/eJYSYIzY8W0d9tV/vW3wIFI4bENPh7RtwDcd+z/SHxutDl 1+3Lm374iLeX5Yo3+aXwIk08Szw5fuaVBTY+KAdMDPqChKZ4JX6hQEmMmRMm5iJ/Y3y8yveNmCry SIcbke8ecb5GtKQT3pQXJ+H7CxuJQyBixJUwwrtk+/1DEvTHDbzQmu3FO+7fh9tvOBo7yvcXOP4P d17WudLz925n9QPONJx9uyrvuN+fnwpB8WqqOCtq7CpGEtb+lAv3RNMC3SQ8I6AMNeZokMptUTE+ LogabZHPJBsiHTHmCeFN6SQxpYqnBTU+JM3y6ky+PD2TtInoeO33j4kGj9vxfuv+cHtqe7+O6v0F jvfDnQc8O+usveP5/PDn2c6+XZV33O9PiyZvhbW7RNP4eZhnH9bmh9fC1M1PZfpFe6cWv9zSEH0Y hca6hT4wnPXYaXEeVH3krAuJXHU2khTCYGMO6XgzqkXOZLT4zm2kpDMKBy/Pr41l+bfQUzFLLURK kMiZsfte6D6+v/yAWOwAF52Q6+HoDnzALq2dXLv+/gLH9OGOFc/AOjPveM4+8EzqudXz/b728fNd yZgT1NTXWR2Jm1F1RwWlUgAic9is8sd1OFBVuxr8qTp6vyaLEkCr0idTmKtKn1xkU7qDmFJ6Em5s 3WZRDf6QB20qi5lvS/7Ah+L5ax8EirrTsP8/1KO443e80Nrai3fcvw+/33A06yjfX+D4P/x5gbO1 zuI7nt8Pf97haqyr9I77/2kNVXqTT72b61niFx5M7n1LlXlC9zyZXeMU2qJ684XCTKPxIsc5StUF 8gL5G4+cpicGFbukjShfnKlo8Z0ayDLjY5bmp4TyGHkjWqjy2jHOBjj9pFQCl/aQ/fuhvmQd2+IS 5siHslr/wD1a+5j1EOB4PvxxwtGvs/JuZ+sDz+A6p3Ke33X/Pt+N0MxG2gXXkewSGNyP7BLIUwG7 A5yizLps/FMs5D0LYElkTo7levjb7E3LfBNPNdW/U0KwUU3ojXN3uED+ph4oGACT2Mp3N+S7SWDw 0gDWrA31w4pkcA++YDD/+2kFQgAuviTpY2JU43PT/mPRKIDwaRlCAANnNU7+apLAXPWsq8qGgF2U 8s09NTpSVqR8XtsQsEDZjZInpAvMzXmPUpDkgpJnvDuWZQykvFMuEcDACUqpqBT4euM3yiUCeHFW FFFDEbl6TDIz3SilWiJgF2VDHTXUkSubdFmBEcDACTrqqCNX4ShKGZJj/UXALsqOOuqoI6j6eV3S EbBACToaqCNXM+iypCOAF+dAIQ0Ukq+7Kb3nNWdHThOShEwYdqiReVUmEsDKKTRiBBASvuT/RpFI AC/OAEqScpkCc6VtknQbi1NrRAIYOE1JUtpSYL5G5EXZScAuyghKknTSBcNijnKPn8pOAhg4TUpS LlJgvujiVSlLAC9OzQgWYyAnlrK7KmUJYOAEKWWUki9lqD28FrI8cGaUUkYpFZQSXvSr0pgLuvgK yqigjHxdwKuymAAGTpBRRRm5Gn5JJHkqigngxVlRRxV1VJ2OrgptAhg4QUcNuiQp8Lc4WT/HMpuA XZQNeqTQUEaugt1V5U7AAiWoqKOKXLG5q7qdgF2UHUU0UETYG8mltqqdjhC6ooEaGqghV7jtsgwo gIHTNBQ30JCvsXZVBhSwSiksy+hIiRKSE3gqAgpg4DQJxQASkveMynlVWBTAizOAhiJ6y768WJJj PpUVBTBwmogiOtLRV+pdpUqlqOiBE33suHzsRF/kMhVFPPKrMqULSnxGsYwGfK5IqzBZidIDo3qv RiMG+tjRV6i9KHsK2EW5fGw2OlKijC6KngIWKLtRoo8dC6qIip89oOApgBbXcq7ZGMiF9Q6fFVAF IPAN40PHOjrHOkuJ01MBVQAvzorKQcc6wgm0kqxaPNUzwvlrqJyGyvHFSK/KsQIYOEE56FVHXzdU KidqLdYDZUfldFQOetXRedVW3/VQiRXAwAnSQbc6uvL4l9VdAbw4B0gobciIApJCqcfKroBVQuLQ RVBQch71KhUrh39gTBsoKG2goIQedcJrIyVSjVHqxC7o4gugIPqIhvE5BV1VngUwcJqCEnrTyXnT q/KscK7KswBenBEklNCdTs6dzlp781jNFsDAaRJKCSSUkpPQRTVbwC7KhApyhKigVcn2ihEkhHwo IedJZwlCWG1cdKtSRgVlVBA60gmv90VZ3IVcdAUFVFBAzo+2krhCqCVxAQycIKAK45zka2HLrX2s sgvYRVl1mMNGR0rUz1WNXQADJ+gH3ejk3Ogs8YcrzoYCaiigjow3avYCdhHCLqIPnXzB5quKvQA2 RhQQOtFpICOHHozRedFpGN9ABQ1VEH+PDus/X1UABjBwmoLy8qI7GaAgq/+rnFL/F8DKmTfogvJy oxmGxUol8HCqKQxg4LTrk5cb3cnA0qIXFYUBuygDKChHJITLo6HFa0a7QBkOe3nQnQysqHpRnxiw RggKysuB7vSVWCO8qk28oIsPHeicQEHZOdAarVuMmhkLYOAEBWVUkHOgL2sdA3hxogedMyrIedCX 1Y4BDJygoIIKci60hsGuONGVzuhK54qMKKGrCsoAXowV+FBCzpXWeNUVI7rSGV3p3FBDeCav6jEv 6OJDVzo31FBzGrqqxQxg4AQNdX2O0feNMV6nsSXjlErMAF6cHR5kuaOGnC99Wd0ZwMAJGhqoIedL X9V2BuyiRFe6bEiIEpKIwzWjSahswAcSKs6XvqgUDVDjAwGVAAIqeHtLrMHqRDtCu7cLOtIlgH5K cPq5KjwNYOA0/ZQI+inR6eeq8DSAF2cE/ZQI+inOkdawxansNICB0/RTEuinOEf6spQ1gBcnetLF MaKArspYA3gxIt+r9Wolo59av8GWwUcVCjEKygfZrgpiL+jiQz+6FNRPQf3oEN6KYR8YUT/oR5eK +qmon8sC2wBenOhIl4r6cY70ZXltAAMn6KehfpwjLSPuU3VtwC5K9KNLR0KQz2W9bgAvRtjFjvJx jvRltW4AGyNKaKCEcB9lJNvkUXZkhD1ER7qgI12cI63DTmOcNxEwooTQka4bSKhuJqF/pJ74tzI9 Tilxc+iRN1FjpsUPSdaQQjeNvsDtDAKtTeeknL9I+v38X7MU58/5PIcjhLcx63f/FNrPiWrPNJ/C bxw0Hsz0OV/PwTVrZn52knTsMrOuXcbJ7BEzfQGZykjcSTiZRU05meIrTZDvQvDx8JbhdKbQdzeU vFPCZbvOtsI2ZKhZAzbEV9HPEk4Mh3wD+DiGwDjnz14mnBjWOJlFLangJzjMZ7hIODGoUTKJWW1R Vp8X8zzhxKBI2YCSK/kzruGI4yrhxKBGySRmdaDEtJirhBPDIicqpYNSnFN7mXBiWOPsTkQdRNSd iC4STgyKlKijAToa2GFfJpwY1jgH6kg+R6o41NFFwolBF6WQmLV0JLkT30k4MShSgo7kG5+MC05H VwknhjXOgEKSWlKKQyFdJZwYFjlBSPLhTMY57/Yy4cSwxhlRSPSVTkW5r4depJsY1hgT8pmKgvNs L5NNDAuMTkXZVBSST4p5nmxiUKPMTkUZVOSc28tkE8MiJ8qogIyKe4N4lWxiWOMsTkYFZOSc3Mtk E8MiJ8qogoyck3uZbGJY46xORtX6o1CdkK7STQyLnNAhyccCGeeTLq4STgxrnM1JqYOUnJ97mXBi WOPsTksdtNSdlq4STgyLnKilAVoaTksXCScGNcrhpDRASs7ZvUo4MShSgpKkEjPh4uaUdJFwYtBF qbWgxQpA6L48+zzhxKBGGJDONBQDPtQuE04MC4yoIflynOJQQxcJJwY1yogS0knohItOQlcJJ4ZF TpCQfMmMcclJ6CrhxLDGmVBDEbxl//mxy4QTwyIniggc6ZidiK4STgxrnM7HjgUYUUVXCSeGNUa8 5OBj+w9vXSacGBYYnYzAx8YPZF2lmyjQ6Jx/HcG/js6/vko2MShSooK402Wc869PySaGMS7e2qwO XPg68VmyieGQD1UDTnV0TvVlsolhjdM51XEAI75KvEo2MawxDuR7rYvRedSXySaGBUaeSc5WAo86 bcj4PNVEgYsuOW86gTednDd9mWhiWOQE2aRgsknOnb5MNDGscQaUj044FRzK5yLVxKBICVcngTed 3HcvL5NNDGuczptOCRhdPsxFsolhjREPO5mCUnIKuko2MSwwOgWBN50c40WqiSKNz7nSCVzp5GaS XCaaGBY5UUIFJORc6atEE4MaZXEKKqCg4vNhLlJNDIucKCHwpJP/ZPhFsolBjdI50qkBISroItnE oEaIJ7KBgJoT0FWyiWGB0Qmom2ORcBcvUk0UaHQdfYoE7nNy7vNloolhkRMPe4B+nPt8mWhiWOMc TkADBDScgC5STQyKlKCfDP5zPnzK+SLZxLCLMzsHOgdgxKtzlWxiWGMMyKcKoomMzoe+TDdBNLCi ivLyogmJr+quEk4Ma5zOjc7LjWYciuky5QTRyAtyyknlREjnTF+lnSDYaBMqKidVlCDx3eJV8gmi kRdltTxqQvoP8F6koCDYaJ1TnYsjdR+zvkhDQbSxFuR06nKu9WUqCqKB1amrah9FSJfgcpGMYljj rNhR5erUVfFRd5mOgmjkRXU1py7naF+mpCDaeJ3LnZuTl3O6LxNTEI28KK/+ikroTl5X6SmINt6O A6I8HKtLo7lIUUG0seK+Dqcv54RfpqkgGlhRX2VDfZUNWS8SVQy7OIXFrIacTl9XqSqIRl7QVwmo rxJcWsRFugqCjda55CWgvIpzyi+TVhCNvHDJSkR5Ff9F+uepK4g11ojiKslxorgu0lcQbKR4AhJq qzj3/DKFBdHA6rSVnbYc60USi2GNMzttZR1+M86n21yksSAaeWEYXorTlpv1fZnKgmjjdd56KU5c zl+/TGhBNPKiuKoTl/+K+Lc4ncsuLGo19GSKm/59mdyCaONty5sZZKG+3GyVyxQXRDOvManVnb7g OX6Z5GJY4zQnni3UV3e5FFdpLohG3g68w+nLzQa/SnVBsNGaL8/WcLR4Eq4SXhCNvMN464byqs6l v0x7QfTiFSa1Akqsuonhl8kviDbegBKrzrmvbjrLZQoMopEXJFYjSqz+hyfBxH2PZ74GH3iV5Q/O IKlr9GpL8rtt9zwFJtAXyae/kZ8WG4z02Xr60PcfVNG0HGqmZM624dpts+TYHGfb4XeNE+lgTRMC ElU7mRvyN4ILZepoNB4tRMpZv7Mxe/qKdGH4ruEwHZNqNgWijVcHH2oNx9uRVyJ3OnzWXBJEI+8A Xg6lK9KNG7pGGTXFQIWLaOPV0D5bHFM35EBeiYhKhoXeZwg2Wo3uq1WB1oXnu4x2NRdEuxsEI20F Ws5dUaQbOXQNMWveij4hEG28mkqjVne8DXklGK4pNvqkRDTyosq6U5kL23cN28sraHUWEGy03Yms O5G52H3XtwuaC3XY2+401p3GhtOYGzt0CHQVdW4RaZwD9SW5LIYEfTXxlzQiV9THR/TiXak1aoHA fF5ME/9OO/SiYzJEIy8oTJJaFOmi+U28UX0AFR2bItp4AypMElsMWZGXfWd9YJZVnB3QyAsKC/Jt KEG6JJkmjr4+4Is+QBBtvJIEvqzheDvy8qBE/ZyikSVEIy9oTBJdFOnGEE0GUeqVFY0BItp4k9NZ Rp35pBk9DXLDFY2AIthos5NZdjJziTNNhqiWJAec2UksO4kVJzEX7W/61l9fYWpoHtHGW5zEipOY S55Rn0aHKKvAHaKRFyVWncRcAo36djqkyvpWBtHGW53EqpOYi/6rL6rDyqwvzhCNvCix5iTmXgKo S65j4KyvDRFtvM1JrDuJuWQaHUDoeD3rG1NEG293GutOY+6NgA6jNL6Q5VU2gpEWZTaczNxLAR31 aZQl60t8RBvvcDIbTmYusUZHvhoTyprAgGjkBZnJF7cF6bNrdPyvEaysiSaIXrz6BfBlDceLMlu5 b3x7ZAnnIxhpQWWSIqNINzNTo0AadMyaYIRo4w2oMsmTMSSq7JCjmDUNDNHGG1FlMaLKfM5NPWRT Zk2DQzTygswkX0aR7lVBXZmfLLes6YqINt6EMovOu/dFT+rKUpUPAkR/W2jVE8ekVnYyc46/Oub6 ziBrpiqijTc7manjH485OMstF7FlzSY2LHKixtTpj49D8RN9RaAvebKNmxRrnM7hjxUYcVQtvodI LNuYR6FGiJdfHf14zMJR/17fmQGb8/Cj8/CjevjxmIKj/rcOh5ONchRrnM67l/QbxaGQ5N2gvtBM NsRRLHI24Owio3hMxxF/Xt+7Jg3+GNQou1NQBwU5n159eX0/nGxoo1jkRAUNGYDEx6EGijrz8hI7 2ahGoUY5cPBBSTiKQgHpdBQZfyWN1Rp2MXINFF02BfmMHM0l0NyChLuYnBOfnBOfgonIJ+TokEBT IJINZRRrnM6BlyQcxbmpUzwckEyNpG9VDIqUoKEUTUPJee46EtAUlWQjGMUap/PbUzQR+ZQciR5q Hk2yQYZCkRI0JHk4jHMZ7joA0GyfpK9BDWucyYkIGVFE4vprklOyIYtijdHxgYj83E3x+jUVK8X1 jFcsMDoVFVCR89I1yK0pY8kGKoo1TuejSyKO4lBFj5XTlmyAojCkQwVVUJBzzHUAoal8aXkgCjVK 55WnCgJyPrmOHTTfMNnYRLHIiQpqoCCX2L7GDXJGk41LFGuczSmoAyO+3ZJB+tzDqHlshjO2jlyg Hud/6/hDc1SjjUMUC4xOPfrZsolzb994hKB5tNFGIIw0voH+m2TgCMq/KuWxgeb6Rs0pNSxygnzy ZvLJzuGW16SakGz+lSIXY3bOdt5MPT4dR4camosdbcihWOQE9UgKDuN8BRQZZmjOeNS8bsMaZ0D1 5AiMeHVkgCGJ7dHGGQo1woh0JqBDFo6MLDSdPxa8EbNzrLNzrCXrhnFPMg50xkHUORaKNL6EAtKP JDLKCUiGKTotItqwQrHIiQLKICDnSusQRWdvRJ0BZFjjdI50Bkf6mHXDg2GduRJtOKFY5EQJFZCQ L4EiQxOdYRO91J0jLSxqVWBECcmgROcBRezRsnOkM15ucKSzc6R1NKKTlaIbP2TnTGfnTEtqDeOe 5FrpNK3oRg8ZwtlaAWVZJiFfAYUdVJ1LFu3NhkKREhUEfvShAIoMbWTKG9A5Hzo7HzqDD52dD60D G52VF9zwITsfOjsfOoMP7Wuf6NBGZyMGe5WhWON0TnTZgPFJhSydMxnc6CE7J7psyGfqKT6tXYY2 +jYxuLFDcV50cV60VC9h3JOMUp1+GuzNBSONL6B6CnjQvv6Jjmt03m1wQ4fiXOjiXOgCLrSvfyLj GvH6gvPzi3Ogi3OgCzjQvvqJJhDrJOZgrysUi5ygoAIetK9+ooMlnb8d3OChOA+6OA+6ICMqSJh0 knmwlxSKNUbHBwpyHrSOlaT7CW7gUJwDXZwDXQoIyBFyPyadRnCjhoJ0xekHfOfifGfNu9eKCMFe SCgWOVE/4ED7+ic6Tooytglu3FCcB12cBy2VSxTnpm4wV5RRaHDjBi1/4limVR9auoRxvpCgcEUZ MQV7E6FY5jQWtTowooKEKcroJqDHUsyJVoq1DALyhQTlJozcAwc3btDqJ45ELfChsfyJjruijD83 e+vASOMzH5otU5CvI8i7FmW0tLmBQzEX2kjEquBCV1dGUKc8RRnabG7oULc1SDQWszpwPqkCTHz2 ikFxyAdXpoIDXcGB/g9LTmn08bEtoXQ0AWXtIkSRvSXpKcgyD+CcrBKruhfPUlXW34tKLXsXLMPr zxdq4RcbnLLRZ48YfamWyzSXsuWV95HpA5B5mz0lLhtGrtt3N3q1zXyiyFUCimGB8RU5ObtDcTeS RAxqlExiVluUhwSRi0wOwyJnA06O+zLOZ4dcZFsY1CiZxKwOlNBnPE2JMBzydeDjrpFxzuG9TFsw rHEyi1kDOPEF11VqgWGRcwDnABU5r/fy9b9hjXOgiiSFQ3E3XtEbdFEKiVlVKQ9ZIFev0g2LnFU4 y8rcYBy+Nb162a1I5jMGs7rxufelV6+jDYucHTijyeiQ9XHxytigRhmXispK1FAcqujqta5hkXMA ZzIV+eooV69eDWqUaYmorAQNxd15PWpY48xLRWUlaDDOh4+vXmEaFjlRRQVUhIxXLxkVaXzFqaiA inzo+OploGGRE1XEjivjfPm/Z2/vDGd8zGDWAD4s/Xf1ps2wyIkSaiAhX/rv6rWYYY2zOQ11YLzz DsuwxojnsYN+fO2/qxdOhgVGp58B+nH1CS/eDSnS+IbTzwD9+Np/V69xDIuccNySaUE4n7Fx+drF sItTWMwawIkaepxfkRgM6UA+kl3BOB89vnqfYVjjDCifGIHxe+8eDGdsEblMOv7zM5dvCgwLjCgd yaRg3LlW7zGqrzhjSygcqXsiKBf1u4q/GxY5G3BmEI6vnX0VMDescWYnnAzC8bWzrwLchkVOVE+x x2w8BI4vgtGGNc6Cz9lYgfHJpNJj4NigRogXu4KAfOnsqzCvYYHRCQj8aPwKzbOYrIKMqjn1NFXP nBlx+ATNVfwU0ciLCuqqIEL6z9BcxTwRbbzdqWj50oJ88iGIU5wS0ciLShqqJEL6OPJVZBHRxjtQ TZRKYThXQeEiEojoxUo8a1klNXGHD9NcBO8QDKSoKknFUKT76stFsM2wxhnQc5OMioVz8roKjSEa eUFeklWhSP+Nmot4FoKNNqK6JCXDkC648zwGhWCkheewJFcoEj78+B9WhbfO4cmMQ/AuVohJcH2W 5bTjMmPWthd1eKl+BjP52EzaZkhm+yWkt7D/s315C/lnjtPEPOcjbW3OTroXAOKXQDx4P4SAvjDn Nkv+7hTxbf7VVS4SVKj2zA9EgmroK6hT6PPoEv2BZcPI1f3uRq+22b1IkGGB8RU5OYijuBuRIIMa pYSTltUW5b1IkGGRswEnP4QYdysSZFCjlMfgsjpQfi8SZDjk68DHAwXG3YsEGdY4JZ60rAGcdyJB hkXOAZwDVHQvEmRY4xyoIgniKO5GJMigi1LDScuqSnkzEmRY5KzAGUxFtyJBijS+gBKSGI6gbkWC DIucICMJ4jDuViTIoEYZUUUSw1HcnUiQYZETVCRBHMbdigQZ1CiTE1E2Ed2MBBnWOLNTUQYV3YsE GRY5UUUFVHQnEqRI4ytORQVUdC8SZFjkRBVxHIdx348EGc74JJa0rAF8dyJBhkVOlFADCd2LBBnW OJvTUAfGO5EgwxojnscO+rkXCTIsMDr9DNDPnUiQIo1vOP0M0M+9SJBhkROOW2I4hLsZCTLs4tR4 0rIGcH4nEmQwpAP5SAyHcfciQYY1zoDyiREYvxcJMpyxReQy6dyMBBkWGFE6Eslh3PcjQYoztoTC kRiOoG5FggyLnOCoSQyHcfciQYY1zuyEk0E49yJBhkVOVE+xx+zNSJBhjbPgczZWYLwRCTKoEeLF riCge5EgwwKjExD40d+LBCnIqJz/LPGbSrMf70aCEI28qKCuCvpEJAjRxtudipYv/YlIEKKRF5U0 VEmfiAQh2ngHqokiOIa7EwlC9GLliJIuq6TuR4IQDKSoKonhKPJOJMiwxhnQc5P4zcLdigQhGnlB XhLAUeStSBCCjTaiuiSAY8gbkSAEIy08hyUSpMj/hEhQ4U9BbXpCNRIkyxL9ob4Clxmztn0eCSqF coCeRILiH2/p50DhoBgpzsPhmU/Ef0qN/3j8p6ay4j97j3CM/qxanPphGe2HR6NBModyJokGx9wy oDQC9P0NX3FTHwWS2l/6hR/cEw4BHUjEkhCQIDEQsqr/SqkqTV82rHEKy7IacrookCtLrXUikJXu 3gOTWPL8EuTTSFCXhOa2OltAG68wLas7Xrh9ta5J1/pXGmkBMNJ2oJWYkCB9VEi/siC9eVtdI6CN V5iWNRwvjun1Yx2shrb6RgAj7QDa4cTlKsZojKRr4e4VIwG08Q5UmIaHFhLH9voZIa3SpHmQiF68 yrSsaryHKJHeBSuMKROUEI28VXghTiRIP+VUP8+msUx/1aRozIFoWd3R4lBNRLvq/eicfUQjbwde eaQJMj4b7jcJltU1NgC08QrTsobjdXOYWV1aQ+fQ80no6EAkVkKV+eCRzhHWm2PVvkK08aalMorS ONZn34DEb3w40gGkGSmdwJ7ORF3hyEM3JiGkA5NYxQkMZwdp0UkNSeoMAsMaZ3HqKtjl+kDSqhGq Ycnl3AEaeRvwVqcuPy1Vy7pqAZJDHyYhpQPTsobjdeM6PvpVKESHigBGWlRXwy7Xx5V0aKcFPfLy xABtvO0VpdAdKwYHtNS1RtQOPZhElxyPLjt5+eLxWptchjwWmgU0sDp5DexvMca0ysfLQCcfzyzu 6Vh9LVsoL59ur7X4xR/Kx85rOHkNlJdGmhjpY036sQQNMa6AKoAXrRItazjaJ/M2Vs0ELY6BaOQF eclHmBTp4k7rkyMabjt0XhJ5OjCJFR0rXjJ9waUBtzXmBbSxRuREefkYlM6AljICWosBscCJ4pKa MIrEz5odXvakQ98V8egTiksjUYpDcSWoy5UO/ZZEog4sYmUnLBeLSocXPmvGP6KNNztlZXyK+3jU +liczjNfI0hAIy90BhqREqSLSa2P+mk87tBxSVTqwCRWdaz4qU2tEyRneM00R7SxogYqPsJ9cGp9 GVNjcit2CGhgxUe4lIhRJJzZ9alRifjFQ8cV8bw2p63mtOXiVOuxJYE5ndWMYKRFeXV8hPswlUY7 NPC3An4ANtqOT3GpFGNIPAda+E+CdMduqztxdSeu4cTlglRR383KKC+sNziANt7hxDVcN+vCVEHD 8Bqsa4dOZjh5DexmpXKMIH2gKqx3qiy04GklUHUgEiugvjBQFVzptBlT05cvC2ucAfUl1WMWDvUV pJ/RiF3QQAuikRfuMSkho0gXqAoiWJ0pGQ79l0SqDkzL6o4XFBa0ppXOvDz0XxKqOjCJlbC//c8I Ve3Ox2x601OqoSpZTu7B5S3Gre2fh6t2nS1v5hhRehsSkAr17afycxgSqvpFEpf+sLiSOSBBE0N0 UEZz4Xm+3NcXckN08hwbnW9c/ua5MwQGBPMYpJu/OLvPv77+p+7AX+h4v3ER3cfVt0emiOFhvt9v b12jfX/QSeVT+8dbqBq2OwXvvnGSJSqZ9EUlfcHssSKaFXJZcJkxa9sfOr1/XtOfOrEzztqltsSt c/uJCGlqXeKjaT4Z7kZIeXTFG359Sa1poPiBy4iSzuTGhq+4acH++FmEFIFA+IqUOtORkXcipIY1 TqnNvayGnC4B7SpCimjkbcCr6doNopzfi5Ai2nildt+yuuO9ESFFMNJ2oNWZj03CkS4f7SJCimjj leLcyxqO1+WkPY+QIhhpB9AOJ657EVJEG+9Aha1ZkI2jkcB6FR817OLU6tzLqsjp8tOuoqOIRt4q vGMFNRV5KzqKYKY1IrO6o8UEkavoKKKRtwOvZmwz0n2P5zI6imjjleokyxqO90Z0FMFIO4A2ocJ8 Re3L6CiijTcthQ0JayoOOS9iowY1wox0Tlz3IqOIBlYnruLE5er0XcZGEW28xamrYHcb/Ad5rqKj iEbeBrzVqetedBTRxluduqpTl6/cdxEdRTDSoroadre+mPZldBTRxtteUQ7dsd6JjiLaWPHG7U5i 96KjiAZWJ7Hh+trnn9c8xkcRbbxj9bdjxTUNeSdCimjkBYmt+ZSEvBchRfCi1ZLcy+qO9tn3fo8R UkQjL1w2iWsq8l6EFNHGG1BiMTrWOxFSRBtrRE7sbA9frn8eIUUscGJXK7FNRd6JkBrWOBOKa823 FNx3I6SIRE4UVsa+9vDt+qsIKaKNN2NfK3FNQ96JkCIaeVFZxSnrXoQU0cZbnLIK9rW+jvZljBTR yAudrcQ2FXkvSopo461OX83p606U1LDG2Zy+Gna2vqz2VZQUwUgLfa0ENxV5K0qKYKPtTmHdKexW lBTBSIsCG66nvRclRbTxDtfVDiewe1FSRCMvCEyCm4K8FyVF8KIVIrVAXbdipIY1xoB8qK2bEVJE AyuKS+KairwXIUW08UZUl8REDXknQopo5IX+ViKkivxPiJCm0ajoFp9SC5xY8h6/Az9YjFrbPo+O pj4uoqMcWeIvyt0MhEbKsc0VPoFX4RN4A+qJ4bJgcOsfitP9uc1/KlYXKUErt343VidrfqWz+2UG n7dB3+7b8EyvAJV05k3vhxDm++28zad555Js84h4MXFAIaTulwliW/7QOf6zGv7U2Q3b9IHnoOgk 0t/3sxu+zDPHf7e6n0FKOb1IMB1zFs4MRJ7eBnynxNwcGVOx5/1/uQJVgsI9cUYwn4iwwsB08Lic 9ETUH49G/1kNf+oKjDn4fxaKDr+9/TT4TQp9hrKyslXsMcw54dcXI1Of+uRizO32SzCv6C+RQ9hl vq358pYlw9i/N7i8U1LeoO5hovmwWr9QrMRPkYhLioCtf+hq/bnNf+7FDN2CPKntWS3G021zcZES OYczYH3kufnC4XDnyEGlxC6SnAT90hBZdZ0IW1IEbP2PXJE/qfnPXREaJz37kGv4bb975v0TPncD Jcr5mV96eH6Ntz47Q/rDvdoX7tWe30Qyj0inFa03AnEffacqH85OM07L1uxc2OIomFqcvsdb4TKh gE38KKTkBpJYIW3yS1vLk+T9ouFib1AR/hWs7PaarRnKPVtzX4/NbGC5feco29w4i2VEwzXxfmre GNa+6+FQGZdO28owusO+itGe8DxvAyYe5OmU8+97E3OAkpoW/drPdqryziRDe/KLFKaibahqyAey Cf+88zad6qSfCNNh+K7cRlxtdlEk3LhuhV/eSJckVtZtmp3//JvXT7+Keo+P+k17mek20MdKnrUh dIFvjrk43pT+d35NHSLdL3zX5N2Lw0a+eWRhzKjFudnpCv713+5xtBmjTCUd95v2ONIeJjsjfDRV 5tpcnQ0KKj3h/N65mD0FfVz6x89Ib6eG8Wxc9zx5vnpKmeOsgQaSbLGmp9WdpQER2owM5ej4C4R5 kZXvYAXMZf4lruXJ8n7RNpHqHWzwr2AVt+NF+pRnVpWbGJuJYLl954y33ZLlRePo309N29bQ8/Ch UAX4MCN5bO19uFjdWe0J1fNmhkUQ6BGQ5cM9IRERFUXfR+dJv/ARZszHmtt/0c8O8BZlPUwyvGX4 58f/B1manhUKZW5kc3RyZWFtCmVuZG9iagoKOSAwIG9iagoxODA5OQplbmRvYmoKCjExIDAgb2Jq Cjw8L0xlbmd0aCAxMiAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicpVZLiyM3EL77 V/R5wR1VlV4NjaDtmTnktmDIYdlb9kFIAtlL/n7qIanb7bF3hmBoy7Lq9dVXn9qNMPx7+Gdww9Hx MqE8g5fnjy/Dbx+Gvw8wyOfHt4OTP4a/DnxIV3/K8UG+29N2vx++flCX8mG70+WA5MY0+BDGPFx+ H355gcH74fL10wxQIM2OSpxxcanADC+OnHeLwwJhdqFMMxI4yOXz5dfD8+XwcefcE2frAUc03zRM 48TOZwfl8sdrFknq8y5yTjUbRM0GJ+cLxBkcYjnC7JI7FZzdpD9IlgkinjjrI/G6EB8FlP1TAZBs ebmUI86cL4oJL9GrIX+Jl7P8sOVS9BwvMcpBdeie1NOzRnhRS3N7VpuTPqfunO35OJJu55Ilh76h sOFM0SVKDKSZaCrNnlOhmrIg7lqZFkitwBUvud3BX9Gk7Ea/Q5NyIWi9LWkG4siCHbSaavGGRsIg 7Ze/0VU4HrWcAr2r4eTTGPcNb+lQ0m642B8V9VwRrwlT27+bGzo/0jaYb8Ec00pxF5LVPrmopOfM 77nL6dpdz52pSNasLA7RkG7pXoOPrcSjUrVTetuGXiJ/HPtUq2AuAa65bBAZ0dkoG2tQH7gZFkxK Q+Tu4/K4p9YjhDbGa498dRglFkzzdhyizZ6lT5YUtnGaOGz/c7KBqHY25rRp6yYMTSsoWlIl6GZg GXxpIk4iT8EotPAXneRxlseT/G8EfwudcaKmjm8kNOZ8M3Nthpo88QAfaW7cPnZym2jRqjoKixJq 02VtPGOWNhTbk6KJRbyWSVGivN3JzMhJIpzlbNPXLj4NVrHba5wds/StXaJlFjOxUjLCJ3rWAnSy nuTmoJefqxbGG7KlqpsnoexWRDlyh09TqWP1anw5Kdq96z/N3mk/pnV8SPdRvTdtrDq+Idu+Xa0b Rx04qhqN0pgtY+WodMuDmtJ691iQdtHBaSWISsZV5YkXoYSfoknhVqRaL1dm9AsOBCMrr2bfr5+a o+AxbbdgIy71pl4l+fqCbOe4hPTwfrQGPRxNl8f33TXoUI5dU+u5kO8gnE12aktvXzNu9bsL1NX7 Q39Niia/VlK0EGmuV8SrCia04fi5Dehqj03OjLkey2P56+zWcrz85cPWsguJJBJ3RexfPR6SDFIc w71b/OFLBeccXnm929Ozvt/dy2GSHAI04WU+KBvwDhsYTp4J8D3pwNyobwOtcIkMDQ5dBtuOVtTm YK4TKjnLTlT8hPVO7pz2Q8E0FVJZ4jmDFnAx4m8OLiIEUDDWc81v1nEjuRa026wBD1Hhuzu/CxWI bUg6KhD/ByIQIXUUrESQS8dAgElqWFY83lLnx+E/jTvNOAplbmRzdHJlYW0KZW5kb2JqCgoxMiAw IG9iagoxMDE0CmVuZG9iagoKMTQgMCBvYmoKPDwvTGVuZ3RoIDE1IDAgUi9GaWx0ZXIvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJw1jDELwkAMhff8ijcXeibp2SKUA8+2g1vhwEHctHVQwS7+fS8VefDl JXkJO8GH3mCUnG2jxq03LjecCrxIYFpmYlvgSTm0uofFYfXP3/ROU7G+NOW7mEir2jWopHaKdMVm EHiPNJ1b7XnPkXfcBGm5C5LZhzJzCBW3epDOOo0awyUdqU800ogvqVcmugplbmRzdHJlYW0KZW5k b2JqCgoxNSAwIG9iagoxNDIKZW5kb2JqCgoxNyAwIG9iago8PC9MZW5ndGggMTggMCBSL0ZpbHRl ci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nMV9S4/lOJPdPn/FXQ/QafFNAo0EuvphYHbjacALw6u0 Z4xBloH5NvP3LcaDcUK6qlLW1/B0A1kM3aNDSjoig8GHttfw+I+Xf39sj5+2Pdni/Fvy/Pu3//34 7//w+L8v4TH//9u/vmzzh8fXlx1EqY8Jf8x/9S8f/T8v//IPL9tr2kZ/bK9lK33+23IIbdKknF7L I29xp+J0Gnk/LeUI6XBIT7xiKA08kqWQ9fY6jLqN3Vrkywpni86btNGsB3L6bFp67ZZNLbu1sllW OFt03sqGrQdy+mzKeG2WTQm7tbJZVnhizfNWNmw9kNNnk8vKJj9Saq/VsllWcL+Fdd7Khq0HckI2 8+Swn7yyiRPG2aAVzhadx9ks64GcPpvQ9pNXNtt4zZbNssLZovNWNmw9kNNns82/mk0c5TWtbMwK J4vPW9mw9UBOl03sYz95ZdMDZrOs+S9aep5mI9YDOX02rbxGy6a2V33hEljhbNF5Kxu2HsgJ2cyT w163fFWrpN1a2SwrnC06j7NZ1gM5fTa5WSZpWBZpGCWmczNMblK96HEkTsmIY34F6mWFs5USFCEZ fUoH+tBX7TWtbVUraIUnVl+117IeyOmz2fKqveIjjPpql29WcL+Fdd7Khq0HckI28+RtVSu71eOq VtAKZ4vO42yW9UBOn02rq1rZrdpXtYJWOFt03sqGrQdy+mxqXNXKbpWM2SwrnC06b2XD1gM5fTa5 r2plWtuqvdCaikdLz1vZsPVATp9Nyqta2a1YV7USwApni85b2bD1QE7IZp68rWplt0Jc1Qpa4WzR eZzNsh7I6bPZKmQz+qpVwAhHg09aebD1QEKXx4ir5gqPnlcG3Z4IJAm9yhCl8kr2CzC3vnir+Stg hKPR+gK1vpgbvn+PmrQqeRRzT4IZLknolXGS2iTp8cWah9Ycj70kwmrJ4JLDAJoUho+XxZiW77E3 GFoRWTJgMpUFWElhEMYQ8n4B7F5ymt3IEBKk4yHNbiRj2L00Hrl4IRP3UixxIYV8WfFsiXspSHEo kdNnI+6lWOJCysnLimdL3EstUJLfMliYjbiXarELuZ8M6eh+ieuslYm4k8joMxHncreW+0hZrHTE 9DpDUOJiIpfRL5eS0uI00mkrHX1a3EUuALuVxoPE4kRSWtxEOmmlo0+Lg0gYcSSNB4nFbZxpdQzn SZaOLq0uIWfOrqPxALE6ipwORrzSYZeZWXG5gYxid9GYkFqcw/nEx3IA58NCK5wtcQ4FKe6gMa4s mJZdQ7HE/ZNTlxXOlriGWpwgvyWwMJvcLJM0LAtJh2M6N8Nk1f1A11DJkhGL+yenLSucrZSgCMno UzrQi2s4rb7cv3kiWuFgjeUaKrKvGmt411CIxTVkS90/PtmscLLUNZRsxBlETpeNuoZiifsn2Swr nC1xDbVAm1YUYGE24hqKJe6fnLyscLbENRSkOIPI6bMR11Ascf/k5GXNOhStvlxDLVDUKgQszEZc Q7U2rX0m8bLCE6tLtREXy8oGXcN5qC3XUCxx/ySbZYWzJa6hIMUZRE6fjbiGYon7JycvK5wtcQ21 QNtrtGzQNZRD4hqyJQ4gn7uMcDTUNZQ8xBlEQpeHuIZsdH0oVZPBjgZFrzJEqbyS/bKYK7uGnKzm T4ARjkbrC9TUFajgGgpZWpVJVTeQT1pGOBriCkoB0vJnqnMS+Yi4iWIE4F9GOBkDYePVSi+/AH9S n2Ia4iDyicsIRyMVgCV1K5L98q3I5X/7ry///oiv2zbS4z8e2+MfH+Hxby8x7q7tNl/9mUrsDvzz yz/tLHFsYeyn57GfP2nS/h/TTKN0oKmB4mf0cpdJRDwzVQIFWrfZ4GGaEXbe9H6/le/f/pWivPP/ Pfnlz5fSZ6c973V4efz5vx7/5Y/Z53n8+S//4+f4x1v6OWxvP8WfY3z7Kfy8pZne2ttP+/E/3n7K /tey/RL62//88x9ffv9zL8GTy0tpk4sLZZOizxRf0PxrKYmGJU3xZfmyxzGmb/6k7IkKthcove0l +2X78haylD/mWfK7V/EpFSSqO/a+AvdByUrcSPzzNRc9khNXJqX2Tu3J7PxwK8A34ay/tqn+9hTo 7xlzzfNVIjSnv42vtVKAfeJrHRQ2/FZZSp2VG/e8OA389HrkSiKIuUr648HpAunMacJjmjDAI6+r kRHxq1rTPZsnjZXKj/cn2VV5eYhKgV9XOkEZOV1O6cN1AI8rYyZ1RPqBLSbI+50y2vdDdnrmKiMX erbPsc7mnK0dKlZxFp2KNEgPbFrSqSL6cdIHomCnarckODDT0/OzrOYv7EXoOVx5G5ujjxyX2HsK Saz9hRcrOGsji8/CNKGATeMTQMkZDLHS7t3xL2WlJ8n7RcZEKiEKgH8Fq7tSs1WfWhRKOWTTwXJl 3zi8Ind4WkYUXRbvp+yNYZVdL2eS5tJIepHgagVnbU+onmcTrUmW2oQAM5sqA0WRiMv8LXWqDnMN QCW/ZeoP6XkiR+SUbGbLMmvQuP8bYih1tnKt5yTNwi5Ckl7lRiFqo7CFt4h/xt6+bXmmfp+NwfbH 3ihg8wUtTaKO+FPSQucSYafkgXa2Lvvf3duYrUygNihk305+62rmzbnI+reZ02/fbax2HrmLiZuT EmaUlq3Z2rLVnFXJ0vPIWizN/date4LEnE0Xq4Qsv4SVnjTvF9kT6YuQGvwrWNmVna341JpUx2wy WK7s3IQUdg7JUqK6Xw1m8X7K3hhW2fVyiJQ6fWztcLGas+oTqufZQH9NmlkCzGxo3DXxm1lKpN+4 1i+lu0yjVC+zkyvnSW2EnJLNPz3+fe8nZhqXnSWb0wNkisBUaTwfDpluI3UPJ+0JnR6zbuHDL0HG fGe/Kj3j3ptKY97k4O5xEc0BO33juJjTDHDshx+zpjliH1lKPXnT7CqkOD2Guoq2sPPw7CQs3vlm zMP98QTbd4phzPQix3n6WEUD9N45XBe9M2c6WPe3fc/iBK6PYVcd6FnPw+VBXcsTvEyaauTkXcbp glDE6YTPDwpMLP7tlYuzP8Z8fjJ0PC32OOToHAI7Pxs6nu0OhEgN9H5899/r+fnQ8bIe0cuMNtAj eoT25AlNjmbchR7QbFrC6TrpaFvXvzNnekSZglXnZ5QpugTyjozeHbdwfkh0fHuF+0JOUZzVZozn p0THg13/DGJUOl4eMZ2fEh2P8PqEQU9pqplu2gk/3eHFHqh7Qle8XluHnmPv8AqFSk+JHNZ2fkp0 vNpdCKHQU5py2TsMp+dExxu8SiHzk3rsfb4jdjLYi8QVIN2SFM76ouNWCb1o7H/e+/NTouMBKgCK ms7js/Y7PyU6HuFd2gY9JYof5PNTouMJ3qWNfL7I84XOGuOpOcbe6CnRpJB2fkp0vEJNsBV6SrNT T77WCZ8e1Oot/kzXQ3d0nJ8SHe/wPm1UvkgDZCeF8dAavE/UFd6PP2iiwBH9oDHMxTyvc1ZGNG3o gKXj0eqAMeghTfVTx+kE75NmXf7o9IzmS0d9wRO8TZr1Jg1ybSPFn9r5EdFx46a2hvrn1Ps5gcsk WbXAyPSA5rWQT3eC50mzbsBgvc3bV7bz84kUvLG3aPAcqnnbSzxXAXR8sxswghyeTxPEOLZ5dD9m EnrpnW55oCexmHsjPcyaLUd4cJ06KJFCAXFdZS90ryjKF+1mvXR6Z6kSzQkus7P7MF/PnJJJqLOj MF/+nArg2SmYV5V32a7KqzH7fpXZmsFHa3xF+9HF3LhBn/co52LX07jx3khwSyiNBiPjRrra7OE3 6mxS/Z2LVdGPxu3ubNHZr9fj3L7Ov7MHtvgrt6SzEckVGqTa6eh+ldWqogd3FmnuZq7QAFRuA7f9 qFXcL5XaujBf19xWlVvpHQ7z9crNXrgHd+jDlFpuUM1VaqPCoFfFKqiXQm3RfnyqHyqWMp9KopYq 92hXVKh1CdOpyR3e6EKtSJj3IXd7F1/YXabGOHd4j0riq9rfCuOmwWQa48oDfD16oebxTkHEVW3R ezmP79c6BrzSna5pvhNlA/eI6oh5fO/nbBnrC7qmeVbZzCl5oRprHp/vNLqCVLeGeYdKAEeAKs8U pO+0jgYu5X7Mmt2XNUtxOCx11chd8syF7sBshn1JGh2tVO6lxszPrsl1GvuQPOd1Rri7nGeiu2hP KEieczYIPlEeMA/0jEwvmfOczxOeHCmaPJL59AeoqNHxTmoxNZKHSY5h7uudLoN0MV3O3PE92uh+ U9iz41sXJNdMWre3NEqu+5W2Au9Mklz3K23rXac3cx4N871zby/lur+lUHPRG5vCVNJ8p9d7Uak2 DvP55Wo9nceMhZHnNesLrHciHZ/1EdS7jWe4FqqPrF5MkuesjaAVbVny3K+zBMiT0XHWjHZXWpM8 Z/0KDmbjt2jPMdsxfuMy1bqgz77RHczUnJvj/dL5jZ7vUU7QZej89lOAO8Gb2Lm2yNS+wJvbuXaZ Ws5xQHtUJd/puax73rvkul8peet6fEiu+5XGiK0o57q/qgOcC+pX07h7DuDSjURH5xt68n/4OPQZ RpbD88U158LgzdEMCjbrGNrRLeDBPxD6oPh5SOy6jDP7ftx8CGpFw6x3cj25Ynwc+mlj0MEpIai1 Fng2dNAF2jY5PsV1ciH5OLxxuxMpFxoe2UIIwD/FCF3PLfKVPvI5PDGPgmPNHQVyRDeoywVLx7HL vBU62qdDfHqc5J9ueJ388lNFAm+/4WUUZeHJ7eIg1emW01GLJVCXo9Hx2bWA+nzhqStiHaxtkPyp csivRx+Vj0NdNIdVAx2fk6nsLTL8DGBi1zDK1U7n5uRfS4gNOjUhydXOXM7s0wWDqw3cvM7pUyeH mSZSYVeSm2ieEWW+kaLp+MArpe4Yz3Q5d8f4eMcrpc4exWRiPT9XOt7wSrkipDHrc2eSj1e41sgu TOAQwUmVdBxa0xD5aObxxBN7fkSo7wN3/wLPLD/XMjzBHVRJIYZ5PD7ICz3xx0eEdiNQHCuRekI/ 1zPzeNwMXflaH6GdqxligOucyPmgnW8k2I3DPnCdQ473ZwErPg4tmITDwkZzas61DB0vcJ2Jq/z5 wod41iQdB3bqPFDYD3w1YC+PAE3BnFIT6Hh+hO2syY2DeaZJjkOG2WyMsyTn4bCBJDnEGWZF/KTk 8YHxMA6ehmnWcz0zzQYvHwdl57D/uY7ZHhjFo5VoiaqlfKpf6DB01QKtUZiHO8SAH4buGDEOPBi4 zbf8eDPoIESiQ6be+Mbe7PFu0GFoRiRUvmn9f+LGw7zIbr+fOVEkNY++cXD8b//6Usp+JVSJz7kA UlwaR0PDUDos8N3TxjptDUDOIrRtFm3v44zqizCQaSymwLOtBGPjvPvhQo6CDkjt17R3y4yOBpgd xzIKEBYk5KGywiNdfWs9I2FBwoKETYY/gmjAKOv+36Tc5Tup+17LV+FcaGBtxhqMk9RtnPstpJG4 nSo/4ST04gzASHfPUBk5O/kjRUYJ+/5P95wZOHn4VI3qWGGWU+yVPNwij6rPh+5IG5JWJB1Aihcv U49KHBQj7DGViJx46SijqDKSRjYiJ78PhaYxTc6Wi+N8jcYaUUtRxroUB2pKIvGyP/nynLUga0bW 5lj74zRxjEZfd9L9jW6etCMp6AmffUQ9JdFRybvwiXO/ucgZUU/w5NOr5wQ9JdHR/tw3ekz7uxk8 J+gpvTrW6lhx1pw89DKf/mSlCs2xNmStyDocK9RJSR572SVfn7MOZAVR5Vd8SxOKKskTKnWvRoh1 1nzAmlBUTLSM7FhRVHI/S830+KmqcqQFSTOSNkeKmpLbOa+fKqn5tjrSjqSgqQKU2WlKrrrs2qcn RVUrcGbUFNSlxWkqO03xNZem136iBEkVlFRxksqvFUilgGU2H5N1r7GyZ63IWpG1O1aUlLCVqSVi nc2AYx3I2o21OkkVJylhmxdO9RQ1BMBaUFIVJVWdpIqT1P5mUpMs//ZDNVVQUhUlVZ2kipPU2AVA pPzvmbQjKUgKKStKKlP7zh3brpNYELn4kM3JqaL7kKnZ3PmEd97U4jnBg2iop/ZaHGtF1tlwTtbp PEzW2QQ61oqsBVm7YwU9ZWrldlYpc6dW0LEOZAU9daenhnrK1CJNVi7zibWhnjrqqTs9NdRTpuZj srKHR3OEHWlB0oykzZGCnrK4rlWK3KnJdqwdWUECWO93JyjxRSu1oXvHbTu4Jx1FBbX+cKLqWEdl dnSq3INBvqmjhDpqoKaG01R3mhK/tFIj+pS1ImtB1u5YUVPimla5tePQlHSU1ABJxc1JajhJiW9a 5d4O8nuBdYCkhGgZ2bGipMQ7reKZD/JYHGtB1oyszbGipsQ7rfzMBrksjrQjqUkqwuVH55pn8U6r PLEjZ0TXPMLFO9ecxuSAk73TSi3T5PTNM6GNEzQVA2qKRgwXq3bAqqhgkGvlWCuyFmTtjnUgKz2f KioYui4AwUAKmoqoqejcc+3nVH71B/nTQIreufAsIztSkJR2dKpI6wlrQdaMrM2xdmRlB7VSW7Kz 6iRJRAMraAqfP168OKdVxDrISQdGuHZ48gl7OzSSb4zimFbR6iCXEhlRTwl6O7LG1XCoJ3FMqywJ GeRTOtaKrAVZu2NFPYlnWuUdeMI6kBUE5Vzz6FxzdcmbvAODHH9gRdc8omsenWsenWsuLnmTcMSg TBxpQdKMpM2RQo9H/ecmFd/Mw3E25GzICe1ehBZKHd0mEYlBTj9wZmS0Vi8WJ6nsJCWOaZM39cyJ kiooqeIk5VxzdUibvKqD7oVjrchakLU7VpSUeKRNYhKjHe4puuYRXfPoXPPoXHN1IptUAIPuMrCi ax7RNY/ONY8FvQl195pUAoPus2PNyJqRtTrWhqzs7jUJTDxhbchakRVVBc+qioPapHIZ1EUBzoqM oKrmVOUcdPX1msQlBukBOVFVDVXlHPQIDvqcZvyNjci+saTuWyusTqvRssyfoNbepjXTyluxuE7G uVZm8ZR4Cjuq2w1h4A8YohzG6C1GYkF0ndvt5Xux0PwAmqWhS+Cirg4Iaa5BmCsb3lL6Of46F7iF /BaaLIXbixPnGj84FFL4wsCU3nZEvrO6oFTeWoo1WSjAwRbPVp9W5bddLF6OqeeRtVgECZwwQ79A NrRUnqxCQ5jz1AjpLjP0z9nDPiEI/wrWcGVnKz+1uszQx2wiWK7svGtICTwrVmbpyC/FZfF+yt4Y YHUBXw7Vho1HHwu/umJVZ7UnVM+zKVYf80IPBsxsaGH/CFyT0VyRXawzTQutLEv6pVNTqWd1cdKA 8e6insj7qUUV+t1lPWv9TZHVq1dLfBqV/lkGz5f4ROKtgVeS8t9O7xDlFAD0y34q/8Ysv8yf6M+v jNiN+wuCOk21PhV0vvF//tu9lUCxb6+2+I4tXdI1dwZBi509PY9XxKkV3G/QzUBiXcbGFi9d4+1H LG1L8I7Zb7gEz+BflxWxrA9dVOfT4Xx9ju1Q6rSWDc70Ipw17SJ/P2SqZ7oldzs7rcmdDd9Mz4WL nI6QTp4AiYEH1k7OnyZtp9O5zYqNa0MmTqtkdLx1qorkjMZLopQJiRt7VnNBKKd5oejcpsXS/Noy HtOEAR5Y9mrE0x1iay52jTSvVlNDlr367LIpwIBfJV2tVJRqLlWeXEFZJYXStbVseKaFhiZhMOG7 y4RR7vJ47f+g20uPQ9IV0s2dfCRcC97m2ub5w06YNnrCPJIZ01wxwaGcSM6qnE7HebWXnNECP+Go GCOusn0MTYNj6+Oh1kCryVJbIoE0o4BNd2QASs5AAYHmdM8TE6Tn036aMZPKPl4A/6pW27CUlI7H 9IGSy4xsvtSNvMDEm1cGI5xD+ov8/ZCpnrnKKnnNZrJL8uPBSTpFksGfjaxAos0vb2Axt9yl9dTz hSDPeaPJQ7wFEq2d5Tz4eGXng8+gCeAfxnSzzS36Uvv2kJuzL7Mho2Y2UQvGjWTWo+FXau7IbntL F3nzCG7t4mpFY3yLm4CJ97qBDnQVzwp0v4HG1bLfu/oYuDo45neznZ1bNvCA/HyiRSx+1rsVhrM0 xu6ThDEqUGwB9hlOYyvQAqc9rSlieH+eJ1Oqcg3+FazkCszW9tTKIl3MJoKFJacZ7nRfJK00c0wA M3g/ZW7nwzvHF0N7FdBU4SjBWbHkZLXo5APV02wwxEuVXRiSCe+8xbGcyP0QGQfja7Asedsv8nr1 PAmBGePNt5HWGUWKoTxzgPmdSvYW8ktRxev9xBt4a0X5LH4YZVX1RSy9e2FUZ7XVfvh0XW2Jng+P FTKQNKtjnpYgPZZSjtkW35Io4OuyGpZxqdan6/m6HNuhzH29lTO9CKUlYfL3Q6Z6plP1jHxSS0K7 8XLzkeQUSXZ/NrICyWpJ6BdqR+ZGvUHbkTnNUqZf5ZUDHQ8jaTsyj0dpRwRyS7fsR9O6wU/olutx 0m1k5e7/5rf0jR7UDi1v0AmDmj5gO9J4C+MnBaIOY5QWg96OELYvZPz6mS4a77x3zuJ20xEqz72Q R1g5vq1WcpaOpvgkYYxqSTQuhq/LiiJNpUDm91OuxuBfrEWqVnJFTu7kdKI6ZrOBdcgmuWzmK8aX mR52v5IreXKU6fCa1QyNB1vaXOjJakV3VWS9HLMxTmg8tNxRtgbs0HiEukHjYVnybxxolPNqW42H 4m69hJ13oK4nzevbdaP9+OR7+Il2JPBuN3LrdNtKsYKzol2/SxMK2HydbBlIWsRAswYt3U00h2xh Mx2EfwVruDIPE/jJ6iaalc0Glit5lOZKd8oei4j+Qhbvp+yNwQs+yBgvtSGBu3ZiBDTiE57neUDo Z9Y5gUM03GroxCZqT2g9mLYzOoWUfpGZy3zO1tT1VdAtmfOejIFmln1O59beMGL3/m7pl3cRHOJ+ 0sYIQ7xPMmQLXTH6q26heTR0191oBFJ3NOSfgwRkRFquQmsfV5J2DTvnynQaW1jYr2YELC4b9Ylx vCpkc8XtPKiyG5wUhgkG5vdjnuvUVVgpPu23TssWBteUbMiJYvQTi+NHNg330dR/+nnyT0l2Ht1M aTbdnZMDs5rHB7cCfMbgADdw3dUqLQ8dc4LBE78ozB2jGtW3XbYt/FQn2veHv1Gtg9wTbykVyx3h z73XJdQTaQmThILEGGBI8GieAUkJySweUFAy5hk4JiPSUCKFkFZyiIYO+WH8CLBfxaAAiJaMkt0n PZlGu6r9AgVtIvS94m5hUZHQhfXd5yUn+avlPVhnrKby1qozyUEmTgZ/7omxWhXPW77OcBGvDpNw UaBdFxpPsgg0uZMzoOMSLuIzJFy0mO4KmlZlt7OP8VTQEKOR/dd+jYOk+AvpuNkvf5/2bTwIa/r7 QueRyCRNWuVtaqRRUmtDS9fVVP3Q0Fijm4pETrm7SDyz0XQNRY7nld5I+U8zZ8oXoTT4V7Vkr3or K1vpbDHxyzGbAhaWfON5kzXw/judypvkl+6yeD9lbwyr7JorkRZeYs1RMLH0ZLH6E6qn2eCqGt7c lAEzG1quufHgRS20yHbjCQ+V3G3L1Bbgfuh5MrqPnHf7yBuvEJxB/cO7E1dsk0YU4xcQOHjf/NbE X/e+BB34Har5W44Ml5rHdb/STsRpjfKqFZ0lew/Lebz7sFrR/RbghgPxzIZWwA4Wd5Bf+kpHEcuz 7AOKxeBfwSqu7EWk/cxisfhsAliu7DxLrHJwjywlok+3QBbvp+yNYZVdL4e2N6w0rjMkNCNWdFZ6 QvU8G5hNOSeq8M8zE9pKj6M8tdFnJjiNN45+Ed9Ozuhdprwo5t4wwqDZDuNJ4P6muKFrebdXmR8h 08egqNqZ6Y+HpgukeWPh7FJlpeoazl00k5J/4v0kdvgrpOe48JNsgEiBX1daPp+lJRIrPrGKvwpg U5dWfuRJh7wsSlatLsLoyN9PGRvD4eJ5QUgitbC1w8XKzuL5kZ7qeTawImVunD0EMLPJr022eZzE iX6TT/6N4TLl3+TDjXKeTNwHzptyjVTRB9pV675cpd4Nf8Tf4u82+aR9thrmXcODTEvjdaJB5oap NdCSye1yHluLZeBvuLJitk4K+ApWk0W0TIRZvB+zB4alk4CkYvmyd3dyf0J1vMoAlsumu2x4nxwa r5VNGjY5jmXvjrRj2Q2uI/ls6fi9nqyWewqHsvtrbq/g78dVch6rDzLFfI7iB1kawKP7K0OKWvEM ADqDV00C121l84afJ//8R3V9VS1/5psHres3AaJ+EkA/dzDrZEvxjwL/9ETJQsv+n3wqYC/5nBbZ 55cA8NsA8be38DN/PyDJUPaPfRVgb/5khvpXSOsFfLfxLLShV37Sq6LuTPzjjQY7Ujs8r7T9YHlz ijIa8BXSd8ubKu2CkNu59vxOeYOVd84A5k3/ttmdKbQX6Ryp/c4+CY02vto4Msu7A27cxXIGwOTN +e6J7O4IzK2ijkVvrayl0y0OALw4mUYMHttYMNyBYW1yoNsmyC4HAF6cScYOxKjG6ZY+rF0OZOME 3ZAAsEBZjZI3jhaYW0Asc79tjwPZjwCwi1I+OqBGR0qYox5lUY7tcTCqo6xI2Y2S1xILzE37t90I ZIMD3Y0AwItTPmWgxkBO3DLiajcCAAMnCKmikNxU+iQPe+1FoNsGAHhxVhRSQ0Zc4SzLR2wjAtk0 AMCLsQEfisitG7UtA3QbAtkyAMDGiCrqqCJchHy1XcCCLr6OEuLBAgW51eJy/2yrAFnUD2DghOse qCG3ZDLJ9a6NAnRNP4AX50ANDdQQfBPxekU/YIHSJCThC4YFtwzxckU/gJVTaMQIyIgSksKtBf26 9B7AizEAH0goBKwvkzCdlt0D2BhBQrIhhsDuLLlf0MUXoa6UbSsU5CR0sdwesEBpCpJNMgSWsK6k J70W2kt7CcDFl0A9sgXEgoF6sqxdP62MBzBwWk0p+zUIzC0Ru1wXD+DFmVE+BRnvrIkH8GIswAe1 ZHDLrbIsBD+uXAesEUIlKfOzBIYLt2XBtq6OWqvWF3TxVVRPRfX47QV0zbq0j2vNOoCBE+TToJLE XgOsWddl8LK6HLCLskE9KSv0FwwVJGuVbcX68JQNKUFAHQXUnYDWynJZrq4rywG8ODsKqEM1Gbpb Aa7rytdqdVlXDmDghHpyoIiGE9HFqnLALsoBIpK+NsPiBoTS+bA15a4yj9viixuISJZ7KwhbWlv7 rSvKZe03gIHTqklZly2wgCK6WvkN2EUZQESyfnrBcO3rxbpvwAKliUgW0wksupW/4qetVd8aGgHw 4oxQW8qy5AXDNd9rhbau+ZYV2gAGThORLB8WWEIRXa7RBvDiTKiijIy47PVqfTaAF2MGPlRRdioS H8jWZssqagAbI6qooIqKU9HFGmrALsqCKipQY8biVhE/X0ENUGC0+lKWogqsOhFdraAG8OKsKKKK IqpOROJfrBXUutYZwMAJImpQY8aGNeblSmcAL84GNWbsyAgiulzlDODFCC9kRxF1FNHlCmcAGyOK aGB1iWXkuu20EHkhF93A2nKggAYK6HIZMoCB0ySUNpBQgo/G/vgi5GdLject4i8iSlhDXotMmcpN qgeDQOvUW1/2DPS/rBOkrwyQt+EjXiG8jbno96fQfk40U6/5ubLGQd+84m734eOgdF7dfpFlw/2t /Lx98RGc2ahm2jaZJt3cCeDMlVAcfvhK0wm6EMzvhKJlOFiE9e0TxV8lXHbxgasAjmGNk1nMGsCJ 8YGrAI5hkXMApzithCtYVVwFcAxqlEyilvitgsM400UAx6BGySRm1UVZXZjpIoBjUKSsQCluK+Fw f8qr8I0ijU8+Ob8sU0pzMaar4I1hkRNFxN4u47oLEFwFbwxrnDLxb1kDODFAcBW+MSxyoogGiMjt x3oZwDGscQ5UEcXhFYURgqsAjmEXI8fyNW0S8vucXgZwDAuMqCHZMpRxuNPhVfhGkcYXUEOBfV1B uQjBRfDGoEjZgDKahA5bfF4FbwxrnBElJPN0FYcSugrfGBY5QUKypSXjkpPQVQDHsMaZnIQyMKKE rgI4hjXGjHwgIb8N5UUAx6BA6BRUQEG4u9mz8I2ijKs49RRQj/N3L4M3hkVOlE8F+fitF6+CN4Y1 zurkU0E+1YUIrsI3hkVOlE+z5jY4j/cqgGNQo2zY2oYOhBgguArgGNYYO/KBevwGgVcBHMMCo5PP sKY2YBzsInyjQKMb2MyGAQryu+1dBG8MipQgIF0aOXGHffGugjeGXZzCYlYHThTQVfDGsMgJTycG E5Dfau4qeGNQowwooBiBEAV0FbwxrDFG5LMqMroxwcvgjWGBEavImExAEfuJF6EbBRpdQgHJRmWC cpGBi8CNQZESBZRBQG448DJwY1jjzE5AGQSUXXzpKnBjWOREARUQkBsQvAzcGNY4i1NQBUaMDFwF bgxrjFpdDIoSmIKqU9BV4MawzGgsajVQkBsOvArcGNQo21IRW6YiNx54EbgxJDI2YOzWzEa34etl 4MawxtlXc8tWB04ML10FbgyLnB04B4jIjQheBm4Ma5xjiYitAZwgo8vQjWGRcxhn2kxIyQ0JXgZv DLs4hUWtYEJKblDwKnxjUKMMKKQUrMlNbqvPywCOYZET3qEUTUoJHOq/Zxe5b80pOsZ24v7mz1gD X3SV9AdHPxIUbXWf+Hc7TyM7PvQSaAsu9jYOM5Z+nzOWIu3TRjtb/UFzl9xihsb9E57+RN/tmyX4 +sKfquTCULJixMkZScJPfKpMk/t03OsvyfhTcS8SRM7nmV7ht/2ezbtW5RZuf9CMpDDneF2HwCJ9 Su4UAJtn8ayx7RdZm1LexgyCZdpz7DhjzD0RevhJFkyTULTZnjcDerGYFoyd+0PP5K/L+lNPZe7e shPZvLDzY5H1PsfnYoc7L+qJulfhFw46PrvfNIMscxiVvp03W8wy+xNWAXTtOKj/pxG1RHO/5om8 LRR9HnFFHtFC5JpZ+/2Tua+qSBeN7Lozu+5SrZFDRBuvRjXVGo63I690u9R71ignopF3AC+HExXp xuO77k+vcT9qF4FXRuQdk1pVpv8qciCvdD0lRKntAYKNViOcalWgdeHJLo65fp5Hmy4EI20FWg4v KtINz3ftfGuMVltuRBuvhjrV6o63Ia98/0A6EkW9DEQjL6qsO5W5cGXXAIR8nkkdIgQbbXci605k bqy+6+cfNKR+KG13GutOY8NpzA3X42b1Rb1WRBrnQH3JJ5kMCfpqEhnS3m5RBxvRi1eYzAKBBTdu 38TX1K8LFO1cIBp5QWESfFSkG7tvEiPTEELRjhCijTegwmRbAUNW5GV/Wx2wshYiABp5QWEShVSk G8VvEiXUqEzRZgHRxqtRUbWG4+3Iyz0O3SC5aNca0cgLGpNopCLdaH6TSKn6y0XDCog23uR0llFn Prapt0FeuKIBEAQbbXYyy05mbmC/SbDYvlsGnNlJLDuJFScxN7DfpM+pXZuiUSpEG29xEitOYi7a 2fR7SBqU1XAaopEXJVadxNwYv/YVtHuXNfCHaOOtTmLVScyN82u/RruiWaOeiEZelFhzEmtOYjqu IZrIGqFFtPE2J7HuJOZG/LVrp53xrNFkRBtvdxrrTmNu3F+7oTrGkSWIjmCkRZkNJ7PhZKbfBBQJ Z432I9p4h5PZcDJzcwB0C3oNnWQdl0A08oLMJJ4pyLg5memn12TIJ+u4DKIX74qvqjUcL8psDe/x 65El6ohgpAWVyWcyFBmww6/hHY1yZR3rQrTxBlSZfJnDkKiyw6fyso7zIdp4I6pMPkOhyIgqq4fR 2KwjkohGXpCZfDJCkW7CrXr1GpXMOiKLaONNKLPovPuYUGZ1jUfL4pfoX4uYUGbROf4S9VSkc/zV MdfAbNZxbkQbb3YyU8c/rijoYhW3XMSWdYjfsMiJGlOnP1IaQ0r6HUpRWrZ+k2KN0zn8sQIjBpTE 9xCJZevzKNQI8fGrox9XEHQRsn+vk0uAzXn40Xn4UT38uCKgyif+t3Zyk/VyFGuczruXuKfiUEgy 3KDjGcm6OIpFzgacXWQUVwx0cbLW5aknDfYZ1Ci7U1AHBTmfXn15HcpJ1rVRLHKigoZ0QCKlUUHi zGd+7sl6NQo1yoGdj7QBIQpIJxNJ/ytp1NiwizFtyGcKSs6P14E1HWhLWMTknPjknPgUTETJufDa JdBPhSXryijWOJ0Dn4KJKDn3XbsDMsCYdODBoEgJGkrRNJSc5649AR0FTdaDUaxxOr89RRNRcl67 RIz1C3HJOhkKRUrQUEqmoZR8YJs7ADr8m3QEy7DGmZyIkNGFtdn11xHqZF0WxRqj4wMROS9dvX79 iF+Kq41XLDA6FRVQkfPSdZBAx+aTdVQUa5zOR08FVOQ8dLpqfkTJOigKQzpUUAUF+cm30oHQrzem 5YEo1CidV54qCMjPvZW+g86cSNY3USxyooIaKMjPvdV+g9zRZP0SxRpncwrqwIgjbNJJnyWMOrHB cMbWkQvU4/xv7X/oZJZo/RDFAqNTjy7Rnzgsn/QQklx5tB4II41voP+WBijHOd3aN9ApPFHnxhgW OUE+eTP5ZOdwyzilfp/V/CtFLsbsnO28mXqyc7W1q6Efko3W5VAscoJ6cjD1ZOdnazdDp1hFnVpl WOMMqJ4cgRGfjnQw5Bu60foZCjXCiHQmoOxca+1ZJClqLPgiZudYZ+dY52QCyu67dNzl1ulvUafm KdL4EgpINwRhlBOQdFP0o8nRuhWKRU4UUAYBOVdauyg67S/qxEnDGqdzpDM40tk50vrVQJ2cGK07 oVjkRAkVkJBzpLVroh+3jl7qzpHOxUmoAiNKSDolOikzYo2WnSOd8XGDI52dI629kSRFja7/kJ0z nZ0znRtIyK0Y4p6IftE8ut5DhnB2bk5C4Ehn50iLg6rTZaONbCgUKVFB4Edn50dr10a2TQA650Nn 50Nn8KGz86G1Y6OzhIPrPmTnQ2fnQ2fwobPzobVro7OZgw1lKNY4nRNdNmDESWrSuYnyb3C9h+yc 6LIhn6mnOCdauzY6Rhhc36E4L7o4L7oEU0/BSWrSs4nCHGzkgpHGF1A9BTzo4jxo7ddE+Te4rkNx LnRxLnQBF7o4F1r6NeL1BefnF+dAF+dAF3CgS/QT6bhDG+XfYMMVikVOUFABD7o4D1o7S1G6OMF1 HorzoIvzoAsyooKESZc/BBukUKwxOj5QkPOgta8k1U9wHYfiHOjiHOhSQECOkOsxqTSC6zUUpCtO P+A7Fz+XV5h0PUuwAQnFIifqBxzo4hxo7SdF6dsE128ozoMuzoMu9bUDJypIuKL0QoPrN5TqFFRX 1KruFnjQ5TCXl7mi9JiCjUQoljmNRa0OjKggYYrSuwnosRRzopVipUFAfi6vvISRa+Dg+g2lr4i7 kagFPnR5sqQ9Sv9zs1EHRhqf+dBsmYKcDy09ryi9pc11HIq50EYiVgUXuvq5vFK4KF2bzXUd6rY6 icZiVgdOFJCUj/hsiEFxyAdPpoIDXcGB/v82PatNp1EnaEmhdArWKiJEkb0lE7SQZV7AebpWrOpe PJustf5eTDLaq2DpXn9+mR0PbPCUjc7fj3QL7S6nuZQtr3kfvOg9b/x9XksbRp7bd096tdP8RJGr CSiGBcZX5JRv+gruxiQRgxqlfs9XrbYoDxNELmZyGBY5G3DKZ3K3fJodcjHbwqBGqZ/IVasDJdQZ T6dEGA75OvBx1cg45/BeTlswrHHqF6rUGsCJA1xXUwsMi5wDOAeoyHm9l8P/hjXOgSqSKRyKuzFE b9BFKSRmVaU8zAK5Gko3LHJW4Sxr5gbjcNT0arBbkcxnDGZ143PjpVfD0YZFzg6c0WR0mPVxMWRs UKOMS0VlTdRQHKroaljXsMg5gDOZivwStquhV4MaZVoiKmuChuLuDI8a1jjzUlFZEzQY58PHV0OY hkVOVFEBFSHj1SCjIo2vOBUVUJEPHV8NBhoWOVFF7Lgyzrm/T0fvDGd8zGDWAD78mPrVSJthkRMl 1EBCzvW9HBYzrHE2p6EOjHfGsAxrjHgfO+jH+b6XA06GBUannwH6wTJejQ0p0viG088A/fidG66G cQyLnHDdMtOCcH7GxuWwi2EXp7CYNYATNfQ4D5EYDOlAPjGYfPwsjcvxDMMaZ0D5xAiM3xt7MJyx ReQy6RxWsF2NFBgWGFE6MpOCcXjFz6P6ijO2hMKRtWeCclG/q/i7YZGzAWcG4fgVbFcBc8MaZ3bC ySAcv4LtKsBtWORE9RRrZuMhcHwRjDascRZsZ2MFRhfefh44NqgR4sOuICC/gO0qzGtYYHQCAj86 4o18EpNVkFE1p56m6tmf3GHp2mX8FNHIiwrqqiBCugVslzFPRBtvdypavrQgnyylPcUpEY28qKSh SiKkjyNfRRYRbbwD1ZQ2x4praq8igYherMSz0iqpiUtuZ4ir4B2CgRRVJVMxFIkP7CrYZljjDOi5 yYyKhXPyugqNIRp5QV4yq0KRbpeIq3gWgo02orpkSoYhXXDneQwKwUgL7bBMrlBk+iv2UPpcjGfG bGjXGylihZiELV6iugLTjFnnPl+GN0fWozD52EziRUe/8B7hv2xf3kKWlUm4j/i9ABAPAnHn/RAC +rL2H/8phLnneni2Jfm81yWlH4sE1dBXUKfQJ84k+gNpw8jT/e5Jr3bavUiQYYHxFTk5iKO4G5Eg gxqlhJOW1RblvUiQYZGzASc3Qoy7FQkyqFFKM7isDpTfiwQZDvk68OnXkvrtSJBhjVPiScsawHkn EmRY5BzAOUBF9yJBhjXOgSqSII7ibkSCDLooNZy0rKqUNyNBhkXOCpzBVHQrEqRI4wsoIYnhCOpW JMiwyAkyCtFkdC8SZFCjjKgiieEo7k4kyLDICSoKyVR0LxJkUKNMTkTZRHQzEmRY48xORRlUdC8S ZFjkRBUVUNGdSJAija84FRVQ0b1IkGGRE1UkX1gL/VYkyHDGJ7GkZQ3guxMJMixyooQaSOheJMiw xtmchjow3okEGdYY8T520M+9SJBhgdHpZ4B+7kSCFGl8w+lngH7uRYIMi5xw3RLDIdzNSJBhF6fG k5Y1gPM7kSCDIR3IR2I4jLsXCTKscQaUT4zA+L1IkOGMLSKXSedmJMiwwIjSkUgO474fCVKcsSUU jsRwBHUrEmRY5ARHTWI4jLsXCTKscWYnnAzCuRcJMixyonqKNbM3I0GGNc6C7WyswHgjEmRQI8SH XUFA9yJBhgVGJyDwo78XCVKQUTn/WeI3lVY/3o0EIRp5UUFdFfSJSBCijbc7FS1f+hORIEQjLypJ v4TaPxEJQrTxDlQTRXAMdycShOjFyhElTauk7keCEAykqCqJ4SjyTiTIsMYZ0HOT+M3C3YoEIRp5 QV4SwFHkrUgQgo02orokgGPIG5EgBCMttMMSCVLkf0IkqLSyIkEaDdEW0yJBVFdgmjHr3OeRoPkl tvY0EhT/mF8wo3BQjBTnSfJ59dvxn/lB6L87/lNTWfGfGk/RH/Emx9qZWevh0aiTzKGcSaLBMZcG lEaAvn/iK57qo0Cyb5q0Dh1LwiGgA4lYEgISJAZC1laYsj2ZTl82rHEKy7Iacroo0NpVVNS3KltA I28DXmm/BPk0EtRlQnNblS2gjVeYltUdL7y+DXe8xc87AxhpO9BKTEiQPirkNhDWRfzAy3GhA9Oy huPFPv3akTnbrn+OtjvaAbTDicvtGKMxki41el0xEkAb70CFaXhoIbFvL07R2qVJ50EievEq07Kq 8R6iRPoWrDCmLFBCNPJW4YU4kSD9klPdXF9jmf6pyaYxB6JldUeLXTUR7drvR9fsIxp5O/BKkybI +Ky73yRYVlffANDGK0zLGo7XrWFmdekeOoeaT0JHByKxEqrMB490jbC+HGvvK0Qbb1oqoyiNY3U9 a9aA22bbkQ4gzUjpBPZ0JeoKRx6qMQkhHZjEKk5guDpIKpsVktQVBIY1zuLUVbDK9YEkDUOusORy 7gCNvA14q1OXX5Yqdc3agORQh0lI6cC0rOF4Xb+Or35tFKJdRQAjLaqrYZXr40ratdMNPfLyxABt vO0VpdAdKwYHpKbRmiEfajCJLjkeTTt5uaWq2oXSqKKFZgENrE5eA+tbt2u2VDMaWczHO4slHauu ZQvl5afb6z7X4g/lY+U1nLwGyksjTYz0sSbd41tDjCugCuBFq0TLGo72ybqNtWeCbo6BaOQFecn+ 14p0cae1t7uG2w6Vl0SeDkxiRceKj0wHuDTgtvq8gDbWiJwoLx+D0hXQso2A7sWAWOBEccmeMIp8 8hkDrRnToe6KePUJxaWRKMWhuBLsy5UO9ZZEog4sYmUnLBeLSocBn7XiH9HGm52yMrbiPh61vtyh 68xXDxLQyAuVgUakBOliUuu7JRqPO1RcEpU6MIlVHeuzT+7KHV4rzRFtrKiBik24D06tz9VoTG7F DgENrNiEyxYxisRv1uj2khLxi4eKK+J9bU5bzWnLxalWsyWBOV3VjGCkRXl1bMJ9mEqjHRr4WwE/ ABttx1ZcdooxJN4D3fhPgnTHaqs7cXUnruHE5YJUUcdmpZcX1ggOoI13OHENV826MFXQMLwG69qh khlOXgOrWdk5RpA+UBXWmCoLLXhaCVQdiMQKqC8MVAW3ddqMqengy8IaZ0B9ye4xC4f6ClLPaMQu aKAF0cgL75hsIaNIF6gKIlhdKRkO9ZdEqg5My+qOFxQWdE8rXXl5qL8kVHVgEithffufEaranY+Z 9aa3VENVkk6u4fIW49b5z8NVu86WN3OMKM19qikgFerbT+XnMCRU9YtMXPoDN65WByToxBDtlPEW 3ZW/uCGbesu2RWT09T3tejAEBgR/x/bif10BPrfN+PbIFDE8rPf77a27bazl1v7xFqqG7U7Bu2/c ZIlKJh2o1P3RJV1hLgumGbPO/aHb+9dl/akbO+Os/ekG7hf39hMR0tS6xEfTbBnuRki5d8Unfn1J rWmg+IFpREllcuPEVzy1YH38LEKKQCB8RUpd6cjIOxFSwxqn7M29rIacbgLaVYQU0cjbgFenazeI cn4vQopo45W9+5bVHe+NCCmCkbYDra58bBKOdPPRLiKkiDZe2Zx7WcPxujlpzyOkCEbaAbTDiete hBTRxjtQYWsVZONoJLBexUcNuzh1d+5lVeR089OuoqOIRt4qvGMFNRV5KzqKYKY1IrO6o8UJIlfR UUQjbwdenbHNyOj33byIjiLaeGV3kmUNx3sjOopgpB1Am1Bhfkfty+gooo03LYUNCWsqDjkvYqMG NcKMdE5c9yKjiAZWJ67ixOU/k30VG0W08RanroLVrVjfi44iGnkb8FanrnvRUUQbb3Xqqk5dfue+ i+gogpEW1dWwuvWbaV9GRxFtvO0V5dAd653oKKKNFV/c7iR2LzqKaGB1EhuurnU7aV/GRxFtvGPV t2PFNQ15J0KKaOQFia31lIS8FyFF8KLVLbmX1R3tsw9AHiOkiEZeeGwS11TkvQgpoo03oMRidKx3 IqSINtaInFjZ+l20LyKkiAVOrGoltqnIOxFSwxpnQnGt9ZaC+26EFJHIicLKWNf6vbMvI6SINt6M da3ENQ15J0KKaORFZRWnrHsRUkQbb3HKKljX+n20L2OkiEZeqGwltqnIe1FSRBtvdfpqTl93oqSG Nc7m9NWwsvXbal9FSRGMtFDXSnBTkbeipAg22u4U1p3CbkVJEYy0KLDhatp7UVJEG+9wVe1wArsX JUU08oLAJLgpyHtRUgQvWiFSC9R1K0ZqWGMMyIfauhkhRTSworgkrqnIexFSRBtvRHVJTNSQdyKk iEZeqG8lQqrI/4QIaRqNNt3iW2qBE5u8x2PgB4tR69zn0dHUx0V0lCNL/E3Fm4HQSHNsc4WPQFb4 COSA/cQwLRg8+8e+6PeXZv+pWF2kCVq59buxOjnyK93dLzP4vA36euWGd3oFqKQyb/o+hDDHt/M2 W/POW7LNK+Jk4oBCSN2nCWJn/tA9/qsy/tw3E7fpA89O0Umkv+93N3yZd47/bnW/g/Ebn7EccxXO DESeRgO+s8Xc5r9cGSi8wkHhnnhGMN+IsMLAdPGYTnoj6o9Ho/+qjD/1BMbs/D//lujbT4NHUvCT oje/KToy1al/wVdFL9+UlDfY9zDReljdv1CsxK1IxJQi4Owfelp/bfafG5ihV/D6w7mn1+byw6+N BuXqiefmgMPhzZGLSoldJLkJ+qUhsuq6EZZSBJz99zyRvyj7T36Rd/aT5hYHxzu5vv0aPvcCJZrz M7/08PwZf+ZTseYl+3+pspsKDDypN9HXDMJYChUj5en1hQ7Jx7smyVV9YWOezufNCA/TzdT7g/Ph uE+gCOtM7yk6Z/5LRO8vlOyM4iwZTgWB0r4/fqiGhat1vJYXX9wq0QcWchVbL+b9xS7yAy8dbse6 S+929z78PbU7bU/gHUs7/dLvCnLT91C+rV0fTwZvn1QQe8PY34LUw1wls4akmtbh3fk3v4WuCgOx 0fmSrreEF+McbZB3NdbZuZQXMdahxt5/ftCsBkoEeuwzGemjwC+UnDF2PoWiPkxFyR1LmUg0KFK8 jUG0LyWfyslJ+P7CRuJolhiUPZ3KRbJy/5AE/XUDL+RmpXjH8n24csPV2FW+v8D1f7j7su6V3r93 u6sfcKfh7ttTecdyf1qMMc3KNwbb/LerGElYeVaGt0TTAr0kvJ6uDDU+HoX2ZE78Iew53kQXI0m+ k2yIdMSYN4RPpZvElCoeykzvZNvUeHInX57eSTpFdLzK/WOiwet2vN96P1xJrfTrqt5f4Ho/3H3A u7Pu2jvezw9/n+3u21N5x3J/WjRzzJ+0u0TTuEHNsw5rs/8apm72Dlb8bVZq8cstDWVahlZEQG0m +dopOS9qfsRdE9P3fhdDviglxmzw+bQ0u0hMRsl3ziNpiJhvwVxYx2fNfwu1ijk8svbsZ6aEzXP2 HZfx/YfmDK0LXHRCrpejBfiAIq1CrqK/v8A1fbhrxTuw7sw73rMPvJN6b/V+v68yfr4qGeVB30/z FclvbyGt6uSOCkqdFyLfJ6t1RoDkw2a1djVqpYo4WZJrBjYi4V/EYFCnmpmSTZPzvszM1msW1Zi3 qPGpksz8WpKRFB/4vhc5lYoG5f+hGsVdv+OF3FYp3rF8H77ccDXrKt9f4Po//H2Bu7Xu4jve3w9/ 3+FprKf0juX/tIbq1rQVdTXLXoHEKaJGkwZ3f2bc9GR2jVOQccwZRaVJcI6Sacw2dO+wSoK8QEpm GQhmYw5U8EmZ525VTb5TBvrBpZg4GWPkkyhRuebfk4U9nTiznOAynwiV74fqknVti0uYI1/Kyv0D S7TKmPUS4Ho+/HXC1a+78m536wPv4Lqncp/ftXyfr0Y6BU/zsSLRiaNpSiBPBewOcKIVzyntwqCf YiHvWQDQf/MO+CxtpMJTFnH1rbkbHcmf5r9jssa3uP0cfiXl/cKRrjR98gkI3Nlj7EWOcZvjs7FX vaiVI+cSaiBPPqwwJS/p1r97JQpyl50ndCMKmEP2SJ1XBAcaDGBrRqPYKs7KMiLik4QxKom6I99k n0MCbAWqGGY6rHSheuN5rkT6IqQG/wpWdkVma3tqTapjNhEsV/ZMo067JWmlmQOnmMH7KXM7f5Vc L4a+4BImBVuzI8BWcRavi/FUz7OBsc/53vLPM5NERPJ9E+rwps6DMTHMkTrLkn+jWSDrvLFqAsVZ FpXHD2cJulhcnmkNtBqHN+ksTDMK2ODed5dBEmvecf6lrPQgF+hpxkyqd9/gX8GKrtRR1DCeWEHu PmazgYVlbzwxZJ6cxTKi7rJ4P2VvDKAcvhzaBpxiDLXrfHArKxt85oHnaR4VFsxn8vvo9z0L8vmb 7mQ9ddLk4wcZ8uNfKjmedEaluQjIJeyzKdp0OxX9DLkO9dNmEvMZt3iq6rjmzG8UEOPY2KpE8/rp V4mQSSX7pEam855VyVfVfctPy/Os/tai/M5xlRCJn+Muea+FfVX8vVsR6RO457wnyZ//do+jzNYw lXIuPhUcbgmXnC+qyhYgf80NLLPb8LQM37uF0oiF0428fw/DrBCfZn58HN9qGekC4mobq1j8/kwr OGuT6TN0GhnKodvhL0KoLSrkERdgpumXlQqrfTznHH37qICvYGVXbG0Rn1naPmI2ESxX8s3aR0or zSbto2bwfsrczodaji8mWfuoXxsUK2D7yCcfqJ5nA7OSqbmhn1f7mOXjcWGvg+SrmtI6rgz3X+Qz f3IOaesD2G7WdNz/oZb1r3o1r7zNqzeT+4HPivD8zeRcfpnJL5T8lY1PvZDP88RK7Z8e/w/vx1zi CmVuZHN0cmVhbQplbmRvYmoKCjE4IDAgb2JqCjE2Njc4CmVuZG9iagoKMjAgMCBvYmoKPDwvTGVu Z3RoIDIxIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJx9U8uK3TAM3ecrvB64qSTL sQPGkNx7s+huINBF6a4zLcO00Nn09yvJeTFMSiBx9Dg+51iGFt3f5o8DdwFZRtJ3YH2/PbkvD+53 g06ftx8NaML9aqTIVq9a7vS7vmv0Z/P8YJD6SN84N+ShjY5DaJObv7tPEzpmNz9/zYgFYwZfukwD xIIZJ/DAMAAVDBlC6TN5BEzl2/y5uc/N4ztw37fB+d6v2N4ht4qeAcv88lFL10mBT91KxpORgTsk SEIFAbggZxIeSilRVy6YjR+MwkgKbH0rCNo2Veo3Gmm0JaE20BWnpQl6laWg8rWQIS/rUBZ0Csja iUhwJjgGFRyo7TfB1HYmmE4E91GKPW+CKZlgBt23l+2T6rpsJJQaI+6RiGA/vPsQaobl8LaEnlrK FpGE5n0q3mtE3BzMk1T7yBpkp7QkqoVU4WyHK3pLHOAgLLEjhQo1ENP1zLNqgPjE7yyw4zxIWMAU lzsat/1lLqwEqYo52KUz3O8Sqc8cj6OyF44K0K2hfedUi2vdiQKmKId8kMCbhDqcCfrqQyGdtytE cfcELFCSC/mhH3ZogkQLt86c199B7uDF/4eimUwx7bd8Bb1XJ/1duCHDDSYxMubjjD+6f3uA+VsK ZW5kc3RyZWFtCmVuZG9iagoKMjEgMCBvYmoKNDczCmVuZG9iagoKMjMgMCBvYmoKPDwvTGVuZ3Ro IDI0IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAxMTM0MD4+CnN0cmVhbQp4nO1ae3hU 1bVfe58zj4Q8hgAhkJA5w5ARmIRAAIEEk8kL1MgrBMxQkAyZgQwmmTgzAbEWR1t8RBT1KlXaitqH qFVPEqQT1EKltS3K41pqq20RH62Prwj2+9R61cz97T0nIbHo1373z+ucrL1/e62111p77XVeM4mG OwOURjFSyNPc5usYzRgnoheJWFbzpqiW9kb+KWCQuWF9x4a2e+8vvZzIOovI9P6G1i3rK+49+ShR xiTMeaIl4PP/LJqVjvEJjC9sAaO+/wYLUWYaxpNa2qJXb2Qe4MzpGKe1hpp9rVQGmDkfjbXNd3XH avUVFeMajLV2X1vgxlEPV2DsJxpp7QhFooRAIWoVTUc40HHNqpN1gNuJRvwcPIZDfOCDmcWY0//v j2k/jQONNz1M41QX5RAl3ga9I/r+YOIdIRc9fw/KcYOI9tDjLEiP0wF6jp3FrCepj/bSb2gs1dD3 6Vq6m24iM60C5xaqx2EC/242LrGXiulBbNGDdAS6l9NW2k/ZLCfxLl1H25TfYdY2SqeJVElLKUS3 scsSnbSaXlO/TXPoMmqnDhZLNCZuT9yV+BH9mPqU3yQ+pxE0nppxHEm8b/pj4s9UhBn30H30Grsr 5SnywEsMmj+gMO1S1qgssSHxP4jAQZsRg0qL6Ag7yN2wHqC3WQ67VqmGlR8m9MQvoZVHa6iFdtF+ Npst5A7T6sSixBHKho+rYfU+6qF9OOL0LL3K0kxnEz9KnKVxVEiXYD176Sg7qPR/fn1/hUg0sjSF 5kESop/Tr+k4c7Jf8JApzVRi8piuSZyg0TSDViDahzHzb+xjvhXHdcrz6oJEFWUgL3eKbNOv6HU2 nhWzJWwln8JD/H4lTFZ4nIHDT0Hk+15YP8ncbB9P48eUH6qPqZ+aJ/SfSmRgR1z0PfoB/YKlY6Ua i7Ab2MvsTV7N1/Lv8TeUu9VH1JcsPqz6Cmqj2+gx+phlsblsGfsGa2HXspvYnew+doQdZ+/wSt7A r+RnlBblKuVZtQrHcjWiftt0o+lW8zv9jf2/7P/v/o8TJYkbaRnq4XpEfw/dj5X10TF6Bcdr9AYz sREsA4fGHGwF+yaOrew29hDbwx5he+HlOHuDvcv+wT5kn3LCYea53MEn4nDyMN/M7+bf58dwHOd/ 558oY5WJiluZrcxXvEoIUd2k3IHjKeV1dbx6TE0gzyWmnabdpj2mx0zPmc6a0yw3WMn64mc//Hzq 5yf7qf/m/p39Pf17E6/TGOzheGTBTvMRvQ/HRuz3TlTck/Q7lobcjWdTWTm7DJlZyzayq9jVyOR3 2C72Yxn7E+wZZOkP7AxiTud5MuZpfDav4ktwXMED/Cp+B7+L7+Uv8/9RLMoIJVMZo0xVFiprlIAS VbYoOxVdeVH5i/KG8pHyGY6Emqra1YmqS3WrC9W1aqd6v/q2+rZptekF01/NqeY2843muPkDy4WW cstSyzLLGssOyz7LCWsTqvMQPUU/G3rOs1PK9Uqt8hTdzmeq4/hRfhT1vJb8yiKOSuV72M38W2wv n2S62lzGy9hiOqu6kOvn+W7+ES9TFrE6tpw28hlJa+bRKq7wNF89RKfVZ7C2o7B8tTmNbeVnzGnU w4jPg89fKdNVt/ICvaq8xizqg/QnNZWNZaf5w8pSVMGzarmpkRzK9+kJ5Sr2LXqK1xKlfmrdjjpe zB7FdaGBlbB/KglS+GJU0RzlTfo2Xcn/SKdxHt9M32V+dQPdTjPZtfQ2/QRnxRRTu3mqeQz7LQ+q XXwU20tcfQSrm8cmMcU0mr7D1ii7zGf4K9RJx9RUOqn8FNEf408oi9SzpnrWgjPgW3QjXZW4nraY GtWX2AZS2EoqUE/h6natUqI60F+Hq8pqXNP24ezej+tApbIInBxUzmWoixW4QuzCcS+uEyoqKIhz /HJcxY7SXnMDj9MGUwbDVYdIfaG/nlYlfkL3JTZQe+IuKsL14KbEtbC4h/5KO2gP29b/TeqgfJw5 J9llpgX8mGlBooh38Vf4cr5z+P4i2wUsh97D8QQG5aanqUv9Ay2nisT2xO9R3ZNxhb2P1tGl9BZW +T48XKwcpJn9i3l3YoHSgfW+RssSDyfsLJVaEq20hJ6hH1tM5LO4scc6ewnr/SYFeH0iqgT6g8jD DmTBg2x14vpzi6d6RUOlp6L8ovllpfPmzpk9a2bJjOnF04oK3VOnTL7AVTDJOdGh2fMn5OWOH5cz NnvM6FFZI22ZGelpI1JTrBazSVU4o8Ja54ImTXc16arLefHFRWLs9IHhG8Jo0jWwFgzX0bUmqaYN 1/RAc/0XND1JTc+gJrNp82l+UaFW69T0IzVOLc5WLWsEvq3G6dX00xIvkvgOidOBHQ5M0GpzWmo0 nTVptfqCTS1dtU01MNc9IrXaWR1ILSqk7tQRgCOA9LHOjm42tpxJwMfWlnZzsqYjKH28s6ZWH+es ERHoSkGtz68vXdZYW5PrcHiLCnVW3excp5OzSs90SxWqlm50c7VukW60oFgN3ap1Fx7s2h630bom d5rf6fetbtQVn1f4GOmG3xp97DVv5ZwbwnhWdeNNQ6W5SldtTlATw66umzT9gWWNQ6UO0Xq9sIG5 vGBBU9cCuN6OJNYt1+CNb/M26mwbXGpiJWJVyfUFnLWC07RR01OcVc6Wro1N2JrxXTrVb3H0jB/v 6UucovG1WldDo9OhV+Q6vb6avO7R1FW/pXecRxs3XFJU2G0bmUxsd0amAdLSh4LAoEwiqS5QXf1g ZpmIyHkJCkLXmjVE0ujEmuaKJjCXuprnQg0fL8Ms3Y8dCeop1U1dtlLBF/N1U4HNqXV9SKgA5+m/ D+f4DI65wPYhCSjqZLDUIB/AututT50qSsRSjT1FjOVyPLuocFOcO50dNg0d0kdLkVuft7QY6Xc4 xAbfGvfQOgz02LLG5Fijdbk95Cl2e3XeJCQHByRjVghJbEAyOL3JiUreKx+Rx+hW1+Bfpi17VG1L qc6yv0IcSMrrljvrlq1q1Gq7mozc1jUMGyXlcwdlBtJHVTcqudxAPFeRUhTl6kFlMWhM09UC/Jll UfvjFiuqUnKYtkC3NV2cbL2pDse/OSmeOCtmye7cNCNMvdQ9fFw2bDwsvLQuBQHjVlnXsKqrK3WY DKWWdHiJ0aHiqaHRoVXrtAJnZgH+4omDcwV5c3UPUlYtFFB/SZYxHKaYa2AvPqI6iwoX4ELX1bXA qS3oauryxROxdU7N5uzq48/x57o6apsGCiee2H9rrr5guxe5amGlOCk4VXU72c3Luj3s5uWrGvts eGm6uaGxhzNe3VTlFYnk1Q2NQ3dPnhLeIlQDZ/IB1yRevvA25xjpGFmAhuGm95mmHPzMY6JPSVMP ivevNnact+A5YATZ+3BDXe7JSDG/qNF0PN91pl3+cI7b9tGa01R8esb0UbMunFmCu4PZOdHVdk9L 8J57gi338KPBu+8OAsNW4jN2WA3xb8BrvieTzSY+3qTBxTi195oc92LbW2tsf6PiRTClzHaMUdUI O3znnfL2KMLlO3Y9FLlzbeb8D625VnnXfOjNC6YO3EETnxkrIkox3hnlPEt5/2KqPnej/cLrlGIG ix+hNjUiLOBeW4Y7vtBS8M6ZfNnkZMMTw0rc9VvUCXAhuKX855R8dSU8a5KBGaXKkSJnZVDUwAqe z28wsAqdUwY24fngPQObKYNZDWzB+0u2ga00nR03cAp18QFf6fxR3jW4ntmmWQZmZDIFDczJYmo3 sELFpk4Dq9D5kYFNlGl6xMBm6McNbKE1pgMGtlKOOc/AKVRrHvCVzlaYt8AyUxX4SrMclVhkyGZ5 VWKz5L8nsUXyP5LYKrDVLHGKyKE128DIoTVmYOTQ2mVg5NB6r4GRQ+tHBkYOU8jAyGFKvoGRw5RC AyOHKX8zMHKYOuALOUx9QOJUEWf6pRKPELGlr5Q4TfLXS5whcVhim4gtfavEo4Cz0rdLPFrq3C/x GGnnUYmzJX+/xOPk3OclzpU6JySeIHXektgu8VmJJ0n9zySeKnBGqsRFEucIbJXxZ7gklr4ySgRO S/LLJZb1nHEpPUIaleAEnk4XAjXgfTmAfhHec9tBUdqC51bBqcYoDCxaH/hBqTENkkpqxaFRPXgb MD9KETkKoA9AexNaPzQrgYOY2yplG/C02YpR+F98lQ7R1L6gW4ozT9iMGP41mg3L0/H2rOG5eBG4 zZCGIA/RelicMsTWl82chvVfPURvEbIwNIKgXI8PFJVr98NOm4zmSvCEn/88b8Jqu7SYnLcCoyBG IlManvWjUjdgeG4Ht1ha0KTtFrkSDWsNITPtMq6g1J72H0fyr3oNg6hGam6WsW7AeAnWul7mWEiL 5O6E8CaSXMtiKWkBR+xVhArBWyo9haUkKHO4HG2nXFFyNzTswDyaiz3wytVoMrdb0HfK+knmKLkH 62WsUckLofVLfof0t2UwUxo4YRlT1MhRu8xlcuyTljqk9zaZ84Gsr5M2Bnak1Vhn+2AUyRkDcYSH 6HbImvMj4mbpI5mPzTJukZHzryE5FrrN8NYpM+KXZ9QXMyFmtEo0GfpT0IsKXGfEfX7b7f+HtZ+z 7h/c+7Csr4G9HKie861gaG0Pj6tsyB6JlSTXEpX+BupS2E+u1Q/OZrnykDzrvqoSfMN2PWCcKV88 X0RWo9DrlDNFtJsGqzlpR2i2QuOramjaI1rJ9OkXag0tAW1RqD0U3dIR0KpD4Y5Q2BcNhtqnaZWt rVp9cENLNKLVByKB8KaAf1plOOhrrQ9s6Gz1hQdmlUqmZnBLVwbCEczXZk+bPkObvCjYHA5FQuuj U6TWUOG0kqslb1FD0kAwghfpaNjnD7T5wldqofVfGpsWbNeikK1oD0YDfm151BcNYHK7vzgU1kKQ hLXmUGd7NBwMRKZ9mZFBXoNoasK+zcH2DdqS9euDzQGtSKsPrYOXxcHmllCrL1KoLfXBXHPQpy33 dbb7sQxtxry5Jd5Qp9bm26J1RgKICCtYH2qPatGQ5g9GOlohQFBaRzgIZjMkAfS+iNYRCLcFoyL0 dVvkQlrhs12YgEDYCEtuRzjk72yOitVubkEgQzygD7Y3t3b6sSfaQBCh9tYt2uTgFC3Qtg62h2i3 f6V3qe4Xqw8HImKVIj3nHCSzbdgqkyuaHISXaKBN5DIchFd/aHN7a8jnH54EX3Lp2I7BfQl1Rjs6 o5o/sEmkGTotgdaO4RmahmtwSJ7bPnnW4Kxm6ajajajbd+VVfkCWvMOIM1GccX5ll9KtPKscAPUp +5Wffv1U8PVTwddPBV8/FXz9VPDvPxUMu/aewz5ZM+eTvT5MrxV2hl6V5XX5S2y2QmfL0LGar85Q 69SF6kVo5w3z0A67X2ZlMdpNMovJc72F6exBheTeimtd2LiO+L7Cwjms0Fd++qhBmdzryrEff0aZ QqdAXJnS455g71MuUCb0lNk9ccXZmzWmJLOySBFfBBXLVkMbAj0JOgBSaa2SD74N7XWgGOhJ0AHQ cZAZr//5UqqBQqDdoFNCokxQ8no0u63yAmUc5oo370xlLJ0BJUAK2dEWg5aA1oJ2gHaDzFJPcEKg 60AHQGelxKOM7blrJmIf23Or7Ho3tpbIoS85XL1GDnsv9yb7RcuSfc0lSbXSpNqMWUn2tKpkf0Fh ss8qKImJPjW95GBltpKNRYpX+g60jP+SMhkjOz2gjCEdxBWzwfEoWb2TXCW7DygqMYUrDJtsTxxU WE/6yJLKVJ7gZyiL7Px9fjop4ad7M0aW7K68lL9BT4IOgBT+Bo7X+et0HT8lco62ArQbdAB0DHQG ZOancLyG4yQ/SZn8L1QMqgCtBe0GHQCdAVn4X9Da+J/Fd0ayFbgCxPmf0dr4n7CsP6HN5K8Cvcpf RWi/65kzr6RPAnexAewFBhiba4Cs7JI4f6nnkymoKBd2GhX1tDKRymmmMrGnYIY9ruT0zA/a4/zN Xs1tf6ByOj9BOogjkhPwfII00FJQE6gDZAZ6GehlioHuAD0A0kGoMrQ2kMYPg14EvUzTQR7QUpCV H++Bmzg/1uOqsldm86P81zQWGT/CfyP7F/nzsn+B/0r2v0Wfj/4wf74n306VIyAnzLGht6EvhtzE f9E7KcueqBzJxbdxdrTFoArQEtBa0A6QmR/gE3v89iwYeZoOWwmaPfSu7H9CD1nJs9HucVWjADXR uEovAkKzW9vt4h7XzvswFI3r9ruAROP6znYg0biuuR5INK7WTUCicfk3AonGtWotkGhcSxqA0MT5 /T+bdIF9zpIrmVaZyTcjS5uRpc3I0mZS+WZx0CeqiO17PVOnImO7PO4pU+2x/Sz2DIvVs9hDLBZg sa0sdj2LzWexK1jMzWJ5LJbPYh4We5rNRSpizLN32HCeJ4fFDrPY4ywWYTEXixWw2CQW09gcT5w7 ei6ZKbta2fVWipMO/UXluPpkcgcy6kDNO3BNOID2GCghRx4oaROTyuPyRT+xd2pFcjyttCRUeTE/ hImHsA2H6DWQig06hDI6BCOHYCATbQVoLegg6AwoATJDeyIC3yHbTLTFoArQWtB1oDMgswznDIhT yAjxSRlYsRH0EjHih3CIf7RwcIdngi3P5rZdrOzIY5n5bEl+Ip/PoWzxhXLWSOvIOEvf93H6Pz9O p5TKFH4730ETsBF3GP2Onk8m2OPs3h7X0/bKMey7lK+i6tg8crEC9HMpIsezKc8q+lmUxx9DX9KT txLTMntchfb9LEPM2mf/JO8t+7t5cQ74Tt7T9j9ocZX12H8PzmP77CfybrH/tjhuBecZV5yh269J 1b68ufbHD0vV6yHY1WPfKrp99m/lLbRfmScFgaTgighGnkx7vWuV/WLYq8lbZ/dEYHOfvSLvCvv8 pNZsMWeffTpCcCfhVAQ7JU86deZLgyvmxFmLp9Cy09JoWWK50FJiKbQ4LHbLBEuuZbQ1y2qzZljT rKlWq9VsVa3cStbR8cQpj1t83z7abBOdWRWtKrGNi5Ynf3DgzMrpUtJHKXW8bnkVq9MPNlPdOk3/ aLkzzlKXrdJNziqmZ9VRXUOVPtddF7ck6vU57jrdsvQbjd2M3e4FV+c3xxk1NMZZQrC25Yrff/uI sZHbbssV/eRtt3m9lJO9qSKnIqt85LwFNedpmozWfe6TMwxP0HfWLW/UH53g1UsESEzw1un/JX4g 7mP/YGdra/rYB6LzNvYp5ewftfWCr5TXeL11cbZS6pHGPoAeKuYDqWfFjVnokWbNT+rtSuoVYD70 JokOeikpVCD1ClJSpJ7KhF53ZFJtTfekSVJnrEYRqRMZqw3VOVwAnYICqZMdo8NS53B2TOjo5VIl Lw8q+XlShY2nPKmSx8ZLlZXnVIoNlVsGVW6RnhR2TicvqZN+akAn/RR03P/uJ1DldrPeMm/zavHj epOzNgBq0m/d1JKjx9ZpWnez1/jV3dW0rrlF9L6A7nUGavRmZ43WXbb6POLVQlzmrOmm1bUNjd2r PYGanjJPWa3TV+PtXbh01pxhvm4Z9DVr6XmMLRXGZglfC+ecRzxHiBcKX3OErznC10LPQumLZI0v bey2UpW3enWy7+UjUlGvTbkOb1W2raNcFm+ZI2dr7n48reyhEW6vnuas0tNBQlRUWVQpRDinhChD /AeFIcrZWubI3c/2GCIb2COdVeSOdkY6Kac2WJP8i+ADVrRTJDzZuiNf9oGsVvf4asT/o9bpU5fX 6RXLVjV2WyzgNokl6aUDvBEjauOJg0nmNDBLBVNRBhUFb77gpaQYiv+6/51GXy3Oghh/upd58lmU Il5Fz69r4LgUNBg/Ve/Hs5S4PUS8WGCEuVlkwIYRtttNyTGJNQ9QtNNARi6iRp+ciSmRgZQMfkSy 3IMZi8Ig/S/Z1jmSCmVuZHN0cmVhbQplbmRvYmoKCjI0IDAgb2JqCjU4OTAKZW5kb2JqCgoyNSAw IG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0RBQUFBQStBcmlhbE1UCi9GbGFn cyA0Ci9Gb250QkJveFstNjY0IC0zMjQgMjAwMCAxMDA2XS9JdGFsaWNBbmdsZSAwCi9Bc2NlbnQg OTA1Ci9EZXNjZW50IC0yMTEKL0NhcEhlaWdodCAxMDA1Ci9TdGVtViA4MAovRm9udEZpbGUyIDIz IDAgUj4+CmVuZG9iagoKMjYgMCBvYmoKPDwvTGVuZ3RoIDIyOC9GaWx0ZXIvRmxhdGVEZWNvZGU+ PgpzdHJlYW0KeJxdkMFqwzAMhu9+Ch3bQ3HiXYNhdBRy2Dqa7gEcW8kMi20U55C3r+K2G+xgox/9 n/gleWzf2uCz/KRoO8ww+OAI57iQRehx9EHUCpy3+aHKbyeThGS2W+eMUxuG2DRCXrg3Z1ph9+pi j3shz+SQfBhh93XsWHdLSj84YchQCa3B4cBz3k36MBPKQh1ax22f1wMjf4brmhBU0fU9io0O52Qs kgkjiqaqNDSnkxYY3L+euhP9YL8NsbNmp6qU0lyrUtcvhXs4tgnbis9kYBciTlXuUOJsQXzA31Ol mDaqvBsehW/ACmVuZHN0cmVhbQplbmRvYmoKCjI3IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBl L1RydWVUeXBlL0Jhc2VGb250L0RBQUFBQStBcmlhbE1UCi9GaXJzdENoYXIgMAovTGFzdENoYXIg MgovV2lkdGhzWzc1MCAzNTAgNTU2IF0KL0ZvbnREZXNjcmlwdG9yIDI1IDAgUgovVG9Vbmljb2Rl IDI2IDAgUgo+PgplbmRvYmoKCjI4IDAgb2JqCjw8L0xlbmd0aCAyOSAwIFIvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aDEgMjc2NTI+PgpzdHJlYW0KeJztvHl8VEW2OF5Vd7+9d3rP0rfTSWdpspB0 CIFIbiBEIAJhNUEzJJAAQSQhJCyOQtxYXXDfh+i4oiNNIhhQxug4js68eTKjz1HnOfJmUNQxI98Z REZJ9/dUdQeD48znvd/3v9/ndVL3nKo6p5ZTp06dqrrd3V09bciIehGH9OVXtnQ2TirUEEL/hhC2 L9/QraFHJo4D/DhC0pIVnSuvTG03L0ZIqURIuGLlms0rfviHm15FyPwkQmU1q9paWt/cfr8ZoWmf QxkTVkHCtbHrJIRqsiCeterK7k2ab9LPIT4D4q+v6Vje8n7D8nkITbdCfMWVLZs6c7n7RYhvgri2 tuXKttzVvUA//V6EHJs6O9Z3I2goQksovdbZ1dY58fUp70O8GCHbbyENwx/9GAEVaZxwvCBKsqIa jCazxWqzpzicLrfH60tNS8/wa4HMYFZ2KCc3Lz88rqCwqHg8+v/ZRziC0lh4AqXxIZSGUPzEaIi1 x0/QPArJZyCs9ERIfvrRM+h3OBdraAB/jdzoLPbi8Wgm4tFXMAj70Qi6CznQQnQ3tqMs5EKL0EzM A00Y3YQfiG+If4ouQrejR+LP4+vi+yD/VvQaOgst+AOPUTmaA/SLUBv6lPsINcbvRzLajgxoMpqP XagFvQN/X0Ib7kB3op/iq+NnoVYHug7Kq0TVqDr+cvwcykc38XuEd5WD6Db0Ahbjy+PtKANlol0k HH8n/iEKoUb0Y/QMtCmMh/gZKICuQDeie7GXew2wu9CjKIaNpImbJrwENc1Ei9FatBHtQvvQL7Ed 1wvvCqfiP4yfRCJKQbnQpnb0KS7Ds8ljvDE+Jf4+ugwdRq9Df+nfEH8Z/4RwWawq/lD8FeREz2MV v4hfFkqEW0aujT8cfxY0MoTGg0TmQD3L0PXoZfQG+j/or2RrfCuagRZAzT/H6VjDIZD4O8RLtpAt 3FuoEHrbBK3tQXtRFEbkCHoBHQXZ/B4dRx9hB07Fs/AyfBv+KzGSVvIm9wD3HPc2j/mnQN5BlA0y 6kaPoUMwn3+N3sQClF+M6/Fq3IHvwQ/h4yRKPidf8TJ/Pf8NPyKEYsdj38TnxL9EHuRDl6Cr0FaQ 7Y/RAHoO/Tv6D/RX9Dd0BlvxRLwKP4yj+Dj+nCgkk8wlneRu8hj5CTeHu417mS/jp/JX8L/m3xe2 CbulFil27vHYHbGfxH4Tfz7+G9AdM5QfQrUg0WtBKx5DL6G3oPT30Afoj1R/oPzJeAn+AdSyHu/A d+Kf4J/j3+DPoJeI/WWSyaQGau0gXSCn68gd5E6o/U34O0beJx+QP5MvOYHL5CZw67iHuSg3yB3j PuatfIgv5Mfzc/klfBxGpkS4WFggPCk8LbwinBIrxVaxU/xEuk66Qf63kfyRP8RQbFUsGhsA3ZVB k64CSfwIPQJ6/xyMwS9Bov8OLT6OTsMo+HAA50C7K3AtrsOz8aX4ctyGr8Pb8e34XvwAfgQ/Cz2A PhAJ2h4m1WQBaSFt5AayndxMnoO/I+QN8g55lwxDy91ckAtz47mZ3BLuMm4t9KGb28LdAJK9jdvH vcm9xZ3kPuGGYdTcfAbfw1/F38c/wT/H/0a4RLgS/h4RXhKGhN8I54RzIhF9YppYJK4WnxT/KInS BKle2im9Lf1N7sRpOB9aro21FsQLczCD7CMOfisehoR0zCML9DwM47AAZsXfUBUXg3Ex03xom5N4 +RTKKep8FPi78QuoDP8cbRUJB5aYP4768X+S4/zPyEXoP3Az9vJPcGuFX5IAehqs0R7yInkBT0XP kUqymDzIIfwRfhJ9BPq+Cd2Jr8Dr0dN4GE/C1+ByvBW9TVzcAnwDqow/Qnis4Jn4FIIWoGv5VvSD f20FcQX6T/Rp7Ee8ib8a7NMguhtG9Bn0IX4KfY2F+Odg3TiwRi1gZW4Cfb8RUavXBPNsK8xHL1iQ NeKb6Dm6okjl4hT+KnQK/R19KhwBjZoKlvRkrJ3/Ef+neHm8AGYYzDL0JMy7VehimDEfgZYchTiN XQ4zXQVbUgKzuh4tQa3oGrB6t8Wj8Qfj18c3xzvQr4D3azwOf437YEYMAkcleh3+bkXv4d0wDy/+ /7YKxFrREPoMe3A2LoH5MCxsEPYI+4TnhJ8KvxbHg7RvQA+ARv8RtFmFHixHv0Gfoa+wDGPjReNQ BNo7EdregNaQRu4omoZ9qBPmbC7Y8anJnqyHUq4D6T0I8/kozI1TYCcuRz9F72KC3dCj5VC/DOXU gZyXAvXjMILX4wFIaQWrnY/+DP0244mkG+rToaS7wWoNQZv+E30M0o6zdo0Du1CDF0NZX6FLUSvU MAHV4wMwAodQBVjWGu7fQN5Z2Iqm4kz8KPA1www1o3RUIfwJEzQuNic+kbRzR2GNiUN6H6xeqegi vA5aYYF+jCAnnovKYvOhDW9hjo/i37JW3Efa4tu5jbE16FfoKRgTnd8g1SCkVy/Uq6ZcVDl5UsXE 8rJIacn44qLCgnHh/LzcnFB2VjAzoPkz0tNSfV6P2+V0pNhtVovZZDSoiiyJAs8RjMZND9Y2a9FQ c5QPBWfMKKDxYAsktIxJaI5qkFR7IU1Ua2Zk2oWUOlCu+A6lnqDUz1Niq1aJKgvGadODWvTXNUFt EC+Z1wD4zTXBRi06zPDZDN/DcBPggQAwaNM9q2q0KG7WpkdrN6zaNb25Boo7YFCnBae1qQXj0AHV AKgBsKg72HkAu6dghhD39EkHCJJN0KioL1gzPeoN1tAWRLns6S2t0fp5DdNrUgOBxoJxUTxteXBZ FAWnRi1hRoKmsWqi4rSoxKrR2mlv0G7twLihXTcNWtGy5rCxNdjacnlDlGtppHXYwlBvTdR91QnP t1Eo3D6tYfvY3FRu13RPu0aju3Zt16JD8xrG5gbos7ERygBekl3bvKsWqr4JhFi3QIPayI2NDVF8 I1Sp0Z7QXiX61xacTlOaV2tRJTg1uGrX6mYYGt+uKJq/OdDv8+mH48eRb7q2a2FDMBCtSg02ttSk HXCgXfM3D3h1zXthTsG4A1ZbQrAHzJYkYjSNRdrO5zGMkVOsbv55yWLaouBMUIiotlyDljQEoU8T 6aNtItq1fCKQwacRA1e0FUakPapMa95lnUTTKX9UyLYGtV1fItCA4PDnF6a0JFPEbOuXiKJUT86r GuSP4tFwOJqfT1VEmgZjCm2cwuJlBeM2DJIJwU6rBgDEh+pBti2Nk4pA/IEAHeDdgzpaBpFo77yG RFxDy1L7kV4UboySZpozNJrjXERzekdzzrM3B0GTn2MbBWdUDp3/t1hdKdNXTYpi17/Ibkvk1y0I 1s1b0qBN39WclG3dwgtiifyJ5/OSWDRlWgOXSpIYSeVYLijl5eeJaaTBGOWz4V9kSt0a5UApWQLW aqPW5hmJZ6MaCPxTnkFJHsM0GD9FuRj4li3Zyuik8IXxyRfEL2idcRcH7eVDpG7hkl271AvyasEA 7dpVG9RqdzXvahmM9y4LatbgrsPkCfLErs7pzaMDOhg/sjs1WntTI3RiFZ4EykrQ1ANBvGPeAR3v WLCk4TBs77QdCxv6CSbTmqc2NhaAa0EHRIA/WKklNPU5gmOiNEiq9BQk8DEOqRIfw8gri0KMcC/i EFLAQfUgT9h6pnKkco71dOXskUpUBbj1HDzGFwdsAVs2PDAs+uc0buicLqBvkMYPQV1s5/QS7I0k pOLqw0iKv6sr5RURMRce0mB8SFdyyyKiDg+IvavXB3IgDx55KJ/PF3LVIuNEVC5UGVej1aSNWyGs kleqn3CWWSImsoI5VVF4ScGw2EsO8ClEhec1QXQIgiirui99ikqrMPjSI2o24TiRVwbxi7pZlIjA w+ZJNrrdPjRIWnSDHzOXvhdzeJBk6YpfwcVKr0KUIyQL8UChaAIWvIYfLPeEQQZNs0e8Z5rWnW5a 5xmZM72t5mMQSKW1sqpy9rDNXlFUORIOV24XCsPbr3l1e6GHAslaWbn91VcPiGTawobnlIhiiqBw 4/hiXBc1LKiLZoC6HEZcPNYv8+qReAwkde6AyE+kn0a8rinMPoEAB384kMJxwkuxn/aOHNoce41M xhX5v3wNz44NCEfO7SLayHG6f58V/5j/q/AWGoeP6Rcdtg2mH8p9bRwvpUhOd4rb6Qm3CW253eIm U3fue8Z3gsZGdZF5UWZjcJVxhX1loD135biN6dvS7w4Y7cHB+PGBDH+EQr3N64vMy5wXfDnz5SC/ LnNd8NrMa4P/lflfQTGs5puyMrOCFaZIsE6tM9VkTguuNrUFN5uuytxp2pX5uPqE6cnMFEVVTGKm GPSqXpMrU8oMqiYeuxd7dK8W6fDgDs9eD/EcIW0oFUbO6Kvwp+LUAgeHZmA6lDN9WqQY67D1asZ7 cB9o5hA4V3/hdV+FFXZrBfmK54u4G7v1FHfEXSflhHyF/pw+a9RKrHX4C5uGikEnvQW/XZAYxboF DQeQPrFx9vDppuE51jMAw13DqGpkXfh0U/hEAnaFT9jdFU1N67rCYbAOh1EmyCM1fQrI41gS/qk/ pSITxAMAYm/022nsmG6xV5g0e4XKgoWmfaKbjZBmqlA9NKRUhMd+GhPaoTsnqZNMZZllIMeZpmmZ tcHH1acyVdQE6oKa1uGmlGyXq7RkQlkklMP+yiITJpRqvFsIhYKZkuh0uF28CxwlkQ9qaBbWfHu3 33rbRZdEDv+lefvWL56CjZZbir2bcs01184sGjcRR9/suSmOXop9FnsHf5B2247N8yIzU+2Fkxdv frbzZyv++kvTuuVlmRWR7KIVVx7dveU/r8BgQXB8OHYFf008AFbEpxtht0J8AvLyF0WoZE9YP0ZF s4fHF3NlAWcKvyd2xaFD1BrcDdbgRbAGThRAZ/XrKiwzLZdKqw2rjfuUJ8x9wUPmdxVVlEXVLbvU CeZac61Fkq2KzWF2WBzWCeYJlostPebN1rdUwyZlk3dD+g5lh3dbuqi4HIrRYl5g7jHfYL7T/GOz YNZMRofJZLQYnSa3KzvF6sDNjj4HcTiQFsgGa2gym51INlNzkINMVhMxvZ2a0ydGxSHxmMiL2zuD WAsWB0kw4NRwQm0Gye6BzPHJ+U+NoLVp3Zkmqjmjk3+kEuZ+0zqAGKxAxfbCcJP5Guur2FaBIE4H D2ZyU6ktUMJGR3K53CkBrpAEgzYbjGdiQIPBu0nHn/+j95WXm69ZPRD70TtdC3+wovL3/7G6cu6M rOdOCkfm/vK6x36XNnHb07E/4qqnGwMjD3JzshqmzrrMKNB5fxfsFk+BjA1oj36RLPCSnC3a/QIu FvYLRBAUjqf9V5VsAwLvuY4jM1RkwAafZio26SbOxCtjO2wcv+DbDs+xNp0B5HTl6cQCQION9phN CyE+1J9eIcBy1e9j4ABT70Yg4gSwfuOLoefOQDLcxVed+5QcH9G4UuHI2dgLX8XWfQV1NsavFDPA ajlh52jRr9mWvj1wP7rf8aDrQbe4yXqNe6O2Td1m3mHd4diZKovpSrYv1ZHuCHizr3BfheRuhBul VdImabNvc8ZmbZe007bTt027T7rfcLftKemQ6zXXOy5beWqDrV1qV69CmyWRw5fARmQN4rNcmTk5 WS4JcSIJpRVYuJxBcsnB0NzMAoWA6Rmw2CJkEC/QLdzbihIK+b05pG5/PrbTPMUQsQ+Sm3StOF/P b87vzO/N78sXtfxT+SQf7I8RW4x+Y7GRMwLRQN6WnyVEum728GyqQ+F1s0+MgBxR1enhsHUkNlw1 DPrjZkpDtQZ0hupNU7bLLdH5LsKstllRAJ4OScxmehPMFJ1WMArloZxylzD+yt4rp+nm5/fsjz0b uxZWtZm4Fm8py40dqag4fvDgf/3XM3rFkqYFtx+ZU/gbR1D6YRW+Ba/CK/GtsXWx+366Z60+7ac/ jH1zbiQWjzsnB54qoXp1RWweWQUjY0W1ujnX8gRHF2CkWJFdPoozkYIwPBG5U1eVvxkf0PhinvCD 5O4B22NXUN+haXjk9LAVpkqVFeYKrHtNOBgiZdaUCeWlhDgddreLtL18X9/yxTcM7Vx5UVkwNu8k /uunOIDJ8aOx38Qu/cujsScfWEGtCNXws6DhFthzbtSzReGw47CHu1jAK4V3BGK3ZcPkRqlWquYW JLty9ktYSo6SREfJ5U8vTm9O70zvTRfSrZax6p42Vt1nW9nY0OmdnNvM32EmGFRZc7NZLEpiMOgl 387fu/DvsXn+ln3L7pmz+o2XH9m/YdoPZpT1CUdcgQ/2bx9stzlHfse/EmsuXFZdv8qkgmSr8XbS TvrAkpboAbq6EVwO3pmV07hijudqBCuiLeTAvD62hpnXptnWj5tQ0XDT+OIU8L6qSS7ejr2xk3Sc /PFPyG3CQ8iLfq3naUjDQTXPMsk8y9xokbxO5OFcTuS2p8AaYCcO7OEUSZWMnkGMdQty97mjbq4Z wJCbcw9ivt+JHYOkewA5qY/YDauXQSlSixAqwkuhmUCh53q4kNu+yFnl2OvY7+CaHb2OPY5jjlMO ATmsDs1R7OAdXt+mvqTOd9VFy8Hfmcz8HUd8aGJj5WzqR4LIrae9J5Cnapj5lkB6AvTfVmqBD1MX Z9DmoOteuVsMZobosmcLlpWWZdvIVUOGnLScWZ5lV19yVYVBufZa7ONDx2MLrwunpb6fXzpv+vi7 8JvH33o0thOGeWb8E76Qn4KCqASv01dJPjlNSHf5ZqXOSJuZ/XvrhzZlgrfWe2lohXdlaFvodu8d vsd9h1N/4Xs91SiKJqdL9LpyxDxno3cj2UYeFw+Kr4nGlyLvWUl6Vsl42zhTlh4ujGTpmbnw8KZH OrLOZZGs2nTqvRSbLZGL0jFKt6ZH0/+ezqenj8OlSIdUC/JD0xYF9DRbVUBPtcLD44sEQOQHeclo UsdR/YU8BiGbQaAYRwdFdxgyxofkPCXX1Og37jUSvxHHjdiom10Ro29uBEeaQS9uKcYYl+YFlrrx h248173U3QFj7C1trx4dGfB+1g03USMfTsROUEd/GGw4TADwaJlPxFa4cMJR6S9Kx+sahxORwygr PvR8anpkYVZrFmkKN1KfFUaQM4PtpxN+XROdOTngqtDlj3O43AFmzehoUg+mfEJ5wpBhOqecDjrU kFiG2+Lh37754mAdl5od+8xglbgZjzY9enTxA7f//JL6jrqF+AcTPssqb6i5ZHqp1UD+WHj/nY07 n48N3nTjJWnlXrm2tn/Hkpvr0rK1tHnTJ8d+ay/x5FROXlwSKs9qA6lsh4lWDtpgRU/qufcIWDHj BcIKoUfgiuwN5lXmTjuvKtR6k1uNcSOpMs41ErDiG/U8ScJI5Yio5oIRVIqVToVXfFvte+1kqX2r fb/9mJ23W1EIc4M4TzcQ0gvuKsFeW9VhnIaYyNeBhRm2smUVHAnvbKr8YGmqhkH6FSVU50FgqC7q hvlSBvPlgFoysRE1BejySaUIqwFIS7ThvthJLEy7oqa58dKLL5o8v4gP3XNFTdmXhdX7Yv8H+jgN LLfOLPdM3ZNDctSVZKV6D2wmnzRLimxF8G+3UhuOYK/HbPhz8t+EB4zUettXT6PWe3jkxIXGO2UK VxYhXKnL7nRIhJu+oGZS2oqdL93zxNS6Z2Lz+n969sOev+CncNHvYhlnf/NF7HTsG2q5q2Hu5YC0 HSgN//gwssbP6rWGivuU+013W58UnlBfUF4wDfpk2YFnkIvFWnVuxpOmQ+Ih3y/U143vqO8az0pf mUxpljSnDnrm1M22iMX5kvNNJ+dkK3RGFYNmN0Bysw4uob3e3GwmZo+d7h4OeVMjuNSOKE26FmEw My8BwwUJ6EljULfApOyjZxdWaPZSu50aQd5g99D5lmWQUAAXOQNzzdjsK8pYmtGRsTeDz7AEZN1k icje9OScCs8eZi4TTCWQ3TB4SbrDo+c6qjx6hgUeMJE9dMYz379qhHlRdmgEUDC3AojsyQlPYf8o KUxWtl9gDAgy7BW00f1uCqIDijqFRasDVWFE6U/QedjEqjfrICUzrdRMqzfrICzECmWbVtjigO9a Skd4HWoKYwFmpwaW1opKSxAXYNuOlMQuw02+xp4Jn+6P/fnGdux4axjbxRGdu65l6pIcbtPiyysr MZ5fdP/DB2/7AHZo4dgvYkev2T0Dr7lq67Rp66kuXBZbwy8DXbChdPSQXm6vJBFTxFGZNovUmGoc s9LkTj9Ol53uSKPQqF5qWpzS6G70LU5/XH087axyxvSVw2hD5lQYj37e4KTDkmKQLFbRE5C9GfY8 2KOEbDYLnXvKrVZs9fkbKumYnIH1vBLmnPUEjE9iaR+mKw7tcRi6jKc16KZ2oV1dkdLubveuSBeb GrGN2qickI1KweUuC9hwwuGiJmoCN7P80aUHe3Zhbmj1A5WYi526sXXFzhtaWm6PrSGuixfs2Iut GGH/ksse+rqWe+7Hex+J7n/gWbpSF8NssIIE8skr+pBoE4NyjtvmDt5rv9dxT85d+YrkqHUQ+wum w+ZfBD4KnjWdyRTzTItMbaa7DPfYn8g8bJSqg3pWTWhlZmtou327Y1vm9VlKeWi6WGuYZZprqQ1M hf11Vk6o3FgWoLvJsixJVAWbEvCYcoyZmZlBKStTH7feuMmx2bkhryd/h/OG/Pudd+U/l/lc0NSL b3Xf5Lkv/6n86DjRHXDpgWDEpaf5I34X/tCFXaVyoD771mySrXvSI9k+uiDpbptaVT8OF4/DRePw uIxAMQi+FAfYxLIoVQwCCZtgCj0A8YY3DdJROQcKyFYfagq7wszrOk3328MouSUuEzEWsQuHMicE agMLcaO7Fbe7z2AVuwnvC2SS3BSTkeT6lvKYr8011PuwrzZFqhppgn/qS4+GpnWpdAP/q4HcfFhe EzCTHXBk0fjxAX9WIu71sbieCsgVJjwhszbzXtOdma9mvp0pBjKNJp730X4cBJuCSql1GXAXVOHk 9GPxzOwIO7NI94FNwYlTC74ZnPFTmEOgE/QMg2eUKS6gBAdsNuLxUv4UOM7QBZcORbtK3TqU69ah ULdeVh5xU+/CrWfnwQPKtbj9bCHn3Yt8emZWxOLD9b64jyQ7z44x2OdEmEZPh9kpBo0mhJE8d0is zuvg09TEjEpW/A1dMdirLLnwADl8fshUYXQYKyjab6QnGZ8dMFQww4GBH7YoiTMJWK4jsKZnsTMJ OlnGHknQuxu62Bdjn33t8ivLsx3OmbFnLtvy/kfvv50b+8q2tKGjWEsL4ZcbG05/8d4ILgrPX5Sb VqQ5Hba6KYvv2/XiLbvHT5nqdwUznGkrZtVtu/23UbAju8GO3MNW8DR0v144MWVGCrFHuApTRUok tYabaZqZUpP691RlsbhYbbQvdi32NKadkf6eKmMk+qj5ECTq4uoug8FqMbsDsq8zA2fY8sxmS8hq xWz17kS99NwovSph18fYkHVnvmNEkiZkhbhCbbevcK3wtKeBCUFNKYk1m27cQAQ5tgB2JM9wwJLs xmLps6sPYxI7d7jh1rmwnLtuWbHsum3LV+7gQw/Wt8b+EBuJnYm9V7to5FPu8MDTDw088chehOMj 8ZNkMqzsHJqop8MGbCbhHITQ+zAOqfjPxCdwf4Zdwx1s13B6duKIi21n6OHkNdZXxxdLuBRz+Iq3 Yrd5hc+/dlC7dBM8noP9FYc62K5+oCQSEaieBrMZ1Ksc7ggSdKFe6BWOC4JfaBY6hVMC3yuAh0M4 JBPuPVg6o+g44obQKUTo9uUYxHi0lh+/d9TfTB4kJ+TG9BJ2VbabcK5w5OtakPdCsI8tbJ+Xhvbo BfZGsfH8CN4r3aecVZTOjN4MMomLGCc5I95ZXI1xlrPGe5+iONjAGnxsz2KQzBbolurOM5tCbEAt FuS7FUbZCotFemJhYNJZd6Zy9vBI5cco4YdVDSfPbNiiILaPHdFAoIyuCjCedvDE6HC6vx1PviX2 TfWBJc/Hvom90n8d9o7Yi2quatlxw8rW7Q9e1ohzYEU0Y++dxHquc98lax979PmHYTTRzdDfBXwI udCDuvtS20rb3QKniF6xklTa6kid7SSRLLRDNt7gQqrT4VAVMcURcjoR7ZPZpWtZkf0uHAfr7PPQ cXKBRdjj6fOQTs8pD/nCgz2qIaTIzL8B2j4Zn5Kx7HVXJSQAQ5A85aE2GEJCzUdPt5LSaEp0PATb r0BiQwYbX0C5OZOOtl+x7xLs9c+vmtGVj717Fy37wb67SV/Mc7xt8tyeE3jom/epfi2CflbBjPWi /9LnNVga7Y2uVZZ2e7vrGs9m7z3kHuNr1tc8v7O+4/lU/FT+NOVT51kxZWLKROcs+yxXrafR2G6U JtnLXeUebqOw0bJd2GbZ6X3S/oTrsP2QSzEzLy41QuFBuyNiLjXRFG9GxJQ8xTEdwTxSQY52mwHp QIp0oEOle2B/dAT8Bh6yNLeEaSosXkUmipgSzl6qFIDNbEP1t/MJnLvw6eEwqho53XQCdkojp6l1 DSeOCdY1YWYAk65CuZBUGepH8ONjfzYvn9t+zdYr6lfANjt8+tefxv6MXcOvfEQ+L1mw8LZ9Rx+8 rKPop6/gECwTEs5+gsquJ3YYP4bp2yVVBxXZIKrSIM7QU8UH8USDqnbhkJRF95J0wvHIa1y5IXld cWIE5j0sqiPsMJIeK4FBoocXsB8rD96Evfk9S8oXzSA7sPeNq27u1LrTli2i9d2GkOiFOWgkHt1g 4EJyyMDxHGxq4r26kjYpomqTJkcUumAmof5oWiGkwkNUZPVPyucqzyuqmkLSeKviV4NkHK8pRbAF WcW3KavVjWQT/6iyTz2oHFHPKF+rrr38HmWv+pryhvo78i7/jvKeepJ8wn+kfKaaNiqb1OvJTfz1 yk3qHiI1GNrIan6lskrdQDbzUg2p42uUOvVS+VKlQZU8apE5QibxEWWyWmWWOGLkRUVRncTHuxUp 6VX4Cc+pimCUpBLRbCxhhy5ErpdNEQN9sF6aDaaIrJtzIgb6gKQHdStFDDIHuoKJpCKZTpGqSrqk JhbUJlw0bH17mCakDsYn6wVQi8bLilLC8Q6O4wmMVQlHACVQDGfkCTGqqqJIsh+0bBCbBuh7DUfI RGZ+L2tKmF33goURoUTSpa0wa49uhVE4atAMRjJIJup2sLc6ECIdiFCJH7b/tBjT+B7YvoFjFQ5b K/9irfR5rSPrRtZV+jxW8PYhwXpiHTTeyiY4tPbCO6vk/VTKAvAI5PjxAwaNXkY1sU/Cj0DhdfQo DGN6CYgD2HYbfgF8Mgm/GBuOfRD7U+wPwpFzHu6Tr2v5677ZQgPo1H0ICT+jJ9T4Nt0ni9huV1WB IxwP6qiooDWCIiuqPIif18OS6JAkkaPXeqpDEEBIHCeqnMKB7ouSwPOw4CCDQZZkfpC09gszZAC6 XWLH2cREDBceZo85vffSrZknsTVLGDh4eO0VRYmz14QwPGEeVkmGyBSRrZXyqxx9ViZU6KCiGZii /LJfzokg5kshWC68ITFH2cPfK/bxUX6Il24Qn+Q/4c8IPJsr5fPpXBnSswDJFi9Su7lt3H0c7IPV fdwR7g1OfZk7xp1TuYvUqRzpWgcbMZBzI/PMxPgnA3ZDlUjvklIshiq+2OSCh9FRxWvgq3H0Usri TUDY2zEIFAwCEYNJun5zSmLvx5w46geyc006jvAv2e7DuWQxvmXkXVIbuzZ25SnhyEgP2T3y83PX kuiXsengH9D7nGUwkilgcMahd/Wqjfl4lXlT/sf8GZj1Aaci5o4LZLvsfudcJyl27ncSp9MRzMy2 p8iaIxsjkprTKfaKRKzLzdlPVTZxSkuPyfVAcaFeWF/YXNhZ2Fu4p7CvUNYKiwtJoSNTQ1pKcQpJ oUNacOGBbeI0PXkn890LCme8tz+9gh4R9PsoGHNBQe9rEnc0yftYCztv0ai6U9+tJIMkLmwSB74C aDp1dpMnvpwtkIyEgneTWc8+vX1Jx9Jte5oe3jAr9lHMhHNf+Un+JZfWzRr3m33Y3heeukDf/Evh SPrl9y1d+Uw458WtrUfXmWTCvxb7iaBcenHNIkUYORzbpBib5ky9PB+xW5GTwknw8+iJ9yP6onuE e+R7jfeaeRlLZtkieXI8m5SNdmmjbZNzG79T3mncZr7RvtOxw7nDvcOzzWeU7LJD8jntPofP4/RJ KQUmxVsgca6c/Sr4RVZVUzk1cX+RridPxvvSRS39VDpJt+b0IUzXFHoCTe8v0r57f9HEzsiZtwTG ATbRKZFyepxXOnpNgR32865R47SSn6zcOYBr8I2xLbGjscOxLXj8xwcO/OmD558/Tt4+fm9nf3hS bG3s/thDsQ58K17191g8Hj939hu6GrWAHH4AcvChd/Q525Sdjp2uvehe8RfK29zbhi85JVvJNeaa 8hx5rh6hR9kmyFKK5HanuN15JJ/LFqRc4T7hHuUN7ucGoQrPBWd1vpW+kn+K2ge6N/UkDoFU2JoO 4iW621PAy2bdbI+Y65Za8FwLtuhOT8QyiHP1THuBylm+MC9GXyBWlK84Dac5c/okbJH8UrHE0buG gdQtC84La8xZ0AjdiZ1IeAuANCU8qyZwF9idLRObO7l7Em30YmcCX4X9U2O//jz2n7Ed+CocwaYn W0tiv/c9tuHHv3q9b8M+knrZqU9BYEvwWnzX3h9Ea7tu+Cz2deyzz++mGrQaIX6b8Abojx9dr+eL VnNKRLBa7ZFJnkleXVjkXOF7WhIVVwrSvf7kcfSSjIlp4HDe0W+930j9zswUnKamYT/CIYSsSsDq 0lzE5QtYArBPsnq1x6YlnY2kXwS2dJiuLKgK+nnCOvJxUzhxoQV7UhxMnvkmtELKnpBVWsLTOSaK MJ1s5Is4nn/Gk319xxV7UmMxA079+K84o/2ZxvAI9uKryo1X973uHz95fs9V12gDX4882fT4rbOW xOzsEgSj26G3jWCXXKhfD1uwH1fgUlJqnYqn2v6A/44VSXAJWaTBtsomYExSHDZ7CmycMPOu0zlY hFSHU3UhZFBDssLcagXHFaz8M7caOUIu53m32olPObHzn7vV5/c9dNUZrqiwudkhuTy6f7TBPhHs DUghwsZfpCh+esfRlgfnpsdOavMuql1bGjsJ5vijvTM6d9w6chsZ/8SSspqd20Y+h05D/3dC/5ey O+C/0ZdKPhgw2ajFH9Kv8RZEJHByUmB1WiHuV19SX1d+pb6vqgu4Zo6YJI9SK14qbxCFQ8qH/DB/ jv9SFOZIc+QV4jX8TfwD/IPC/eL90v2y6uftYpgPC/livpQvF5nq+DpBPb9+wyot8gaBF+nLRnR1 BvuiGmCFvlL3CUVyhV/CUhssziHci6g+gada9cPkPGFrs/XMOg9MlIT2JLcfzD+hq/Do2ku79nq/ Eki+SEOdEtTVlNhFjq5hO0FbZuIlsbvA3Pwm9uX14I6cwRtiV4/8AH+wM/YMVL0FPNx7YTeSgycf RnkgoyabWgWOutEpuowRLiJHPJFgDZkuT/fUBI0aV5S3QGnO683bm/eo+IT0uPGgeNAYzTuWdzzP jPKK8uoh46W8D/PEPHo+UwXxXpYpSAFe8qW76MZUlejNjp7BS1abLSc1LS2UA3ZYtFhDdpu+pKzZ hjts2DZIanWLLzWUngZpHWm4GewLpD2XHQrl0F1sP0I5yZM1CvUJ0O4cIM3RqyFUQsjKieToky6K FOW8mfNhDmfJ8ef05nAoR8spzonn8Dne3D9Vjm7Gk6+gJK8kwKaHYVk8A65H5bfKytzExO306GrZ FabXOjhMjzfoeQ+73XG7mPLmnFfeb/V4C+Z2D624u7j2kct7HskFbU7PmTd5VWHsZEbVhOpVBbGT fOi2pxYuWrRw6eU19440kqU/KqycsfvuGCG1DywZV3vDfSPnYMzGgX4fZm+VdenBIqWYLxbqlU6l V9mjSCIWSDbPEQnJitvt47cKWBjEBboqShouRluprYeojTPXk07SS/YQnnjlkWeSbwTNazhAdHop CS4Fu5Wc3lZzInkDzK6xmsDVLaPvMOAPY7P5m2Nz+FfOnv1mCrRqGaxOR2F10sATqp2YUZexWNog bzDeKN9gvNF9Q6oiusVUu9uemmvL9eT6cjPkGYbL+IXKEsNq/of8VZ5u3yHzIesvTK9Zf2c9aTVz aaLGTkr9vgo6RbIJxq60AlGx0wXJXjc3BafQ1SiFrkb5rgILhzDWvEshOce+mPg1jSM+LbM4k2R6 c/pUbFH9anFinR8IbNl7warE3mY5PbyOvbuWWJ1gcRq20RtvUITRl1dgfSoL2GCFyswiZRF7+bcv HYlOegwyobyMqyJbmmJ7D34c2/fM0OGbf4ttuHRc7H3/072vfPTJi00vTCOpX40MLtn5Ml751ke4 denMj35ZvuaaM3+NfRP7ZmbkCLXdseXkBja29XqJWCzoAhHKEVfFz+UJX46tyM4RkUi8YAUjclp4 ACH64t4xzOFmeeXV7FWDSuvwcBNV1uTiAwkQ2F25M2grdd6O/3ryZGy5dOkHXy//gNrLENTpYXXW 6PlVwlxWZTGvsxrtyAqLEvHDfus0FvgH0IcY42blxxsSdY2wwhM1Qa30Th6DhpTagmXEEzOfBDt9 9qkPhL2/T+ym+UawNS60V/dIKe6UJfIq2LjwGKyMtUausXxqFUS2CNkks0k0GgzgnhEcciG2CCEc h0L+xdmO0UztgslkPL8WGfEp8KsvXIvOXzpesByNPeNZRy8Zxyw+bHLDksQ3xk5mzauY2R2mN467 32q6f66fZDzTNrH+hv6Ynw89+Ny0VTf8kEr0Dng8w84QF7AzRD0PrBM9MSS9QlQYEo4JXyQODrcK fZAgJI4sCRfCiduBQFYEeflkq8NjTwrXNXUxC38H9rJzwmRd2AsFZOlO2DOrJDTmDIQ/fwYyQk9A 2FtIlHn0fQkDjMkSPgS70VTdKeT6iiISfYj0IdMHLJzvDgDkacM036TI/TwWYfsvq0YDrPPEzvkU n5qJCgy/MBih9ad0V7oWUZFgcCCvIRvlGyJokmE7UpLvfqrYZGRlGRR3hMdIwSJSQXnoNAuzF8dS dbsBqbxBVRRCsAi4UkFPr3RPWm7EYPKzN7V4E1g3q1qlzmWTulg38KTCwNN5wvFHSDEoS69uMZYh rGEdZofX+GqfJ+ylkgjDtrcJlKDJy95dZXEmXjpn7BUYmsCuBMJN9A4w8eYpDqS46RV9Ciysz8cW 4pzXJ7lFs/WXOBAD6Y388eB0V0EByaAnfGTM6Eto42Gk0DNjOv5KvUJ6lagypBxTvlAEv9KsbFX6 IEHgRAkJPGdBWGcnxRxqApUQBVHiVSKFMD+qFbxX/getANsMfgN7ycxaOaoj9MUYnBhqUFYvfwjz sXPfzOJD0ESMHoJRf0x4FgnoIt1XL9Fzax52CEjmBZ9EuLGnBuL4w2NfgYvROmePJI+tS9nseAh2 yseFZ7+Z+RXt/fb4J/ydyXPrh+iN7ll9vKGiPPXiVGKntxCJE+yvJLGMn2yanFKWOp2vM9WlTE+9 U7pPUY1maAwaezORYjBYkDp6M2HNg1nCLjaN+Lv3EonT63+4lUDrwHZPa9AN9FYicYIt0DsJNo9g ZtuTlxLOlLGH2Nux97r+V2KxkcOXHdDtkZmbm66/YWXbNnA7T90ZOxn7e+xU7P3LGh8k+Y/N7dz7 9KGHH6KzKRMh7h2YTVY8+zn7GzzGg/G4Pt5qi6gYHhKWVfIVPquScsPF6sXGBtxA2nE72WqXP+SP Gb/gjxt5tYh/WHqBdCMZqXihriiKLOIi48PMObdYrUi9ld8LhlkLFcKUxOHnFLXUakk6QhTq2fSO 0WK1aJZii27ZahEtPt2Oh+zH7MQuyaWo17iHvsQRP64rUIZkdNMYDvdj/E9uKo1gi2ybfjh6U0kt aFO4y3oatGFd15kmmnK6cjjcRU/SRr48Ac9hCvG6UT8Vx4/pZsUTgX20WgxQlWTqP9Fr+YTriuhV HE4cUxCwIKqhwmA1QjCxS7ZGVFqGJ5SLkgCeB5YmlAacmfiWZUXj62M7ubWx1bf2pOGB3+M3Oos4 TD79RWzcAxLTxDsREugNihXM4Va9NFfIVS92t/FtRiHfXeGe4Wp0rXIJFe4JqdtT7xPuNgh+Gz2U SbFnW6yy9x/em0vpDWAtUBwgAZtdQ5q12EqsdIJo33sGc/4AZvSl5UCJ28VeFxHpXzBxhDKF0FMT 8BTvJOnPN1872FxQvmL29cseHXkL535wdfmMpZWVaxZMOSgcSQu9Ejv57wev71tel+/nXzlXZrYv /vm+fYdW2M1svQHfKwt66kW79ImSLCmS1S27lIvlixXpUmWx9W7rPbZ7nQ+4nrA+7/qd8yPxjGgw GY3QWSk7RTEaNNOb9OCV7NYz9dT61OZUrjO1N5VoqcWpfalDqXwqJtBjb7F3yMt5aZ999GB1bJ+7 zjQl7NEwW0rZlVZKwAYT6vwNidVMki+u3YFzDSm3Xr2l14dzi69999nfvrfFkQ5bk4+PTlxy5cq7 n+XC52Kxs+/f3djywKItZ2j/7oWRDEL/FPzvoEmcKHs5t8zbZcLB8oToiSDd39GjYrbPy1+wMMKV SLJDkmROJkTiFJ4QBSI8PSXm6SkxXyK+SX1j6LRXN9Qbmg1cp6HXQPoMQwaiGYoNxCAryULZaaV5 wYKIUsIs4xA7C9o9oI4RA5sYTaOSgBizzWxBQ4m3oeGz/ZpXv928wQQ050RkLXGuPvS8Qk/a2Rcj EpfS0xhV7yFDmdxrKGMdu8hXGJEXwEPgXFwJp3N8LXejvEfuk/vlE5z4Kvem/L7MwS5NjnCT5bny 7dxeuY/bL0e5l2RD4gsnpWURopeyL5wc101FJRGi0YfkKIOUe2CRKYyQhfBg1LUZGsTgIRNJ8hDO LY0jOdJkUirNIbp0OVksKQ6SKs0m06X7paelX5H3yCfkpPR3YsghudIsaZO0Q3qGiPR+c3SLFQ6j 0eNzsMH09JyuIdh2L9ZIA06J/W7kAKhCAffW17Xci+dq6Oi7YLU6ykZ/Bf0OzamDlgqJYHvyFsNI JPp2BIytQWXvE2g59M2D43oqyBJzkqhDgqhBRORgkeNB5+mVxXDVCLU/zAiFceIFCep7OIkowVaJ ODAmYr5AYFnkCR4kId2CZClbQbIozJA7FcyUIhuso+JL6o+BL4YhqeeaoZ75OHGK5FXPPTOqIxAS rxdSg5n4DtHH7DmcvHhIDjqmLz1pidcngvQrQb22Mh3PEOtxK+4QO/FWsRfLRAvkRiQd6Mhg/PF+ W5mBkpdZvZE5UpO0nLRLXeQa6WbpIHlBUtKJVSogmlRFipMjVy/tIr3qrYaz5JRkSX7Dhp5M0VNw WBgx3eThgNPFkZFF/PhzH3BTsYF7/uzH54Jfse+0CeTWhcMDTUstlV/KXpl9O/iRP1We/9WH+HBs nngv7AYxfTV69OvTCElTYnPQtG+/UP2dLxiXiJAk/AKKX4xm8evjw4DfDfhdYgVqJPvQFRQHuB6C n1+PZnLpaDvg0wCv5v+ELgNYDHA3qYiPkAp0E+ALASKAN0PeIsB7xH3oNij3Plo2LRdgC+SvhnA7 0OyU0tEWwMdB3jIo+3YIIYjfBrx30AA0Bgb/hB6CsJ1HKBPKuBPCHRDuhTTQWDQB/Y0EyUXkC24O n8o386/zXwhbxW3iWekieZr8qrpS/chgNSw0/Jvh34y68Q8ml1m3ZFveszZZv7ats/0f+/aUlpRn HHMdOx1HnSXOVc7trvGu61xRd6H7S89qz/ve93yPJCVYgkrZz5nQNc+KitAihMSvySvg3dFvoC3g PkMomb+aPTnGp7IYx7hk1J3EOdSArk7i9Lcy3k7iAspAnyRxEXnYr6JQXEJHcEYSl1ExfjeJK2gX kZO4iewjt58f6zKhMonDUAvrkjhBvLAhiXNonHBVEueRKjyexAVkEaJJXERG4aUkLqEm4VdJXEYe MTeJK2i6qCdxE14k3gglY56DuszS+0mcRz7pE4ZTaakySeI8cslGhouQLsqZSZxHdjmX4RKVmzwp iYOs5KkMlyHdKC9O4jzyyMsYrlD5y1clcZC/fCKJ03L+ksRB/vKZJA5lKnOSOMhfGS0H5K/0JnGQ v3JvEgf5q/OTOMhfvS6Jg/wNib6otO+mQ0kc+m56leEGSLeb/pDEeZRhOsVwI22b2ZzEoT1mF8PN VNPM+UmcR2nmhBzo66J28+IkDuWYVzE8hcrQvC2JgwzNNzHcQdtj/lESh/aYn2G4E9Id5teSOI80 c2K8XIz+6yQO9BaZ4V5Kb8lM4kBvmcDwVDqmlsVJHMbU0szwdNoey4YkDu2xXM1wP6O/JYlT+oRs s+iYWp5N4jCmliMMz6fysfw2iYN8LIl2FrBy/pLEaTlnKS4z+VvNSRzab01jOOuXdUISp+k1FDcm 6H+QxGn6GoazcbFuS+JggKy3oKdgy18CzkkxWB4NLUSrUBvA2agDrYXQjTajTpYyDWJdgNNnC6S3 M4pCyKlGa+BPQ/MhbSXwd6P1LNYGsA2oN8Czlf2WTBdQtADtVOBdA2nfrWXSGBrtPNUktJiVsz5Z p4bKoLRiNB6wXCijHS2H3A7I70AroKy87y3ln5VRCL3fNIajYEzrFl5QUjvrVwuEbiaDVijxSoBd 6ApIo3X/z+VHS13LSkzwLYJYO8SoxDS0ALAWFkvUvBZSi1gJGit7FeuTBv3vQD2Q281aS6kL/8ct +Ue6heexGka5kbV1JcTnQl9XMLnT3AI22h1oWbIvc1jOKibFFmjLOEirZzV1sZx2JsMF8OxhPUqM iwZjUYEmwmg0st5oTLabAfYwPUrIKDEGK1hbu1laBzxbWXonq2/zeUlpkNLF2tSdlNFaJstEvIWV 1Mlqv5LJfFTqy1gZoyOyJtnPtedbkeAYbUfXGNpOpoet0OLlrI6EPDaydlOJfH8fEnFKuxxq62ES aWUz67uSoBxrGJYL9HkAqQYuS7b7+8te+//Q929Lbz0/9l1Mv0bHclR7vq8HY3X7wnZNHjNGtCeJ vnSz+kb1kpaf6GsrpGxkPe9gs+5faULLBaPelpwp350vVKrdQNfDOGlrN5zX5kQ5lHINUPwrHSp8 SispLp6gLVzVps3uWNvRvbmzTZvW0dXZ0dXS3d6xtlCrXrNGm9++clX3em1+2/q2rg1trYXVXe0t a6Z2rGkdZZnEUjSaNGlxW9d64NTKCovHa7mz25d3dazvWNGd9y3JWIrCkk0so4AVtzBB1L5ea9G6 u1pa265s6bpC61jxT9unta/VuiFv0dr27rZWbUF3S3cbMK9tLero0jogp0tb3tGztrurvW194T8r 5HzaQvqo6WrZ2L52pTZ3xYr25W1agTa/YxnUMqd9+aqONS3rx2n1LVDc8vYWbUFLz9pW6Is2vmJi SWNHj3Zly2atZ30btAh6sKJjbbfW3aG1tq/vXAMZ0Cits6sdEpdDThvAlvVaZ1vXle3dtOnLNrOO rIE619IiIIOW0cVSO7s6WnuWd9PeblwFDRlTA8D2tcvX9LTCuGijjehYu2azltuep7VduQzKHkO9 9l/Wzshbae+72tbTXlLxfFtBQtrJsiazHuW2Qy3dbVdSWXa1Q62tHRvXruloab1QCC2JrsNwnB+X jp7uzp5urbVtAxUz0KxqW9N5oYQKwQ63wYyl85WuImNXsgtzulEPNoFGf3oBzbepK9hsHpuXSKll /N0X5CTTuB3cUe5V7iV4Hhibf0H6/3oe/+t5/K/n8b+ex/96Hv9jz+O8BW//p7Y9kXMJwFUANwA/ Tem5gPYfcy9mElh/AdVoWi2sBWvA4pwB+k8h7UK7f2HeKM/65BrR8b0lfpu7mGFjaRIpM1hsA1tx Lsy/MKceyqC97mG2gMpq8wXU35c/VlId/1SGHbyfn8JP5qfxE/iJvM5fxNfxFWOpvzd/4feuqd+m 1v5DfxIpdTSGxwPN2LxvU+vYLOgESXd8h+J8OrahP3JB0Ocx+efTLmFWov07OvNt6n9Xr/6bsvtv lzeqERz6l58DC3urTdwzaD8Egqzw1CD0cfT4R+eeGZBMJfogQLuDwX5XuORwfAiQSaUsveDOkt4X uafRUlQKyU/3L6LJTw/oNSUMlk5OwKLxDPbLiWzJUeKv9gFbEQSCLElsLoRbIeyF8BIEERr0NPoQ QhwCxz3JPdJf64cSHoOCLNUO7jGEoZWPoTchxCFw0PrHoC+PoS+SKTy06scDipFW/2PGlcr9GLgs 8LRC6IWwH8KbEATUAc+9EOIQOMAegbxHEOEe4R7ut/qt1Sr3I7QVAuHuRxZMf+RiiLt3wMpkc9+A JaVEr7Zyd6F6CARFudloCAKBYm8DttsQAfK6/oLxTIR1A6q5xAr0u6HRu6Ehu6HKPnhiFtchUPrd AykuWvz1/RYb4/thf3EkgQxYPSX1IIVNCHNt3FoURH5uC8AMgMsBpgNcxrUiE2unPmCxlvRCfVVA XsU5wU77uWrOBau0n6vhfPSdXCDr6Tcn6unpz80vgR5P4zyMxMKZUASgzEn9JX7tBU5nwt8xoBho +3b0W50lR7kbOQk5gKoXqNx+y1FOhZFVWU8WDiimkj3VRm4hdHMhiMUPbcQg5bWsoLX9UFC1jZvO pSEX5F3BpSMnwFoug8EnuIdhSvu5hwZCaf6hF7g7GNfttFCofkpCtaYMmMwlQ9UKR1+Ei3K3wADc wirfMxCaWIKqQ1wuKoZAQMZbAdvKlH4XYLtg1HbBSO2CkdoFjdoF2oe4nZBDf62jiLsKdXIb0R4I ewGnauXsB4EeZkhWbslhzst5QDDWF0CUGFJ9A4qZtszTb09hZJ4Bo7mk6ii3HvR8PZSpc90Dbk9J xwtcPuvKuAFPKmXo7Ad1Pcq5E0MDjC46JEe5NBAEFUw6l9Hv9Eer/RCniuxHmPySHKNCIm+R/6DD TX85mcFfJeGvk/DfEzA+RI4lJgX5LYXHq9PIR1DYUvIB2gsYIS+Qn4FL7Sfvk0HaCvIeOYyqAL4L 8VaAhwGWAjzSH3jdP0gGBwBA2x/oN7loZ8nP+sNFScSfnUTcqUnE7iqpziavkJdRGhTxO4BZAF8m QygT4EsAPQCHSDd6HeBBUgZehp88l4SvkhepipPnySHwMf1koN9MmxDtlyjY3y9S8Gw/SsTqi/wv kmfJ08gHpD/pD/kg9cmBUJbf8gKUh8ljpLs/3W+vVsnDuAGfBqI+9C6FyE4e6S+nhezpf1HzHyZ7 yB7dU65n6wX641xxdnFB8eOclg1b8nLtca3aSm4BA7KXwPwlu+FZjjQC2gNBh7CH7Ozny6PVI9An 2i+CeuHZx7BmeHYyDMHTej73FMOqyI1oLgQCZWyBsBVCL4RrEQ/PqyD8EMLVEK5hKd0QeiBsBGvS CRydwNEJHJ2MoxM4OoGjEzg6GUcnq70HAuVoBo5m4GgGjmbG0QwczcDRDBzNjIO2txk4mhlHPXDU A0c9cNQzjnrgqAeOeuCoZxz1wFEPHPWMQwcOHTh04NAZhw4cOnDowKEzDh04dODQGUcxcBQDRzFw FDOOYuAoBo5i4ChmHMXAUQwcxYxDAw4NODTg0BiHBhwacGjAoTEODTg04NAYhxU4rMBhBQ4r47AC hxU4rMBhZRxWNj49ECjHceA4DhzHgeM44zgOHMeB4zhwHGccx4HjOHAcJxsPcMeqfw4sx4DlGLAc YyzHgOUYsBwDlmOM5RiwHAOWY8mudzNhEFCbLRC2QuiFQHmHgHcIeIeAd4jxDjH16oFAeaPAEQWO KHBEGUcUOKLAEQWOKOOIAkcUOKKMow84+oCjDzj6GEcfcPQBRx9w9DGOPqa4PRAox/9cKf/HQ0Ou xQ0yrLWkF+cxuBV9zuAW9C6D16ADDF6NHmfwh+g6Bq9C5QxuRCEGoTwGu5Ffxv3+cku1C0zAXAhL IXRA2AthP4SXIEgMexPChxDipEzP5C3SXGmvtF96SRL2S8clYhHninvF/eJLorBfPC4SrTqVmJgd BdOCbmXPrfD8AgIsIvCsYlgViUC9EbCzZfAXIRHdNqx9kY/fzMcv5eP9+fjWfFytkIsxzyydhsoJ NBw36MbQFP+7EMpDOVPAMt1y6HO3vz80wT+IX0yAPD0M8HMIByA8DuE6COUQSiAUQMiG4Gdp+UDf oGcmi3wRQg6EAASNVoFc9PbcbpP1w8SEHx/4uQnR3y3tz8kFvhf6c4oBDPbnzAXwfH/OMn+1gg+h HOoV4YMwck8D3N/vPwHZP0mAZ/r9LwB4st8fAdDUn1MI4LL+nF/7q014EfLzlHVhEi6AflM4v9+/ GMjm9fvz/PTtuJwQpc6HirIhNw83oBMAs5NcWYmagv3+yQAy+/0VlFpGOXTgsYgKWPMECBRyA9Cg Lw7jBh7rBv+w/w7/58D+ZxAsqMd72iAP4M3sQbxYV/0vFvwIiKv9/dUqpYf14UASRik86H88e6f/ ASgLZx/y3+cv9N9SMChD8s3Q7p2sin7/ddogeVpP8ff6i/3dBSf86/2z/C3++f6mbEjv91/uf5E2 EzXiBvL0IX89FDgTepHd7784e5A1sda/2a/7c/wV2otUvmhiotzyghepBFBJovZxIN/87EGq44vK B7FNz5dOSXuky6Sp0mQpKGVKGVK65JDtslU2y0ZZlWVZlHmZyEh20Pd1wvSNAIdopUDk6ZNnuJXQ J0m87ECwTNAsFE3h6kjdgqm4Ljq0HNUt06JnFgQHsTpvSVQITsVRex2qWzg1OjFcNyjF50fLw3VR qf6yhgMY39IIqVGyYxCjhQ2DOE6Tbkylv+d9AKMbb049jDD23nhzYyPyuDZUearsU2wVtTXf82hO Psf8gqlnLJoevbtuQUN0X3pjtIQi8fTGuui19Ne+DxMLMU2vOUzMFDQ2HOY7iWX6fJrOd9Y0AtkJ RgbabAYylEMBkMlTkUbJwJ5MpWQwRgm6ELADXYACoFNNKMToQqqJ0fGY0h14V5tec0DTGE02Qu8y mnez0Rga0BjgrTkQCjGqoIYbKBVuCGqsYXmsIL8fSAr8jAT2wX5WkB+zyqJF35JkJ0nKzpOUsbo4 /C2NP0HjyB2lceQCTfj/8dM2NYwHxvds+Rn9AfXm4PQ2CM3R3RtWeaK9yzTtwJae5C+rh5qXLV9F YUtbtCfYVhPdEqzRDoz/2fdk/4xmjw/WHEA/m76w4cDP9Laa/vH6+OnBlprGgarKhuoL6tp5vq6G yu8prJIW1kDrqqr+nuxqml1F66qmdVXTuqr0KlbX9Haq9/UNB2Q0lX4rmsEBYlBBh5tTA41TXdbO KVShD08OeLakHuERfhIZwo1RY3Bq1ASBZhVUF1TTLJhnNMtMfyU/meXZMjmQegQ/mcyyQrItOBWd f32PEtGfZKuLBhYsaaCqEtVbvn/M1tMPy/ag6e018A/xbhbgbywlWv+9n+7v+/T09Kynj57weoTq ovkL6qIT6BeWJQmqaq5phLTC0TSOY2kHFGX6YHwIMsPQCNxNq6NYGNOfEdNV2HVJpE/skwjdKnQP +NJLOo7CCr4VAuzjyMb+IrZ9JhsHMrPp/qV7oKgsAWG7SmG/L1BC3z4sB1YKsxNQtxUAsid7T8Ge 8r7svoK+cpH+FtvjkOh/nC6l/UWPc6g7vH5UEIB2N6LEr5tBfQ/3p6WzivsoEg43htezrySg74p6 9FvsIPTzgl2fLHU9K757dEAS6euThcBIJGrvGWXrSTKxzB7GlCgkETv/+PYDMYT+L6XWRM4KZW5k c3RyZWFtCmVuZG9iagoKMjkgMCBvYmoKMTc3NTAKZW5kb2JqCgozMCAwIG9iago8PC9UeXBlL0Zv bnREZXNjcmlwdG9yL0ZvbnROYW1lL0NBQUFBQStBcmlhbC1Cb2xkTVQKL0ZsYWdzIDQKL0ZvbnRC Qm94Wy02MjcgLTM3NiAyMDAwIDEwMTFdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2Nl bnQgLTIxMQovQ2FwSGVpZ2h0IDEwMTAKL1N0ZW1WIDgwCi9Gb250RmlsZTIgMjggMCBSPj4KZW5k b2JqCgozMSAwIG9iago8PC9MZW5ndGggNDQxL0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nF2TTY/aMBCG7/kVPm4Pq8SO4ywSisTCInHoh8r2B4TEsJEWJzLhwL+v33nTVuqB6PF4ZvxgjfPt YXcIw5z/iGN39LM6D6GP/jbeY+fVyV+GkGmj+qGbl5V8u2s7ZXmqPT5us78ewnlcr7P8Z9q7zfGh njb9ePJfsvx77H0cwkU9/doe0/p4n6ZPf/VhVkXWNKr359Tnazt9a68+l6rnQ5+2h/nxnEr+Jbw/ Jq+MrDVVurH3t6ntfGzDxWfromjUer9vMh/6//bsiiWnc/fRxpSqU2pRWN0kNsJVCS7Je7AlG3DF /ArsGJfaWti8gF8YL8ArxnfgjXBtwa/CTmq3jEv/HfNX4DfmyFl75iBfF2R4avrXOEvT38BZ09+i j6a/w7ma/kby6V+jv6a/k570N1sw/S38Nf3tK5j+Fs6a/lbOpb+VPvQvJU5/h/sx9HfoY+jv0N8s 9w9Ps/jX4OX+JZ/+leTT372BF384m8Vf4vSvHZj+DndiFn/Jp7/DfzH0rzdg+lvxoX+Fuyrpb9G/ pH+1kWFbpgpjh3fxZ5xVd48xjbI8HplhTO8Q/N/3NY0TquT3G8Y63kQKZW5kc3RyZWFtCmVuZG9i agoKMzIgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQ0FBQUFB K0FyaWFsLUJvbGRNVAovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDQ5Ci9XaWR0aHNbNzUwIDcyMiA2 NjYgNTU2IDcyMiA2NjYgNzc3IDMzMyA2NjYgMzMzIDMzMyA1NTYgMzg5IDMzMyA1NTYgNjEwCjU1 NiA2MTAgMjc3IDI3NyA2MTAgMjc3IDYxMCA1NTYgMjc3IDgzMyA3MjIgNzIyIDc3NyA3MjIgNjEw IDYxMAo1NTYgODg5IDYxMCA3NzcgMzMzIDMzMyA2MTAgMjc3IDI3NyA1NTYgMjc3IDYxMCA2MTAg NTAwIDcyMiA3MjIKNzIyIDYxMCBdCi9Gb250RGVzY3JpcHRvciAzMCAwIFIKL1RvVW5pY29kZSAz MSAwIFIKPj4KZW5kb2JqCgozMyAwIG9iago8PC9MZW5ndGggMzQgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGgxIDM4ODQ4Pj4Kc3RyZWFtCnic7L0HeFTHuT88c872erY3SXtWq92VtJJWvYK0 oN4ASQgkQICQBAhQQYVum7gb27HjlthxXFJwjS0EGGEnMcklPThOgu00O/jeJHackNiptrGk750z ZyRR7Hvv8/y/5/v+z5MVs7/flDNn5p13Zt6ZM2cZGxnvQwZ0EPEo3jPQPXz8M987ihD6EULY2rNr TFSfuEcL/BxCSt3m4S0DX43/Yx1Cqj8hpPVu2bF3c2t3z1cQEjQI1b+6ta+796Nv/82PUCekR4Vb ISAy/bAaoTVu8KdsHRjbc0E8yIF/EeSZu2Oop7v7+z//EkJrhyH+wYHuPcMXUt4OIrTOAH5xsHug b7hq7WHwZyDk6hseGh1DUFCERu8h8cMjfcNPvmP7DfiPQfZ6CMPwRz5wPVYRP8crlCq1RqvTG4wm s2Cx2uwOp8vrS0hM8ouB5GBKKDUtPZqRmRXLzsnNyy8oLCouKS1btLi8Ir5kaWVVdU1tXX1jE/q/ +KN+CKGZuy8KWoG2oVFo84PoRnQ7uhu9iH6FNqHrgN2PHkGH0RNoAn0TfR+99n+yHDN7lQPIwJ9A KmRDaPbD2fMzh8FNKU0LQu4Gn00hzofMCrN/viTszzN3zwozUyor0knXGrmfQujf8PTsh1wF8c8W Ej93E3CzdMV76odmnp157BIZtKA1aC1ah7rQRtQN9e9FW1E/SGY72oEG0KDkG4S4LfC9GXwbIFUP pCJ8PtUQGgY3gsbQONoFf8PAR2Ufidsp+cfRbvjbg/aifWg/OoCukr93SyEHIGaf5N8D7mp0DbTM p9C1EmNIQ65D16MboNVuQjejWz7Rd8scO4RuRbdBO38a3fGx/PaLfHfC32fQXaAP96B70X3oc6AX n0cPXhL6WSn8AfQQehh0hsTdCyEPS4zEfg19Bx1Hz6Bn0XOSLHtAalQiTC6bJRkOgwwOQA2vW1Bi Kr/dc9K6GupO6nZIrukeCL92wRW7ZDmSlNdBSpoLbQeSy1WXSOJOqAPl8zWivnul+s+HLpTKJ4Uy eTy4QDKfl3yEXRr6cfw+9AXogY/CN5EqYV8ETtnDEl8Y/tBc2kck/5fQl9FXoC0ekxhDGnIY+GPo cejbT6Kn0NPwN88XMorPoK9KLTeBjqBJdBQdg5Z8Dp1AU1L4J8VdKfyoHD45F3ISPY9eAA35BjoF I8234I+FfB3CXpRDT0th1P8t9B/gJ6mo7zvouzBC/QD9EOaqH6Nvg+8l6ft74HsZ/RT9DL2GjcB+ gv4A39PgULy2d8P6rnVr13R2tK9sa21ZsXxZc1NjQ31dbU11VeXSJfGK8sWLykpLiosKC2JZmRmp 4VBKMNnvtlsEs1Gv02rUKqWC5zDKqA7WbBQnwhsnFOFgXV0m8Qe7IaB7QcDGCRGCai5OMyFulJKJ F6eMQ8rNl6SM05TxuZRYEBehRZkZYnVQnDhTFRSn8JqWDuC3VwU7xYnzEm+WuCIseYzgCQTgCrHa vbVKnMAbxeqJml1bD1VvrIL8juh1lcHKPl1mBjqi0wPVA5tIDQ4fwanlWCJcanXpEQ5pjOS2E3yo urt3YkVLR3WVLxDolMJQpZTXhKpyQi3lJfaTMqNbxSMZpw7dNiWgTRujht5gb/e6jgm+Gy46xFcf OnTThCU6kRasmkjb91s3VLlvIiNYVT0RDUJmja1zN8ATypAQFA/9A0Hhg+f/dHFItxyiCgn/QISS Ks6JCeIZR1A2KCHULxAgZbl1Ko42gWfiYEsH9Ytok28SxWPRzgluI4k5xWIc7STmIIuZu3xjMECa qnqj/G/XVvfEwU1iZgZIX/oXgn8QL07w4Y2berYS7O47FKyqonJb2TERrwIS75brWn0kOwbpuzdC JfqJGFo6JmLB4Ql7cClNAAEiaYP+tg7pEvmyCXvlBNrYI181EauuIuUSqw9trKIFJHkFWzpOorzZ c0fyRd/RPJSPOkk5JpyV0Cjh6kMdvZsn/Bt9vaCfm8UOX2Ai3gni6wx29HWSVgoKE2nn4HYB6Y7S VVC3S1KzxKTm6pBG7OB8fCdpLQgQa+AruHQRRAjQXJKXtOjSRWIH9iGWDO4ipyDsonzAw4cq60gU Ty6trPMFOgP08wlF8sllUoYmNAvyEiBgrkz0Ph9bNJqaFChNrO6rWlDAizJVygWUc7tyOTkiC/nG cIWGNGcdi+JD0HMhjINspCDSim5xAq0QO4J9wc4g6FB8RQepG5G11L6NbcHGljUdUmvLWrLyIh+N L6a+CRSAaObhKkEHa6I+1qySv1byz3nrLomuZ9HiIU2wse0QyTwoZ4hE6EFQaVW4vvvWYms+dM0a GN2CNd1BURBrDnVPzR7cdOhIPH5ouHrj1lKSR7C+91CwrWORTypra8dVvn3kVlbUiBtXLs3MgLFn 6ZEgvrnlSBzf3Lam46QAdv/NKzsmOcxVblzaeSQF4jpOijC4S6EcCSWBxCMSD8mpFTwaKb3vZByh g1KsQgqQ/D1TGElhGhaGUc8UR8MEFsZBmIKGxaUw8oFGcm8FEcNwWy32kuY50Ln10MZO0rmQE5oS /uEJHCxHE1yw/AjmVIYJXbBv6YQ+uJSEV5DwChquIuFqUAzsxCAcMiYd2hiEcQoUqgP5MFVFnmQp Ts3OruwInPGd7wyAqq0Dt6ZjQhuFsV8ZaoB0tcRthODaiYM93aQcqL2DXKsO1fd0gtqyDCFJ/YQW ctDKOUCKGukaoo5wUQ+0DTSgdP1B8Ewc7JzojJKbdvR3SuosTKC6YCk0O81TGSY3inUesgZzpb4J XUEXuomAFsqG2jpoiA+8cLNOKiS1AUreE4Sono0iSFuBetpA1elYqvPRkD4YEhXhPsnpfHIkItXi Q3qjbkKbBRnCP8L1WaRLKkPqzk5aeMl3k5wA7i1M6KFE4QWilC8A6UBUPSkL/LsJikqSfpNk0zKF WoN7YGQhhZZyUkP0hDFU3w2DP71eDyHBYnaxhowRejmP0zRUTWpuALnzoZVTs48F9wYWfDIzgmRy IIqJfCdBsVHnoUsDJtZGMzM0l4YapeBDhzTGK19A5aUxziEJFKth1oCESlihjfI/hRUVj9SoBDWj ZWjt15ARtyInKsXHjzuqqjSZ6m/gSugIIl6JNAjjyrhZwRlPeL0VwRMFqtt5S/0UzjxWob6d41DF 9BvTL8Wm3zhvLYmdx7HX33zjTeG9lywlsbw3z76Zk40tAYvk7CZOrbargslZXEEkXJiXl1vOFeSH g8kmTgrLLywq5/NykzjezkLKOeLH/E8/WsMvn1ZxVwcrVuUpk7xmu1Gl5BLc1sxFIaFtbWhRVqKa V6t4pUadWrQ0uXFHdfIv1ZZEhzPRqtFYE52ORIt6+ldK04d/VZouVCp2XLiHV5Wtq0jhP6fTcAqV airJ7UkvC9SvMtsEhd4mWJwatdViSK1aN32jI4HkkeBw0Lymm8n4MHte8bYyAOvUCDoQ99rdAm62 C2b4shvhy2qAL7cevqa4vLhWRNnSvkvS1OzbRyEl4LtHzRL+6ahRwj8fNUj49lG4KukFLg/pkAen TZrbglM4ekS5ClWcrwDhvhkln7NdFEG4l4hKnZ/FEYE67Ekcka/i7Ya737jnrldurWq454177jh7 e/XxyNrPDQ9/bkNaeM1nR3Y+sD6Vu+8LHx3ZsPrwPx+5/8NnN6z6yt+eGPz6rctW3vbClpFTtzav vONrMEYmz37I7+e/hjLQf51Ewdn34y69ATf5NeQ75MdJlCRhJ6kZ1MAho12ukU1Gq4wWiI8XASmy 4LAFRwScqsTJqRCwOBmnJOMAoRUBnBLAohQq4hQRR8x4VwAHpmZfjmstjrqAaMPN4Hs7rgWhBkQz 9RFJBkj+BrgwkFof0Hvr9U2oosJaUoFjktxQtCsnu6urK0r/4S7CpQ/4o1FJU7GJJ4KN4Hnhumyu Ipusovsxx3MzZxRGb2pSUqrHpJh5SaHEGpvflRi0aRUzCv4Cp7MFfK4ki5p/WKHVGdQfPaE3aXiF xqTjVxusWl5jUHPwpZ32Ggzc77UGDc9p9Ai0q2v2PH8//wMUBevtmXh6rLCicKiQt4mgKjZSS5st kCFALTOIimUIRvJlFnBTxhT+4HhV9MtRLgr1Pw4po/mKqdlzRMcUso5Jfr2Ebx8jFymmOF08EMj4 7kHFnQrulAK/rMAKRULs1+EG9zsbTcMmzqR9J6EZevnZLlBB6ONdO0eYJua+HqWqCMFEHbsw9O+A rHtETg67SbVQPx2RQqnDq/n7I57pyaSa4ZZ4b33MoNareI5X6wtX7YwPPTZSumjnIz3b7t2YeZjf u3vxuvJkmO8jgcY9q7IcXofa5LEabWaD3uO2le+b2jd28lPVVaOf77Bde09WU18R2Ru8f/ZD7jGQ YB7qOTZcgMPmqdl/ktqbZf0DfFeqPSFEPOYp/H7ciuKgUShugS8ibOTVTeFQXBttCJsdYr2DKlEJ 6Yenoc5SxUukStNOKFXMwnqkhVXZIamMinuMU2k1GldiisOTXVAa1FhFj1u0qVXWBJczUVCHlpSW JBoDKYkGBY/5Tc4ki1ar1dizmoqmJzR6jUIBX/z1Gr2W57V6zXWFVREzr9HptCYf0Zl1oDMVUo3j aCIumpf6l8aW8nqtK98A9c4nSpJP1CVf0pT8KfyvuAlFImaEDYgMXKiUSAKSlhIRGWXUU5REVTrF aeJ2i+vbKF/I58pO5WOUj/Pzs5akT2Ff3PxyMk5OViS+k9Ww+NeGZgWKVcjact4i6cz6LqY0p6Pr u0piAlUgkN/6rpBdBVoSDhcUqOa1Ja9AHsvkEIUkTDUd3Zx5uYVFfIWQ4PP6TWWfaakdbcksH3u8 /4AzZ1nJ4u76HAN0LIXat3TV5vzum1eGv3x7Ve9Sf+eKJUOL3QaDSmUwrKmoCdVsXtI03BCqyV9R 4EsMJmoEj9mT6A0m2jLar1552pVZkVbTtrSK6hMuV+5EDhQ/UeFa7hpy8UjWHCSrFpLlhZhqIVCp YzqhRknURq46KEvoMv3A5UwV1DbR7RGtGg9rb2WxxkCYQUO0eg20sch/HxWgW44kwH1OkckEyR2c 3P8YuX9EnmUi8iwTkXt+RC4g4DvkgsgUp48bYyZs8rzlj+uMdf6UKcwdszXwf8yBvI9pjXU5MKKo jmilzh89L33hmDz3kB6Qm5MduriDqxx0gg8mqxwLhgFe5JRqz6LGjlj3fX0FS3be3xltqSpwa1Wc 1WiOLGov3X1NIN61qGRVRdSg1qn5L1o8FqMnlGiN7z86fsOL+8oEb7LbZHNbI/5AauDEM6uv64im RIMaW6Lc2/lHoHVy0d5jFfk43TY/69CmsMltZJPbzEZ6uytJr4MwPekaetI19FLX0JM4HYqTJk1K 9wgggROZDSk1niapISuIUuNYjPZ+YW4MWNCsUu2vMA5YCgsl5B+B9pba2Z1Vn11+oOrS5q+9s37N /qbAnBZw5ub1VSkd7dO3Xq4X079rrF+8+ZZuMgbcAFraooyBlgbQbScqgsuDQ0HeKfdnpywDyW+T 8BxRE6esJk5ZaM4XuJ0oATmopBzyVQ451sFE6gAxPafzx+FK/xQuP+YR6iX5vHo+Kuv6WaonV9Z5 G1GTMJh8ebnOy/XfllFWGiXOMz/wqWmF1Ti7ND2tBBxp+cDsX7gBxVdRKVp3LA1ZgplyZTLlhs6U i58p94lMuRqZpJENLmPm+WBdovG8qy5nCiuOqJslK+sMGeDzaOlzz5ymSq6g5ZcKTQcnNrrTaU4V DFrIqERDuQGNIKZluWp644lXm61KjVFzFavcW2RksprfKqp1pSTYNUqtUrE2MVkwaVWhxtFlnElM sXkt6lfVkEqhNQCxeG0p4oyua4NWp1Wa3KTe98BI8CDYY7norrgfVF4fIVocIfoc0ZA+LqlyRJC6 O/7gOTqn+WWp+GWpAL4vNSYhRCx+1rp+2X6Dpv0grrVl1kf0Sk89jA/Ko6ZmqZ3PSzMhM0ijZ2l/ uLgrsNF8vgdIQ0Jh0VwA/6DamuhwJVpUzfc1E51X20U3aILGFavLLt9frbb7QTGs2jk92N2+bNGW WzZxyWwenP778g2VoY52bpyFEPk8jRB/AFY4GWjXEe8VBsR36QBIxTA/MHKWuFZrE20i0iLvFNbE jQfD+FQYvxzG4bDKM4UNk8YWEKjhiGolqlhoDcVAGjF5TpOHRS4YAGWxgIoHqCEEAZZLKH9AoTNq pu92paW5uM2gJUqiKjMqPKkxkuYHvozDGqNOUWv1WTX+iOLaiF9j9dmtPotmZptWSLBZvYJ6Jkdj kayA4OyHiquVdpSMwugLJ1EKTAkGaM7glEzCpIH10ignEx2xlL2EhQTybZS+DdJ3PBWHSHQGCCcl GA793aA3uJMTgzojdioMyCAYuGeDLwZ/HOSDhqDBmthqbVe2kzFSEkZXl8VVAnN/iSVPOJ9ryYPF SlS2slE0GnI6qXZE+ABPTO1wuLAIU+PapQ7yAcW4Bgshvz8E1vTQ9O+38TpbMCExZMYaPKkweiJJ YrrXpNiPf4O/tdjpMyl46DC4bOb7WhCc0uRzKiaJtc1rzPrbp/cT2TwNs8R3QScSUBracyRFJWuF StYKlawVKlkrVLJWqIhWuCyJZImXSCylRMFgxE2JIsQlTnG5k8gSmsK6o2BTwFJNf9TRYiAykBfD ZxdME0QvJFMxuGBukLRDIS3bghYyfPDfje/+6p67tbaAxxOwa9K92JHe3D/QlHa8bHVXxsOfX7al JoW/u/vBwUUzWTAcKpVkYHwyNVntqli3d/Xybfmm6Q9Sa3tIjYm98AbYhGSV+ng8oSINp1pxGqy4 jDhswGENDqtxOo/TOHyFlem5K65MyWIhKabDugVLXvHiJe/znA6h2VMnzKh5GLoi9Bo8aW4A2XBH lM3yMrZLHi5icwvZLvb571a0/Bulo18dGfrKYGHJ6NOjgEXP+Mq3La/vrwr4KrYtr9tWJeLfDZ68 sXHp1cdGABsAD9Rfu6kkf8O1zQ3Xdpfkr7+WjBCgDe9DT8lDm+KWHDJQZpPSxwgL6GRx6GRx6GTd 0Mm6oZPFoSO6YXBEWgM6wdcqzGv/3MAITQ7fdEQMhyP4ClaBrPQwhagxdjr599X2ZF8ww6meSdHY Ax53sl2jsSe7iTLgH6gEV8DrhanSaJ1pwy9Z1Alk0FAJOu6m6b1qI1EHo1rxS6YY09/kKmAOUSgh wOh1Tc9OP+C1gWbcD5rxClhM6WgxuuE4mKe6QKFct0K5roVyHQvZnFBI5kyfI0paOkraPEoEFiV6 ECV6ECW6oUUOXWFBQKHMhrniuXCDr0ZoKgEqNz3pF64S1i2i82uAuWaPOC6XEBUQUwS1xSnNs/wr eT13dkXra2oiMCI67AlWFZtiUxvr6lI33bo69RlH/qq4WB6vjlQdqCzvKPLgt8ZfuL7GEi5NGwSR KBQgo4W2VFpxUFh23cR49bW9i63pS3Nn7m9bvahnP+hLy+x57iXoS/Xopbgh1ljRuLzxmsZnG5VL ZHEtkcW3RFaZJcQ8t8l+QUY9QfzruD8lNyXX4CNzto/M2T5BIF968gXX+p7H/yRdKK4jCzNDHMIN kF08DPlVGJ41cIas14t0f7SssGy0DFv4IkuRxbnoV0t8yrQG59tU0KCD5y3SKCycF6QONzdFS4Pz vG0mC17B+hvdlctSzRv084tb6IMq7qW89dcuy15dne3UKVR6tT5asao4vSrXF4mvaG+JR9Ja97em 1JWmOdQ8z6t1Km1yYX0sPZ7mSI23trfFI9hUvQPW0y6PPcVvg7nLJ/qswcJQOD/VnxwtX7WooLs+ w2B1CAazU7B4BLXT47QFsxMiBalicvqilfJIrtDDSF6IqtBn4klClqWIGD1FRHZF0uhcRLSyiOhn 0RSXdyItDt60CovcFha5jSxy21nktrPM7U5xlsmELDD9Nc8Nx3E87loMI/vxQItL7uF0XVsy18kX iFae+qWJLYu/bKh3upJ4IlF1Eu+yOZ04PxwJh+WRX6FX2VOSvAG7XrHbkVm+smyUTQJpLmzLWeIF 8zASXLquRMzPTLWPmTQz01UrPBV5n3m8qmep3ytpsVYw4Jz81RXB6V/MTQ7PRPxK3li8aqhyyZbl pXZTdNGynJn/Sknkb2jqd6lVM02BshWg4aHZD7kblXvQItQ76RTIslJaTvpkIfnYOOCTpeWTpeUD G3EyOz1EtuWsggUMCd35wlpv+Hx2ndgk1EnyyiWDfvR03nt05Zh3en7nUtKrhUY0k9elpraCuxHG MZXakZTmC+WLpu+Dwae0mr+vsVGT8RpBIJ34mmDdQENwaYpBwyvNNpdJqdVr3XktpZuoHf3RH+eW FA5qaXetv2lVmtFssPkQnRdUUdCtRejpuLCxfLicM2Znu2IxXZbb7ZWnBa+sP15ZNF5ZIl5ZIl4y LSSl5BgMOqKHOqKXOtLZdaSz64ha6p7nLFIX9xAZpxS26N0uY8ydk6Xyp7b425khVQGjpSUPZhOm YWBHCXPMUrI4lpdHLKsFK6zg3MblxbonGVY4j8w2krBVUQ0Y166ATcPN5PF6R6LdkWTXczO1WGOn q7EM31YxO8WtxbuV+Ea91x/2DJh9NoN3TrG2XLiHLNYV0MsVOy7cPxd+OD3F4E31fbSaPwwraL3W luiYnUVmWJ2+qdzHhRE5I6hCHjNiOyuwknEg20nwkx2TerZjMt+X/kebJfObYzBGIP4E/qlyH+Tr RL64URd3XKP8jZJTHhScoJJveM904Zj3DKghmVzAFlWrmRGqxkkwyya7E4ImTnNcY7T47E6vnlff rmwHi1KhNlq0f9AZ1LxKJ+hPsN0HmBly0T1xs5UM4jbyJW9ESAOOTVaY+f2Huf0IeaOCTK1JejIN 0P0IojJ0e0LamYD4E/KWBNmQiOsyG9I9KfVsT8Iq7UnKexLM2iSzKmK2xyduTDj+u40JtkXZ9Nnm /2ZjYr4NdrcvX7z5lo1sNdYItpYX1Z1EDtqHHLJIHFMft9HAWY4hrbnVQZ5/0OUWjp1h5uKC9RWz EqT1VCOsmbTTp11pcybTy2RB0Gj32bSwenqG6eiFR7WWBARaKdnIklYK5Agl8uAViMwx98/cw78C rUospIPEQgoUXsEKpCPivDlItpUc1DiSzCQ3iaZ20hWto3ph+cdaR1cyjj5uc/mKxtFd61OrlsRT FjSi3eGzqtOamlsyNx0ixlGeZBzVRKr2VZZ3FnnxH3Z97bpaITk/OFPObCLFH6AtYRml1+5NL09z NF3/7Hj1p3oX2dIqc2YeaOtY1HuAtHAniOw1/gSKorKTSIAlo5PMwmFpLo5BfL62SstpQxZYBBz1 1Jkj0mKgEUkTQy5YJ2e6iJ0816hkxC/CAXkCkNbM0qSJCeVeU2lMmulXHT7yKAXfPnONYCOtDvOn BUw6CJsZx4dh/ayqsfnAQA4km5xOj8BtC4Rg1axWmZwW0eR2eYXp+9SCNOavnf2zYo9SRBXoi/HE hASzm4zabtIF3aQzukk/dJM+7SYDuxG9GMFiJB7ZGOEjZnlKMMvqbJYf6ZnlhdP8Awcu91gsH+e7 Ya14LDm5JFb+AtYhJdLhtMmSNvsUzjgSkx7yTZ+VNsznN1rPdnWdZuZF7JJ5k+2nXCQqC9utkudN xR6yb2YoXn/dmu1P7qqo3vdE36L9BTNnLRaFFtbMn9c7rTpr6bpNvTn3/elLq7qeOH9nw7V91V6d Yr0t0aYJZ4WXHfrG0IFT11clJuK9ySkgVI1GSLDO2LzhxGS3oevpd+954MOJbm8wzZsMPUp6EiH1 KKXco7xSj4JRQHEHzKxW5Ee744kVAWwjcrYROdvIY1Mb6TI20llsL3C5cI33fzjdvgBzqRa5sWHS 1ALWSPiIcuXFj0vnFpn40m2ZBQtvxR2rvvLu4Zk/k70YHHr87S+0HM8fevLGZ48ceHKkhHvg8Qtf aaX7L6u/9Pb9/cevb/jIUn7wm0R/Pjv7LzyIziE9ch1BKrDUnyP7B1oexuYzYPZ8kwxXC7Y7B2Pl i7KIG6iNZVWDk+0O3AFjpAOtkJ4wPCs9YXhb3uGX6v+xTxyILaGDFbeDmBmtkuWA2WRw5ScOHWxl qXUEXGSYnJ/U59aO8uysfBlGwRXonbiPzm2kfcICed4bcZPv4VZcc/l8dtm8987cvntSkpPsLCTl UmtIsoskk0igYyn+4MQKsl25ovzyDTqa7WUbeS/g92H6FbBqsrEhhcyPxiUN5TWZxfWZTXPb9tKD u3mdKJEtKktJLHrRfPnJM+Z/M4W65LW88mU6k9o09oyqrJLRamKkgq2ldmZUZpWMXT6x3lFf3FmV LWS2NNamrN5V75+fYoMll0yxl4dcNOl6Y0tSc6rSbTD5NkFvDMz+hf+LMga9MSz1xgj3EJJ3zvlf K76KlqDFk7ElAnlWFU1KiprJhq+BL4guqROi58sK6mBkUhwNNWvpnu8ZGLBxLPf1N63kAV4uGY5y nY55cQQW7IE7PmnTnH88yQkycRERzcQWbIV//L45f8Ln/eiz89b7/I64NTFg+djtc9kWJM9F9MiA 7GBlcjuPQe80EDvwjGRm4oXdE7ewpw8zzyrOyA8bZo5APhvJrrtyACRZgm6N+yvKsN5XQvS3hGhy CbHeSshoVkLUueQF/AFIOkY30mJyX47JqhuTn7bGZNWOEfNAZwvU6EsiPoUpHYyCSXdDPhH+3IY7 MQ4qLhnTcq+44S6J2ema32YPhxduoRXxD6otYAwkWDW196/tuW11au6mz2xYfl1cbfcTUWsPV15V VdFR5HHkr1oSWAwGgodtluxuXtV83ZFNYy9cX1tdyenZjtN0ddvqRZsOxKuu7VtsTa/MIRrWPfuu wqBMAlltOpqAyqKyBKKyBKLyTBmVZ8qoLInoN7g8ZILRPIYCKIwzJm1tihdwOipA2TjriHYVeRYp zZJMEsKrp6/0GPLSWZKKQmHglBp7fMP++qt/eEdz230/uaZ425oan0bJE6Uy5S7fuXzV7b1FBT13 rm0ebck3w9KGPyG4rSZ7WsS38svvfeHRj55d5xDTfSab12pPsGkjsUj1jd88sP/r1ywJx8IqSxLi UcHM3fwt/PdQOVqGNqCX4w5rZi3Ri1oN1LNWFGy4qTavgjxzAX+FLA/Ac8+RqAr1cqBxo9mKm5b7 FOZsPk+tlh/W+cg2kJE8yMpT+3zqvEwFWafH88ks0EFu0SEKcFlHeiiuBwyZs9V8ccMvDW1vOxwb i/k/LKpLF5f+orhh7S/E5fIDjApqbrxKTc9o3hmyQHeVxOADoyMECmei8C/KvmhvCTqdVMThiAqE 7XTJ+xqsDYrCpDtJ31QXA7lks2Pu4X05Z8sPRyImXvbxt9jMnwom5HYdXFbU47O6lhT+sXK4NSt/ ++GdA/dvyhACOWJOLDfkT8lf96mmtFo/FiyWmZm+ruzamKtvbU5dzNW2oeUPYppbe/2uxr5yHz8W 9Kesji3b05aR6LRmJQWzOB0XWNxZVj7cnhOKd+YHyovzPJ6mjMUbw6Gupc37VmZqNYGZ99ZtEYvr Uzs3+4vqpteXVnAaT2ZaqmNJZWJ2OdHpG2Yew39T3oqCKDnu4Ml8yBOp85Khyzv8+htQRQzH8qSJ F6ugrlbX3IOOLF6SDJ0i8F82dG1Yq8SmRI/VazPwha3FCf6S1jysFRKcrgSBU276/kznq6/NrPmh waJXciqNcvNPfv76zp2//sVPtyhUKrL8JCXaByV6C0oUQHknkZXuMVpllSJ4nJTMSg4LPKeXTrTQ EkZzo+z42NzCt9BakM9FwvJZJ6cVv5VQ3FLIG0DTvYlGrFy3fv16BSckuBwJFg23ZZzz7Hz95z/Z rNSoOCWY3j/Aj732Kn7s+1oB+oxKpTgzs1zeZ18JVl8ErTuitsljwH+/HuYsx42JKClRPYUNR202 j2oKpx5NbvEseLQSO20pufi5ykWP1y55xMLxKxU6o3omjE+pjTqFxOMau+glVlCai6uRQk/boGoz dbAucICZq53+3dyW+jPkuZt02iAZVoYH+K+hFNR6EvlgrVNAthl9OM2H3ZJx5MZhU6GJi2ixl2zd lnqxpxiwzIP99R6drV7XqFiOGmWjpALG7yg9gkaOogV4qixFNvK0IJwvmxU4zyZ1I6ddzeXtUeXk ekULpzqgFfiZFzVCSlJSsl2rxJh/X2VJFhNSLKqZ44JFabCbcInCquPXOdwmJa8xG6ezuFdteiWZ M6EmtTCf9SgDqB69dRItkY/5LNjQnt+4phvbb9MNbC4jHs2N2+y4KZfYaXQvW1rp0h1tuplNdgiJ OHzPczlkp+uoT7JYTx31yGin+JzZgpuQIesFHEFFsBwKx/UWsQgXxYlxaSHjnY4wuskN2nCc7HO3 Oadwmnwqcm6rOxqVN7vPEqVYsNkdnbOF/7eb3XxP5e5Hu5YMrS5z6clq2JS3YmdDcVdlSm5r/+DW 1ryy/s+sjK5uXmRTKTiebIbHqrpKC1fke3Pbtg1ua8vD29d+uifXKSa7Q35nolWdnBpMKlqRV7Ss LCevfOXO5S3XrMo0e/w2vcVts8JskhBMTMxeGipctig3b3HbTmijanyMy+IWIzMyHUNq/XkFIrov j8IBarRIq+Isq2VmvRU++Iuw9lXiDyJJ/nA4SWXxQi5Pzp5X7IXVRRTdH0/cmIlFsvISydAlkiYT if0iktYSpzghbkFxBzkHN3cYzin32wVnRd697EwJOTvyPCeQlchRh7Q7ciquhSx04Vah1TffXtIh TNmIic43zfyDv0uOC5QvCFHsrT44Nb594uoq2nVtmoy28frG8ZaotKAJ2LT4jV0nDy4t3/vcbj7I VjIf/XXNjZ2ZGR3XruZdC1c3i2c/VJ0DqSxCW46GF+FcmJHjldJJ1lwck460psZwSFrrhEI4WVru pCVjt0hIZg7OzMaZKTgziIta01uD2Xp+4SNwsNUq6GNNLJ0qlf5Cc3uzPGMw8hYu2JtdwMiupPI6 hZCQluSPJpgUM+9xH/Imb5oYyEgw8zNPqrAlLPpTbGoOBzG281p7KCkhYNdKT3QTeZUtmJgUFLAy bLIQW9hi4n/yUYxxxVMur0nBa0z6C6cVpXozsarN+gvfUZTpgCtNXpe8KlWsAAnF0NSxihwcNMiK YJAVwSArgkFWBIOsCAayUZLgStG7BbaZKW1rLtjRBD1zLdQz8uSAbnG6pqgGEXwO4lzprbCoy4ib TxnwywZsuPikQaxr53lJpRb0+tz5B+4LVr+BKzx8Dcyr1gpQIbdXtGumj1763JVrltRt4TqZK5/+ 1uVr5ukPYaJeoGHJIL+tIL8UNBhPTCEPqVJTsJdg2ItTXeRJfIYHZ7ixh52ylAiZs90shJC4lQR5 3B53OORvdSutdJUP04fFiukQR/oQAmWTJpIoVTTF5epFlIo7oTB5IonOgNtiUPMznRpsTU1OCFi1 CjyKcT+vsack+VOMvCaJHKHACiVZdE1Khyw0Rt2FFxUVJJwcsiD7OhthPnxQ3im9Me6D/u3XR0lr R3UG9pBYWtpHyYooHeVRez9PVqE8eW8gT1atPFmF8qQVkSNUr18c9SuELLIi8jYUkxWR0Kxc/nEr oov2SwsstJfNHeAu+PgVkZYs2P12dVpDXX2EbI/m9nxmQ2pNdW06OfxvT7CoL1sVzRxju6T4TFpJ 0MxWRpZQWdoA2zad+QddGtFHyrA0wgjPvMXrlN9ADqQ5IihRDJbRLlpQdgJG/bjCaE90eAJWhYrr UhhtSQ5YlymU7xnN5AmEzajabzRrebXBboT8ssHG+qfUS7PjiWkxnJaFiRHiwhEnTkU4rTWotyS2 WhYcT4Dpg562mD+Gg/HcKZwFSjOnM5j/rVFpTUsWUxx6xcy5mdeVBkdKUiBsVhpx98yzBrUAU1vY qVNhJ7YrdbbkRH/EojDMTJQ7vWYlEQTHT0/DgpxXmr1Oro2rcPrMCl5t1Mwk4N9qjGpJn6a/TXrN Q9yD/GrlzVAfd9yUlOqPxFxqs6DS6YN6EBa0ORQfiqRSRSI2J1m5F9nUKvIgtagoQuzYQpeLD5O1 vJovKnSCAa5W8/UmzuVKNLySwItZWSKfcNaQ5HJh03vvmTCsXQxnWfgrhkSXizO9xz+mCkZSrdrP z3xoFmAAU31ea02NBFXbt6mDkYhV+wBWCvCZufAAhIeD6m2w7iM7nBhs3SSYZ4vR9+JePxn+/GT4 85MO4XeTQ3eidK6Oy4qneh3kubSDnKF0OPQZJHEGSUyP9JPEGSRxxvNkN3T21HFiwIcX9BPWf96V +88/5X7F+o8QNz6iP6Xn9N7I33Ny1DCIaieFlvwprD+inju/Rh5jd132HBsGlJIFRpPisrNs6iQe z++d2hZso2J/8fKenfUzz0gbqeGxe8AAii5JL1hXnToz7S1e0zB5urK10LMsVLu95aUPyzoqw3h0 8ZbW8nQH3V7NWLmvOWtlbbFVV9A6yOFYU0HCTFewbPn066Udi/wzxQlFraAj6TNv4FF0DvmQblLv SkDC2TP0qRB9kEcs6LnXh0ZVJpflFqXR5rFZXDqsuEHvTvF6Ulz6O/z5WZmel9Q66KowYmPbQZ8o qFSCSLSwYPZD5fVg51ejN06CqXwqvhikXUyW8GnFuIhgCPpZAIdFHPbjcBIOJ+JIAk5V4DQel5bh slJclokXkbe5YTIT5BU8wbgO2ksQIQfBLAcTjBvIgwMSbF5SL6UjL3tUCMuFIeEaQSHErc46Ia8+ VF96ZwbOIHEZxMYSbM66LRm7M7hqCHU1STt1r5D3WbpOV1ScgbmAvvUyP0XQSYJ+6Osuqrm3XfiI eoFlcoUXXxZQ5fUK5cy/eKMrNcmf7jHwX+e4Z3mjF6yVCPhmPlAqyA5fQrJVw/+C477Laa1+j9tv 1XCvcfhVTmsLeN2J5OUYtd08/2oMd7tWOz06/6KM2a7W6tUcDBTaaa9Wy/1eC0MFaaxpN/NxGh07 BX5AuRPlo3vjhopCnJaDc+JW3JwzNfuyNJHmyIfacsiMY5BQehUm5wUugpKRQX6a9/E2DX4/7nVm ZiLSYamp4kzWK1PrE2osC3aZpZdDSmKCdNYh9xwzb+cMkf/RIbADGluy1xd0m1Uz11/6wBuv1Fg9 YJgkO7RG88zzeNColw5/EBnhv84YLz8k/tFP8S6dUQty02sNbmHm+ZmQxUHm7hDI7DnlXmRD7ajy SDV6gRtEOuTHH0y2t4hkK9hRmJ3RUtd8flGtmHG+0KwsrAs3eaSqnj0jkKd35KFs3pu5r7939s2X Ln8djb+S8XXpdvDCdwYcgVyng39O64wkJUZcOp0rkpgUcWqt7JDHzI5Lj3uk1PZXOTNSfDpYgukM Gos3lFBdyqm9HsWPEsIkh3BCQsij1XpCF3LmN48vPwbS3XXDqjQF+f0gwW0RE9Qa9ebhHp902roP 1sn3wbhejr4ZN0aKcKRQOjzJ47i0fuWaN8ZxkTwsF0kHa8kRJPJUJhX6ZyqEphKVSTUtzx3KvSaX z73yYdLnuTwY5t8+ChmShfFxSctsU+QoJXmHweYuJFawIaP07yJ510aZ0eImQzlbBce6YPFLHmdg 4VXZED7ddfasRMkmAzUO5RZSXbICJsIPXjTEw+pSfmGBv6/m4JEdi3asLDSrlBxM5Wpdem1/XeVw S1ak5cCqxR3hBLc/kVusMeuUdutMYrA+e+jwUAl+ZOsXh0otHrfJYPFaLT6LxpPoFau2NJRvqPAb vCHOHBC1sOhNSZ25V8kVdB8CSY8gxD+oDICk74kb0wpxNAmnJZKxlUg67qKidhLpOSXBOYngnFNc 5nN5IfhDJXIrlDzPXYP0sIwg6w0ykurJEsRSXCKKJbAUzXouz6nKahNKpnAqPVuQK28jxKQOTGR2 Zu5ANxUeGTPlB9TyFicMg5e8oqTKY7OjWtpyelCpNWunC0wOs5rXmQ0XVveXWBMKVuRLLyip9WoF p9S4yzq3l62/vSvLWXvj0BkuD1ZhygayF6AWkpx2MFKMWLfurj2botHm0uTk1GSNNclhdgomR0rQ XbBuX3X5/jueHXlVa5XOfxNL8GdgCaajLHQhXkomqEwcycApEZwSxqEEHPbhoBeneHDIjUMwOztx 2IHDdhwWcNiMU5Q4RYGjPpxNxG0l4oYlrtMNxCkK8jsjdP1/7gRZ9ydkZcFE9VE8EVIIpFmIqQRf ZH4j1r9AtkgF8nw2ghSzZ4lqK2A4Zi8ixnXkTURFdiziA/teH9cpogFB0AVadXR1A62Rdz43l6xx yPQlv5NBjj6dYcs7uWUu+eCLj5LNNRkbZi3kQU8QB/if2a13sfNO0+8YBKOSU+nU+KdKW1JGUiAn SbjL4ph5lJtZix/Dw4HwzLts2MCCSkhy25I8LiNv1ZDDZhqj9qPvBLk/TJeSMaMHWuJZGDP86LWT yAIrOJ0lgJssgiAfM7z4+OHb8vHD9yWJjEkvxQpT7CpBoIaDdJUgXyVF68lOxLhAmk8lHzANsDEp gBe8IvZz6SyfY4p2iQVv87wtH8I5dxyucSgtUzjzqLdFL+2z5tLXZc/QLhCV35Flr8rOvyUrLRoW HkHgn+WVWtVMltLsSvEmhy2cCr8zfbfNptSZtNxfTQ69SnHamujzmC68ZIBljAoWNIqG1BQbaL3K moDw7AczdyvQrBsZkfk4Uuv+oCBPKy7f9nIqkGD5aLHFarXw/yFYZl4NiknB5GRRekN7ifImGEki qAx9Op6oC1hTiX6mEv1MJacNUslpg1SyOk2d4nLjOiQmZCccTOATcuUxJFc2sHPlB1W58oOqXFl4 uVNc3jFrQGfMnMJpx1xtIUUROapkJMPx2TPEti6Zf1977gQHrF2UzBBQXfxqrGRVK/El592hFjqD yt45dn15zn097E3uW392R50trTy9frAu1a6ZefrSl7pHXH6LKlCxZlFSxqrD/3rkgQ/Im91//ULL PdcPZy6qTDbbgty5wa/duqzt9ue3jrx4W/PKO75OtNYMWvsaaG0y6jvhjpOzLxaiRMfIqYP/8QsT ZOKzwPxFVFtlJRv3ifI7EUShJLMo+u2ocDo6t21/WUelWvSa9ALMPWw3Bpj8ggx/vfR6jLRbf+Gh uW2YTRpLgs1GX9NH0onWvyieVu5BfajzSLxBeuWrLxhE+X19hpqOPAT2zVGYRpZNYUXcsaE5XpdX V1rqzDyfUNuADOeddSrpsWturrRMIoezqKlz9jR48+gDcPLrBh9/YPWi3WRH4JNfGZt/XI63XXak tXagIVSTBItnXqVRauzkBGweLADuo6ahVfN7Ihmr+a3COmcowaGGRAqtkJQWc9b2xhP5rI859Go2 Gmw+28Izsh//1pl14StqINtnYKZ+WOmCeeZ38ZSUJJySiFMScNCHU6Tphe4/pEmvm1jJ1CHNKEY6 oyAya6M0WZ/SZH1Kk/UpTdanNPmltDSyl2hKcpOL3HryrbfI8xCgNKdY5IFuQfgpeUR9N66FKx6x YIsNVLHiaLA1TZjCajbrT5+RzsbTYe50NI9ppzSzRBfMLBdN/XkBi1qlouujotD8nAI6+7BKZ1RP r1Mb9CoVaC82fUjky6v0WpyuMFjdVmgu1Tsak1ZZRU6/qwWvzeq1aPmf36tTGJNcFrdgUL3IKxRY odarLtyhtXiJJm8BC/QuGM06sPIkWgOSTCCSXINzNFDrHDKm5Uj2UA4RT84UVxDXLWsLL1vmtuHm OJkoYHJvDpMlYxxCw3He5NMI7G0D6UqfKB3lpiL3gUV1HGn08lvFxCA1yaI1ya1lIu1pAxmbyoht WxaXjvqVYUn0chPEdSSwzFJmcRZK03t9W8bfRFFZTx7fLDBcz5cIc09wYF6J0ScD8ogpPYomB3Ws JQJ7hzo6b8UWXmTEzr88PmfWXsE4cyTx/F3lY09uX7Kzo9SsUfEmo7agbahqaW9VcrRtb/N+sMHU Kr1Ju3Npf33Em99SUNrdlKsDg43nVBpbaftQfM3NazPF8jVllUMrMvFI5x2bixyJfpPJnuhISRBD YnJ5e25RRzwZmtdh85jVyfHOotT6Qn8wNag0+5xml8VkA/sta+V47eL+lhI9py5YsR1mrVZo58PQ ztloKfp63JaWhdOVOE3aUUgP47AOVxGxiqTxq6DxjazdE/fl4JKc+pz+HD4Ky17yiE6LTCYRDUOm UstJa4pzx8iaooy0MlxaRnqHtLE8XoYLy2rKNpfxKWW4bIqLxk2xEA7F/yqK6sK/p7fBOkNzRL1q bsuI7BhJP5kBK13pVX7w5C5cZUjrDMWlT9qKLprwFBe/2VXIH7Znt+x/YjjasiTDDkaBXqNPXdya 131rRwZXcM/GHXd3RnK3fXmk5ap18Yjl2eSlGyuWrCtL8BSvWdp4G/f8yqcfvnVrmV6wWv1ep9ek NFvNjVcfXufPLtt8W9uqz++qSWseOPRozcFnd2THlvcWlG2qCmWS87/bQeJfV4qcCjVIpxRlP8pH dej+k6iBLTsacHS8Am+uwJUVOL8Cp1TgiimuMm43JCQY9hXgbQW4sQCXFuBoAS6AiOeGERYRRnKv Id3oBGmDbAM2TM1+GNeBx1A6m52tDE9hNGnrrJrCjiPKDQtEHO06S4ytN6XhxypLGeS8QP8V8s8i XPTcUn3JiWD23tzX83cc3tlyYN3ikGDNWr778GCoKZ5hgjUIVuu1+nBhc17Xje1pvHdJ86qc/js7 w8+4CtcsDTVUV3gDFesr4uvLE/GX2h/eW5/asOPQl9e3PfnQrVsWac1WvdFsM1m9gsZkMTUdfGKd OcltLum7ZWPphqUpRpff+qln+jOzW/qIbG/md/NZMB/7UBEyHlMlO3NrUUXeGTKLXnR2RD4iob5C qPQE/LDeFXS7k516ldEl3KQ0WD1WwanDyhnXFSIceoWi9movjLoqq+hNysvK9JzR6NTkfVHNzPmP iSCljfK7uZ/MlVYfceXNlXZumzEczp/fZ1RecfeR+wkpzM0KI4z9UBj+ep0r6HEFnfqZBxZEQPEV UgwpvTLih9K4z8BKW0F+IAZbrvGKFpXKIno/LkI600dKje69rfCVDeZF/0AejfTzty/88cCP2E/h gl09qjqn/AZQLUkrfTD55eDpXy74xVx8yQ/6NilMCCmbUA//BZTMX0Bd3A/Q/fwraB1+Fd2PfwyW wCa0RpEP/FV0A/cMCgC/h38bPa14FAUVyYDFEJ8KCGn4AGpRdKCnuZ0opHoNPQ3XmEk+3CqEpPgu OT3haahTaUBryb0Uf4JrlOiznAI9repF9yvG4T7g4Fpy3UZFFermT6MCbgDKMID28V9FT/MPQ3m/ imq5UVStTEZPqpPQYsVHkP8hlEyu4V0IKyIom/8IPaRYA2WZRenKKVTAfwnyX4RCUO8+cCPgssH1 8B/NfqDcBPh7ZFacl+KfAbcFXCu47cTxnehmFJXk9ij24Je5ndw7/P38r/lfK7Yq/qTsU76p2qk6 r96v/rvmWi3WPqDbqNfrP20oM9QYRgyPGYuNNxrvMqWZbjbHzGXmx80/EBzCPy2cZY/lQWuedcL2 Bdvv7YX2hx0Kx6uOD5zXuxyu4+6I+5T7bc8Kz9PeTd67fdsTlAmfS2xOPJ806W/xj4hGcSyQHPhF 8pngjcFPpyxKuTvlj1ILN6PNSIk6kAI0QUAxsJJR0J2iBz+JLeCuRfQnuBHqlb55STNMko+XdM1E 9mskzku/cEW5AsInZK5EbvQNmasg/FWZq9GH6Lcy16B0/IbMtUjkNDLXcY9wqTLXo1WK78ncAG2U JHMj9zllncxNaIf6nMwFZNI0ydwCfM2cTudqtsocI7XmAZlzwB+VOY/cmsdlroDwUzJXIoPmuzJX QfjPZK5GV2l+KXMNcmhXy1yLBO0OmevwCu0BmetRVPejuV8vd+j+JXOYh/UGmUN/M3TIXEDqOW4B vkHmVuCbobRYoSVtZBiQObSR4ScyhzYy/Ebm0EaG8zKHNjImyhzayBiVObSRsVLm0EbGFplDG5ka ZQ5tZBqXObSR6V6ZQxtZCmQObWS5VebQRpbjMoc2sjfLHNrIflLm0Eb278rcCvwV9AQSUS5oVTYq ANYs/ar0CBpCo+A2ozEIq5R+jZv+Jnc3hPQDG4T1iIiWoB3wJ6JWCNuCtkLcqOTrA+yD1LvguxdS VsJ1OyDNJgjrl+K3oHEI6Qb/5Xcsle658IrSBWW8OGaVdJ9RuUwkVZaU7uJUF/tEcKScfYBjUGqS gwgpREBSsn7pV677JF8vhI5J9e4F34BU4u0QNjR3zZVjN/+vZClKv4suyqURUTv4+qUykPu3AeuW fKPSPQchNCaXYGhBDXrANw6xY1ItSeqs/0UZmuDaHpQKIaMoDVL1SiWpla4ld7myDIkEBiC+VyoD qcOoVMJRifVJaYksNkPoAPAdaC/4dsuSF6Xfcd8EfId0txG5Br2SPLZIuQzJuY5JEp6XAK0vuSfV AKKP9VL9NkNIt/Q75SOyzEakkB1SqcfkevRATIaU84AUskPKsRvkQsPZXQYkTSVSGpZLOQghA9Jd aZ6knmMLSkDuOCzVhf2OPZUwLTu50xBIQJR+wX2LJIV+6TfbyW/hjy3QBdanqMzoXUSp7INyvaie bZJSzpd4YY2I1PZI19Fabwd/1mX9KyLlNiDlsFeSw7jcexfKm2knuftuSardcz2lX25tekfS1iLk MTxXG1rGLXIa0l/3ybmPQS1oC+2aa6VuSUdIbxq4qF5Mg3ugJN3S/Xvk+2dJkhqDO5ZC34hJ/zfA bggduEz/syS9GYA0Y1BX0kJbpJyGIYe9EEpy3Cy1F2nJi3Nl4Zul/91gRJIny69T0l0qxb1S7Ucl aY1J7Twq6SW9WpTkRnSkT6phv3QP2tc3SdcySVfDSNAEoyy9dmRBDNWvXqnPzuvMbvl/Bdj6Mfel fpK2B+Q8LvXa3rk26JXih6Vxee8CuQ9LNR2UJU/z6pO+iSZdWm8STzU2Fa5Kk8bZAahX35wOXV6q wcty/p/LaD53NmqIcr+n42DPRf3v8rrPj7wXl6tsgQRITWhd6CjExs6RuRGtV+rTg1Lf7v7YmlI5 d18k0z55HL90NCdSJZo3Ll3ZK/UPUpu+uXxIyh1SH/ukFvo/1S/m+0RMKg3pA3RkzJLaahjGmU+Y 558Qc7OzC8Tm/p6RodGhzWNi5dDI8NBI91j/0GCWuGTHDrG1f8vWsVGxtW+0b2RXX29WZfeO/k0j /a19W8Z3dI/MXVgqyhGlUo6yZ1XfyCjkJOZmZWfLQTKI/aNiX//Y1r4RsVsc6dvSPzrWN9LXK46N dPf2DXSPbBeHSMwC7+Yrl1LsHxQhG7F9sH8Mrm8b6x7rGxW7B3tjkMGQdIOeofHBsZH+vtGsK+bQ NN6T2j2aJvb2ibUjQ0NjC0rYLQ4M9faNDIqj3YOjIkigf7O4uXugf8decTcUXhwd3zS2o08cgRv0 9g9uGRWhPFCRAakAcN+RQRBAllg/Jm7u6x4bH4GSjfR17xD7x+AePaMZ4uhAN8i4p3sYOLlkYHzH WP8wZDk4PtA3AilH+8akDEbF4ZEhKDEpMOS+Y8fQbnErNI3YPzDc3TMmSYG0FJQMLhF39A/CvUBm m/q3SBnTG4317RmDi/u392Wx9oqMigPdg3vFnnFoXlpuIs7Bvt3iSDdplH6oNlzYPSCOD5PbQI5b IGS0fx8kHxuCCu0iVeoWd3ePDNB7EQH3bO0egYL1jWRtHRsbLo3Fdu/enTXA5J/VMzQQG9s7PLRl pHt4695Yz9jmocGxUTkp4Zu7oXDbSbrOoXEo4l5xfLQPigatQqLFbpBI38hA/xhp9U17pUJXtzct gdgRyQPy6h2nktm9tb9n64JrAfsHe3aM9xKFGxJ7+0eHd8ANSNmHR/ohQQ+k6hscyxLZvYcGQbCp /Wli38AmctF8VoMs8RVLJCUnqgFiGgUd7KHtN3d3SXnlvMqkAqT2w11AhYh2jhBF6x3aPbhjqHvh TaHM3bSk0BBzaj40PjY8PgZqvKu/p4+k2dq3Y/iSCl3ce2Xfvxcb/15s/Hux8e/FBvr3YuPfi41/ Lzb+vdj4f2mxcUnc3P76x34mtbw4xV1/TOvGDUCuY+RaRj7FyEFGrmHkakauYuQAI/sZ2cfIXkb2 MLKbkV2MjDMyxsgoIzsZGWZkiJFBRgYY2cHIdka2MdLPyFZGtjCymZE+RnoZ6WFkEyPdjGxkZAMj 6xnpYmQdI2sZWcNIJyMdjKxmZBUj7YysZKSNkVZGWhhZwchyRpYx0sxIEyONjDQwUs9IHSO1jNQw Us1IFSOVjCxlZAkjcUYqGClnZDEjixgpY6SUkRJGihkpYqSQkQJG8hnJYySXkRxGshmJMZLFSCYj GYxEGUlnJI2RVEYijIQZCTGSwkiQkWRGAoyIjPgZSWIkkZEERnyMeBnxMOJmxMWIkxEHI3ZGbIxY GbEwIjBiZsTEiJERAyN6RnSMaBnRMKJmRMWIkhEFIzwjHCOYESQTPMvIDCPTjHzEyAVGPmTkA0be Z+RfjPyTkX8w8ndG/sbIXxl5j5F3GfkLI39m5Dwjf2Lkj4y8w8gfGHmbkbcY+T0jv2Pkt4z8FyP/ ycibjJxj5DeMvMHI64z8mpFfMfJLRn7ByM8ZeY2RVxl5hZGzjPyMkZ8y8hNGXmbkx4y8xMgZRn7E yA8Z+QEj32fke4x8l5HvMPJtRk4z8h+MfIuRbzJyipEXGfkGI19n5GuMvMDI84ycZGSKkROMPMfI cUaOMXKUkUlGjjAywcizjDzDyFcZeZqRpxh5kpEnGHmckccYOczIVxj5MiNfYuSLjDzKyCOMPMzI Q4x8gZEHGfk8Iw8wcj8jn2Pks4zcx8i9jNzDyN2M3MXIZxi5k5E7GPk0I7czchsjtzJyiJFbGLmZ kZsYuZGRGxhhZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9mZg9m Zg9mZg8eYYTZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZ P5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5jZP5iZPZiZPZiZPZhZ O5hZO5hZO5hZO5hZO5hZO5hZO5hZO5hZO7jyKCFgNU8mlfvBZp5McgBcS32fmkwqBThIfddQuHoy yQBwFfUdoLCfwj4KeycTlwDsmUysBNhNYReFcRo3Rn2jFEZo4M7JxKUAwxSGKAzSJAMUdlDYPplQ DbCNQj+FrRS2UNg8mVAF0Ed9vRR6KGyi0E1hI4UNFNbT67qobx2FtRTWUOik0EFhNYVVFNoprKTQ RqGVQguFFRSWU1hGoZlCE4VGCg2TvnqAegp1k74GgFoKNZO+RoDqSV8TQBWFSgpLadwSel2cQgW9 rpzCYgqLaMoyCqX08hIKxRSKKBRSKKCZ5VPIo7nkUsihkE0zi1HIotdlUsigEKWQTiGNQiqFCM06 TCFE80yhEKSQTLMOUBDpdX4KSRQSKSRQ8FHwTnqXAXgouCe9ywFcFJw00EHBTgNtFKwULDROoGCm gSYKRgoGGqenoKOgpXEaCmoKqknPCgDlpKcFQEGBp4Ec9WEKSAI8S2FGSoKnqe8jChcofEjjPqC+ 9yn8i8I/Kfxj0r0S4O+T7jaAv1HfXym8R+FdGvcX6vszhfMU/kTj/kjhHRr4BwpvU3iLwu9pkt9R 32+p77+o7z8pvEnhHI37DYU3aODrFH5N4VcUfkmT/IL6fk7htUnXaoBXJ12rAF6hcJYG/ozCTyn8 hMLLNMmPKbxEA89Q+BGFH1L4AU3yfQrfo4HfpfAdCt+mcJrCf9CU36K+b1I4ReFFGvcNCl+ngV+j 8AKF5ymcpDBFU56gvucoHKdwjMLRSWcFwOSkcy3AEQoTFJ6l8AyFr1J4msJTFJ6cdMJ4jZ+guTxO 4TEad5jCVyh8mcKXKHyRwqMUHqHwMM3sIZrLFyg8SOM+T+EBCvdT+By94LPUdx+FeyncQ+Puprnc ReEzNO5OCndQ+DSF2yncRlPeSn2HKNxC4WYKN1G4cdLRDXDDpGMTwPUUrpt0bAa4lsKnJh3tAAcn HTAY42smHYUAV1O4il5+gF63n8K+SUcvwF56+R4KuynsojBOYYzCKM16hF6+k8LwpKMHYIhmNkhT DlDYQWE7hW0U+ul1WylsoSXbTC/vo9BLU/ZQ2EShm8JGChsorKeV7qIlW0dhLa30Gpp1J71RB4XV tLir6I3aaS4rKbRRaKXQMmmPA6yYtJM7LJ+0E/VeNmm/DqB50p4J0ESTNFJomLSDXYDrqa+OQi0N rJm0Xw1QPWm/CaBq0n4NQOWk/SDA0klrDcASCnEKFRTKJ60wv+PF1Ldo0tIJUEahdNJCVKOEQvGk pRagaNLSAVA4aVkDUEDj8inkTVoyAHJpypxJC6lY9qSF9M0YhSx6eSa9QwaFKM0snUIazSyVQoRC mEJo0kKklEIhSPNMpnkGaGYizcVPIYlel0ghgYKPgpeCZ1LoAnBPCusBXJPCBgAnBQcFOwUbBSu9 wEIvEGigmYKJgpGCgabU05Q6GqiloKGgpqCiKZU0pYIG8hQ4CpgCis+aN/mJmzH3+KfNvf6PgF8A 9yG4DyDsfQj7F7h/gvsHuL9D+N/A/RXi3gP/u+D+Au7P4M5D+J/A/RHi3gH/H8C9De4tcL83bfH/ zrTV/1tw/wXuP8G9CWHnAH8D7g1wr4P/14C/AvdLcL8A93Pjdv9rxhz/q4CvGHf4zxrD/p+B+ynw nxij/pfB/RjcSxB/BsJ+ZBzw/xD4D4B/H/j3jNv83zX2+79j3Or/tnGL/zRc+x+Q37fAfRNcfPYU fL8I7hvgvm7Y6f+aYcT/gmHU/7xhzH8S3BS4ExD+HLjjEHcM4o5C2CS4I+AmwD2r3+t/Rr/P/1X9 Af/T+qv8T+mv9j8J7glwj4N7DNxhcF/RZ/q/DPglcF+Eax4FfES/3f8w8IeAfwHcg8A/D3k9AHnd D3l9DsI+C+4+cPeCuwfc3eDugus+A/ndqVvmv0O33P9p3Rb/7bqv+G/TPea/gQ/5r+eL/dfhYv+1 7QfbP/XUwfZr2q9qv/qpq9r1V2H9Vb6rGq/af9VTV/3qqnizSnegfV/7/qf2te9t392+56nd7bue Gm9XjNvHx8b5v4/jp8Zx1TjOHsccGhfGxXHeMNY+0j761Eg7GlkxcnBkYkRRNjFyboRDI5j82N7R EV9SDXk97MCIUajZ2T7UPvzUUPvg5oH2bVCs/uIt7Vuf2tK+ubi3ve+p3vae4k3t3cUb2zcUd7Wv f6qrfV3xmva1T61p7yzuaF8N6VcVr2xvf2ple1txS3vrUy3ty4uXtS+D8ObixvampxrbG4rr2uuf qmuvLa5pr4YqowQhQUzgBVKAZQlQEuTDS7N9cd8537s+BfJN+E75eKvZ6/dyaWYPrlzuwUOeazx3 eHiz+8duLu5Oy6gxu37s+o3rLy6FLe5Ky6pBTsEpOnnppXVn88oaCSuqKOYUSHVtdgbDNWYHNjv8 Dq7a78DIcs7yroV3vCj8WODMZmw2z5q5uBmSm01+E0e+Zk183JRTVGM2+o0c+Zo18s64EUJIjhHD ipU1Zr1fz7VX6Jfrubi+orImrs/MrkE8FjFGWADgNeS1aOzw1/Bfw+RAvhJhfOeRlW3RaOOUBrU2 TmhWrJ3AN0+E2sh3vGXNhOrmCdS+Zm3HEYw/3XkEc5UrJ+yNLWuo/4bbb0eJSxsnEts6JvlHHklc 2tk4cZDweFzis4QjSNIZXT86PhqNjq2Hr/WjY1HpH/jwOPFFSSD5NzoGfvI3LvlR9BM/NBnAhlH4 jMlhY5980f/fP/j/6wL83/85gkBNO5bMctejXu46cNeC+xS4g+CuAXc1uKvAHQC3H9w+cHvB7QG3 G9wucOPgxsCNgtsJbhjcELhBcAPgdoDbDm4buH5wW8FtAbcZXB+4XnA94DaB6wa3EdwGcOvBdYFb B24tuDXgOsF1gFsNbhW4dnArwbWBawXXAm4FuOXgloFrBtcErhFcA7h6cHXgasHVgKsGVwWuEtxS cEvAxcH9P9XURZIQRgCF4Xk4QYKGwTVAgpPgVnMMNmQzJ+AEbNDgCe7uBHd3dw0E9+Du8N2Coqu+ XvSqN+/vQ2960ZMedKcbXelCZzrxO7/RkQ60px1taUNrWvErv9CSFjTnZ5rRlCY0phENaUB96lGX OtSmkFr8RE1qUJ1qVKUKP1KZSlSkAj9QnnKUpQylKVX0xV2SEoSCguJ4y2c+8ZEPvOcdb3nDa17x khc85xlPecJjHvGQ/3nAfe5xlzvc5hY3ucF1rnGVK/zHZS7xLxe5wHnOcZYznOYUJznBcY5xlCMc 5hAHOcB+9rGXPexmFzvZwXa2sZUtbGYTG9nAetaxljWsZhUrWcE/LGcZS1nCYhaxkAXMZx5zmcNs ZjGTGUxnGlOZwmQmMZEJjGccf/MXYxnDaEYxkhEM50+GMZQhDGYQAwuKiwbE/mP/sf/Yf+w/9h/7 j/3H/mP/sf/Yf+w/9h/7j/3H/mP/6Y8GRAOiAdGAaEA0IBoQDYgGRAOiAdGAaEA0IBoQDYgGRAOi AdGAaEA0IBoQDYgGRAOiAdGAaEA0IBoQDYj9x/5j/7H92H5sP7Yf24/tx/Zj+7H92P637vB3fvp+ 6w9856fwj34FXwEhT3O3CmVuZHN0cmVhbQplbmRvYmoKCjM0IDAgb2JqCjE5OTk0CmVuZG9iagoK MzUgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9CQUFBQUErQ2FsaWJyaQov RmxhZ3MgNAovRm9udEJCb3hbLTQ3NiAtMTkzIDEyMTMgOTUzXS9JdGFsaWNBbmdsZSAwCi9Bc2Nl bnQgOTUyCi9EZXNjZW50IC0yNjgKL0NhcEhlaWdodCA5NTIKL1N0ZW1WIDgwCi9Gb250RmlsZTIg MzMgMCBSPj4KZW5kb2JqCgozNiAwIG9iago8PC9MZW5ndGggNTI5L0ZpbHRlci9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nF3UzY6bMBQF4D1PwXK6GIHvNWEiRZEy+ZGy6I+a9gEIOClSA4gwi7x9Ofe4 jdTFRAdjrj9fxmTb4+7YtVP2bezrU5jSS9s1Y7j3H2Md0nO4tl3iJG3aeopX9lvfqiHJ5mdPj/sU bsfu0q9WSfZ9vnefxkf6smn6c/iUZF/HJoxtd01ffm5P8/XpYxh+h1vopjRP1uu0CZe5zudq+FLd QmZPvR6b+XY7PV7nR54TfjyGkIpdO1Lqvgn3oarDWHXXkKzyfJ2uDod1Errmv3tlfOR8qX9V4zzV zVPz3M+TV7lYLhfIanlRIHuOC3LBcYe8YN4il5YlR37juCIvmd+QN8xL5HfW9MhbZltrR4/lPbOt dbBcoL7LWQdmF/3vyPQv4HT0lzA4+gsbj37s0dHvd8j07y1H/x6Zfo89OvoPVjP6zRP9G+ToL5Hp 38Pv6PfYr9AvqC/Rj55I9MMg+uyP0L+wTL+HQWL/sZbE/qPPQr9YzejHfoX+0sbpL6wO/WLr0l+g /0J/YfWjH/WV/gI1lf4Se1T6Be9F6S9sPv2C/mj0410o/YLeKv0l1tLYf7xTXT7fl9KvsCn9anXo V/RH6VerE/3mif8/cProx3zvnvU9/Wpz6Ff0x9Ov6JunX20+/JI7+H3JvLNDF08Xjh++D3+PdVp/ jON8pO0jYmcZp7jtwr/vzNAPeMr+/gDR1hG2CmVuZHN0cmVhbQplbmRvYmoKCjM3IDAgb2JqCjw8 L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0JBQUFBQStDYWxpYnJpCi9GaXJz dENoYXIgMAovTGFzdENoYXIgNzEKL1dpZHRoc1s1MDYgNjYyIDQ1MSA0OTcgMzQ4IDQ3OSAyMjkg MjI2IDQyMiA1MjUgMjI5IDMzNCA1MjUgNDg4IDU3OCA1MTYKNTI3IDUxOSA1MjUgMzkxIDU0MiAz MDUgODU0IDIyOSA1MjUgNDIwIDUyNyA1MjUgMzk1IDYzMCA0NzkgNjE1CjI1MiAyNTEgNzk4IDU1 NyA1MjUgNTMzIDQ3MCAzMDMgMzAzIDQ1OSA0NTIgNDU5IDMwNiA2NDEgODg5IDYyMwo1NjcgNTI1 IDM4NiA1MTkgNDk4IDU0MyAyNDkgNzE0IDQ1NCA1MjkgNTA2IDUwNiA1MDYgNTA2IDQ5OCA2NzIK NDg3IDYxNSA1MDYgNTA2IDUwNiA1MDYgNDE4IDQxOCBdCi9Gb250RGVzY3JpcHRvciAzNSAwIFIK L1RvVW5pY29kZSAzNiAwIFIKPj4KZW5kb2JqCgozOCAwIG9iago8PC9MZW5ndGggMzkgMCBSL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDE4Mzg4Pj4Kc3RyZWFtCnic7XwJWFvHtf/ce7VvSAhJ gABdIYPBAoTBrF6Q2WwWLxjkIK8ISYBsQEQSJnbixE2bOo8sbeK0TdtsXdOUppWVDbdpk6ZO87q4 6ZK6a5a+LulGk9c2bZLW8D8z5woDcdL0+973vf//+0cw+p05c86ZM+ecmbmySBKxyTDRkRNEIN7g WGCiMMeaSQj5NiFcZvBIQnzq6Y/qgH6BELlhaGJ4rLflWY4QxcuEqM3Do0eH5LnFqwgxyggxKEbC gdDMk4ECQgpAh9SOAONFRYMK+q3QXzUylrji78IviqE/Av2q0WgwkJvzMwv074B+3ljgiomf8xNq 6M9CXxwPjIUz9t5+DfR/TIjtJxPReIKAo2D6QTo+EQtP7Pvhyy9B/xnw4QLwOPihL+qzgvZ5QSZX KFVqjVZH/v98Ke8iZP7UMtZOcojEIecnyHvJTeQUeYz8jAySdwP1YXIP+TS5jyTJV8k3yI/+J/2Y PyofIzrhEaIgZkIWXl+Ym/80tFm5YQnnFPTMMvEiZ8G48KcVvD/Nn1owzs8qMomG6er57wP3L9yF hdf5JtpfqKV9/iTQGUzjv5V3zX9h/t5l7nSSbtJHfGQ3uYz4yQ6yHdpO0kO2kf3kIAmQIAmRMBki w2SERCBeh8koGSPj0IZIlEyQy0kMYpggk+QI0AmJg/0ryFFyjByX8EpyFdBH4f0Yo64m10Dk37WI 1y7iRc67yXXQ3gPv7yUnyfXkPwDp+3Le8t40uYHcCPm8mbxvkX7fJbmUfj/5ALRbyK2Q9duAvh1y /xHyUXIH454iHyQfYr27ycdh/IPLZOnYRfk7yV0gdQ/5GEh+Aqrn3hWyVPJu8ij5MtTU18lXoNoe A+oJcgboJ8jz5AXyK/Ii+S35Hefmarkt5M/kr+RpiP4QRJ3GfIK9R+B9eDHiUxDbdGSvhogtj8MR aQzjeS2LU3psCiRPQjauXaIzzfKUtkWl07aWxouuia7oIg9XeGqRc3Hdy7VQbmnMlkfwI4yzfHRl ZJfSH3vTkU+QT0H7JLzTPKzspanPwA6n7bNkhnwOKHy/2E9T95PPky/AWXCaPEAeIg+TR8jsYv9B 6F0cTzFOWubS/C+SL7EqeIw8zvL/NXKW8R4D6ow0+pg08kVGP0GeglPoW3AbnSNPQu08xdq3yHeg Pr5Hvg+n1s/Jc1IFnWcV5OLc5Lvke7Ji8mO5gZMLj5Mn+O3kCuj/iP8wZIJ42w8e2L9v7x5/v6+v d1fPzh3bt3V3dXZs3dLe1trSvNnbtGnjhvWNDfV1tTWeivKykuKiVa5CR3aWyZih12rUKqVCLhN4 jpS1udoHxGTxQFJW7Nq6tZz2XQFgBJYwBpIisNqXyyTFASYmLpf0guTQCkkvSnoXJTmjuIFsKC8T 21xi8lyrS5zl9vT0A31Tq8svJucYvY3RsmLW0UPH6QQNsS17pFVMcgNiW7L9yMh020Ar2Dut1bS4 WsKa8jJyWqMFUgtUssQ1cZor2cQxgi9pazzNE5WeTpsUitoCoeTOnv62VrvT6Wc80sJsJRUtSSWz JUaoz+QG8XTZ49M3zhrJ4IBbF3KFAvv6k0IAlKaFtunpk0mTO1nqak2WHvtVNiw5nCxztbYl3S4w 1rVrcQIuKS8yusTpVwg475r743JOQOIoioyvEErSJS6GCcbTNAHfwENYn9NJfblh1ksGoZM80dOP fZEM2lPE63H7k/wAHXk8PWLx0ZET6ZFF9QGXk6aqbUD6PTKSnTwxKJaXQfTZbxH8wriYFIoHBoMj FAPhaVdrK8atrz/pbQXCG5DW2na60gPygQFYRISGoac/6XFNJLNczSgADJHmINLbz1QktWRWS5IM BCWtpKetlfoltk0PtKKD1Jarp/8MqV544fQ60f5ANVlH/NSPpLUFklLcNt0fGko6BuwhqM8hsd/u THr9ED6/qz/sp1lyGZOlL8B0TjYj04K1rZBOC9OVK4tUYj9vF/w0W8AQ2+HN1bwBBoyQLtalGW3e IPZzdpIWg1kkCUotswMdoahlKx0SqGrLVrvT78TXW7hkl3ySFyVVS2wZgbHoE87zpq6hNHWoVGwL ty5xcJlRueSgZO3SfvI0FtLEoKGi6dyaHhKKYOcCjwczjEWzmC0myU6x3xV2+V1QQ96d/XRtNNYs v129rq6ePf0s21KV9C3r4Xg99pLECcPpDt8CNdjutqfTyvpbWH+xu3XFcEd6WJxWubp6p6lxl2SQ iLCDYNGK4o7ADfWZ62BrtsPp5moPuESj2D4dmF04MTh92uudnmgbGGmkNlwdoWlXb/8GO/N1V/9x +zE6VSbp4rr6msvL4OxpPu3iru857eWu793Tf8YIj/7X9/WneI5vGWj2n14FY/1nRDjbGZenXMqk HZF2qKVd0FExefsZLyEn2KiMMVg/OMsRxlOleRwJzvLIM6Z5PPBkyPMyHn1BkrJHIMRw3LaJIZqe q/wj0wN+urmIFVIJv1ySc20iSd616TTHK3RJjSvcnNS6mim/ifKbkK+gfCUUBmflIDj0TJoecME5 BQXVT+wclqJATYqzCwt9/c5z9jm/E0ptH7Q9/Um1G85+eVEnyG2hbQDYW5InggHqB/H1U11lUUfQ D2WbNggiHUk1WFBLFkCinenQcgSlIOQGEsj0T0AnecKf9LvppP0RPytnY5JsdTVC2tGmvJhO5PFP Z7qq2N6EraApOklBDb6R3n7k2KELk/kxSEodeB50wVBwQIRoy0iwF0odz1KNHTlhOBJlxWHWNHZp kNBlCUVavSaprgCD8EtpbQXdkvIipd+PzrPeSUkA5jYmteBR8ZJQSgoQHRjqoL7A70lwlYp+lZrp mSW7XFfAyUKdZpaUMJzUF3UE4PBHfS1wXPVpZRU9I7SSjbPIVdKV6yDuQlHf7MK9rqPOJa/yMhe9 HGhhEvsZKGzin17JSO51l5epVnL1jD09rdJfWgHjpdIvIjDhoz18OosLP4VPUwJRkvXsU9GOh8qt 5VbVhs0abo50ECUXguoXuRuJinBcyJsp44vqFEKPXW+a6OF6WpV8H2l69rln9z/37DnAc5zn2bnz c8YL5+cyGxo8nrWVnMlpYi3LwCuVCoWrsIKvq6utra6u2sTXrKvgXYUGaMU16zbxdZuE6qoCnomi JOOCMOUKP/3nXmHHBQV/paNtfPsq3mE3ZOnknCh32FQbd1SYM5w1JSVej0OpUfBylUJV2tha2Hqg MXf+IUGpVWpEqzXXIJcpdSq1mGPOMcjm2+WG1/8sN/yjRTb6j9uEteuGd9XKb9eoeJlC8ajdVrS+ 3ZnjFs0ZZqPOIDdbMxVKc6a2eGPnhRtUtlybUqNR6owadXa2VaXWKHTGC/VwdDQtvC5/Ufgm2Uvu /SJ/DX+C9Lthg7f4+r0NreXlFQ02a6Fze+FesldLNJxZ0NQXans7TSWveTs66yucNg2xlmsL925v bTBUb+qo7s7rlneXuLOb4JVpa2jK3XbhbBPn8XjOwsOsqbrKlNlwFuDrQFWvrbR7nf+urbWV/iKD wFJirq2tWVdMk6EU3oKFGVIqEW0IliyFUj7MaSzO7GyHScFH5cq1G6sOD3SadvLINCq4qFJetaH6 EDKznNk5DpOcf4hTm/OzLPYMGVeY0bZvrGHD7rpcIat932h9y576bJUyR6VVyWTwxpflr8v1dm88 fGr3/PhFZkFjzsaO5UzhOsixIKh0ys8VdnvXOBt2eFzdTWuKm/vXuVpXEShnyBL3ktxDzKSUHFqe pwdLHVkFZJYf9Go1joKCLEepbFVOxiy35WG5d1VHDkYw97ltcyYIIuc5/8ycqZoF/5F/IQuh5qQg SlW+IqTc7+SmvDUF+cWZvFyRaQeqyMzP//1irB7ggMyBAMs52bfzim0aja04L68oR63OKfrH2sXV vwdWD5ROSVfaszAna5CPkTLSRE6uqEiNs7ypEAbUhXWzfIE311JYJqxuB6ZaRRSGytfyOhtf9Rq2 CdI6ts01zdHCgX3NeebONniqq46fNJw9Swsv522r0opLHwIsADLY4jJWS4uBKKY1J7NkWekRUSeU C6vWWHKNcl7Ut+6PrV9/2foii9Ja2XXohn5396Z1liGIiwhxyZTz8+c9Y601vta1orG5oy460JmZ YzLIlFr1Z5xdTaWOdW0dnY7G999yw+Fms7Mih5tX6pVyObxdGGzbunbXocvHKwLDGw7dehns5K3c g3wDv5FYiO0hos38paokHT63Z47znIOTLcsgcznZySWrdlZZ+QZOodKaNPP79To4gHQZWu4TBi2f p8iy2bJ0mZlysy3brM0E25cvvMQ/KbuftJHpFTkprS1z17mbVerN6s11are7ss5WZyOVzVvrNm9Q lf1S7XbWbs141evcRgNL4wohnas619AAx8I5euBmNtB6NB4/efas8SQmx/w2tGl10uW4BIVCCnx1 ldVCD2IsU3YQm6Vzurq6Ln0OgBT/JK/QaA3q34RlCnelvSTfqlKpYf1KlbjGY6vfVW/n5XIhfFyr U+jM+qvdnDaLnRNyzv2bDI1wSm2xWiFqGss6U7VHrVFrM/SOgmyl0qBVZFdvq9Xli6KBe11vNhSJ 1vNKnVomU+uU561Q3dsW5oQ74bStIBtWVvfDa6rqFDKinuUNXrXLpCsQsrJcnlle77UQl+IrdXVr CkwmXdX31nTqnvcWLAZkztTggVOVZvgZuME8tgbjnIluXgjj29DCMPIu15tHkdW6UjpWqYRwp/f6 Z247pJQHo96hrkq1Wi1T6VW6jX2hKv97/WU5tbun7hjsm+wqvG9n5+bQtjrTUOQmn4v/NdyBa5yb 7KFDZqtZr9Pk5eeqdTazrqT3qr7NH7j1vUOb1jT31FU3lXeH63PLN+DdxP8ZolVNRleeBCUmU35m HsnP081y2V6jt7wzM89Ukr9aYSvssOEmxjsD4uI5SyuMnXlniO5fiKfrqhDv+Te9R6zgGZxZepXK bCvIKvTv3mLasfzkk24Jp62ps2e1yVVgUyiEO2S2AtGeqdQo14/c3DsffeMN8MnS7oZCuVKtUBCM gJCECDSSK1dEoHhtbq69WGYQSAaXJWQYiiyveWs7i+wGWW7G2mKV6O4Qu9XS9bkYibP0Goard/H+ tf5rLRYQxb9xxQpJlfJyXm0R8eSHW3Tdxprowa43vUVbD1y+kd6d/Hm47S585+JV6Wi0bux6y6uy tKUfotQNu2q38A1Ss3JPPZCXR0z0qsgvWff3Eoeck2v+5ukU/1ZCcow5vEbIyXrdWyRtigvPEAiO e64JCAC8MWiM8v5d1fSewhKSLdtXCpd0/FYVyITdSoNZZyhY29XoDXZUFuj3+Dfv37zGqFLL1Prs DTv2rf3Y3Zaq7bEPBko6N9fkK4XtmcVOa/6qghrf6Phw8fAhsVTMMOicroKcVfnmT3584y2npg97 9VZnbibUzsKB+VPC4YVsuA+yH4b74HnVjosXQtOlLwThML0GDJp/btRreAg3HHZP6HXzryjMFqtZ azYA2rK0ZrinF16dv034LlTmGrinb11Rm3pnTa1OX6OvydbbsgmNf57bpqutccqUla8Vd9r02aIs 096RuaPhVa9y8UxiBTfHHlKemfNIlwJc1yaOlWru2zewZA+vXlK3S4tUKT3HK5VWmh2Z8F28n8s7 N62z+ng1PLfY4H7mLvDsKocyNbTAVd497M27Hx7bV9dODHSZnJ7R1prLWtY6M/j3NN5y2w2jmzNF d+78ThU+z6hkvzcaBKjXGWfX5jXrLpva4d66Lm/D6KnLPtXeVtV3KDaBzzvCLyCOxfBp5qYV1avO VxXMcl94sHh18XrVLPf5R0hGMTyDF6+lIbWZiXr96vxiheDsWPNabmftyueXJhbKuWegNJ+do9GE Q5/dC9a3ofiGpx7pJrDa6tKBTD/0FPD41FMmW7UmK9cIZtlTz87IJpvF03XoRr//miqzrLgkyw5h /AE87tRCyBwZWkete+kDz2dF2M/1+xIb62++7cZoy9amvRA82Od/bGur7jscGy9ztTW4No7e2k+/ E6PfnfKEHG160HAwY8MrJEfFvir70h+u+nb6azOo/7j8RXiS5ImayhJJT3nXhZ9e/HINPiN+ZNm3 bTqZgRAFfETkzpMmWT7p4eNkK/95crnwfbKN/wrjNQl9pFv458IBWf7Cq6SH6X2Gu5J7mb+J/5Jw UPibbEqukX9AflYxohSYr3qyj352ZV4biYcMEKL+HbedyNhoDX8twa+LCQmxd4H5amA9gWnpSEyi BbKJXC3RMpJHHpVoOckmP5ZoBfBflmgleZ3TSbSKrOEVEq0mIl8p0Rr+Hn6nRGvJbllaV0fWyNsl Ws/fLp+QaAMZVakk2kgMqoREm4hOda30zTYhVaqbJZojStXjEs0TheopiRaIQ3VOomVg548SLQc7 r0u0ghjUColWkuPqLIlWEYv6FolWE6P60xKt4XaqH5ZoLXFrFYvftFu0ayVaz3Vr2yUa8q27VaKN RLlIm4hC92GJziQG3d3gLSdT0xzp7pdoyJHeJNGQI71DoiFHerdEQ470EYmGHOmvk2jIkf5OiYYc 6c9INOTI8IBEQ44Mz0o05MhwQaIhR6a0LuTI9BeJhhxl5ks05CjrIYmGHFmcEg05sngkOpPkWdaT +4hIqkgl/NQAtY1ESBCqLUri0IZIAngtQMXIBHsPACcC1Dg8xYpkMxmFH5HsAh79BjoBWrQXBgyD 9BF4D4FkC+iNgswg8CKkA+SwH7zEfI1sxqXy4jKNxiX+vpXcbuZBXPKW6lQwreU65ct0VtqLsPWE AROwOmpPBAkRMAzrjbDvecOsFwJugsWHfh8/Bhgjh4EXXdS59OjQvxVz6tE4s0W9EYkPehHmA52/ l60kwaJP5xwHrkfyILpkBUHoTcJogq2SSlf8Gz50g26QlAAnTkpBKsQ82cJ06SyXjiGNwBiMh5gP dA1x5mGcUWEmS2MxBFz8Fv0o9KakyFOZSbCYAH6YxR9XEGLxGGZWopLVBIvwxQjgeumcWA8VUp3Q ucJsXZMsg3EprwFW0ZElVREnZczyGOOMMosBiAvy07OMgZ1RFqUJyctx4IyxWdEmXWdiiQd0xgm2 FoxxOsLoO50pChEQ2V92DLMoRNjfGdC/+kgsqYX03sOY4Swi831cWhfW2SCTvOjx0hXRqF3B9HDV h6Ff8YaduJpZG2MWjrI4TEq7fGm809VJZ59iUQ0s7pSIlG2ckeZaBBsTi6tBH4clGbp7j0nWE7AK zNCRxSwFWI3Q3TS2bF3pCg6CJwE2f1Cav4JFiv4dTCPsDQ9o058KVnPL67+C1c0YyCRgrTRDw8zS BFg4ClxqcYjli2ZyudU0n1YzRu7woj0/q12M4lG2+jiLVoLlOc7qErVFFjdaI2G2wgibA/f6INNN R7oNToJuOI1RN7ZkBOsrxPbsxZqZYnMFWU1dal7sU9kgxHmS7drQYg5CbJxWOa4gHfcJttJxKfJo K8zeaSWtXDcdx4otAa1Sds6OwbrCizX0Rq/G32D57cfoovX0qSFK+x7PweCy/ffGtV88eZf7tX5J BOhKcC14CqXPztjiiRZie3qc7e3Am64U4xxYFtOwdI6vPM1pVGnlTTLNENsfdDXhRTtUcpTtsbfK 0P/Uvri4JzzS36YFpJOxguVqAs6ZN30euE+sqqysEbdFgrFoPDqUEFuisYloLJCIRMcrxM2jo+Ku yPBIIi7uCsfDsSPhUEVLYDQyGIt0JACDi3qNosQXcaCR2V3O2x2OxcGsWFVRWSmNlONIWi4SF8OR xEg4JgbEWHg4Ek+EY+GQmIgFQuGxQOywGKUjS7pDl/ZcjIyLYEb0jUcSoN+bCCTCcTEwHvKAgSib IBidHE/EIuF4xSUtdE8GSwLxUjEUFrfEotHEEg8D4lg0FI6Ni/HAeFyEqESGxKHAWGT0qDgFzovx ycHEaFiMwQShyPhwXAR/YCFjzAGYNzYOcaiAmIhD4UBiMgaexcKBUTHCQhEvE+NjAYh7MDABNFUZ mxxNRCbA5PjkWDgGkvFwghmIixOxKHhMHQbro6PRKXEE0iVGxiYCwQSLAs0eeAYq4mhkHOaCmA1G hplhnCgRviIBypHD4Yp0ElfHxbHA+FExOAkpR79pOMfDU2IsQJMSgWWDYmBMnJyg04DFYeDEI8dA PBGFBR2hSwqIU4HYGM5FAxwcCcTAsXCsYiSRmGj0eKampirG0vGvCEbHPImjE9HhWGBi5KgnmBiK jifikiilhwLg3GEq549OgotHxcl4GFyDrNBhMQARCcfGIgma9cGjzOk2X/dmGI2xDsQrNImRmRqJ BEeW6AJGxoOjkyFacFExFIlPjMIE1PeJWAQEgiAVHk9UiOm5o+MQ2JJIqRgeG6RKF02Np4Uv6RET p6UBYYpDDQYxf4uzs+KVbK1nDpREYBYoIVqdMVpooejU+Gg0sHRS8DmAnkIiFss8OpmYmExAGR+J BMNUZiQ8OrFiQct29PIt+86HlXc+rLzzYeWdDyvvfFh558PKOx9W3vmw8r/7YeUtb/TFf9N/09dp tTDLH0sVbHLM8kcRrkgVaAGmEI6kChoBJhESKBJPFawHiKUKNgBcjjCBEE0VbAQYRxhDhVGEw6n8 zQCHECKp/GaAkVR+C8AwwhBCGCGEEESFQVQIIAzg2EGEA6m8NoD9CPsQ9iLsQfAj9CNchrAbwYfQ h7ALoQdhJ8IOhO2pvFaAbdjrRuhC6EToQNiKsAWhHaENoTVl7wBoSdk7AZoRNiN4U/YugCaETSl7 N8BGhA0I6xEaEXoRGtBmPUIdGqtFqEFYhzarEapQby1CJYIHoQKhHI2Vobob9dbgWClCCcJqlCxG KEKFVQgu1CtESSeCiOBAKEDIT+VuB8hDsKdydwDkIuQgZOOYDcGKTAtCFoIZxzIRTMg0Yi8DwYBM PYIOQYugQVCncnYCqFI5PQBKBAWCHEGGIgL2eAQOgTDgFhDmES4wBe6f2PsHwusIryG8ivB3hL+l snsBXkH4ayq7D+AvCH9G+G+El1HkJYQ/IXMO4Y8If0D4PYr8DuG3CC/i2G8Qfo3wK4Rfosh/IfwC mS8gPI/wHMKzKdtugJ8j/Cxluwzgpwg/QeaPEX6EzPMIP0R4BuEHKPJ97H0Pe99FeBqZ30E4h/Bt hG8hfBMlv4Hwn8h8CuHrCE8inE1Z4VzivpayNgE8gfDVlHUvwOMIjyF8BeHLCI8ifAnhi6h3BmEW mY8gPIzwEMKDCA8gpBBOo14SffkC9j6PcD+KfA5hBuGzCPchfAb17kWFTyPzUwifRPgEwscRPoZw D8LdCHelLIMAdyLckbIEAT6asoQAPpKyhAE+nLIMAdyO8CGEDyJ8AOE2hFMIt6YsAYBb0Ob70eb7 0ObNCDeh6RtR4QaEaZT8DxS5PmXxAZxEY+9FY9chvAcl341WrkX1dyGcQLgG4WqE4whXIVyJcCxl gTOZO4ozXIGmpxCO4AyT6EsCIY7zxVD9coQJhCjCOMIYwijCYVzKIZwvgjCSstQCDCMMpbKuBQin smjthlJZ1wAEU1lUbxCZgVSWF2AAmQeReSCVdTXA/lTWuwH2pbKuA9ibMsMlzO1JmQsA/Aj9KbMG 4DKE3SkzXPOcL2WG+53rQ+hF2JUywzXP9aTMcLFzOxF2pDKp19tTme0A2xC6kdmF0InMDoStCFtS mXBvcu0o0obMVoSWlGkLQHPKRDfl5pSpH8CbMvkBmlKmPQCbEDamTLRaNyCsR2hEaEiZ3AD1KVMZ QF3K1ABQi1CTMtGJ1uFE1QhVKRON4FqEypSJBtKDUIG+lCOUoUtudGkNQim6VIKwGp0oRihCWIXg QoVClHSiSyI64cD5ChDyUTIPwY7quQg5CNkoaUOwooMWhCz004wTZSKYUM+IkIFgQNCjiA572pRx P4AmZTwAoE4ZDwKoEJQICgQ5SspQUkAmj8AhEO8C4ALIzQNegPZPaP+A9jrwXgPFV4H+O7S/QXsF 2l8zBh1/gfbnjKDjvzNCjpehvQTtT9DmgP9HaH+Asd9D/3fQfgvtRWi/Af6vof0K6F8C/he0X4Dc C9B/Htpz0J6F9nNoP4P2U8Ow4yeGEcePof0I2nloPwTeM4A/gPZ9aN+D/ncBn4b2HWjnoH0b2reg fRPaN6D9p/6w4yn9qOPr+jWOJwHP6sscXwPeE0B/VT/m8C48rj/keEwfcXxFP+L4Mow8ql/r+BK0 L0I7o7vcMauLOR7RxR0P6xKOh6A9CO0B6KcAT4NMEtoXoH0e2v3QPgdtBtpnod2nvdrxGe0xx73a o45PA35Ke5Xjk9rjjk8A/+PQPgbtHmh3Q7sL2p3Q7oD2UWgf0ZY7Pgztds29jg9pPuX4IOAHoN0G 7RS0WzUjjls01zrer/mo432aOx03a+523AT8G6FdJxQ53iPUO97N1Tuu9Z3wvWvmhO8a33Hf1TPH fdrjnPa4/XjX8SuPzxz/2XHvNoXmKt8x35Uzx3xHfVO+K2amfEdmJn2yyazJxKTw10luZpJrneQq JzmeTBonxUlBl/DFfPGZmI/EdsZOxJIx2fpk7IUYT2KcZnbh8Qdi9oJ2QO9VMb2x/XJf1DcxE/WN D435DoFbkfph38jMsG+oPuQLz4R8wfpBX6B+wHewfr/vwMx+3776Pb69M3t8/vp+32Ugv7u+z+eb 6fP11vf4ds30+HbUb/dtB/62+i5f90yXr7N+q69jZqtvS327rw2WTPKMeWKeYKQObM8DT4ida660 e+0v2F+2y4g9aX/cLmRm5Dpy+dKMHK5lRw4Xzbkm5305Qkb209m8N7u0rD3D9rTtedtLNpnZayut aCdWo1W0Cha6Nuu2vnaGTa2Ia2vYWrdZXcXtGRYuw+Kw8G0OC0dML5heNgmWx4xPG/mMDC4jYyGD 92aAeIbBYeDp24JB8BrW1rVn6B16nr4t6AWrVw8canG1bmdfe4bWoeV9TdodWt6rbWpp92rLK9uJ wIkcRzgjgKAC2Qc5i6NdeJT930LkhOPef7qv1+3umlUu7OpKqnfuTXLXJ4t66bu3Z09ScX2S+Pbs 7T/NcTf76R8R9iWz6H/0yPrX3XQTyW/uSub39qeEe+7Jb/Z3JU9Q2utl9AKlCYj43Qfik3G3O3EA 3g7EE272Cz1ukvbclEl/4wno059J1ifut3yhGMDBOLwSEi/x1kr/z764/20H/i9/ZR88QAj5P2qs QkMKZW5kc3RyZWFtCmVuZG9iagoKMzkgMCBvYmoKODM5OAplbmRvYmoKCjQwIDAgb2JqCjw8L1R5 cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvRUFBQUFBK0NhbGlicmktSXRhbGljCi9GbGFncyA2 OAovRm9udEJCb3hbLTQ3NiAtMTkzIDEyMTMgOTUzXS9JdGFsaWNBbmdsZSAtMzAKL0FzY2VudCA5 NTIKL0Rlc2NlbnQgLTI2OAovQ2FwSGVpZ2h0IDk1MgovU3RlbVYgODAKL0ZvbnRGaWxlMiAzOCAw IFI+PgplbmRvYmoKCjQxIDAgb2JqCjw8L0xlbmd0aCAyNzkvRmlsdGVyL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicXZHdboQgEIXveQoutxcb1P3rJsZk69bEi/6ktg+AMFqSCgTxwrcvDNs26QXkm5lz zHhgdXtttfLs1RnRgaeD0tLBbBYngPYwKk3ygkol/K3CW0zcEha83Tp7mFo9mLIk7C3MZu9WurlI 08MdYS9OglN6pJuPugt1t1j7BRNoTzNSVVTCEL7zxO0zn4Cha9vKMFZ+3QbLn+B9tUALrPO0ijAS ZssFOK5HIGWWVbRsmoqAlv9m4RfQ0g/ik7sgzYM0y47XKnCR+Bx5l3gfeY9coOaAfML+MWkOkU+p X0S+T/3HyOfEu8gX5EMT+SHps8h10uS48G2zuHrM9icSKhbnQhz4AJhDTEBp+H0ja2x04fkGETeH ZgplbmRzdHJlYW0KZW5kb2JqCgo0MiAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlw ZS9CYXNlRm9udC9FQUFBQUErQ2FsaWJyaS1JdGFsaWMKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAx MgovV2lkdGhzWzUwNiA3OTEgMjI5IDUxNCAzMDYgMzM0IDQ3NyAzNDIgNTE0IDQxNiA0OTggNTE0 IDUxNCBdCi9Gb250RGVzY3JpcHRvciA0MCAwIFIKL1RvVW5pY29kZSA0MSAwIFIKPj4KZW5kb2Jq Cgo0MyAwIG9iago8PC9MZW5ndGggNDQgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDIy NzIwPj4Kc3RyZWFtCnic7Zx5QFzVvfjPvXf2fYBZYIC5w7APzLATyMIkLGEJZiGjkJUBJgHD5izZ NBq1bmjUVmurVmNbq7VRM0yijsZqqmlsq9HWpq61Tdu0rtRo1VYj8L7nfu8QEuN7fX39vd8fT+A7 n3O+53u27/ecc88laDgYCRAN2Uk44u0d8o8O+5b2EEKeI4RJ6t0c5jeVnFgK6WOESD/aMLpxqKP+ DYYQ+VFClMkbB7dt+Nq188OEGN4iJPX5/oC/7/lD1/KEFMahjap+UHwyuVsO+ROQz+4fCm+9TTPa SYgrBfKDgyO9/su6mqF9107Izxnybx09xIxrIE/r88P+oYDr5PEuyL9CiOW7oyMh6IuDovqLaPlo MDDqeu8pH+S/Q4gpC3QMfNMvaIOR0TzLSaQyuUKpUmu0Or3BmJScYjJbrKlp5P/Kl/xOQqZumqW4 FL6/Q/aQh8hj5CfkF+TX5G+MinSTK8iT5E/kHfIhOQlulDMmJp0p+PeNY+py6RDRcgeJjFgImf5s +u2p+6bfhnWlm6W5CXIWSe4pzXTS9MSZuqmbpuJTz8vUxCDUNbDPgvYEMzH9GVtH89NVNM9eRdNC jRPyO6f2Tu0+bTijJEgiZCvZRraTC8kOcjG5hFxOriRXkavJNeCLSyB9LbmO7CLXkxvIjeTr5Bvk JnIz+Sa5hXyLfJvcSm4jt4Mf7yB3kt1iGc3fCd+3CKW05HvkHnIfuR/4fXI3+QG5l/wQ8j8C799P HgQdajD/AGjuIt8F7T2gpVZUtxe+o2ScxMg+sh9ihvlELk4OkofJI8BHIZoHyOPkx+QJiONBiOxT go5qEvkvt8TPp8kh8lNymDxDfkZ+DivjWTgHjpDnyQv/UslPZzQ090vyK/IirLWj5DfkJfIyeZW8 Tn5Hfk+OkT/CqnvvC+WvgMVrYPOGaPUHsPozeRssJ8AS7dDmt0LpW0ILR6HuMXKcUZCPGZacJNOQ otG7RYjQrUIcafRodO4W/EzjsRfyNEL3zsTmAfDxAxBPmqPp28RoPAi24+DBhP/O7rXnxeigvx8H G+oLWnJE9MUzYiRoO0/M1H1WKIsJ9Z6aafWUR3GGv5nlnd/O8uGfyV8Ez6D3sPSU96jFcbChXqZt nO7bP0Jd9D6tS/Wz69Cy1yD/NpwO74GnKd8VIvEueXMm/aZYPkH+St4nHwufJ8gHcJ78jXwE+U9A cwJyX9Seqfk7fP+DfEo+gwh+TiZn5SbPKJkkUxBjwjAMy3Bk6lTqlFYQCSNlZHCmKRglo2I0jJbR MXrGAJrTS9QzJcYvlGjOUqYUNElMMpMC56WFsTJpjA3OzQwmk7EzDiZrVlnqTAkPJU4mm8kRy8xC zdSZunawsMyyLWBKmC3w6WLcjAfSpUwFU8lUMzWgKYZ8GeRroaxE4CJv0/p1a9esXtXV6VvZsWL5 sqXntC9pa21pXtzU2FC/aKG3bsH8eXNra+ZUV1V63MVF+bk52c4suzXFaNBr1SqlQi6TSjiWIUWN zqZuPprbHZXkOpubi2ne6QeFf5aiO8qDqul0myjfLZjxp1t6wXLDGZZetPTOWDIGfh6ZV1zENzr5 6JEGJx9nVi3vhPSuBmcXH50Q0u1CWpIrZLSQcTigBt9o7W/go0w33xht2tw/1tjdAO2Nq1X1zvqA qriIjKvUkFRDKprvHB1n8hcwQoLNb6wdZ4lCS7uNcjmN/r7osuWdjQ02h6NL0JF6oa2orD4qF9ri B+iYybX8eNHBseviBtLT7dL0Ofv8azqjnB8qjXGNY2NXRY2uaIGzIVqw/bgVphyIFjkbGqMuJzTW tmKmAyYqzTE4+bGPCQzeOfHe6Rq/qJHlGD4mNEmnOOMmKE+kCYwNRgjzczjoWK6Ne0kPZKI7l3di nic9thjxelxdUbablhxMlJh8tGRnomSmerfTQUPV2C3+bO63Rnf28MVF4H3hJwd+oJyPcrndPb39 lP7AmLOhAf22sjPqbYCE1y/OtXG8xAP2/m6YxAB1w/LOqMc5Gk1xLkIDUPA0BgMdnUIVsVo0pT5K unvFWlFPYwMdF9841t2AA6RtOZd3PkrKp4+NV/C2feWkgnTRcUTN9RCU3Maxzr4NUXu3rQ/W5wa+ 0+aIervAfV3OzkAXjZLTEC04Bt05hB6FWjC3M6wTxnTm8hwF38nauC4aLVDwTfDhXDQPCgwQLiFL I7poHt/J2EjCDHoRLWjqtHYgw+XUN9Mijlatb7Y5uhz49Z8MySaOSZoTVcxqywCKmTFhP186NLSm AyrgGwMNswZ4WqNScYBia2cfJ0t9IXYMNRQ0nM2JIi4Hdi7oWGhGUNEoWvkoWcZ3OgPOLiesIe+y Tjo36mshvm0dzrblqzqFaIurZOVpOSyfg7kocUBxIsPWwxpsctkSYRXyi4X8TLb5jOKWRDE/pnC2 dYzRxp1ig4SHHQSTluW2+K+dk1QBW7MJTjdnk9/JG/imMX98emfP2LjXOzba2N1fS9twtvSNOTs6 59mEsa7o3GHbTrtKIm1M28pFxUVw9iwadzJXLx/3Mld3rOp8FO6t/NUrO2Msw9Z3L+oaz4ayzkd5 QryClqVaqqQZnmZoSysgoxDsbY96CdkplEoEhZDvjTNE0CkSOob0xlnUGRI6FnQS1HkFHf2CIFn7 wcVw3DbyfTQ8F3X1j3V30c1FzBBK+GGijHMBibLOBeMMK9NEVc7AoqjauYjq66i+DvUyqpfDwoDn HjiHnklj3U44p2BBdRIbg0uRo03y8enplZ2OI7aJLgcstTUgqzqjShec/dKcVrBbTKUb1IujO3v9 dBzE10nrynNaertg2SYaBJOWqBJaUIotgEWTUIcuR6jUC7GBAAr1d0ImurMr2uWinXYOdAnL2RAl zc5aCDu2Kc2lHXm6xpKcZcLehK2gyrmKQgljIx2dqLFBFjrrQifJNTDyXicU9Xbz4G0J6e2ApY5n qcqGmgAciZLcgCAqm1hI6LS4HLVWFVW6oUH4oWm1m25JaY68qwsHL+SuEg2gb0NUDSPKneVKsQJ4 B4pa6Fjg5yoYKjX9CW1meZyscG6Fk4UOWmhJDsVRbU6LHw5/rK8GjXNOorKCnhFqsY1DqJXTmWvA 71zOyvj0vc5tjllfxUVO+nCgC5PYHoWFTbrGzlREV7uKixRnarWCemxMoT17BfSXQjtDUMJrJryB hrjX4Y2RI3JSQ9rJOWTl40TL3AGvlbXMs/sbGhTF8icgyxKeeZYo4Pp4hzdZwmpttjpnpew6brmx pU5+HbuS1E3+7o3D8HEkqcZzhPG8MfHShGHysLHGM3F0orSEMTqMgqToWLlcJnNmudnKvNyq8vKy BWxlRa4zS8cKuoqq6gVceVkmy6UkNAtYmme41z9fyjVOZrPbHHM7SqWMK8diT1YoOHumNqec17e1 O6vy06QShYyTKuR5VYucvi2tWc+rrHnpGXlWFTAjHTj5lFT32YdS3cnzJA0nH2ffqulckC3bplWz UqXijvxMU3Zp+vw2rV4r1dksaelyhVGnKmz2T96almNRqSw5aek5tK2cyblwTNRNv81dJ80hLeQA bOJ6HzxlF7Lfeii7LLtMY4uz34kRjfsAU0yqiYopfthYDd/mefHpt/ar9cySeXGm2KtZaJMWdJit VGGOM50xr/RcYq1La59w1SXV1Ey4jDU1Ho9hwjDBeI5OJNEMONP2OHH/m5otLeli0NGShKMxIm6Z mJeZxEDQEJlSMmXcdUsue7C3PtQ5N00tUepVuvJlIy0lSyrTS9p7+nvaSxoju7vca5YtSJFLWU6u VatLmtZUu7wuk2dpX3/fOSXM1zbctrHCbM9KK3XbC9PUjnyHpXBBblFdqatkvi+8fO2utW6dNTNF Z3GmZeSnadIdNlNORYYLy0Pg913Tn0kWSFNIOelBvz9JStibiYOo2JuIiWSxh/cVFZmUcfY5r85L THkrHCqDbYXBJ/WBE+qoB+rAneANWKqwSMuoS73qs5mBe3KE6efm5jHGxIo0ip4yGRlcq6YUmZxh zGbJArW9qmBhTap8apsmsywvtzxTq80sz80ry9QwF8pT+LK8/Aq7Jil16g7mcrMyT21Uy1TQ6obJ 29QGtUwGH5Kn1QaVTKYyqCdfZXO1RpUEtCpjdt6UZ/KRAhvsww7Gwt3DnU+0xEYy9hOd3KR+HF7u JMQIn1bigY3HeMqPlMGmS5E5HVm5sKfKHWVm42k57h6LaVJqspgs7En4mJXm1JVFRZXlRUVTNVWF hVXlxXBOsGQXIZKDcE4kETu5IOH1ZPZ2OGbS2G8QJbGKC9AaZ9xepW65TVh9tjizElbfysTqm3Ax eCDA2fTP1kisUTp4ozD6TFZaAQvSaaRrVXJw7YOf3j/1rKO42MEseeCDH5w7dcK1/pvbrrhm8Obe Uva22ORdbXlFkv6ivOW73/n+mjvDCz+/cc4FP4R1tGlqN5suvZE4SdaTJI35DOZiYD4lMsKx4X0m u/oKUudhPJMvgUfBmTIIc5LFnIKHV56boxtEPKxYy8pzz1shMxfnp+fb9FzVsso0W9XSSlZjLeCz 3VZO2vn0lP+116d6DxssBoVErpb3//rl1y8Yff3lowNwWnFynRnXtewC8PE88ip62KvWlpRYPB6V 22pNi7N9+7NLNRoVJB4h2VXLUzVqKz1evMQ9fWK/wckuKY1Pn/DyNGUx0E8tflo8JaVumT1/ud2X lFjddUmWGhd8gY/LysrofpgoM5Yb6IexZr6nvNxYDkF66N/by8x2opvIyeg4wZOMc9bOok+ETNbC lNOtJewt2QXqjJKc7JJ0DTt1jSTJXpKVVWJP4qZuYdWZHtBnqKuK73cvKuE1jFXCZGntBXNyxm15 qdpsFe4klSTj5HHYSZyU7q/0k3+a0V9aXqV31hR+PskxhbXZeh3Uor8tt0z9lrmHccD+Mo0bSJy9 fl+S2pJODEfhuTZxuLQkR3iI4eirk2ceUPcoktJNV8qN1qy0jGwDI91uyKrIgWuQPp6/sLY646BK p5BKYWMzKXdmFZrlcnMh7Ks+rpbrlm6FvqpJ1rgNelsbU1fnAR5Kl2WZyxaTOtjL0O+Rlyaha8Y0 67FYLa4++Vm0ZnOKnP2L3l7KO9yZWrnBlnyJXG/hrWm8npFOsXp7icPhztDRgp20wJLGGySS+bdn FdCRFWTlemur0p9U6ZQSCXht6v0vKYAZtMJT8GHuZeIiFYwU1+2+5GRHUZytj7kqJHE26FU5uKLk ItZW9LQkPn3Qa9Ey7URikLBLlkm6JexdkqiElUjSPfAM26dn2im9PNh4jue2Wj8hOoOONXI6pVXD tCutYKD81JveLpwPky7X0fXr1k7AKeGCw3ztBevWuibWrQV3lb1BT3d6sCv/d/sWTis4aVPwSYqP B51s9lXGlFclXHjk3MMF2ZN/sM1du3BRX0uJXqlRcKxEoa1dFV60Zd/WuQs233f+6O4NJR9xq9eX LPakssxn7qKatQuzki3J8iRHqtlu1uusFuO87Y/t2PLkFU2LInet48/flj2/wwOr+OLpz9gDEJdy MopRGc/Vx9lur4ak6VV2lUfFaTkVnbaaaVfFmQ6vyutqzdWb+BbTErp56fOPnsDrqT8PTdQIZ7bq v7Y/daUQrgzyLz42TcKylbEHYK4qRUpqZpKpsLg0XQPbPKckQ6NKK7DzhRaVc8GcOenaTN6qlkpY ri3bnaaSK+TG7HlFk0dVehXsJb2KuyiRGilbmKvn5EqVxkT31cXTb0uIdJQUkvnkFpx/TOWoOsB2 ww3BxX7NqyQmVVWlQyItSVydSuJMm1eb22prMiypEZ5FNXGmFZ5F7YlnUR3EGk40eljCSUk98vC/ 2sYsL+WZvnixwI0tPOUEH5rNwqOOVPTcsLr4nMWN2erUwkx7Qaoq4bSshobm/N6x8/KnThoL68tT S8qrMiv9laUNxSnMe1ueuLLZmFtb4FfrVRKJSq+WOlV431BNJcNpqlt65b5IzfkrSnVZVflTrzQs Llu2AXzYDD6UwApKJnmnnvkpbASek5nwqSKp4qxT40yaV6lvdQozdsaZ9Nkznv3M/2drzHJPYtck nGESd5ZEMm97/MIt0fCc+dsfuXBrNDRnatJU1lE3Z2WVzVy6ckHNyqo05u3g41e3Lro4vjn446ta F14cv3TRyAp3wdKRxcDignNGYJ+0TL/NfgizbCFvn7rFu2du8Q3eLKKRuBn38Wq1ilG9aaz2wgYw VPPVLCdcvfXzmHn0iWgTrt/H6dW71WzQaJklxMwYJOYPZyYGO0m8f68VLuDr17oME2vh57TLvZf/ f9zbv3DnZz+s6b++o2x1c4lZI1FolGqX11eVVZmXkjO/fXn7/JyydVetLFzqLUpWSDhOrlEoc2va SrLKeEPugqXLly7IZTKXhM/J01uspuKiDKdJnpqZpkvLT8t08elZRd5Vdd5NSwo1SSa93mS32LJS 5CarSZfmTLEX8umOIm8XRGkucwM7h11L9MQYI3L1o/B4lsBdl/EcOeOeC5exOWbrVHeq2ZzK3KUx aqTM32vdnpo5bpU1nz7dm6ff4RzcS6SS3CGeC+kk7wk2THTEytjhepstrtHsOGOPJbdKHmOaSSk8 OtQQidIiYcEWxZmmmFeZeBAcdU3UwSeMZuJQmfB+9j9tCW9Ks58aEBMZhkRmmvVsgalI5dba1vPc G3cPVtdvvbsnv72+0qyUcikGY25Fc1lPf1p5e3lF25xcrVIjl0TTnFa9xZFm8O7YH77y6Z0L4FXL rLc6U2s96Vnp3/pG83Brjj3XrrIVCjeh6ffY6yXjpJbchL56xGjUzi0gzuI4uz5m0RYnzr1imOE+ Z3OGNqHQ0ilbmkvjzOKYVy4uSdjYR4TjoHyy7FCZER/Qj5Lif6UR9JBEvEvS6INDymcesSbxvQxe ElLMCWex16uTnJ7q9Lbh5qxNySn0sXG+OqM0OwcePk/RB0lK8tPuuSl8qlEuU8uk24s8yXq1LHfp 1hXMzz3VGfkW1TNwbkrhHgkJS35GtWdqbUuLXCmXm7LBW+apb3L7ucMkm/Sjtx5mlEodSYNTZNHD 3uw0XpVmjbMhr96rS7O3pKqSW1RtkqWkTbwqw1tpqseK76VphjfSAPR3KfRI0JzVHFzg4PB1pDqZ vqHmVlRVCdfn5PJkOmPhEnj5oHJZe36JlZVv0ZqkU0e01hqPqyxdJ3+ROyhLLqp21dgUU4dSzXKD 1ci4ZKk6rsKZY1JwmlTL5B7Wn2ZUKMw5qfQd0AZ3VYt4V80eL3LTu2o6vSCvfTgpXZ1nKU9cVl+a OGwQbqtnvShLz6rlLHJDWkriLqpnJJv1maXCHXVqK72lXiozWOyWNAdcXzfr7FgiNZx2G9UwhrNf U2cV0FXth/e+JHjvc5DsR2FeoViSSXoAXv/0xM6c3GdKU+GLH/0NlvDmR8dLh5ubW1FdlVRZwebl 4pgt5iQ2Ka1yaRWnt+WnFxSbZR3nneuTcqnFOfb8NDXXP8imXfD6y7/uhxc+iQJe/Q4xu19/jdn9 tNasg5c+hfTFqQ7wa9XUMeYxbi88Zz3EMZ6dcoC9huTCwOIPqeyuEqmeeI7gu8fRCdGps5+LxrO/ jTymc1QVFFQ5NBqkTmFMT7kM3k4cqelZ8HYSMTgqnFmlvJ4zF87J1uuz5xS6arMNhuzayS3C+8rj iTs+Y5h5X2HI0ul3JRqpk9SQa2dOT9cT7DPC6ekHl+aKezc3znTHkjskcWbVI5UlVvFy1ANn3bmJ s27m0Dx6SDw0/6UGTjsrk4QdcOYDbOa4lGg4mcpctzrScMVLtyzrvPONK6r6fA02lYyTwHT17pZA U/s2X5HnvAvbmza0eLQqjUJyKNWZmmTJdphXfP+j7/2AIQ+uSsrItSWl56ZnFqZpnC5nXeSe/uC9 g5WOfF5hdRG8e3Mvwu2zjAwl7hRqODDLClPgBr4vszDVkDjiDHGm3av0FrdmN6UukS7BvU0vQUk1 9C1GuDbF/jn7096uhcuS7CyXbyMeESbuRU06nnzJ2TW5JT2ViZtkgguvalm9oz0rK3HBZiYXtlZm NNVP7k1oZt8ivXXz+q/tTcz9AMy94tRv50rh1g23KPg0Eyf78L7iYrMqzj5CfztnzlJL81vSm4wz k4Ery2m/nTsu/HbubGazJvzP/HaOO6DOKMsvKHckyadePnO2jEKR4ijNzSm3a/T6qZOMW6N2qPRK qURp0DIvTeV/cc6ff8D0apIErVqflTz1ylRxSgbMfxu8Dz8HT4Eyskl871LnHWDXwaXZzq736pOL W/LU0tSWbKt4M2jf79W146wSv6CtE/Y6fb/w6v4Z89mRrxR/uX7KDcLyr6qeUXDPqVIL7I4Cq6r1 1hVrdrQ7hEcg+CApBxaCv1otuCRdMxP5jcuWzeu/ZgM7o5hSNAlLgV2e0GDcZUq4Ry8je8R5NyXD LWFfZmaZit4Wli3Io29fZcQwaynH2lqz46duSe2wJBa2LmgqntNSvCR1dqxnvUrUHJ2g/6yAL6T/ o8b+ix3zZVvIJD5lxeUlU2rSS3JySzLURmdlTvGaKlhTgj+NWVXZ7jWVZ77Xtt60rLqzscyY397W lte1vY2f8StrLD5ji31Rc+qNF8Jicc3LcS3IS563cayd/v0e/TtPlpDycvvn6/XzPiapCuHP+g68 e9Fzs/7mMCS7AJ5+DFFSWyLWk985+dqsvwRkzvhDRZtERwj3M1In6Sa7mBcg/TnpkKrJLvZiskk2 BTQQC3ch6ZPISSv7CrlY0gbSTpq5UtLChshcros0s4fB5hfEDHY2qOdnK0mVZB5ZSm1h5dA622SX kYuhvzuZVcyrzKtsCnsxe5gb4w5KHJIJ6aBMJ7tUvlK+TaFX3KM0K7crn1JZVXvUBer7NDmaN4VR 28hy+u9agicM8ETtJkSTziyE1wVaWsleRvDPZQnpEz45YbY6IccJtRQkKKY5uPluF9MSYiX7xbQU 0s+JaRmkj4tpOfmMfC6mFaSQ+URMKwnP8mJaxd7FesW0mpwrOSamNaRQWiWmtey3pd1iWkcG5f8Q 0waiUyTGaSQKRXAmTmWK7WKaIXLF/WKaJRLFPjHNkQzFI2JaQjSKo2JaCuljYloG6ffEtJzsUPxD TCuISRkR00piUI6JaRWzTHmbmFYTl+qdmb80NqlNYhpeTdWFYhrWkGazmDYQ+UzaSCSaHWI6iWg0 l8JoGYmSxkizS0xDjDQfiGmIkWZaTEOMtHIxDTHSLhTTECNtl5iGGGkvENMQI+01YhpipLtcTEOM dA+IaYiR7oiYhhgZh8Q0xMj4tJiGGBknxDTEKOUKMQ0xSkmME2KUkhhnErGa5OQ+wsMRWALflZBq JwOkF1bbCAmBbCBh0NVDKkhGhU8/aAYgNUzcULKQDMI3T1aAbiPph7KQkAsAA2C9GT77wLIe6g2C TQ/oBsgiqD8I+i/2VSv0NtuWn7GunTXOL7M5V+g1JI6Q2ruFGqfbF8/Yn9nOgDD+ADAMs6Ft8WDB AwMwP1oaFrR0VjykqT/6IDcEDJJNoBuZqXP20g3/LR/TEQ0LbdHR8MQHuQFhDLT/Dkj5hVxI6HMY tB5xBCOzZtALuQiUhoVZUmv3f2MMS6BuL8kHTYgUgFWfMJLFQl3ay9l9SD0wBOV9whjoHELCCENC KiDYUl9sAO0QpAfJNshtET1PbSLQYhj0AcH/OIM+wR8bhVZGxFbDgodPeQDnS/vEtUDXaYswvw2g ofOKCBEMiXH1Cyt4QPDloOCVECkSWh4SNINCi37wC+oTvQxBO4OCl0bFUQ6DZkjoFduk8wzPGgHt cVSYC/o44WEcO+1pBDzAw/xxN9FRDYGtH/oPz1oLib2GPsNeeGHsw+K8cJ31CJanRjx7RtRrW4V6 OOtNkHd/YfflCa0NCS1sE/wQEXf1bH8nViftfYvgVf/MThkQo4090ljz0MbozGxwjBtFG7pzt4ut h2EWGKHNM1HyC2uE7qah0+aVWMG9MBK/0H+v2L9b8FQYeqyFveGB2vTbLay509e/W1g3Q2AThrnS CG0UWhqFFraBlra4QYgXjeTprSb0dDWj5zbNtNclrF304jZh9iHBW2EhziFhXWJtXvAbXSMBYYYD Qh+413uEuglPN8JJsAROX6wbnFWC66tP2LOn1swWoa9eYU2drV/MU9te8HNE2LV9MzHoE8rpKscZ JPw+Ksx0WPQ8thUQPulKOnPetBxXbD7UKhDO2SGYV2BmDX1xVMNfaPmf99Gp1hOnBi/uezwHe0/b f1+c+6mT9/RxzZ3lAToTnAueQomzMzhzovUJe3pY2Nv+L50p+tl/mk8D4jl+5mlOvUpXXkSo2Sfs DzqbwEw71HJQ2GP/WYT+Xfvi1J7wCKOhewBPRrcQq1E4Z876/L+PLyspqeTbB3qDI6GRDWG+fiQ4 OhL0hwdGht38wsFBfsXAxv5wiF8RCAWCmwN97nr/4EBPcGDRyGDfTK1aXtTyVF0rtDlbc24gGIIG +TJ3SYmoL6b6hM1AiA8MhPsDQd7PBwMbB0LhQDDQx4eD/r7AkD+4iR+hJbOyG84+Yn5gmIdmeN/w QBjqd4T94UCI9w/3eaCBEaGD3pHIcDg4EAi5z9rCkkhvvj9UwPcF+MXBkZHwrBH6+aGRvkBwmA/5 h0M8eGNgA7/BPzQwuI3fAoPnQ5Ge8GCAD0IHfQPDG0M8jAcmMiQMAPoNDoMX3HxLmN8Q8IcjQRhZ MOAf5AfC0EdvqIgPDfnB373+UUjTKkORwfDAKDQ5HBkKBMEyFAgLDYT40eAIjJgOGFofHBzZwvdD mPiBoVF/b1jwAo0ajAyq8IMDw9AX+KxnYKPQMHYUDmwNQ+WBTQF3Inx5IX7IP7yN741AqHHc1J3D gS180E+DMgDThor+IT4ySruBFjeCJjSwHczDIzChzXRKfn6LPziEfVEH9/b7gzCwQNDdHw6P1no8 W7ZscQ8l/O/uHRnyhLeNjmwM+kf7t3l6wxtGhsMh0ZSmN/hhcJuoXddIBIa4jY+EAjA0iAot5v3g kUBwaCBMo96zTRh0o2/JQigNChnwV18EPbOlf6C3f1Zd4MBw72Ckjy64Eb5vIDQ6CB3QsY8GB8Cg F6wCw2E3n+h7ZBgcmz9QwAeGemilU00NJ4zPOiLBnC4NcFMI1mAvxm+md2Hxim3NFQaQPwC9wBKi qzNIF1rfyJbhwRH/7E5hzH4cKQRiZpmPRMKjkTAs480DvQFq0x8YHD1jQrN28uzN+tXLyFcvI1+9 jHz1MvLVy8hXLyNfvYx89TLyv/cy8qVP8ZnfzX/p17iSi7OfxjIz7HH2H7FMF+DvscwiwCeIjxEf YdnfMPch4gPECcT7iL+i5QTiPVS+i3gH8TbiLcSbiL8g/ow4HstUAv6EuT8i/hDLSAIci2WkAn4f y/AAfod4A/FbxOto8hrmXkW8gngZ8RLiN4ijiF8jXkT8CvFLxAuI53EQRxDPIZ5F/AK7/Tla/gzx DOIw4qeIQ4inEU8hfoI4iHgS23wC8WNUPo44gHgM8SgijngE8TDiIcR+xD5EDDEeSy8DRBF7Y+nl gAcRDyDuR+xB/CiWXgq4D/FDrHcv4h7EDxB3I76P+B5W/y7iLsRuxJ2IOxDfwaZvR9yG1W9FfBvx LcQtiG9ivZsRNyG+gfg64kbEDYjrseldWP06xLWIMcQ1iKuxwlWIKxFXIL6GuBxxWcxWAbgUsRNx CeJixA7ERYgLEdsR2xBbEVsQmxERRBgRQgQRFyBGESOxtErAMGIIMYjYhDgfMYDoR2xEbEAEEH2I XkQPwo/oRqxHrEOsRaxBrEasQnTFUqsBnYjzEOcifIiViA7ECsRyxDLEUsQ5iHbEEkQbohXRgmhG LEY0IRoRDYh6xCLEQoQXUYdYgJiPmIeYi6hF1MSsNYA5iGpEFaISUYEoR5QhShElCA/CjShGFCFc iEJEASIfkYfIReTELHMB2QhnzEJXclbMUgtwoJJH2BGZiAxEOsKGSEOkIqwIC8KMMGEPKdhDMiqT EEaEAaFH6BBahAahRqgQSmxTgZCjUoaQIiQIDsEiGAQRwEwjphCTiM8RJxGfIT5F/APxd6Fb5hNh RszHqPwI8TfEh4gPECcQ7yP+iphAvId4F/EO4m3EW4g3sb+/xMxOwJ8Rx2NmWFnMnxB/jJnnAP6A OBYz1wN+HzM3AH6HeAPx25i5EfB6zNwEeA3xKuIVbPplxEvY2G+wsaOIXyNexMZ+hfV+iXgB8Tzi COI5xLNY7xfY9M8RP8PBP4M4jP39NGZeBDiEFZ7Gjp7CUf8EGzuIeBLxBOLHiMcRBxCPYdOPYtNx bPoRbPphxEOI/djRPkQMMY7dRhF7EQ9i0w8g7kfsQfwIcV/MBAcu88OYaSHgXsQ9MVM74Acx0zmA u2OmpYDvx0wrAN+LmbyA76LJXWiyG03uRJM7sOw7aHk75m5Dy1sR38YK30LcEjMtA3wTq9+MuAnx DRzS19HyRrS8AXF9zLQcsAstr0NcixiLpXQCromldAGujqWsAVwVS1kLuDKW0gq4IpayGvA1LLsc LS9Dk0u9e4En9I3293XN9mOac+xPgfwE5CDIk+pz7TGQcZAoyF6QB0EeALkfZA/Ij0DuA/khyL0g 94D8AORukO+DfA/kuyB3gewGuVPVb78N5FaQb4N8C+QWkG+C3AxyE8g3QL4OcqOy334DyPUgu0Cu A4kzl8SS6e67OJZEV1IYEYoZ6UoKIi5AjCJGEMOIIcQgYhPifMQ8xNyYgaIWUYOYg6hGVCEqERWI ckRZTE+XZSmiBJGEMCIMCD1Ch9DGIAZxRoNQI1QIJUKBkMe0NLIy72rgX0EmQN4DeRfkHZC3IXq/ B/kdyBsgvwV5HeQ1kFchCq+AvAzyBMiPQR4HOQDyGMgd4PnvqKind6Knt8eMdIVvQ+dsRWxBbEZE EPWIReiHhQgvog6xADEfp2xCpCCSERditx0Y2RXY+3LEMsRSxDmIdsQSRBuiFdGCaEYsRjQhGhEN iCyEAwfII+yITEQGIh1hQ6QhUhFWnIMFYfbeDpwE+RzkJMhnIJ9CEP8B8neQT0A+BvkI5G8QuQ9B PgB5E+QvIH8GOQ7yJ5A/gvwBIngE5DmQZ0F+AfJzkJ+BPANyGOSnIIdAngaJgzwCUX0Y5CGQ/SD7 QG4XIrwDfXwRYiBmdAP6ERvRHxsQAUQfohfRg/AjuhHrEesQaxFrEKsRqxBdiE7EeYhzET7ESoQH 4UYfFyOKEC5EIaIAkY/IQ+QicjAo2QgnQoqQIDgEi2BwuxHv94DTIFMgb4FHXwL5DchRkF+DvAjy K5BfgrwA8jx4+FGQK7gc+9c4t/1yxm2/rHmn79I9O32XNO/wXbxnh0+9Y+6Oth2ceocNcOGOPTte 3yG7qHm778I9232S7SnbWdW25i2+rXu2+NRbGM3m5ohvZeR45KMIlxJZGemLhCM3R46CQn53ZH/k UISj/3FnUmTO3KadkRsjbAqUsyTC6KnaEVHrmsLNQV9oT9AnCVYE2bnHg8wvgwzLBxlvcFmQBat9 wez8Jmo9HTSnNZEgHywJchc0j/hG94z4hpuHfC8MMZtgKufDlAbcG339ezb6Nrj7fIE9fb5ed4/P 7+72rXev9a3bs9a3xr3Kt3rPKl+Xu9N3Htif617p8+1Z6etwL/et2LPct9R9ju8c0Le723xL9rT5 Wt3NvpY9zb5lzcxid5OvkauyEztDMuFnNHNn5olMibo7YzSDHc04lnEigxtNP5HOXmJj9GmXpN2Q xunhg8WPVHvqDam7U/emSvVCgtOMJu1MYkeNO41sidFr/KXxmFFCjHcZWf0N+t36vXpuqX69/n39 tF6yV8/s1T2pe0Hn7eaW6tbrRnScXkc1nMGrc5c26bV2rUfLzfNo67RLtdwNWsardZc1ebXZeU11 mqWa9Rput4bxanILmt5XTatYrwoK3ldOK9lpJUM4hmcYwhgAnAK8vJ8x2Zu4x4X/M6mUMMyN4ys7 XK62uHx6RVtUuWx1lLk6mtNBP73LV0VlV0eJb9XqznGGub6L/nHxymgK/Z8PCfkrdu0iGYvaohkd nTHurrsyFnW1RXfStNcrpKdpmoBJl2tdKBIKhV0hF3yArAuBJhyBHwEMfAIjYVoSDhEwcX3JVwgl FFkfgbqQWRcK0VYjLpqjQnv4v/vF/P8ewP/ZL+v6dYT8B1fowEoKZW5kc3RyZWFtCmVuZG9iagoK NDQgMCBvYmoKMTA2MjcKZW5kb2JqCgo0NSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0ZBQUFBQStDYWxpYnJpLUJvbGQKL0ZsYWdzIDQKL0ZvbnRCQm94Wy00OTIgLTE5MyAx MjM5IDk1M10vSXRhbGljQW5nbGUgMAovQXNjZW50IDk1MgovRGVzY2VudCAtMjY4Ci9DYXBIZWln aHQgOTUyCi9TdGVtViA4MAovRm9udEZpbGUyIDQzIDAgUj4+CmVuZG9iagoKNDYgMCBvYmoKPDwv TGVuZ3RoIDM0NS9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdks9ugzAMxu88RY7doSIB Cq2EkFoYEof90bo9AA2mQxohCvTA2y+2u03aAfSz89n5Eicsm6oxwxK+ukmfYRH9YDoH83RzGsQF roMJVCS6QS/3iP56bG0Q+trzOi8wNqaf8jwI3/zavLhVbI7ddIGHIHxxHbjBXMXmozz7+Hyz9gtG MIuQQVGIDnrf56m1z+0IIVVtm84vD8u69SV/gvfVgogoVmxFTx3MttXgWnOFIJeyEHldFwGY7t9a lHLJpdefrfNS5aVS7uLCc0ScnJBj4kgiJ8RxhbxjTYKcsmaPnHGeNHvOl8gHz5FUxEfKpzvkE3EW IZecJ66Ya+RH1pC3mntifyVZg3nF/jP0o9h/dkCOeV/Ss/+I8uw/xjMq9p9QH/af4lkU+09Jc+Ce 6Fnd/Vd0sfcbxCvGN/AzOqFvzvmx0UOheeGkBgO/b8lOFqvo+wYWxqg0CmVuZHN0cmVhbQplbmRv YmoKCjQ3IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VGb250L0ZBQUFB QStDYWxpYnJpLUJvbGQKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAyNgovV2lkdGhzWzUwNiA0NzIg NTQ2IDIyNiA0OTggNjMwIDMxMSA4NzQgMjU3IDQzNSA1MDMgMzU1IDUzNiA1MzcgMzk4IDMwNgo0 MTggMzQ2IDQ3MyA0MzUgMzExIDI3NSA1MjkgNTM2IDQ3OSA1MzYgODEzIF0KL0ZvbnREZXNjcmlw dG9yIDQ1IDAgUgovVG9Vbmljb2RlIDQ2IDAgUgo+PgplbmRvYmoKCjQ4IDAgb2JqCjw8L0YxIDM3 IDAgUi9GMiAzMiAwIFIvRjMgMjcgMCBSL0Y0IDQyIDAgUi9GNSA0NyAwIFIKPj4KZW5kb2JqCgo0 OSAwIG9iago8PC9Gb250IDQ4IDAgUgovUHJvY1NldFsvUERGL1RleHRdCj4+CmVuZG9iagoKMSAw IG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDIyIDAgUi9SZXNvdXJjZXMgNDkgMCBSL01lZGlhQm94 WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+ Pi9Db250ZW50cyAyIDAgUj4+CmVuZG9iagoKNCAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDIy IDAgUi9SZXNvdXJjZXMgNDkgMCBSL01lZGlhQm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJh bnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRydWU+Pi9Db250ZW50cyA1IDAgUj4+CmVuZG9iagoK NyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDIyIDAgUi9SZXNvdXJjZXMgNDkgMCBSL01lZGlh Qm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQi9JIHRy dWU+Pi9Db250ZW50cyA4IDAgUj4+CmVuZG9iagoKMTAgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVu dCAyMiAwIFIvUmVzb3VyY2VzIDQ5IDAgUi9NZWRpYUJveFswIDAgNzIwIDU0MF0vR3JvdXA8PC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMTEgMCBSPj4KZW5k b2JqCgoxMyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDIyIDAgUi9SZXNvdXJjZXMgNDkgMCBS L01lZGlhQm94WzAgMCA3MjAgNTQwXS9Hcm91cDw8L1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJH Qi9JIHRydWU+Pi9Db250ZW50cyAxNCAwIFI+PgplbmRvYmoKCjE2IDAgb2JqCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMjIgMCBSL1Jlc291cmNlcyA0OSAwIFIvTWVkaWFCb3hbMCAwIDcyMCA1NDBdL0dy b3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCL0kgdHJ1ZT4+L0NvbnRlbnRzIDE3IDAg Uj4+CmVuZG9iagoKMTkgMCBvYmoKPDwvVHlwZS9QYWdlL1BhcmVudCAyMiAwIFIvUmVzb3VyY2Vz IDQ5IDAgUi9NZWRpYUJveFswIDAgNzIwIDU0MF0vR3JvdXA8PC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0IvSSB0cnVlPj4vQ29udGVudHMgMjAgMCBSPj4KZW5kb2JqCgo1MCAwIG9iago8PC9D b3VudCA3L0ZpcnN0IDUxIDAgUi9MYXN0IDU3IDAgUgo+PgplbmRvYmoKCjUxIDAgb2JqCjw8L0Nv dW50IDAvVGl0bGU8RkVGRjAwNTAwMEUxMDA2NzAwNjkwMDZFMDA2MTAwMjAwMDMxPgovRGVzdFsx IDAgUi9YWVogMCA1NDAgMF0vUGFyZW50IDUwIDAgUi9OZXh0IDUyIDAgUj4+CmVuZG9iagoKNTIg MCBvYmoKPDwvQ291bnQgMC9UaXRsZTxGRUZGMDA1MDAwRTEwMDY3MDA2OTAwNkUwMDYxMDAyMDAw MzI+Ci9EZXN0WzQgMCBSL1hZWiAwIDU0MCAwXS9QYXJlbnQgNTAgMCBSL1ByZXYgNTEgMCBSL05l eHQgNTMgMCBSPj4KZW5kb2JqCgo1MyAwIG9iago8PC9Db3VudCAwL1RpdGxlPEZFRkYwMDUwMDBF MTAwNjcwMDY5MDA2RTAwNjEwMDIwMDAzMz4KL0Rlc3RbNyAwIFIvWFlaIDAgNTQwIDBdL1BhcmVu dCA1MCAwIFIvUHJldiA1MiAwIFIvTmV4dCA1NCAwIFI+PgplbmRvYmoKCjU0IDAgb2JqCjw8L0Nv dW50IDAvVGl0bGU8RkVGRjAwNEIwMDY1MDA3OTAwMjAwMDQ0MDA2NTAwNzIwMDY5MDA3NjAwNjEw MDc0MDA2OTAwNkYwMDZFPgovRGVzdFsxMCAwIFIvWFlaIDAgNTQwIDBdL1BhcmVudCA1MCAwIFIv UHJldiA1MyAwIFIvTmV4dCA1NSAwIFI+PgplbmRvYmoKCjU1IDAgb2JqCjw8L0NvdW50IDAvVGl0 bGU8RkVGRjAwNTAwMEUxMDA2NzAwNjkwMDZFMDA2MTAwMjAwMDM1PgovRGVzdFsxMyAwIFIvWFla IDAgNTQwIDBdL1BhcmVudCA1MCAwIFIvUHJldiA1NCAwIFIvTmV4dCA1NiAwIFI+PgplbmRvYmoK CjU2IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAwNTAwMEUxMDA2NzAwNjkwMDZFMDA2MTAw MjAwMDM2PgovRGVzdFsxNiAwIFIvWFlaIDAgNTQwIDBdL1BhcmVudCA1MCAwIFIvUHJldiA1NSAw IFIvTmV4dCA1NyAwIFI+PgplbmRvYmoKCjU3IDAgb2JqCjw8L0NvdW50IDAvVGl0bGU8RkVGRjAw NEIwMDY1MDA3OTAwMjAwMDQ0MDA2NTAwNzIwMDY5MDA3NjAwNjEwMDc0MDA2OTAwNkYwMDZFPgov RGVzdFsxOSAwIFIvWFlaIDAgNTQwIDBdL1BhcmVudCA1MCAwIFIvUHJldiA1NiAwIFI+PgplbmRv YmoKCjIyIDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jlc291cmNlcyA0OSAwIFIKL01lZGlhQm94WyAw IDAgNzIwIDU0MCBdCi9LaWRzWyAxIDAgUiA0IDAgUiA3IDAgUiAxMCAwIFIgMTMgMCBSIDE2IDAg UiAxOSAwIFIgXQovQ291bnQgNz4+CmVuZG9iagoKNTggMCBvYmoKPDwvVHlwZS9DYXRhbG9nL1Bh Z2VzIDIyIDAgUgovT3BlbkFjdGlvblsxIDAgUiAvWFlaIG51bGwgbnVsbCAwXQovT3V0bGluZXMg NTAgMCBSCj4+CmVuZG9iagoKNTkgMCBvYmoKPDwvQ3JlYXRvcjxGRUZGMDA0OTAwNkQwMDcwMDA3 MjAwNjUwMDczMDA3Mz4KL1Byb2R1Y2VyPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2 MDA2OTAwNjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMzMDAyRTAwMzI+Ci9DcmVhdGlvbkRh dGUoRDoyMDEwMDgwOTIwMDI0OSswMicwMCcpPj4KZW5kb2JqCgp4cmVmCjAgNjAKMDAwMDAwMDAw MCA2NTUzNSBmIAowMDAwMTA1NTYxIDAwMDAwIG4gCjAwMDAwMDAwMTkgMDAwMDAgbiAKMDAwMDAw MDUyNyAwMDAwMCBuIAowMDAwMTA1NzA1IDAwMDAwIG4gCjAwMDAwMDA1NDcgMDAwMDAgbiAKMDAw MDAwMDc2MSAwMDAwMCBuIAowMDAwMTA1ODQ5IDAwMDAwIG4gCjAwMDAwMDA3ODEgMDAwMDAgbiAK MDAwMDAxODk1MSAwMDAwMCBuIAowMDAwMTA1OTkzIDAwMDAwIG4gCjAwMDAwMTg5NzMgMDAwMDAg biAKMDAwMDAyMDA2MCAwMDAwMCBuIAowMDAwMTA2MTM5IDAwMDAwIG4gCjAwMDAwMjAwODIgMDAw MDAgbiAKMDAwMDAyMDI5NyAwMDAwMCBuIAowMDAwMTA2Mjg1IDAwMDAwIG4gCjAwMDAwMjAzMTgg MDAwMDAgbiAKMDAwMDAzNzA2OSAwMDAwMCBuIAowMDAwMTA2NDMxIDAwMDAwIG4gCjAwMDAwMzcw OTIgMDAwMDAgbiAKMDAwMDAzNzYzOCAwMDAwMCBuIAowMDAwMTA3NjIwIDAwMDAwIG4gCjAwMDAw Mzc2NTkgMDAwMDAgbiAKMDAwMDA0MzYzNiAwMDAwMCBuIAowMDAwMDQzNjU4IDAwMDAwIG4gCjAw MDAwNDM4NDggMDAwMDAgbiAKMDAwMDA0NDE0NiAwMDAwMCBuIAowMDAwMDQ0MzA4IDAwMDAwIG4g CjAwMDAwNjIxNDUgMDAwMDAgbiAKMDAwMDA2MjE2OCAwMDAwMCBuIAowMDAwMDYyMzYzIDAwMDAw IG4gCjAwMDAwNjI4NzQgMDAwMDAgbiAKMDAwMDA2MzIzMCAwMDAwMCBuIAowMDAwMDgzMzExIDAw MDAwIG4gCjAwMDAwODMzMzQgMDAwMDAgbiAKMDAwMDA4MzUyMiAwMDAwMCBuIAowMDAwMDg0MTIx IDAwMDAwIG4gCjAwMDAwODQ1NjAgMDAwMDAgbiAKMDAwMDA5MzA0NSAwMDAwMCBuIAowMDAwMDkz MDY3IDAwMDAwIG4gCjAwMDAwOTMyNjUgMDAwMDAgbiAKMDAwMDA5MzYxNCAwMDAwMCBuIAowMDAw MDkzODI0IDAwMDAwIG4gCjAwMDAxMDQ1MzggMDAwMDAgbiAKMDAwMDEwNDU2MSAwMDAwMCBuIAow MDAwMTA0NzU0IDAwMDAwIG4gCjAwMDAxMDUxNjkgMDAwMDAgbiAKMDAwMDEwNTQzMyAwMDAwMCBu IAowMDAwMTA1NTA2IDAwMDAwIG4gCjAwMDAxMDY1NzcgMDAwMDAgbiAKMDAwMDEwNjYzMyAwMDAw MCBuIAowMDAwMTA2NzU4IDAwMDAwIG4gCjAwMDAxMDY4OTUgMDAwMDAgbiAKMDAwMDEwNzAzMiAw MDAwMCBuIAowMDAwMTA3MTk0IDAwMDAwIG4gCjAwMDAxMDczMzIgMDAwMDAgbiAKMDAwMDEwNzQ3 MCAwMDAwMCBuIAowMDAwMTA3NzYwIDAwMDAwIG4gCjAwMDAxMDc4NjIgMDAwMDAgbiAKdHJhaWxl cgo8PC9TaXplIDYwL1Jvb3QgNTggMCBSCi9JbmZvIDU5IDAgUgovSUQgWyA8OTZCMEZFQUQyRENF REI0OTM1NzYzOEM3NzVENTU2RTk+Cjw5NkIwRkVBRDJEQ0VEQjQ5MzU3NjM4Qzc3NUQ1NTZFOT4g XQovRG9jQ2hlY2tzdW0gLzJFOTlCOTNFRjFGNUFGQkFDMEY1REJFMDkzRTQzQUQwCj4+CnN0YXJ0 eHJlZgoxMDgwNTMKJSVFT0YK --Apple-Mail-93-288219876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 El 09/08/2010, a las 20:10, Nicolas Williams escribi=F3: > On Fri, Aug 06, 2010 at 02:47:29PM -0400, Sam Hartman wrote: >> I do find it telling that several of the major Kerberos >> contributors--myself, Nico--think that gss-eap is a better fit than >> Kerberos today. >=20 > It's worth noting that some of us are usual suspects in the Kerberos > world. Sam and I, for example, have been active in the KRB-WG for = about > a decade (Sam probably for longer). And have authored or co-authored > Kerberos RFCs and reviewed many more. And we are or have been > implementors. >=20 > Normally one would expect people to boost the technologies they are = most > familiar with. But that is not what's happening here. There's a = reason > for this: Kerberos isn't the solution to every security problem, not = any > more than PKI is. >=20 >> I think I've answered in enough detail for a charter discussion in = the >> section on the feasability analysis. Ultimately, I think Kerberos is >> something to continue to think about, but several of us who are very >> familiar with Kerberos have tried to fit it into this model and = failed. >=20 > I think you have, but I'd like to explore a related angle. I hope = this > will help settle the desirability of Moonshot. >=20 > Let's consider the range of possible solutions here. We have some > authentication infrastructure that exists already but is neither PKI = nor > Kerberos. And we want this to be usable wherever SASL/GSS-API are > usable, as well as in web and non-web HTTP applications (but allow me = to > ignore the HTTP apps for now[*]). >=20 > I see two types of solutions: >=20 > - Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs > that issue short-lived certs) or Kerberos that uses the > existing authentication infrastructure. >=20 > - Type 2: Add a GSS-API (and therefore SASL/GS2) mechanism that uses > the existing authentication infrastructure. >=20 > Note that that type 2 is actually a... usable in type 1 solutions! >=20 > That's because SACRED already uses SASL... And we could easily define = a > Kerberos pre-authentication method that uses the GSS-API... (in fact, > I've proposed this in the past). >=20 > Clearly, by far the the most general solution is type 2 + a generic > variant of type 1 (i.e., where pre-authentication uses GSS = mechanisms). >=20 > In other words, if you want the most general solution you should want > _both_. And you should want to start with type 2 solutions. >=20 > Now, what does solution type 1 buy us over solution type 2? = Ticketing, > effectively, and the ability to combine multiple existing = authentication > infrastructures. If you have Radius... you can have Kerberos! Nice. >=20 > But if you don't need ticketing and you don't already have Kerberos = (or > PKI) deployed, then solution type 1 simply adds overhead, signficant > overhead. Enough overhead to make it unlikely to ever be deployed. >=20 > Which gets me back to the principle that Internet protocols should > support the authentication infrastructures that users have deployed. > Internet protocols should absolutely NOT dictate which authentication > infrastructures users must deploy. >=20 > Exceptions for protocols like IKE should be allowed but only because = we > can define additional KE protocols such as KINK, though I'd really > rather make IKE itself able to use a variety of authentication > infrastructures by making it pluggable (it alread is or is becoming, = via > EAP, but IMO it also needs direct GSS-API support for non-VPN uses of > IPsec). >=20 > [*] Back to HTTP... For non-web apps I think HTTP/Negotiate will do. > For web apps I think we need something more like a REST binding of > the GSS-API, with channel binding to https via tls-server-end-point > CB (though I can also see how to do it with tls-unique CB). >=20 > Nico > --=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail-93-288219876-- From Nicolas.Williams@oracle.com Mon Aug 9 15:07:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307AB3A691B for ; Mon, 9 Aug 2010 15:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Wt7vD24vVroC for ; Mon, 9 Aug 2010 15:06:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9D8B43A69D0 for ; Mon, 9 Aug 2010 15:04:57 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o79M5Hck010138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 22:05:19 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 o78LGRWN015354; Mon, 9 Aug 2010 22:05:16 GMT Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 480638391281391477; Mon, 09 Aug 2010 15:04:37 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 15:04:37 -0700 Date: Mon, 9 Aug 2010 17:04:32 -0500 From: Nicolas Williams To: Rafa Marin Lopez Message-ID: <20100809220432.GE5213@oracle.com> References: <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ED04531-3291-49AE-A549-23417652CECE@um.es> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 22:07:10 -0000 On Mon, Aug 09, 2010 at 11:50:14PM +0200, Rafa Marin Lopez wrote: > related the two types of solutions you just mentioned, we sent a few > months ago a small set of very preliminary slides (you may find an > attached version in this e-mail) to the moonshot mailing list > regarding the next two alternatives: > > -- EAP-based Kerberos pre-authentication where KDC is acting as EAP > authenticator (and Kerberos protocol acting as EAP lower-layer). Then, > the KDC can interface with a backend AAA infrastructure. With the key > material obtained after EAP authentication (e.g. MSK) it would be > possible to generate a shared secret between Kerberos client and KDC. So... the client speaks EAP and the NAS speaks krb5 AS exchanges to the KDC? or the client speaks Kerberos with EAP pre-authentication? The former is type 2, the latter is type 1. > -- a GSS-API based Kerberos pre-authentication where Kerberos uses > GSS-API to obtain pre-authentication data. In particular, the GSS > TOKEN could carry EAP as EAP-GSS approach specifies. (this could be > the generic variant of type 1?). This would be type 1, yes. > So, if my understanding is correct, I think first option (EAP-based > Kerberos pre-authentication) is a Type 1 solution and second option > (GSS-API based Kerberos pre-authentication) is an example of type 2 > use in type 1 solution, right?. I didn't understand your first option, and the second I understand to be what I called type 1. The key is: what does the client speak and to whom? If the client speaks first to infrastructure using Kerberos, with a pluggable pre-authentication framework using GSS-API mechanisms, then that's type 1. Similarly if the client speaks kca or SACRED using GSS-API mechanisms. If the client speaks SASL/GSS-API to the relying party (server) and the mechanism itself speaks EAP, IAKERB, and so on to infrastructure, then that's type 2. > Nevertheless, in terms of Kerberos, I believe that solutions which > bootstrap Kerberos credentials by means of some out-of-band mechanism > (so that they do not use Kerberos pre-authentication mechanism) may > not fit well in type 1 or type 2 solutions (as may happen with the > Hannes' I-D draft-tschofenig-pana-bootstrap-kerberos-00). Obviously, > unless the term "pre-authentication" in type 1 also includes an > "pre-authentication" mechanism different than Kerberos > pre-authentication. Do you refer to Kerberos pre-authentication in > type 1 or a more general "pre-authentication" mechanism?. I did not consider out-of-band solutions. Either those are uninteresting or they fall into type 1. Nico -- From cantor.2@osu.edu Mon Aug 9 15:25:49 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23C83A6878 for ; Mon, 9 Aug 2010 15:25:48 -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 Ds5STnIt9BzF for ; Mon, 9 Aug 2010 15:25:48 -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 EA7B23A69B6 for ; Mon, 9 Aug 2010 15:25:46 -0700 (PDT) Received: from defang9.it.ohio-state.edu (defang9.it.ohio-state.edu [128.146.216.78]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79MQKUj026845; Mon, 9 Aug 2010 18:26:20 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang9.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o79MQKLI013463; Mon, 9 Aug 2010 18:26:20 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" References: <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <01b201cb3809$20701ab0$61505010$@osu.edu> <20100809214120.GD5213@oracle.com> In-Reply-To: <20100809214120.GD5213@oracle.com> Date: Mon, 9 Aug 2010 18:26:23 -0400 Organization: The Ohio State University Message-ID: <01bc01cb3811$e5ea5410$b1befc30$@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: AQMolb8fzI/Y797JzYwAvu+fZ0mJ7gJz6boRAWWRJPsA2YRNDgKcd/inAoMuyYsBzFXbDgFbRqR+AkWCtEYCAN6ecAE6MCtKj4sf2NA= Content-language: en-us X-CanIt-Geo: ip=128.146.216.78; 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: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 22:25:49 -0000 > Do browsers support Negotiate with HTTPS and channel binding? Negotiate, certainly. I don't think CB are supported. My point is just that browsers aren't written by script kiddies, while other clients often are (or at least tend to be used by them). You seemed to be suggesting that the non-browser case was more likely to accommodate a more complex solution, which seems backwards to me. > If so, wow. If not, well, then I'd expect that the REST thing would work > better, provided there's some JavaScript bindings for the GSS-API and/or > a way to make authentication go from HTML. If you meant authentication of script code running within a browser (i.e JS), I didn't catch that implication. Even so, JS engines inside the browser are usually part of the browser code base. I don't know what REST buys you unless the goal is to support people that would want to write REST clients and servers. I think the security should be underneath that, or you're targeting the wrong developers and will end up with as little security as such people can agree to. -- Scott From Nicolas.Williams@oracle.com Mon Aug 9 15:37:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1ECD3A69E5 for ; Mon, 9 Aug 2010 15:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.109, 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 pKPZrb6X0ayj for ; Mon, 9 Aug 2010 15:37:07 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 139633A6B52 for ; Mon, 9 Aug 2010 15:35:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o79MZfum025319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 22:35:43 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 o795CGpw022206; Mon, 9 Aug 2010 22:35:41 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 500545341281393279; Mon, 09 Aug 2010 15:34:39 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 15:34:39 -0700 Date: Mon, 9 Aug 2010 17:34:34 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20100809223433.GG5213@oracle.com> References: <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <01b201cb3809$20701ab0$61505010$@osu.edu> <20100809214120.GD5213@oracle.com> <01bc01cb3811$e5ea5410$b1befc30$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01bc01cb3811$e5ea5410$b1befc30$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 22:37:09 -0000 On Mon, Aug 09, 2010 at 06:26:23PM -0400, Scott Cantor wrote: > > Do browsers support Negotiate with HTTPS and channel binding? > > Negotiate, certainly. I don't think CB are supported. We need HTTPS and CB. > My point is just that browsers aren't written by script kiddies, while other > clients often are (or at least tend to be used by them). You seemed to be > suggesting that the non-browser case was more likely to accommodate a more > complex solution, which seems backwards to me. Browsers also don't evolve fast enough in this space. I was hoping to be able to do a simple FF extension with JS bindings for the GSS-API and a JS method for doing GSS-API with CB in a RESTful fashion using well-known URIs (see host-meta). OTOH, if we can get XmlHttpRequest extended (in FF and IE) to support Negotiate with CB then we're golden. Non-browser apps can more easily have their HTTP libraries enhanced, or at least so I assume. But if my assumption is wrong then the GSS-API REST approach can still be used there. > > If so, wow. If not, well, then I'd expect that the REST thing would work > > better, provided there's some JavaScript bindings for the GSS-API and/or > > a way to make authentication go from HTML. > > If you meant authentication of script code running within a browser (i.e > JS), I didn't catch that implication. Even so, JS engines inside the browser > are usually part of the browser code base. I meant authentication of the user. The code to make that happen can't be delivered by the server because we want mutual authentication as well, and we can't trust the server's code for that. > I don't know what REST buys you unless the goal is to support people that > would want to write REST clients and servers. I think the security should be > underneath that, or you're targeting the wrong developers and will end up > with as little security as such people can agree to. REST buys you not having to modify HTTP implementations. For example, JavaScript XmlHttpRequest gives you everything you need to implement SCRAM with CB to tls-server-end-point in a RESTful way. The only thing is... the script can't be delivered by the server (see above); it has to be delivered by an extension. Nico -- From cantor.2@osu.edu Mon Aug 9 15:43:00 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A09A3A68EC for ; Mon, 9 Aug 2010 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 XSmCDitywTmq for ; Mon, 9 Aug 2010 15:42:59 -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 517B43A6878 for ; Mon, 9 Aug 2010 15:42:59 -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 o79MhX17003617; Mon, 9 Aug 2010 18:43:33 -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 o79MhXZ0030049; Mon, 9 Aug 2010 18:43:33 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" References: <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <01b201cb3809$20701ab0$61505010$@osu.edu> <20100809214120.GD5213@oracle.com> <01bc01cb3811$e5ea5410$b1befc30$@osu.edu> <20100809223433.GG5213@oracle.com> In-Reply-To: <20100809223433.GG5213@oracle.com> Date: Mon, 9 Aug 2010 18:43:36 -0400 Organization: The Ohio State University Message-ID: <01be01cb3814$4d8a6d10$e89f4730$@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: AQFlkST7hYZcLZjDxtr1R8sTFuhkBQDZhE0OApx3+KcCgy7JiwHMVdsOAVtGpH4CRYK0RgIA3p5wATowK0oBo5SJ7wFKsOtwkxiI5cA= 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: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 22:43:00 -0000 > Non-browser apps can more easily have their HTTP libraries enhanced, or > at least so I assume. But if my assumption is wrong then the GSS-API > REST approach can still be used there. I think that's not so clear. It definitely depends on the app and the library. > REST buys you not having to modify HTTP implementations. I get it. Thanks for clarifying. -- Scott From Nicolas.Williams@oracle.com Mon Aug 9 15:47:27 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43FA43A69A4 for ; Mon, 9 Aug 2010 15:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 GRODpfpDp3-e for ; Mon, 9 Aug 2010 15:47:26 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 53B083A6967 for ; Mon, 9 Aug 2010 15:47:26 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o79Mlwgi011611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 22:48:00 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 o795v9qt026863; Mon, 9 Aug 2010 22:47:58 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 500567911281394028; Mon, 09 Aug 2010 15:47:08 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 15:47:06 -0700 Date: Mon, 9 Aug 2010 17:47:01 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20100809224701.GH5213@oracle.com> References: <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <01b201cb3809$20701ab0$61505010$@osu.edu> <20100809214120.GD5213@oracle.com> <01bc01cb3811$e5ea5410$b1befc30$@osu.edu> <20100809223433.GG5213@oracle.com> <01be01cb3814$4d8a6d10$e89f4730$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01be01cb3814$4d8a6d10$e89f4730$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 22:47:27 -0000 On Mon, Aug 09, 2010 at 06:43:36PM -0400, Scott Cantor wrote: > > Non-browser apps can more easily have their HTTP libraries enhanced, or > > at least so I assume. But if my assumption is wrong then the GSS-API > > REST approach can still be used there. > > I think that's not so clear. It definitely depends on the app and the > library. Right. Apps should use either HTTPS/Negotiate with CB if possible or the REST thing if not. > > REST buys you not having to modify HTTP implementations. > > I get it. Thanks for clarifying. NP. IMO not requiring changes to HTTP implementations is key... From Nicolas.Williams@oracle.com Mon Aug 9 16:01:47 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7623A69E2 for ; Mon, 9 Aug 2010 16:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.105, 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 UeFlGBc9d3lM for ; Mon, 9 Aug 2010 16:01:47 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E00CD3A6967 for ; Mon, 9 Aug 2010 16:01:46 -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.2) with ESMTP id o79N2Ja7031831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 23:02:20 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 o79IcX4n010703; Mon, 9 Aug 2010 23:02:18 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 500590901281394839; Mon, 09 Aug 2010 16:00:39 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 16:00:39 -0700 Date: Mon, 9 Aug 2010 18:00:34 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20100809230033.GI5213@oracle.com> References: <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <01b201cb3809$20701ab0$61505010$@osu.edu> <20100809214120.GD5213@oracle.com> <01bc01cb3811$e5ea5410$b1befc30$@osu.edu> <20100809223433.GG5213@oracle.com> <01be01cb3814$4d8a6d10$e89f4730$@osu.edu> <20100809224701.GH5213@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100809224701.GH5213@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:01:47 -0000 > IMO not requiring changes to HTTP implementations is key... In particular I think the server-side of the REST thing can be implemented without any changes to the HTTP layer, and the client side only needs JavaScript bindings to SASL/GS2 or GSS-API -- again, no changes to the HTTP layer. The downside to the REST approach is that it is significantly chattier than HTTP/Negotiate. If request pipelining is not used (e.g., if HTTP/1.0 is used) then you have 4 or so IP packet round-trips per context token + the round-trips needed to fetch the host-meta, versus just 1 in the Negotiate case (+ the round-trips for TCP connect and shutdown). With pipelining it gets much closer to being as round-trip efficient as Negotiate. Is there a specification for how to do HTTP/Negotiate with CB? RFC4559 is clearly not it (since it pre-dates RFC 5056 and 5929). Among other things, how is server support for CB indicated to the client, and how does the client indicate that it is using CB? I.e., how is CB negotiated? Nico -- From rafa@um.es Mon Aug 9 16:18:38 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ED953A688A for ; Mon, 9 Aug 2010 16:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, 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 lxQUm5Qu6kH3 for ; Mon, 9 Aug 2010 16:18:37 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id 7D6B23A67B2 for ; Mon, 9 Aug 2010 16:18:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 5AE6553919; Tue, 10 Aug 2010 01:18:31 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NqyfnTG7xh-b; Tue, 10 Aug 2010 01:18:31 +0200 (CEST) Received: from [192.168.1.65] (unknown [83.35.104.108]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 23B4E53C9D; Tue, 10 Aug 2010 01:18:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <20100809220432.GE5213@oracle.com> Date: Tue, 10 Aug 2010 01:19:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:18:38 -0000 Hi Nico, thanks for the answer, please see my answer below... El 10/08/2010, a las 00:04, Nicolas Williams escribi=F3: > On Mon, Aug 09, 2010 at 11:50:14PM +0200, Rafa Marin Lopez wrote: >> related the two types of solutions you just mentioned, we sent a few >> months ago a small set of very preliminary slides (you may find an >> attached version in this e-mail) to the moonshot mailing list >> regarding the next two alternatives: >>=20 >> -- EAP-based Kerberos pre-authentication where KDC is acting as EAP >> authenticator (and Kerberos protocol acting as EAP lower-layer). = Then, >> the KDC can interface with a backend AAA infrastructure. With the key >> material obtained after EAP authentication (e.g. MSK) it would be >> possible to generate a shared secret between Kerberos client and KDC.=20= >=20 > So... the client speaks EAP and the NAS speaks krb5 AS exchanges to = the > KDC? or the client speaks Kerberos with EAP pre-authentication? [Rafa] We thought in a new Kerberos pre-authentication mechanism based = on EAP. That is,=20 EAP is directly transported in the padata field in Kerberos messages = (such as KRB_AS_REQ/KRB_AS_REP).=20 For example, this would imply definition of some new pa-data.=20 Thus, the client acts as EAP peer and Kerberos client, so it speaks EAP = and Kerberos. The flow would something like: client (EAP peer) <---EAP over Kerberos---> KDC (EAP authenticator) = <---EAP over AAA--> AAA infrastructure. (slide 3 shows a more specific signaling)=20 That is why I thought it would be type 1... unless I am missing = something?. >=20 > The former is type 2, the latter is type 1. >=20 >> -- a GSS-API based Kerberos pre-authentication where Kerberos uses >> GSS-API to obtain pre-authentication data. In particular, the GSS >> TOKEN could carry EAP as EAP-GSS approach specifies. (this could be >> the generic variant of type 1?). >=20 > This would be type 1, yes. [Rafa] Ok then the first alternative (EAP-based Kerberos = pre-authentication) is similar to this one,=20 since Kerberos interfaces directly with an EAP stack (instead the = GSS-API) >=20 >> So, if my understanding is correct, I think first option (EAP-based >> Kerberos pre-authentication) is a Type 1 solution and second option >> (GSS-API based Kerberos pre-authentication) is an example of type 2 >> use in type 1 solution, right?.=20 >=20 > I didn't understand your first option, [Rafa] I hope I was able to clarify it. > and the second I understand to be > what I called type 1. >=20 > The key is: what does the client speak and to whom? >=20 > If the client speaks first to infrastructure using Kerberos, with a > pluggable pre-authentication framework using GSS-API mechanisms, then > that's type 1. Similarly if the client speaks kca or SACRED using > GSS-API mechanisms. [Rafa] I am confused here. As far as I understood from the type 1, there = was no reference to GSS-API. So this type would include a pre-authentication mechanism which may not = include GSS-API=20 (as for example EAP-based Kerberos pre-authentication) "- Type 1: Add "pre-authentication" to PKI (via SACRED or online CAs that issue short-lived certs) or Kerberos that uses the existing authentication infrastructure." >=20 > If the client speaks SASL/GSS-API to the relying party (server) and = the > mechanism itself speaks EAP, IAKERB, and so on to infrastructure, then > that's type 2. [Rafa] So basically here in type 2 we define a new GSS-API mechanism = which is used=20 by the client (GSS Initiator) and application server (GSS Acceptor). = Then the application server speaks to the infrastructure with the mechanism = contained in the GSS token. Is this correct?. >=20 >> Nevertheless, in terms of Kerberos, I believe that solutions which >> bootstrap Kerberos credentials by means of some out-of-band mechanism >> (so that they do not use Kerberos pre-authentication mechanism) may >> not fit well in type 1 or type 2 solutions (as may happen with the >> Hannes' I-D draft-tschofenig-pana-bootstrap-kerberos-00). Obviously, >> unless the term "pre-authentication" in type 1 also includes an >> "pre-authentication" mechanism different than Kerberos >> pre-authentication. Do you refer to Kerberos pre-authentication in >> type 1 or a more general "pre-authentication" mechanism?. >=20 > I did not consider out-of-band solutions. Either those are > uninteresting or they fall into type 1. [Rafa] I believe that if they fall into type 1 then the term = "pre-authentication" here may not imply Kerberos pre-authentication.=20 On the other hand, (just curiosity): why do you think they are not = interesting?. Best regards >=20 > Nico > --=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From Thomas.Maslen@quest.com Mon Aug 9 16:26:55 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021473A68AC for ; Mon, 9 Aug 2010 16:26:55 -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 tNY-SD0KgaPW for ; Mon, 9 Aug 2010 16:26:54 -0700 (PDT) Received: from alvxetw01.quest.com (alvxetw01.quest.com [12.106.87.93]) by core3.amsl.com (Postfix) with ESMTP id 0E7423A688F for ; Mon, 9 Aug 2010 16:26:54 -0700 (PDT) Received: from alvxhtw02.prod.quest.corp (10.1.4.50) by alvxetw01.quest.com (10.1.100.93) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 9 Aug 2010 16:27:29 -0700 Received: from alvxmbw02.prod.quest.corp ([10.1.4.42]) by alvxhtw02.prod.quest.corp ([10.1.4.50]) with mapi; Mon, 9 Aug 2010 16:27:28 -0700 From: Thomas Maslen To: Scott Cantor , 'Nicolas Williams' Date: Mon, 9 Aug 2010 16:27:28 -0700 Thread-Topic: [abfab] Getting the charter done (Negotiate - HTTPS - channel binding) Thread-Index: AQHLOBpuO0p0bKkkY0Ob/IUXQXzZww== Message-ID: <723530449330F342A68634ADF3CE8DE2044C50C09E@alvxmbw02.prod.quest.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done (Negotiate - HTTPS - channel binding) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:26:55 -0000 Harking back a few messages: > Do browsers support Negotiate with HTTPS and channel binding? Internet Explorer (8, 7, and 6, maybe even 5?) does, as of October 2009 (KB= 974455, combined with previous KB 968389). [In fact, if (for whatever reason) you don't want this behaviour, you now h= ave to tweak a registry setting, "SuppressExtendedProtection"]. The umbrella name they used for this was "Extended Protection for Authentic= ation", which seems to cover a fair amount of channel-binding goodness, inc= luding the Negotiate-with-HTTPS case. I'm not sure whether other browsers running on Windows that call Windows SS= PI -- Firefox, fairly recent versions of Chrome, ...? -- now get this autom= agically or whether you have to tweak code to get the channel-binding bits = from the TLS code to the SPNEGO code.= From Nicolas.Williams@oracle.com Mon Aug 9 16:27:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DACD3A688F for ; Mon, 9 Aug 2010 16:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 IDddoibTGMAh for ; Mon, 9 Aug 2010 16:27:06 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6B93E3A68AF for ; Mon, 9 Aug 2010 16:27:06 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o79NRbxo000523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 23:27:40 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 o79MmTE1023317; Mon, 9 Aug 2010 23:27:37 GMT Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 480812991281396456; Mon, 09 Aug 2010 16:27:36 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 16:27:36 -0700 Date: Mon, 9 Aug 2010 18:27:31 -0500 From: Nicolas Williams To: Rafa Marin Lopez Message-ID: <20100809232731.GK5213@oracle.com> References: <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:27:07 -0000 On Tue, Aug 10, 2010 at 01:19:04AM +0200, Rafa Marin Lopez wrote: > El 10/08/2010, a las 00:04, Nicolas Williams escribió: > > On Mon, Aug 09, 2010 at 11:50:14PM +0200, Rafa Marin Lopez wrote: > >> related the two types of solutions you just mentioned, we sent a few > >> months ago a small set of very preliminary slides (you may find an > >> attached version in this e-mail) to the moonshot mailing list > >> regarding the next two alternatives: > >> > >> -- EAP-based Kerberos pre-authentication where KDC is acting as EAP > >> authenticator (and Kerberos protocol acting as EAP lower-layer). Then, > >> the KDC can interface with a backend AAA infrastructure. With the key > >> material obtained after EAP authentication (e.g. MSK) it would be > >> possible to generate a shared secret between Kerberos client and KDC. > > > > So... the client speaks EAP and the NAS speaks krb5 AS exchanges to the > > KDC? or the client speaks Kerberos with EAP pre-authentication? > > [Rafa] We thought in a new Kerberos pre-authentication mechanism based > on EAP. That is, EAP is directly transported in the padata field in > Kerberos messages (such as KRB_AS_REQ/KRB_AS_REP). > For example, this would imply definition of some new pa-data. Yes, that's type 1. > That is why I thought it would be type 1... unless I am missing > something?. Nope, it's type 1. > > I didn't understand your first option, > > [Rafa] I hope I was able to clarify it. You did :) > > The key is: what does the client speak and to whom? > > > > If the client speaks first to infrastructure using Kerberos, with a > > pluggable pre-authentication framework using GSS-API mechanisms, then > > that's type 1. Similarly if the client speaks kca or SACRED using > > GSS-API mechanisms. > > [Rafa] I am confused here. As far as I understood from the type 1, > there was no reference to GSS-API. So this type would include a > pre-authentication mechanism which may not include GSS-API > (as for example EAP-based Kerberos pre-authentication) There could be. You're using EAP for pa-data. But you could have used GSS-API. And you could have defined a GSS-API mechanism that uses EAP. Can you see now what I meant about generality? If we have a GSS-API mechanism that can use EAP... and we can use GSS-API in Kerberos pa-data... and other places (SACRED, kca, ...; see the list I posted)... > > If the client speaks SASL/GSS-API to the relying party (server) and the > > mechanism itself speaks EAP, IAKERB, and so on to infrastructure, then > > that's type 2. > > [Rafa] So basically here in type 2 we define a new GSS-API mechanism > which is used by the client (GSS Initiator) and application server > (GSS Acceptor). Then the application server speaks to the > infrastructure with the mechanism contained in the GSS token. Is this > correct?. Yes. But note that the GSS-API doesn't force you to have one or the other of the initiator and acceptor to talk to infrastructure. You can do it either way. In Moonshot the acceptor talks to infrastructure. In Kerberos the initiator talks to infrastructure. A PKI mechanism could have both, the initiator and the acceptor, talk to infrastructure (namely, to OCSP responders). > > I did not consider out-of-band solutions. Either those are > > uninteresting or they fall into type 1. > > [Rafa] I believe that if they fall into type 1 then the term > "pre-authentication" here may not imply Kerberos pre-authentication. Right. > On the other hand, (just curiosity): why do you think they are not > interesting?. Well, to be honest I haven't thought enough about non-pre-authentication types of out of band solutions. So I was rash to call them uninteresting. My intuition says that there aren't any such solutions that can't be thought of as pre-authentication (i.e., type 1). Nico -- From Nicolas.Williams@oracle.com Mon Aug 9 16:34:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00B033A6967 for ; Mon, 9 Aug 2010 16:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.101, 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 t5wSZ+ID+aPj for ; Mon, 9 Aug 2010 16:34:29 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1116C3A68AF for ; Mon, 9 Aug 2010 16:34:29 -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.2) with ESMTP id o79NZ2Nf011907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Aug 2010 23:35:03 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o79KeHP3016561; Mon, 9 Aug 2010 23:35:01 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 500651791281396834; Mon, 09 Aug 2010 16:33:54 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Aug 2010 16:33:54 -0700 Date: Mon, 9 Aug 2010 18:33:49 -0500 From: Nicolas Williams To: Thomas Maslen Message-ID: <20100809233349.GM5213@oracle.com> References: <723530449330F342A68634ADF3CE8DE2044C50C09E@alvxmbw02.prod.quest.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <723530449330F342A68634ADF3CE8DE2044C50C09E@alvxmbw02.prod.quest.corp> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] Getting the charter done (Negotiate - HTTPS - channel binding) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:34:30 -0000 On Mon, Aug 09, 2010 at 04:27:28PM -0700, Thomas Maslen wrote: > Harking back a few messages: > > Do browsers support Negotiate with HTTPS and channel binding? > > Internet Explorer (8, 7, and 6, maybe even 5?) does, as of October > 2009 (KB 974455, combined with previous KB 968389). > > [In fact, if (for whatever reason) you don't want this behaviour, you > now have to tweak a registry setting, "SuppressExtendedProtection"]. > > The umbrella name they used for this was "Extended Protection for > Authentication", which seems to cover a fair amount of channel-binding > goodness, including the Negotiate-with-HTTPS case. Or Integrated Windows Authentication. I'm aware of this. I'm asking if there's documentation on how CB is negotiated, if at all. IIRC what happens is that the initiator just uses CB, and backwards compatibility just results from either a) krb5 acceptors ignoring CB when the acceptor app does not provide any, b) NTLMSSP negotiating CB?? > I'm not sure whether other browsers running on Windows that call > Windows SSPI -- Firefox, fairly recent versions of Chrome, ...? -- now > get this automagically or whether you have to tweak code to get the > channel-binding bits from the TLS code to the SPNEGO code. Using SSPI alone does not get you this. Nico -- From gabilm@um.es Tue Aug 10 01:20:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3ADB3A6A7A for ; Tue, 10 Aug 2010 01:20:24 -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 pYyFMpmNdFcd for ; Tue, 10 Aug 2010 01:20:22 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by core3.amsl.com (Postfix) with ESMTP id 6F5023A6A76 for ; Tue, 10 Aug 2010 01:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 9AD2D5D4AB; Tue, 10 Aug 2010 10:20:38 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aYXRrbsvQdvD; Tue, 10 Aug 2010 10:20:38 +0200 (CEST) Received: from MacBook-Pro-de-Gabriel-Lopez.local (141.Red-88-22-76.staticIP.rima-tde.net [88.22.76.141]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id 2CF8E5D47C; Tue, 10 Aug 2010 10:20:32 +0200 (CEST) Message-ID: <4C610BDF.4000204@um.es> Date: Tue, 10 Aug 2010 10:20:47 +0200 From: Gabriel Lopez User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Nicolas Williams References: <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> In-Reply-To: <20100809232731.GK5213@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 08:20:24 -0000 Hi Nico, all, El 10/08/10 01:27, Nicolas Williams escribió: > >> [Rafa] I am confused here. As far as I understood from the type 1, >> there was no reference to GSS-API. So this type would include a >> pre-authentication mechanism which may not include GSS-API >> (as for example EAP-based Kerberos pre-authentication) >> > There could be. You're using EAP for pa-data. But you could have used > GSS-API. And you could have defined a GSS-API mechanism that uses EAP. > > Can you see now what I meant about generality? If we have a GSS-API > mechanism that can use EAP... and we can use GSS-API in Kerberos > pa-data... and other places (SACRED, kca, ...; see the list I posted)... > > > This is the second proposal described in the slides Rafa sent yesterday. Best regards, Gabi. -- ---------------------------------------------------------------- Gabriel López Millán Departamento de IngenierÌa de la InformaciÛn y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From alper.yegin@yegin.org Tue Aug 10 05:30:40 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 300CE3A698C for ; Tue, 10 Aug 2010 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 7uhFtd28MkFn for ; Tue, 10 Aug 2010 05:30:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 35A8A3A69BF for ; Tue, 10 Aug 2010 05:30:39 -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 0MfEpO-1OYJLa2BTu-00OteO; Tue, 10 Aug 2010 08:31:12 -0400 From: "Alper Yegin" To: "'Nicolas Williams'" , "'Klaas Wierenga'" References: <4C5B3C5D.7000607@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E605102C@EXC001.atlas.ukerna.ac.uk> <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> In-Reply-To: <20100806210111.GC5213@oracle.com> Date: Tue, 10 Aug 2010 15:31:06 +0300 Message-ID: <016b01cb3887$eaf36070$c0da2150$@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 Thread-Index: Acs1ry9XoA0zlna9SyCESp8HtkGu8wC2Jl/Q Content-Language: en-us X-Provags-ID: V02:K0:LoGfyeX2ST7pw2kCY2m2n0VuKFChqkHmV2vumsEzR/g PkSL+W7vu4g6PdBZk6X7bo0DMgYbpY7s1iYhML5qj9/mB4h7PE 03M1eRrXqEGog6BsoAKdx0PizqA5uSe5KVtwAM/jgcT59adkYw lJXSjBmfSADWJ0btYcM3bAxJEhnEOMtQ4G4slwrmN3ncN8fkjF AxbbJ1u3KBeGgmoKiO5msvpa1dYy8120IK+UUDD2Zw= Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:30:40 -0000 > It is necessary for the IETF to eliminate unnecessary redundancy for > the > simple reason that review capacity is limited. And also multiplicity of options works against interoperability. From rafa@um.es Tue Aug 10 05:51:35 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA673A68AC for ; Tue, 10 Aug 2010 05:51:35 -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 mnPBUtxULZKc for ; Tue, 10 Aug 2010 05:51:34 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 87CCC3A684C for ; Tue, 10 Aug 2010 05:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 2504F4BC5B; Tue, 10 Aug 2010 14:51:30 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7zlHdUgy2+rF; Tue, 10 Aug 2010 14:51:29 +0200 (CEST) Received: from [192.168.1.35] (52.Red-80-33-78.staticIP.rima-tde.net [80.33.78.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id 0E7664BC82; Tue, 10 Aug 2010 14:51:25 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Rafa Marin Lopez In-Reply-To: <20100809232731.GK5213@oracle.com> Date: Tue, 10 Aug 2010 14:51:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> References: <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:51:36 -0000 Hi Nico,=20 >=20 >>> The key is: what does the client speak and to whom? >>>=20 >>> If the client speaks first to infrastructure using Kerberos, with a >>> pluggable pre-authentication framework using GSS-API mechanisms, = then >>> that's type 1. Similarly if the client speaks kca or SACRED using >>> GSS-API mechanisms. >>=20 >> [Rafa] I am confused here. As far as I understood from the type 1, >> there was no reference to GSS-API. So this type would include a >> pre-authentication mechanism which may not include GSS-API=20 >> (as for example EAP-based Kerberos pre-authentication) >=20 > There could be. You're using EAP for pa-data. But you could have = used > GSS-API. And you could have defined a GSS-API mechanism that uses = EAP. >=20 > Can you see now what I meant about generality? If we have a GSS-API > mechanism that can use EAP... and we can use GSS-API in Kerberos > pa-data... and other places (SACRED, kca, ...; see the list I = posted)... [Rafa] As Gabi just mentioned, that is the reason (gain flexibility) of = our second proposal "GSS-API based Kerberos pre-authentication", which = precisely transports GSS tokens in pa-data.=20 However, I feel that, in terms of implementation, it could be easier to = implement directly interface EAP - Kerberos (already specified in some = sense in RFC 4137) than implementing EAP over GSS-API first and then = GSS-API over Kerberos. At least two new implementations may be required = in the second alternative. What do you think? >=20 >>> If the client speaks SASL/GSS-API to the relying party (server) and = the >>> mechanism itself speaks EAP, IAKERB, and so on to infrastructure, = then >>> that's type 2. >>=20 >> [Rafa] So basically here in type 2 we define a new GSS-API mechanism >> which is used by the client (GSS Initiator) and application server >> (GSS Acceptor). Then the application server speaks to the >> infrastructure with the mechanism contained in the GSS token. Is this >> correct?. >=20 > Yes. But note that the GSS-API doesn't force you to have one or the > other of the initiator and acceptor to talk to infrastructure. You = can > do it either way. In Moonshot the acceptor talks to infrastructure. = In > Kerberos the initiator talks to infrastructure. [Rafa] I am not sure if I understand this. When you say the initiator = talks to the infrastructure in Kerberos... what do you mean?. In our = proposal, the KDC, acting as acceptor, talks to the AAA infrastructure. = So I am a little bit confused here. >=20 > A PKI mechanism could have both, the initiator and the acceptor, talk = to > infrastructure (namely, to OCSP responders). >=20 >>> I did not consider out-of-band solutions. Either those are >>> uninteresting or they fall into type 1. >>=20 >> [Rafa] I believe that if they fall into type 1 then the term >> "pre-authentication" here may not imply Kerberos pre-authentication.=20= >=20 > Right. >=20 >> On the other hand, (just curiosity): why do you think they are not >> interesting?. >=20 > Well, to be honest I haven't thought enough about = non-pre-authentication > types of out of band solutions. So I was rash to call them > uninteresting. My intuition says that there aren't any such solutions > that can't be thought of as pre-authentication (i.e., type 1). [Rafa] I also believe those kind of solutions could be classified as = type 1, as long as we consider them as mechanisms which are used to = authenticate user before KDC provides a TGT, for example. This mechanism = can be part of the traditional Kerberos pre-authentication or potential = out-of-band mechanisms. Best regards. =20 >=20 > Nico > --=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From alper.yegin@yegin.org Tue Aug 10 05:57:55 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D83373A69A9 for ; Tue, 10 Aug 2010 05:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 Tn6qonqTL3IK for ; Tue, 10 Aug 2010 05:57:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 72B293A6990 for ; Tue, 10 Aug 2010 05:57:54 -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 0LfTF3-1PFiRM2XHd-00p0Jl; Tue, 10 Aug 2010 08:58:28 -0400 From: "Alper Yegin" To: "'Leif Johansson'" , References: <4C5B3C5D.7000607@sunet.se> In-Reply-To: <4C5B3C5D.7000607@sunet.se> Date: Tue, 10 Aug 2010 15:58:23 +0300 Message-ID: <016c01cb388b$b9f609b0$2de21d10$@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 Thread-Index: Acs07lTQxD8rBiZ6Ra2LS55S+1bMzgDnRu1Q Content-Language: en-us X-Provags-ID: V02:K0:j3WQUZO+Tb37alIP5WYDixEE0yl11jFFjH0rzRnbbjn 5bdmVaZgDe6YKUDmflEx6uVz4lSLUg/IuuEybNyfOdSmAokIYG XR7swA4AhGmHJVP6bV9JSbs+6Ia6T/NvZ2wRnyZRTvlE6his10 TmlJuxal20PGVAty9SspMaVKDXcuXfxLQTt9EgMkTozWsmhx2V RnSoXgUwFXFS/XKRqXrYksX3G+Q9/F+FlJIkDnhw1s= Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:57:55 -0000 Hi Leif, Are we expecting to see a revised charter that reflects the documented consensus? The referenced text does not seem to do that. Alper > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Leif Johansson > Sent: Friday, August 06, 2010 1:34 AM > To: abfab@ietf.org > Subject: [abfab] Getting the charter done > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Folks, > > We're still working off of the version of the charter online at > > * http://www.project-moonshot.org/bof/charter > > Before and during the BoF session in Maastricht we had a few > proposals and a few things have surfaced since then. > > Acting as one of the BoF chairs I'd like to kick off a discussion > that will hopefully lead to a charter that both the community and > the IESG likes. > > Here is what Sam sent to the moonshot list on 26/7: > > 1) cover descriptions of issues that may require changes such as > user-interface in the architecture document; I think this is in the > current charter text. > > 2) Explicitly call out that when thinking about user interface we need > to consider the elements of information that will be required for user > interface. For example Eliot gave the example of a banking interface > that requires information of who you are paying, what you are paying > for > and how much you are paying. We'd need to explore which of these > elements are needed where and do the same for other use cases. > > 3) Explicitly say that we want to hold to WG open to do a revision of > the architecture based on ongoing work including ongoing user interface > work throughout the industry. > > During the BoF session there was consensus (by my interpretation) > around > (2) at least. > > - From the excellent notes we have the following AIs: > > 1) Make privacy more explicit in moonshot related materials - including > the charter. > 2) Charter needs to specifically mention liaison with OASIS about the > SAML RADIUS binding. > 3) Order deliverables in the charter in a more logical fashion. > 4) Charter needs use-cases and architectures as deliverables. > 5) In the charter, change "within the GSS-API" to "within the > application" on the 4th deliverable for broader applicability. > > There was also consensus on the moonshot list (by my interpretation) > that the charter should explicitly make alternatives to GSS-API in > scope for the WG. > > Finally Elliot has suggested a simplification of the introductory text > in the charter - Elliot: could you send your latest version to the > list? > > I'd be perfectly happy to attempt a new version of the charter based > on this set of changes. > > Cheers Leif > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxbPFgACgkQ8Jx8FtbMZndI8wCfS5N+qjfab/sQQboQ7m3reGl9 > JpsAnjqOSbgVW/hJ1WQTFTUEtF7YXOUH > =A3L9 > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Tue Aug 10 06:00:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67063A69CD for ; Tue, 10 Aug 2010 06:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 vb+5XYH4fnUc for ; Tue, 10 Aug 2010 06:00:13 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 19D343A6835 for ; Tue, 10 Aug 2010 06:00:12 -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 C1C41204EE; Tue, 10 Aug 2010 09:00:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C73C64129; Tue, 10 Aug 2010 09:00:39 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> Date: Tue, 10 Aug 2010 09:00:39 -0400 In-Reply-To: <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> (Rafa Marin Lopez's message of "Tue, 10 Aug 2010 14:51:59 +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: abfab@ietf.org, Nicolas Williams Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:00:14 -0000 Your proposal includes a type 2 inside a type 1. Mechanisms such as iakerb can convert a type 1 into a type 2. From Nicolas.Williams@oracle.com Tue Aug 10 06:34:42 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8BB3A69DB for ; Tue, 10 Aug 2010 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, 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 KPKFnsdKcs5s for ; Tue, 10 Aug 2010 06:34:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4CD923A6A13 for ; Tue, 10 Aug 2010 06:34:29 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7ADYwWa020216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2010 13:35:00 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 o7A256UK001001; Tue, 10 Aug 2010 13:34:58 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 482724771281447207; Tue, 10 Aug 2010 06:33:27 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Aug 2010 06:33:26 -0700 Date: Tue, 10 Aug 2010 08:33:21 -0500 From: Nicolas Williams To: Alper Yegin Message-ID: <20100810133321.GR5213@oracle.com> References: <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <016b01cb3887$eaf36070$c0da2150$@yegin@yegin.org> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:34:42 -0000 On Tue, Aug 10, 2010 at 03:31:06PM +0300, Alper Yegin wrote: > > > It is necessary for the IETF to eliminate unnecessary redundancy for > > the > > simple reason that review capacity is limited. > > And also multiplicity of options works against interoperability. Depends on the context, but, largely that is true. In this context the use of pluggable authentication frameworks helps. These frameworks are often implemented as pluggable frameworks as well (that is, they aren't pluggable in name only). Indeed, I would argue that the main hurdle in terms of security interop in Internet protocols has been the uneven use of different frameworkd in different protocols: - IPsec? -> PKIX (OK, now there's KINK as well) - TLS? -> PKIX - NFSv4? -> GSS-API -> Kerberos (even though the GSS-API is pluggable, until recently Kerberos was the only standard option) - SSHv2? -> PK, GSS-API - IMAP, SUBMIT/SMTP, LDAP? -> SASL -> DIGEST-MD5 and Kerberos - ... That is a recipe for non-interoperability as well. We've been doing our best to rectify this over the years. The main way in which we've been trying to rectify this situation has been to bridge security frameworks. For example, the SASL/GS2 framework, which allows GSS-API mechanisms to be used in SASL generically (and which fixes problems in the original SASL/GSS bridge). Your interop argument ignores the argument I made earlier, too, that requiring users to deploy authentication infrastructures other than those they already have is a recipe for non-deployment of Internet protocols, or for standardization outside the IETF. The IETF is a volunteer SDO. IETF participants can choose not to review [and therefore not charter WGs to standardize] any piece of work that is brought to it, and have done so too. Yet there is a cost to the IETF of rejecting work that is relevant after all, and that cost is not zero. Whether to take on some work is a non-trivial decision to make. Nico -- From Nicolas.Williams@oracle.com Tue Aug 10 06:52:50 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECAC03A68CB for ; Tue, 10 Aug 2010 06:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.097, 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 9Zm3g3E1KTcx for ; Tue, 10 Aug 2010 06:52:48 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BF4EB3A6919 for ; Tue, 10 Aug 2010 06:52:48 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7ADrKaG032720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2010 13:53:22 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 o7A8pRKt023194; Tue, 10 Aug 2010 13:53:20 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 502717781281448324; Tue, 10 Aug 2010 06:52:04 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Aug 2010 06:52:03 -0700 Date: Tue, 10 Aug 2010 08:51:57 -0500 From: Nicolas Williams To: Rafa Marin Lopez Message-ID: <20100810135156.GS5213@oracle.com> References: <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:52:50 -0000 On Tue, Aug 10, 2010 at 02:51:59PM +0200, Rafa Marin Lopez wrote: > [Rafa] As Gabi just mentioned, that is the reason (gain flexibility) > of our second proposal "GSS-API based Kerberos pre-authentication", > which precisely transports GSS tokens in pa-data. > > However, I feel that, in terms of implementation, it could be easier > to implement directly interface EAP - Kerberos (already specified in > some sense in RFC 4137) than implementing EAP over GSS-API first and > then GSS-API over Kerberos. At least two new implementations may be > required in the second alternative. > > What do you think? I think we need to get our terminology straight. I'm not sure what "X over Y" means. Instead I'd like to refer to these things as "X in Y" or "X [pre-]authentication mechanism for Y", or "X Y mechanism" (where X is the basis for a mechanism for the Y framework). Thus a Kerberos pre-authentication method using EAP would be "EAP in Kerberos" or, better, "EAP pre-authentication mechanism for Kerberos", or "EAP Kerberos mechanism". Can you clarify which you had in mind? Each possible solution has its own implementation challenges. But generally speaking I believe type 2 solutions will be simpler to implement than type 1 solutions. That's based on the observation that the pluggable frameworks that one fits into in type 1 solutions aren't always all that pluggable in actual implementations, whereas type 2 solutions are much closer to pluggable. That is, I think Kerberos pre-auth is much harder to plug into than implementations of EAP, SASL and GSS-API. For example, an EAP Kerberos mechanism requires specifying the relevant PA-DATA type(s), fitting them into the FAST framework, and implementation then is going to be very specific to the host KDC implementation. Implementation for Heimdal will be very different from implementation for MIT krb5, which will be very different from Shishi, which will be very different from the implementations for other (usually not open source) KDCs. While a Kerberos EAP mechanism will likely require no work on the underlying Kerberos libraries and KDCs. If the EAP implementation that you're targeting has a public plug-in API/ABI then your work can stand alone. On the other hand, if you were trying to plug in to a PKI infrastructure for a type 1 solution, well, SACRED is a lot more pluggable than Kerberos pre-authentication! > > Yes. But note that the GSS-API doesn't force you to have one or the > > other of the initiator and acceptor to talk to infrastructure. You can > > do it either way. In Moonshot the acceptor talks to infrastructure. In > > Kerberos the initiator talks to infrastructure. > > [Rafa] I am not sure if I understand this. When you say the initiator > talks to the infrastructure in Kerberos... what do you mean?. In our > proposal, the KDC, acting as acceptor, talks to the AAA > infrastructure. So I am a little bit confused here. "Initiator" and "acceptor" are GSS-API terms that roughly correspond to, say, TLS "client" and "server". The GSS-API doesn't dictate which, if any, of the two talks to infrastructure services. > > Well, to be honest I haven't thought enough about non-pre-authentication > > types of out of band solutions. So I was rash to call them > > uninteresting. My intuition says that there aren't any such solutions > > that can't be thought of as pre-authentication (i.e., type 1). > > [Rafa] I also believe those kind of solutions could be classified as > type 1, as long as we consider them as mechanisms which are used to > authenticate user before KDC provides a TGT, for example. This > mechanism can be part of the traditional Kerberos pre-authentication > or potential out-of-band mechanisms. Yes, that makes sense to me. Nico -- From hartmans@painless-security.com Tue Aug 10 07:00:17 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559153A68F6 for ; Tue, 10 Aug 2010 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 Xn5u4tmkaeRC for ; Tue, 10 Aug 2010 07:00:16 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9E84F3A6934 for ; Tue, 10 Aug 2010 07:00:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CB470203F8; Tue, 10 Aug 2010 10:00:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D2E5D4129; Tue, 10 Aug 2010 10:00:43 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4C5C371D.1090504@cisco.com> <005701cb3584$a374ff20$ea5efd60$@osu.edu> <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> <20100810135156.GS5213@oracle.com> Date: Tue, 10 Aug 2010 10:00:43 -0400 In-Reply-To: <20100810135156.GS5213@oracle.com> (Nicolas Williams's message of "Tue, 10 Aug 2010 08:51:57 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:00:17 -0000 Their first proposal was EAP pre-authentication for Kerberos. Their second proposal is GSS pre-authentication for Kerberos using an EAP GSS-API mechanism. From Nicolas.Williams@oracle.com Tue Aug 10 07:09:52 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB2E3A69BB for ; Tue, 10 Aug 2010 07:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.095, 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 Wkz6EG6hpR8q for ; Tue, 10 Aug 2010 07:09:51 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8F1503A69A5 for ; Tue, 10 Aug 2010 07:09:51 -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.2) with ESMTP id o7AEAOCN004598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2010 14:10:26 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 o7A2StUB022602; Tue, 10 Aug 2010 14:10:24 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 502783761281449423; Tue, 10 Aug 2010 07:10:23 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Aug 2010 07:10:23 -0700 Date: Tue, 10 Aug 2010 09:10:16 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100810141016.GT5213@oracle.com> References: <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> <20100810135156.GS5213@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) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done (EAP over Kerberos) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:09:52 -0000 On Tue, Aug 10, 2010 at 10:00:43AM -0400, Sam Hartman wrote: > Their first proposal was EAP pre-authentication for Kerberos. Their > second proposal is GSS pre-authentication for Kerberos using an EAP > GSS-API mechanism. Ah, thanks for that clarification. I like the second proposal :) That's because it would produce two re-usable things: a) a re-usable EAP GSS-API mechanism, b) a more easily pluggable pre-authentication extension framework for Kerberos. (a) is a type 2 solution. (b) is a type 1 solution re-using a type 2 solution. As you know, while I'm a fan of FAST, I'd rather have gone with a GSS-API pre-authentication framework for Kerberos. Of course, by now FAST is sufficiently well implemented that it's probably easier to plug into it than it would be to add a GSS-API pre-auth method to Kerberos... Nico -- From lear@cisco.com Tue Aug 10 09:37:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877FB3A6A01 for ; Tue, 10 Aug 2010 09:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.432 X-Spam-Level: X-Spam-Status: No, score=-110.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 JGmJAnQKHeu5 for ; Tue, 10 Aug 2010 09:37:07 -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 12A943A6888 for ; Tue, 10 Aug 2010 09:37:06 -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: Av0EAIIdYUxAZnwN/2dsb2JhbACDFZ0gcaEriVKSBIEmgyFzBIlA X-IronPort-AV: E=Sophos;i="4.55,349,1278288000"; d="scan'208";a="146001407" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2010 16:37:41 +0000 Received: from ams3-vpn-dhcp6557.cisco.com (ams3-vpn-dhcp6557.cisco.com [10.61.89.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7AGbeDG024415; Tue, 10 Aug 2010 16:37:40 GMT Message-ID: <4C61805D.6080607@cisco.com> Date: Tue, 10 Aug 2010 18:37:49 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nicolas Williams References: <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$@yegin@yegin.org> <20100810133321.GR5213@oracle.com> In-Reply-To: <20100810133321.GR5213@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:37:23 -0000 Nico, Alper, Let's distinguish between "options" as in "protocol options" and options as in overall choices. I would agree with the statement that protocol options hinder interoperability. However, when looking at design decisions we should at least allow for some flexibility early on in the process. That way we can see what people like and then later narrow in on that set of functionality. That is, arguably, the standards maturity process we have in place. In this instance, I see several possible avenues that could be pursued, and quite frankly I don't think anyone on this list can argue with a straight face that they know which model will ultimately be acceptable. And so while I don't think we should let 1E+3 flowers bloom, 3 doesn't seem like such a bad number – at this point. Eliot From Nicolas.Williams@oracle.com Tue Aug 10 10:02:09 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 995303A6984 for ; Tue, 10 Aug 2010 10:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.094, 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 oakkOteXqIfQ for ; Tue, 10 Aug 2010 10:02:08 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 71EE43A67E2 for ; Tue, 10 Aug 2010 10:02:08 -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.2) with ESMTP id o7AH2ctb026876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2010 17:02:39 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 o7A7oTD2031141; Tue, 10 Aug 2010 17:02:38 GMT Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 503428021281459670; Tue, 10 Aug 2010 10:01:10 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Aug 2010 10:01:08 -0700 Date: Tue, 10 Aug 2010 12:01:03 -0500 From: Nicolas Williams To: Eliot Lear Message-ID: <20100810170102.GX5213@oracle.com> References: <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$@yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C61805D.6080607@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:02:09 -0000 On Tue, Aug 10, 2010 at 06:37:49PM +0200, Eliot Lear wrote: > Let's distinguish between "options" as in "protocol options" and options > as in overall choices. I would agree with the statement that protocol > options hinder interoperability. However, when looking at design > decisions we should at least allow for some flexibility early on in the > process. That way we can see what people like and then later narrow in > on that set of functionality. That is, arguably, the standards maturity > process we have in place. I think that's mostly right. Though it's also true that if we don't have common required-to-implement mechanisms for the various pluggable frameworks then we could lack interop anyways, and even if we do have one or two required-to-implement mechanisms (say, Kerberos and SCRAM) that could still leave non-interoperable islands using optional mechanisms. In practice, I expect most implementations of pluggable frameworks to be pluggable themselves (either with public interfaces or interfaces subject to contracts), so I'm not terribly concerned about having a plethora of authentication mechanisms. > In this instance, I see several possible avenues that could be pursued, > and quite frankly I don't think anyone on this list can argue with a > straight face that they know which model will ultimately be acceptable. > And so while I don't think we should let 1E+3 flowers bloom, 3 doesn't > seem like such a bad number – at this point. I agree. Also, note that all the proposals to date leverage existing standards. This is a good thing because it will lower the review burden. Nico -- From cantor.2@osu.edu Tue Aug 10 10:05:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53753A69CC for ; Tue, 10 Aug 2010 10:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZlgwjp4C39I for ; Tue, 10 Aug 2010 10:05:45 -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 083B53A6984 for ; Tue, 10 Aug 2010 10:05:44 -0700 (PDT) Received: from defang9.it.ohio-state.edu (defang9.it.ohio-state.edu [128.146.216.78]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o7AH6Jvw020083; Tue, 10 Aug 2010 13:06:19 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang9.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o7AH6JeK003007; Tue, 10 Aug 2010 13:06:19 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" References: <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> In-Reply-To: <20100810170102.GX5213@oracle.com> Date: Tue, 10 Aug 2010 13:06:21 -0400 Organization: The Ohio State University Message-ID: <025801cb38ae$5b0e9b60$112bd220$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-index: AQJz6boRj7IcZ1yjOUHR9WC0NkuV9gFlkST7ANmETQ4CnHf4pwFrrvOGATNNgLECWLvGvwJdWLHeAPHJOTMBpLY8fAJ2jG5jkP+bKGA= Content-language: en-us X-CanIt-Geo: ip=128.146.216.78; 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: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:05:46 -0000 > In practice, I expect most implementations of pluggable frameworks to = be > pluggable themselves (either with public interfaces or interfaces > subject to contracts), so I'm not terribly concerned about having a > plethora of authentication mechanisms. The feedback I've gotten from people about SASL or GSS is that this is = quite untrue in practice, or that the implementations are simply too = fragile to count on plugging into them. It may be that there is work to be done in producing BCP on how to = implement them to improve the quality or avoid common assumptions that = break pluggability in practice. -- Scott From Nicolas.Williams@oracle.com Tue Aug 10 10:20:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF633A6A8B for ; Tue, 10 Aug 2010 10:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, 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 rtDGgYPrJ8Cx for ; Tue, 10 Aug 2010 10:20:11 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B2CC73A6A85 for ; Tue, 10 Aug 2010 10:20:11 -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.2) with ESMTP id o7AHKjP9013627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2010 17:20:46 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 o7AHKjke011514; Tue, 10 Aug 2010 17:20:45 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 503503751281460842; Tue, 10 Aug 2010 10:20:42 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 Aug 2010 10:20:42 -0700 Date: Tue, 10 Aug 2010 12:20:37 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20100810172037.GZ5213@oracle.com> References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025801cb38ae$5b0e9b60$112bd220$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:20:13 -0000 On Tue, Aug 10, 2010 at 01:06:21PM -0400, Scott Cantor wrote: > > In practice, I expect most implementations of pluggable frameworks to be > > pluggable themselves (either with public interfaces or interfaces > > subject to contracts), so I'm not terribly concerned about having a > > plethora of authentication mechanisms. > > The feedback I've gotten from people about SASL or GSS is that this is > quite untrue in practice, or that the implementations are simply too > fragile to count on plugging into them. It's true that Solaris' libgss isn't exactly open, though internally it is. And MIT krb5's libgss is pluggable, but its interfaces are not really public (yet; there's a project to make it so). That's for starters. I think the situation is not great, but not far from pretty good. > It may be that there is work to be done in producing BCP on how to > implement them to improve the quality or avoid common assumptions that > break pluggability in practice. I agree. From lukeh@padl.com Tue Aug 10 10:21:33 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB6D3A68F3 for ; Tue, 10 Aug 2010 10:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=-1.850, 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 gwi17sDhLn43 for ; Tue, 10 Aug 2010 10:21:32 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 2A3CD3A681D for ; Tue, 10 Aug 2010 10:21:32 -0700 (PDT) Received: by us.padl.com with ESMTP id o7AHLvVB011832; Tue, 10 Aug 2010 13:22:02 -0400 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20100810172037.GZ5213@oracle.com> Date: Tue, 10 Aug 2010 19:22:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> <20100810172037.GZ5213@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1078) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:21:33 -0000 > It's true that Solaris' libgss isn't exactly open, though internally = it > is. And MIT krb5's libgss is pluggable, but its interfaces are not > really public (yet; there's a project to make it so). That's for > starters. I think the situation is not great, but not far from pretty > good. Since 1.7, it can load a GSS implementation that exports the GSS-API = itself. Heimdal, too (since which version I'm not sure). So, it's going to be easy to plug in EAP GSS mechanism. Of course, = naming extensions support will require a modern mechglue. -- Luke= From hartmans@painless-security.com Tue Aug 10 10:41:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B234E3A6A8C for ; Tue, 10 Aug 2010 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 oQrnRVeFxMs0 for ; Tue, 10 Aug 2010 10:41:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 056B93A6A29 for ; Tue, 10 Aug 2010 10:41:29 -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 2C40920463; Tue, 10 Aug 2010 13:42:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DACB24129; Tue, 10 Aug 2010 13:41:54 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> <20100810172037.GZ5213@oracle.com> <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> Date: Tue, 10 Aug 2010 13:41:54 -0400 In-Reply-To: <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> (Luke Howard's message of "Tue, 10 Aug 2010 19:22:00 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, Nicolas Williams Subject: Re: [abfab] Partially Summarizing Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:41:30 -0000 So, there's been a very interesting technical discussion of options, browsers, HTTP negotiate, GSS, Kerberos and the like. However as I read this discussion, people participating in that subthread have not actually expressed disagreement with Leif's summary of what is outstanding. Also, with the exception of Glen, have there been any additional requests for changes? --Sam From alper.yegin@yegin.org Wed Aug 11 00:42:56 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8DEE3A6A34 for ; Wed, 11 Aug 2010 00:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 ojYZEDiR9bNd for ; Wed, 11 Aug 2010 00:42:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D0F8F3A6A31 for ; Wed, 11 Aug 2010 00:42:55 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MSuJ3-1OK2DB0eeL-00RxFz; Wed, 11 Aug 2010 03:43:28 -0400 From: "Alper Yegin" To: "'Nicolas Williams'" References: <005101cb3563$ece9f0a0$c6bdd1e0$@net> <4C5C14BB.8010108@cisco.com> <009101cb3574$f711f9e0$e535eda0$@net> <4C5C1FAD.2030605@cisco.com> <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$@yegin@yegin.org> <20100810133321.GR5213@oracle.com> In-Reply-To: <20100810133321.GR5213@oracle.com> Date: Wed, 11 Aug 2010 10:43:22 +0300 Message-ID: <028e01cb3928$e337c870$a9a75950$@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 Thread-Index: Acs4kNf43IMNi9oeRJiZIwzLF/FSOgAl7g9w Content-Language: en-us X-Provags-ID: V02:K0:/ElqzLHhAeTu1hvPwPZeYmDgw7Nl1drkvQfn3AEZRu8 xQnNbTB2z0ru0IzXwUTMTfpQ5rmIgNZW/qeb4qK+5D4i8XxHv3 2nh0XxjgY7nyt8sjxu8D90PSanj2lXyWJZG4G+EFLatBxp8dlF v+7PA/3L79HG7Pn8gpmop+kg//mZluklo4zXzmx758SzQY+nMD v4hc3TcjgMTpB8lzOtjVblCx36V9QHDPvf+QMDyUCM= Cc: abfab@ietf.org Subject: Re: [abfab] Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 07:42:56 -0000 > Your interop argument ignores the argument I made earlier, That was not my intention. I was just commenting on that one aspect. I didn't mean that this is the determining factor. There are multiple other considerations, like the ones you listed below, and even more. > too, that > requiring users to deploy authentication infrastructures other than > those they already have is a recipe for non-deployment of Internet > protocols, or for standardization outside the IETF. > > The IETF is a volunteer SDO. IETF participants can choose not to > review > [and therefore not charter WGs to standardize] any piece of work that > is > brought to it, and have done so too. Yet there is a cost to the IETF > of > rejecting work that is relevant after all, and that cost is not zero. > Whether to take on some work is a non-trivial decision to make. > > Nico > -- From alper.yegin@yegin.org Wed Aug 11 01:08:26 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2103C3A6A34 for ; Wed, 11 Aug 2010 01:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, 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 zWf8E+fhwU3z for ; Wed, 11 Aug 2010 01:08:25 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 465543A6804 for ; Wed, 11 Aug 2010 01:08:25 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MZjOA-1OUB5C0HXC-00LXOp; Wed, 11 Aug 2010 04:08:53 -0400 From: "Alper Yegin" To: "'Sam Hartman'" , "'Luke Howard'" References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> <20100810172037.GZ5213@oracle.com> <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> In-Reply-To: Date: Wed, 11 Aug 2010 11:08:46 +0300 Message-ID: <029501cb392c$704cd9a0$50e68ce0$@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 Thread-Index: Acs4s1qR3zAJpCSKRH2oUeMq3doPDQAdurAw Content-Language: en-us X-Provags-ID: V02:K0:Z5RNxa+jTfZiqAugMMC28R5KGzTr1p+jeRXiaID84bU 5VzRspyDQjfY9g++0dS+NaYeXj8cX2E5fNOKhxyiM4AEVOEV0p XwoEwYkZ9BoRrjnLL78/+ATwkkDHXt742HYFCFpUSv/ZcG9FRG vnCqdFkVbWGlhhqrXRhtRgAIanRiHZYhFjKB2ZS7ifLrXrAv6c 2F9TaoSJeBBSzmBcL6djoTaNN7rVRFZeVS+5s215EE= Cc: abfab@ietf.org, 'Nicolas Williams' Subject: Re: [abfab] Partially Summarizing Getting the charter done X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 08:08:26 -0000 > So, there's been a very interesting technical discussion of options, > browsers, HTTP negotiate, GSS, Kerberos and the like. > > However as I read this discussion, people participating in that > subthread have not actually expressed disagreement with Leif's summary > of what is outstanding. Also, with the exception of Glen, have there > been any additional requests for changes? Not sure if and how this impacts the charter text... but one other thing that bothers me is about EAP applicability statement change. Charter text says: * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case * An update to the EMSK root key applicability statement in RFC 5295 It is obvious that this is needed for the work to progress, but it is not clear when and how the IETF agreed to do that. In ICOS BoF and HO(A)KEY WG formation era (and even afterwards), leadership was shooting down proposals because they were violating this sacred applicability statement. Now we see there is a totally new work which is based on updating (not "violating" this time ;) this applicability statement. And in between these two events is a .... blackout! No proper discussion on how we went from point A to point inverse-A. Before people get on the defensive or offensive mode to protect their "progress", let me restate that I'm not against changing the applicability statement. But not having an open, informative, and constructive discussion to take the community from A to inverse-A is plain wrong. Without that discussion, it looks like the decisions are made randomly. Alper From hannes.tschofenig@nsn.com Wed Aug 11 03:41:35 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53863A6807 for ; Wed, 11 Aug 2010 03:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pUREyF96lkR1 for ; Wed, 11 Aug 2010 03:41:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 47CFB3A689D for ; Wed, 11 Aug 2010 03:41:34 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg97r008046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Aug 2010 12:42:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg39a025777 for ; Wed, 11 Aug 2010 12:42:09 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:42:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3941.D61C0C29" Date: Wed, 11 Aug 2010 13:42:03 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E5D296@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback solicited for Privacy and Identity Management Terminology Thread-Index: Acs5PdubqHsp/hsJSNOKWeUPC+SJQw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Aug 2010 10:42:07.0956 (UTC) FILETIME=[D8960940:01CB3941] Subject: [abfab] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:41:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3941.D61C0C29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 we have just submitted a new version of the privacy and identity management terminology document: http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-01. txt =20 The full document titel is "Terminology for Talking about Privacy by Data Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management" and here is the abstract:=20 This document is an attempt to consolidate terminology in the field privacy by data minimization. It motivates and develops definitions for anonymity/identifiability, (un)linkability, (un)detectability, (un)observability, pseudonymity, identity, partial identity, digital identity and identity management. Starting the definitions from the anonymity and unlinkability perspective and not from a definition of identity (the latter is the obvious approach to some people) reveals some deeper structures in this field. =20 Please let us know whether the terminology is useful and complete. Your input is highly appreciated! Ciao Hannes ------_=_NextPart_001_01CB3941.D61C0C29 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Feedback solicited for Privacy and Identity Management = Terminology

Hi all,

we have just submitted a new = version of the privacy and identity management terminology = document:
http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology= -01.txt
 
The full document titel is = "Terminology for Talking about Privacy by Data Minimization: = Anonymity, Unlinkability, Undetectability, Unobservability, = Pseudonymity, and Identity Management" and here is the abstract: =

   This document is an = attempt to consolidate terminology in the field
   privacy by data = minimization.  It motivates and develops definitions
   for = anonymity/identifiability, (un)linkability, (un)detectability,
   (un)observability, = pseudonymity, identity, partial identity, digital
   identity and = identity management.  Starting the definitions from the
   anonymity and = unlinkability perspective and not from a definition of
   identity (the = latter is the obvious approach to some people) reveals
   some deeper = structures in this field.
  
Please let us know whether the = terminology is useful and complete. Your input is highly = appreciated!

Ciao
Hannes


------_=_NextPart_001_01CB3941.D61C0C29-- From hartmans@painless-security.com Wed Aug 11 05:38:47 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AD8A3A67AC for ; Wed, 11 Aug 2010 05:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 oqINvyxApkuk for ; Wed, 11 Aug 2010 05:38:46 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6B0F33A67FD for ; Wed, 11 Aug 2010 05:38:46 -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 CEEC7201C7; Wed, 11 Aug 2010 08:39:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C4CC04129; Wed, 11 Aug 2010 08:39:07 -0400 (EDT) From: Sam Hartman To: "Alper Yegin" References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> <20100810172037.GZ5213@oracle.com> <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> <029501cb392c$704cd9a0$50e68ce0$@yegin@yegin.org> Date: Wed, 11 Aug 2010 08:39:07 -0400 In-Reply-To: <029501cb392c$704cd9a0$50e68ce0$@yegin@yegin.org> (Alper Yegin's message of "Wed, 11 Aug 2010 11:08:46 +0300") 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: abfab@ietf.org, 'Nicolas Williams' Subject: [abfab] Charter: EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 12:38:47 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> * An update to the EMSK root key applicability statement in Alper> RFC 5295 Alper> It is obvious that this is needed for the work to progress, Alper> but it is not clear when and how the IETF agreed to do that. The IETF hasn't agreed to do that. The IETF would agree to do that by chartering work to do that; we're having the discussion now about whether that's a good idea. In particular, if you believe this topic needs more discussion, you could call that out when the charter goes out for external review within the IETF. Alper> In ICOS BoF and HO(A)KEY WG formation era (and even Alper> afterwards), leadership was shooting down proposals because Alper> they were violating this sacred applicability statement. I think I was most of the leadership doing the shooting down:-) I went back to review my statements at least as far as they went into the minutes. The statements in the minutes seem correct with what I remember saying. In those fora, I never said that you cannot change the applicability statement. I outlined some of the things I think you'd need to do in order to explain it and why I believed that would be hard. When you brought up this issue a few months ago, I explained in my response why I believe that this proposal meets the criteria I set out at ICOS and elsewhere. I may have made stronger statements at the first ISMS meeting after I became AD. At least what went into the minutes is consistent with what I said at ICOS, although it would not surprise me if some of the shorter statements I made at the mic were over-simplifications of the entire position and were not entirely consistent. (I was a new AD at the first ISMS meeting; I had only become aware of the applicability issue when briefed by Bernard shortly before the meeting.) I cannot speak for other IETF leadership. It's my understanding that my position was consistent with the position of other IETF and EAP leadership. I believe that everyone in the leadership who expressed concerns about applicability of EAP is aware of this proposal. However, I do agree with you that this is an important issue and we should make shure we handle it correctly. --Sam From leifj@sunet.se Wed Aug 11 06:11:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51D953A68C3 for ; Wed, 11 Aug 2010 06:11:11 -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 g-59GLx78BWd for ; Wed, 11 Aug 2010 06:11:08 -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 113183A6847 for ; Wed, 11 Aug 2010 06:11:07 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7BDBe1I012595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Aug 2010 15:11:42 +0200 (CEST) Message-ID: <4C62A18C.9090500@sunet.se> Date: Wed, 11 Aug 2010 15:11:40 +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: abfab@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 13:11:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaas and me have been trying to summarize feedback from the BoF in the form of new charter text. We both felt it was necessary to rewrite most of the text to capture all of the feedback we've gotten during and after Maastricht. We have been very careful in capturing the essence of the first version. Abfab Proposed Charter Abfab - Application Bridging for Federated Access Beyond web Federated identity is today widely deployed for web applications using such technologies as OpenID, Security Assertion Markup Language (SAML), OAuth and Information Card (IMI). However, for protocols such as IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on HTTP/HTML there is no readily deployable solution for federated identity. While work continues elsewhere on basic mechanisms that rely on using an HTTP/HTML interface to authenticate and authorize non-web applications, this working group will look at approaches that do not rely on the web, taking into account user interface concerns and the need to pass structured data to an appropriate authentication interface, as well as the need to handle large scale discovery. The working group will develop a solution for federated identity for IETF and non-IETF application protocols by combining SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). Constraints: - ------------ The working group will ensure that any solution developed has built- in technical controls for privacy protection. Initially the working group will focus on using GSS-API (RFC2743) to integrate federated identity into application protocols but other technologies for application interface are in scope. Adoption of such solutions by the working group are subject to the normal IETF consensus and (re)charter process. The working group may not change EAP (beyond the development of EAP mechanisms) RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - - draft-howlett-eap-gss-00, - - draft-howlett-radius-saml-attr-00 - - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. In addition, the working group will explore the usability and user interface issues associated with federated authentication. The work is not chartered to standardize protocols or recommend best current practice in the area of usability. The working group should explore the area and produce informational documents describing the issues and recommending appropriate work for the IETF in this area. As future work in dealing with user interface in this area progresses, the architecture of the system may need to expand to include additional components or make significant changes to adapt to improvements in understanding of user interface. In describing architecture work, the working group will emphasize this possibility of change. Coordination with other SDOs - ---------------------------- This work will require close coordination with work going on in the OASIS Security Services Technical Committee (SSTC). There should be sufficient overlapping participation between the SSTC and this working group for informal coordination. The chairs of this working group may work with the SSTC chairs and the IAB in case formal coordination is required. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables - ------------ The deliverables of the working group are: * A document describing applicable use cases. * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture * A standards-track protocol for carrying SAML messages in RADIUS and Diameter * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case * A standards track solution for using EAP methods to provide authentication within the application * An update to the EMSK root key applicability statement in RFC 5295 * A standards-track description of GSS names and name attributes required by the solution * Informational descriptions of usability and user-interface concerns related to this work -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxioYwACgkQ8Jx8FtbMZncfdACbBJw48M6pHRaQ0EgAqQJZ9DM0 CiwAoIpCZQ9dHsSO0ApwAUZChHkUQd2B =QESJ -----END PGP SIGNATURE----- From hartmans@painless-security.com Wed Aug 11 08:01:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0753A69A2 for ; Wed, 11 Aug 2010 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 c7qCJ3UILCsv for ; Wed, 11 Aug 2010 08:01:33 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C19453A6915 for ; Wed, 11 Aug 2010 08:01:32 -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 9AE9E201C7; Wed, 11 Aug 2010 11:02:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 64B624129; Wed, 11 Aug 2010 11:01:54 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4C62A18C.9090500@sunet.se> Date: Wed, 11 Aug 2010 11:01:54 -0400 In-Reply-To: <4C62A18C.9090500@sunet.se> (Leif Johansson's message of "Wed, 11 Aug 2010 15:11:40 +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: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:01:34 -0000 I'm certainly fine with the proposed charter. I note however that you rolled back changes made to address feedback from Hannes. In particular the first version of the charter I circulated claimed that we would useSAML, EAP and AAA without explanation why. He gave feedback that we really needed to explain how that came about. Thus the more verbose text in the version of the charter we used at the BOF. I'm actually happy with your revisions, but you should close base with Hannes to see where he stands. From lear@cisco.com Wed Aug 11 08:29:43 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99A33A68DC for ; Wed, 11 Aug 2010 08:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 xkcS+MtLWRJX for ; Wed, 11 Aug 2010 08:29:42 -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 A8AFA3A67D0 for ; Wed, 11 Aug 2010 08:29:42 -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: Av0EAKVeYkxAZnwN/2dsb2JhbACDFZ0ScaEGiVKRf4EmgyFzBIlQ X-IronPort-AV: E=Sophos;i="4.55,353,1278288000"; d="scan'208";a="146472895" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 15:30:18 +0000 Received: from dhcp-10-55-82-26.cisco.com (dhcp-10-55-82-26.cisco.com [10.55.82.26]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7BFUHjK002178; Wed, 11 Aug 2010 15:30:18 GMT Message-ID: <4C62C211.7020209@cisco.com> Date: Wed, 11 Aug 2010 17:30:25 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C62A18C.9090500@sunet.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:29:43 -0000 Sam, Leif, I like what's there. I think Hannes' concern is obviated by the idea that other approaches will be entertained as and when they are presented. Eliot On 8/11/10 5:01 PM, Sam Hartman wrote: > I'm certainly fine with the proposed charter. > > I note however that you rolled back changes made to address feedback > from Hannes. In particular the first version of the charter I > circulated claimed that we would useSAML, EAP and AAA without > explanation why. He gave feedback that we really needed to explain how > that came about. Thus the more verbose text in the version of the > charter we used at the BOF. > > I'm actually happy with your revisions, but you should close base with > Hannes to see where he stands. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From leifj@sunet.se Wed Aug 11 13:09:31 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DFDA28C0F2 for ; Wed, 11 Aug 2010 13:09:31 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-N84Hsahbs5 for ; Wed, 11 Aug 2010 13:09:30 -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 40C063A6A8F for ; Wed, 11 Aug 2010 13:09:29 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7BKA2bI005717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 22:10:04 +0200 (CEST) Message-ID: <4C630399.50701@sunet.se> Date: Wed, 11 Aug 2010 22:10:01 +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: Sam Hartman References: <4C62A18C.9090500@sunet.se> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:09:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2010 05:01 PM, Sam Hartman wrote: > I'm certainly fine with the proposed charter. > > I note however that you rolled back changes made to address feedback > from Hannes. In particular the first version of the charter I > circulated claimed that we would useSAML, EAP and AAA without > explanation why. He gave feedback that we really needed to explain how > that came about. Thus the more verbose text in the version of the > charter we used at the BOF. I'm sorry about that. It was unintentional. I'll talk to Hannes (unless he chooses to chime in on the list very soon). > > I'm actually happy with your revisions, but you should close base with > Hannes to see where he stands. Great! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxjA5UACgkQ8Jx8FtbMZnf61QCfWkBbhbChccn3IA1E+Ew5zcuN RVUAn0u1N9neXCQ6yDQqETmpuYG1oNiX =8Upi -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Wed Aug 11 13:36:04 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67823A69BC for ; Wed, 11 Aug 2010 13:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6lEQH67IN9vO for ; Wed, 11 Aug 2010 13:36:04 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 015943A683C for ; Wed, 11 Aug 2010 13:36:03 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7BKaaSG013015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 20:36:38 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 o7BG0ASn004947; Wed, 11 Aug 2010 20:36:36 GMT Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 508143511281558889; Wed, 11 Aug 2010 13:34:49 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 13:34:49 -0700 Date: Wed, 11 Aug 2010 15:34:44 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20100811203443.GH5213@oracle.com> References: <4C62A18C.9090500@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C62A18C.9090500@sunet.se> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:36:04 -0000 On Wed, Aug 11, 2010 at 03:11:40PM +0200, Leif Johansson wrote: > Federated identity is today widely deployed for web applications using > such technologies as OpenID, Security Assertion Markup Language (SAML), > OAuth and Information Card (IMI). However, for protocols such as > IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on HTTP/HTML > there is no readily deployable solution for federated identity. You might want to explain why Kerberos doesn't qualify and/or that even if it did, it's not what's been deployed for web use, therefore it's irrelevant. That would help address Glen's points. Proposed text: It is true that many Internet protocols can use Kerberos V5 for authentication. However, Kerberos is not an authentication technology commonly used in Internet-scale web deployments. Moreover, in the Kerberos model clients contact the infrastructure, whereas it is highly desirable for servers to contact infrastructure [maybe list some reasons?]. ... > Initially the working group will focus on using GSS-API (RFC2743) to > integrate federated identity into application protocols but other > technologies for application interface are in scope. Adoption of such > solutions by the working group are subject to the normal IETF consensus > and (re)charter process. Is it worth mentioning SASL/GS2? I'd think so: Initially the working group will focus on using GSS-API (RFC2743) and SASL (via the GS2 bridge to GSS-API [RFC4422] [RFC5801]) to... Looks good to me. Nico -- From rafa@um.es Wed Aug 11 15:08:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8113D28B797 for ; Wed, 11 Aug 2010 15:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYM4nkoxhtHH for ; Wed, 11 Aug 2010 15:08:10 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id 5B4773A69C2 for ; Wed, 11 Aug 2010 15:08:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 204975430B; Thu, 12 Aug 2010 00:08:02 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yhwtPiOMRFYb; Thu, 12 Aug 2010 00:08:00 +0200 (CEST) Received: from [192.168.1.64] (50.Red-79-144-170.dynamicIP.rima-tde.net [79.144.170.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 82AE854144; Thu, 12 Aug 2010 00:07:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <20100811203443.GH5213@oracle.com> Date: Thu, 12 Aug 2010 00:08:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 22:08:11 -0000 Hi Nico,=20 El 11/08/2010, a las 22:34, Nicolas Williams escribi=F3: > On Wed, Aug 11, 2010 at 03:11:40PM +0200, Leif Johansson wrote: >> Federated identity is today widely deployed for web applications = using >> such technologies as OpenID, Security Assertion Markup Language = (SAML), >> OAuth and Information Card (IMI). However, for protocols such as >> IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on = HTTP/HTML >> there is no readily deployable solution for federated identity. >=20 > You might want to explain why Kerberos doesn't qualify and/or that = even > if it did, it's not what's been deployed for web use, therefore it's > irrelevant. That would help address Glen's points. [Rafa] In my opinion, we should not explicitly prohibit/restrict = Kerberos (or, in general, any other potential solution/alternative) from = the beginning before deeper analysis. For example, AFAIK (please, = correct if I am wrong) GSS-API implementations usually work based on = Kerberos tickets and are deployed in precisely protocols not based on = HTTP/HTML. If after further analysis Kerberos must be discarded, we can do so. Best regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From leifj@sunet.se Wed Aug 11 15:14:49 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287483A6ABF for ; Wed, 11 Aug 2010 15:14:46 -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 4Q3cDZPuMTYD for ; Wed, 11 Aug 2010 15:14:29 -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 905753A69BC for ; Wed, 11 Aug 2010 15:14:29 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7BMF2lf005433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 00:15:04 +0200 (CEST) Message-ID: <4C6320E6.8060703@sunet.se> Date: Thu, 12 Aug 2010 00:15:02 +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: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> In-Reply-To: <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 22:14:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > [Rafa] In my opinion, we should not explicitly prohibit/restrict Kerberos (or, in general, any other potential solution/alternative) from the beginning before deeper analysis. For example, AFAIK (please, correct if I am wrong) GSS-API implementations usually work based on Kerberos tickets and are deployed in precisely protocols not based on HTTP/HTML. > > If after further analysis Kerberos must be discarded, we can do so. Rafa: there has been discussion about why Kerberos isn't obviously suitable on the list. Can I get you to explain why in your opinion the arguments put forward by Nico and Sam (among others) do not apply? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxjIOIACgkQ8Jx8FtbMZne7hACgmCeDbRk43MrYyZx3uoF/Rh8p p0cAoLeSfcccX5YpkzLOa+FPffaXZjH8 =XWU1 -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Wed Aug 11 15:36:27 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 344A73A68D9 for ; Wed, 11 Aug 2010 15:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.089, 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 ItBDXIQmiGxg for ; Wed, 11 Aug 2010 15:36:26 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 551923A680C for ; Wed, 11 Aug 2010 15:36:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7BMb0Rn007010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 22:37:02 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 o7BLV6we011514; Wed, 11 Aug 2010 22:37:00 GMT Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 488245411281566210; Wed, 11 Aug 2010 15:36:50 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 15:36:49 -0700 Date: Wed, 11 Aug 2010 17:36:44 -0500 From: Nicolas Williams To: Rafa Marin Lopez Message-ID: <20100811223644.GJ5213@oracle.com> References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 22:36:27 -0000 On Thu, Aug 12, 2010 at 12:08:07AM +0200, Rafa Marin Lopez wrote: > Hi Nico, > > El 11/08/2010, a las 22:34, Nicolas Williams escribió: > > > On Wed, Aug 11, 2010 at 03:11:40PM +0200, Leif Johansson wrote: > >> Federated identity is today widely deployed for web applications using > >> such technologies as OpenID, Security Assertion Markup Language (SAML), > >> OAuth and Information Card (IMI). However, for protocols such as > >> IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on HTTP/HTML > >> there is no readily deployable solution for federated identity. > > > > You might want to explain why Kerberos doesn't qualify and/or that even > > if it did, it's not what's been deployed for web use, therefore it's > > irrelevant. That would help address Glen's points. > > [Rafa] In my opinion, we should not explicitly prohibit/restrict > Kerberos (or, in general, any other potential solution/alternative) > from the beginning before deeper analysis. For example, AFAIK (please, > correct if I am wrong) GSS-API implementations usually work based on > Kerberos tickets and are deployed in precisely protocols not based on > HTTP/HTML. > > If after further analysis Kerberos must be discarded, we can do so. Sure. My intention is not to leave Kerberos out but to explain why Kerberos is not enough to discard the EAP GSS + AAA + SAML approach. From Nicolas.Williams@oracle.com Wed Aug 11 16:23:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7472E3A63EC for ; Wed, 11 Aug 2010 16:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.087, 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 UumKGs99sSkX for ; Wed, 11 Aug 2010 16:23:29 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 965CA3A6895 for ; Wed, 11 Aug 2010 16:23:29 -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.2) with ESMTP id o7BNO4bN006536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 23:24:05 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 o7BLCWK7032375; Wed, 11 Aug 2010 23:24:04 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 488354571281568967; Wed, 11 Aug 2010 16:22:47 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 16:22:46 -0700 Date: Wed, 11 Aug 2010 18:22:41 -0500 From: Nicolas Williams To: Rafa Marin Lopez Message-ID: <20100811232241.GK5213@oracle.com> References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100811223644.GJ5213@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 23:23:30 -0000 Also, excluding Kerberos-based solutions from this WG's charter's does not mean excluding Kerberos-based solutions altogether. From hartmans@painless-security.com Wed Aug 11 16:33:27 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD33828C0F2 for ; Wed, 11 Aug 2010 16:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IXti-ZDm28v5 for ; Wed, 11 Aug 2010 16:33:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id D46323A696C for ; Wed, 11 Aug 2010 16:33:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2E18E20438; Wed, 11 Aug 2010 19:34:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2F361412A; Wed, 11 Aug 2010 19:33:50 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <4C6320E6.8060703@sunet.se> Date: Wed, 11 Aug 2010 19:33:50 -0400 In-Reply-To: <4C6320E6.8060703@sunet.se> (Leif Johansson's message of "Thu, 12 Aug 2010 00:15:02 +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: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 23:33:27 -0000 >>>>> "Leif" == Leif Johansson writes: >> [Rafa] In my opinion, we should not explicitly prohibit/restrict >> Kerberos (or, in general, any other potential >> solution/alternative) from the beginning before deeper >> analysis. For example, AFAIK (please, correct if I am wrong) >> GSS-API implementations usually work based on Kerberos tickets >> and are deployed in precisely protocols not based on HTTP/HTML. >> >> If after further analysis Kerberos must be discarded, we can do >> so. Leif> Rafa: there has been discussion about why Kerberos isn't Leif> obviously suitable on the list. Can I get you to explain why Leif> in your opinion the arguments put forward by Nico and Sam Leif> (among others) do not apply? I find myself in agreement with Rafa. Both Nico and I have acknowledge that more of Kerberos technology may be appropriate in the future. I don't see why proposals that involve more or less Kerberos technology should face a higher or lower bar than anything else. We have an explanation for why Kerberos is not the answer--if someone proposed just using Kerberos unmodified I'd agree with them. The most likely proposals for using Kerberos technology involve building on GSS-EAP or taking some Kerberos concepts and adding them to EAP. I strongly prefer the original to text to the text with Nico's suggested modification. From lear@cisco.com Wed Aug 11 22:40:45 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9083A6964 for ; Wed, 11 Aug 2010 22:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ICmBifDT8co3 for ; Wed, 11 Aug 2010 22:40:44 -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 B49A73A695A for ; Wed, 11 Aug 2010 22:40:44 -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: Av0EAA4mY0xAZnwN/2dsb2JhbACDFZ0kcZ5viVKRcoEmgUuBVnMEiVA X-IronPort-AV: E=Sophos;i="4.55,356,1278288000"; d="scan'208";a="146749277" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2010 05:41:21 +0000 Received: from dhcp-10-55-82-26.cisco.com (dhcp-10-55-82-26.cisco.com [10.55.82.26]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7C5fKRA028916; Thu, 12 Aug 2010 05:41:20 GMT Message-ID: <4C638987.5010007@cisco.com> Date: Thu, 12 Aug 2010 07:41:27 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nicolas Williams References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> In-Reply-To: <20100811203443.GH5213@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 05:40:45 -0000 Nico, Can we please keep the charter from becoming an entire treatise of work (moreso than it already is)? I think it's sufficient that the IESG and the WG know why Kerberos wasn't a starting point. Eliot On 8/11/10 10:34 PM, Nicolas Williams wrote: > On Wed, Aug 11, 2010 at 03:11:40PM +0200, Leif Johansson wrote: >> Federated identity is today widely deployed for web applications using >> such technologies as OpenID, Security Assertion Markup Language (SAML), >> OAuth and Information Card (IMI). However, for protocols such as >> IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on HTTP/HTML >> there is no readily deployable solution for federated identity. > You might want to explain why Kerberos doesn't qualify and/or that even > if it did, it's not what's been deployed for web use, therefore it's > irrelevant. That would help address Glen's points. > > Proposed text: > > It is true that many Internet protocols can use Kerberos V5 for > authentication. However, Kerberos is not an authentication > technology commonly used in Internet-scale web deployments. > Moreover, in the Kerberos model clients contact the infrastructure, > whereas it is highly desirable for servers to contact infrastructure > [maybe list some reasons?]. ... > >> Initially the working group will focus on using GSS-API (RFC2743) to >> integrate federated identity into application protocols but other >> technologies for application interface are in scope. Adoption of such >> solutions by the working group are subject to the normal IETF consensus >> and (re)charter process. > Is it worth mentioning SASL/GS2? I'd think so: > > Initially the working group will focus on using GSS-API (RFC2743) and > SASL (via the GS2 bridge to GSS-API [RFC4422] [RFC5801]) to... > > Looks good to me. > > Nico From Nicolas.Williams@oracle.com Wed Aug 11 23:02:25 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C683A6966 for ; Wed, 11 Aug 2010 23:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Psf2J8Eo5JnC for ; Wed, 11 Aug 2010 23:02:21 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4710A3A695A for ; Wed, 11 Aug 2010 23:02:21 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7C62tHj011801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 06:02:56 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 o7BK0ZTU010314; Thu, 12 Aug 2010 06:02:54 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 509344761281592890; Wed, 11 Aug 2010 23:01:30 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 23:01:29 -0700 Date: Thu, 12 Aug 2010 01:01:25 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20100812060124.GL5213@oracle.com> References: <4C62A18C.9090500@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C62A18C.9090500@sunet.se> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 06:02:25 -0000 On Wed, Aug 11, 2010 at 03:11:40PM +0200, Leif Johansson wrote: > HTTP/HTML interface to authenticate and authorize non-web applications, > this working group will look at approaches that do not rely on the web, > taking into account user interface concerns and the need to pass > structured data to an appropriate authentication interface, as well as > the need to handle large scale discovery. > > [...] > > In addition, the working group will explore the usability and user > interface issues associated with federated authentication. The work is > not chartered to standardize protocols or recommend best current > practice in the area of usability. The working group should explore > the area and produce informational documents describing the issues and > recommending appropriate work for the IETF in this area. > > As future work in dealing with user interface in this area progresses, > the architecture of the system may need to expand to include additional > components or make significant changes to adapt to improvements in > understanding of user interface. In describing architecture work, the > working group will emphasize this possibility of change. Regarding UIs... Since this work will be based on the GSS-API, and the GSS-API lacks APIs relating to UIs... Will GSS-API extensions relating to UIs (say, enhancements for mechanism interaction with the user) be pursued here, or in KITTEN WG? Presumably the latter. Or is this mechanism, though a GSS-API mechanism, not to be used through GSS-API bindings? Nico -- From Nicolas.Williams@oracle.com Wed Aug 11 23:10:33 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E5D3A68C0 for ; Wed, 11 Aug 2010 23:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.085, 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 99-xc1CUNppy for ; Wed, 11 Aug 2010 23:10:32 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1434F3A6861 for ; Wed, 11 Aug 2010 23:10:32 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7C6B6te000916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 06:11:07 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 o7C6B5w3016197; Thu, 12 Aug 2010 06:11:06 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 509366051281593372; Wed, 11 Aug 2010 23:09:32 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 23:09:32 -0700 Date: Thu, 12 Aug 2010 01:09:27 -0500 From: Nicolas Williams To: Eliot Lear Message-ID: <20100812060927.GM5213@oracle.com> References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <4C638987.5010007@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C638987.5010007@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 06:10:33 -0000 On Thu, Aug 12, 2010 at 07:41:27AM +0200, Eliot Lear wrote: > Nico, > > Can we please keep the charter from becoming an entire treatise of work > (moreso than it already is)? I think it's sufficient that the IESG and > the WG know why Kerberos wasn't a starting point. It seemed like an FAQ. No, the charter doesn't have to go into detail on this. The question should be addressed somewhere that people stumbling into this WG will find it, but that's it. From Nicolas.Williams@oracle.com Wed Aug 11 23:26:09 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63813A68C0 for ; Wed, 11 Aug 2010 23:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.083, 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 P8iAgnwPYCrS for ; Wed, 11 Aug 2010 23:26:09 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EAA553A67B4 for ; Wed, 11 Aug 2010 23:26:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7C6QhOJ016549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 06:26:45 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 o7C4VpHf011007; Thu, 12 Aug 2010 06:26:42 GMT Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 489123941281594314; Wed, 11 Aug 2010 23:25:14 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 11 Aug 2010 23:25:14 -0700 Date: Thu, 12 Aug 2010 01:25:09 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20100812062508.GO5213@oracle.com> References: <4C62A18C.9090500@sunet.se> <20100812060124.GL5213@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100812060124.GL5213@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 06:26:09 -0000 On Thu, Aug 12, 2010 at 01:01:25AM -0500, Nicolas Williams wrote: > Regarding UIs... Since this work will be based on the GSS-API, and the > GSS-API lacks APIs relating to UIs... Will GSS-API extensions relating > to UIs (say, enhancements for mechanism interaction with the user) be > pursued here, or in KITTEN WG? Presumably the latter. Or is this > mechanism, though a GSS-API mechanism, not to be used through GSS-API > bindings? Oh, please excuse the above late-night thinko. As with the GSS-API today, UIs can be invoked without the application's help in GUI environments, and that's enough for starters. Nico -- From leifj@mnt.se Thu Aug 12 00:56:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF863A6849 for ; Thu, 12 Aug 2010 00:56:08 -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 eBHoEt5ukxsu for ; Thu, 12 Aug 2010 00:56:07 -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 0AF763A67FA for ; Thu, 12 Aug 2010 00:56:06 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7C7ueUD012381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 09:56:42 +0200 (CEST) Message-ID: <4C63A923.1080709@mnt.se> Date: Thu, 12 Aug 2010 09:56:19 +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: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> In-Reply-To: <20100811223644.GJ5213@oracle.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 07:56:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 HTTP/HTML. >> >> If after further analysis Kerberos must be discarded, we can do so. > > Sure. My intention is not to leave Kerberos out but to explain why > Kerberos is not enough to discard the EAP GSS + AAA + SAML approach. So can we leave the charter text as it is (in this respect)? In general I think less is more when it comes to charter text. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxjqR8ACgkQ8Jx8FtbMZndIvwCfelib1EZSZLNmeV6eF//8/B7s 6YYAoJiHOVRVabJ77+R9/mMtq0eOFpoe =MIFu -----END PGP SIGNATURE----- From gwz@net-zen.net Thu Aug 12 01:04:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4443A69E1 for ; Thu, 12 Aug 2010 01:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49qDMi8d9UxK for ; Thu, 12 Aug 2010 01:04:30 -0700 (PDT) Received: from smtpout07.prod.mesa1.secureserver.net (smtpout07-01.prod.mesa1.secureserver.net [64.202.165.230]) by core3.amsl.com (Postfix) with SMTP id E84FA3A69E8 for ; Thu, 12 Aug 2010 01:04:29 -0700 (PDT) Received: (qmail 4638 invoked from network); 12 Aug 2010 08:05:06 -0000 Received: from unknown (124.157.141.92) by smtpout07.prod.mesa1.secureserver.net (64.202.165.230) with ESMTP; 12 Aug 2010 08:05:04 -0000 From: "Glen Zorn" To: "'Nicolas Williams'" , "'Rafa Marin Lopez'" References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <20100811232241.GK5213@oracle.com> In-Reply-To: <20100811232241.GK5213@oracle.com> Date: Thu, 12 Aug 2010 15:04:39 +0700 Organization: Network Zen Message-ID: <000001cb39f5$05666b00$10334100$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs5rExz+7RNprQeQruJdnrRhnBJOwASKd9g Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:04:30 -0000 What does that mean? Hope this helps. ~gwz > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Nicolas Williams > Sent: Thursday, August 12, 2010 6:23 AM > To: Rafa Marin Lopez > Cc: abfab@ietf.org > Subject: Re: [abfab] charter take 2 > > Also, excluding Kerberos-based solutions from this WG's charter's does > not mean excluding Kerberos-based solutions altogether. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@sunet.se Thu Aug 12 01:11:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA813A696B for ; Thu, 12 Aug 2010 01:11:13 -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 PBLcIiwH-TIi for ; Thu, 12 Aug 2010 01:11:11 -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 7A3EF3A6784 for ; Thu, 12 Aug 2010 01:11:10 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7C8Bje0004221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 10:11:47 +0200 (CEST) Message-ID: <4C63ACC1.4090108@sunet.se> Date: Thu, 12 Aug 2010 10:11:45 +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: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <20100811232241.GK5213@oracle.com> <000001cb39f5$05666b00$10334100$@net> In-Reply-To: <000001cb39f5$05666b00$10334100$@net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:11:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/2010 10:04 AM, Glen Zorn wrote: > What does that mean? > I think Nico means that anyone is free to propose work for the IETF and given enough support work will get done. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxjrMAACgkQ8Jx8FtbMZncsQgCaA7CnWB7QGey251kIqPajqbfB tN8An2SiNPwbTtBHLZYyVjbBT+ROKW4J =LzoA -----END PGP SIGNATURE----- From gwz@net-zen.net Thu Aug 12 01:19:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC0B28C0F6 for ; Thu, 12 Aug 2010 01:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yu1+jZTTnph5 for ; Thu, 12 Aug 2010 01:19:23 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id C69DF28C0E0 for ; Thu, 12 Aug 2010 01:19:18 -0700 (PDT) Received: (qmail 13908 invoked from network); 12 Aug 2010 08:19:55 -0000 Received: from unknown (124.157.141.92) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 12 Aug 2010 08:19:54 -0000 From: "Glen Zorn" To: "'Nicolas Williams'" , "'Leif Johansson'" References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> In-Reply-To: <20100811203443.GH5213@oracle.com> Date: Thu, 12 Aug 2010 15:19:29 +0700 Organization: Network Zen Message-ID: <000701cb39f7$17b27db0$47177910$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs5lOkq0Qh2S4vgQ92LvtZXrvDikAAYSEsQ Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:19:24 -0000 Nicolas Williams [mailto://Nicolas.Williams@oracle.com] writes: ... > You might want to explain why Kerberos doesn't qualify and/or that even > if it did, it's not what's been deployed for web use, therefore it's > irrelevant. That would help address Glen's points. > > Proposed text: > > It is true that many Internet protocols can use Kerberos V5 for > authentication. However, Kerberos is not an authentication > technology commonly used in Internet-scale web deployments. Now I'm really confused! Why does that matter? For that matter, surely you aren't claiming that GSS-API, (non-existent) eap-gss & RadSec (not RADIUS as advertised) _are_ authentication technologies used in Internet-scale web deployments? > Moreover, in the Kerberos model clients contact the infrastructure, > whereas it is highly desirable for servers to contact infrastructure > [maybe list some reasons?]. ... Maybe also what, exactly, 'servers contact infrastructure' means... ... From klaas@cisco.com Thu Aug 12 01:20:15 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37FC928C0F8 for ; Thu, 12 Aug 2010 01:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 mGlsbpEcfxDO for ; Thu, 12 Aug 2010 01:20:14 -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 5491628C0DE for ; Thu, 12 Aug 2010 01:20:14 -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: AjQGAFJLY0xAZnwN/2dsb2JhbACTNI0EcZ5um0CFOgSJXA X-IronPort-AV: E=Sophos;i="4.55,357,1278288000"; d="scan'208";a="146785628" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2010 08:20:51 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7C8KoDW017557 for ; Thu, 12 Aug 2010 08:20:50 GMT Message-ID: <4C63AEE2.4000605@cisco.com> Date: Thu, 12 Aug 2010 10:20:50 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <4C63A923.1080709@mnt.se> In-Reply-To: <4C63A923.1080709@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:20:15 -0000 On 8/12/10 9:56 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > HTTP/HTML. >>> >>> If after further analysis Kerberos must be discarded, we can do so. >> >> Sure. My intention is not to leave Kerberos out but to explain why >> Kerberos is not enough to discard the EAP GSS + AAA + SAML approach. > > So can we leave the charter text as it is (in this respect)? In general > I think less is more when it comes to charter text. I think it is fair to state explicitly that we don't want to paint ourselves in a corner wrt to the technology choices we made. We have a proposed starting point (GSS-API, SAML, EAP, AAA) that was met with rough consensus, that shouldn't stop us from discussing possible better solutions and adopt them if WG consensus says so. Klaas From gwz@net-zen.net Thu Aug 12 01:21:52 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0D7828C0F8 for ; Thu, 12 Aug 2010 01:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.205 X-Spam-Level: X-Spam-Status: No, score=-101.205 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_20=-0.74, 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 siTcZW7Z5pKW for ; Thu, 12 Aug 2010 01:21:52 -0700 (PDT) Received: from smtpauth12.prod.mesa1.secureserver.net (smtpauth12.prod.mesa1.secureserver.net [64.202.165.35]) by core3.amsl.com (Postfix) with SMTP id E6BBC28C0DE for ; Thu, 12 Aug 2010 01:21:51 -0700 (PDT) Received: (qmail 16601 invoked from network); 12 Aug 2010 08:22:28 -0000 Received: from unknown (124.157.141.92) by smtpauth12.prod.mesa1.secureserver.net (64.202.165.35) with ESMTP; 12 Aug 2010 08:22:27 -0000 From: "Glen Zorn" To: "'Leif Johansson'" References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <20100811232241.GK5213@oracle.com> <000001cb39f5$05666b00$10334100$@net> <4C63ACC1.4090108@sunet.se> In-Reply-To: <4C63ACC1.4090108@sunet.se> Date: Thu, 12 Aug 2010 15:22:02 +0700 Organization: Network Zen Message-ID: <000801cb39f7$72ec8680$58c59380$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs59gWqb44pYxTVTE+MboCtumjMmwAASftg Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:21:52 -0000 Leif Johansson [mailto://leifj@sunet.se] writes: > I think Nico means that anyone is free to propose work for the IETF and > given enough support work will get done. Just not in this particular Rube Goldberg experiment? ... From leifj@mnt.se Thu Aug 12 01:30:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367423A69F0 for ; Thu, 12 Aug 2010 01:30:46 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fibmGbV7Rxt0 for ; Thu, 12 Aug 2010 01:30:44 -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 9C42428C0E9 for ; Thu, 12 Aug 2010 01:30:44 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7C8VIEw008681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 10:31:20 +0200 (CEST) Message-ID: <4C63B156.4080007@mnt.se> Date: Thu, 12 Aug 2010 10:31:18 +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: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <20100811232241.GK5213@oracle.com> <000001cb39f5$05666b00$10334100$@net> <4C63ACC1.4090108@sunet.se> <000801cb39f7$72ec8680$58c59380$@net> In-Reply-To: <000801cb39f7$72ec8680$58c59380$@net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:30:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/2010 10:22 AM, Glen Zorn wrote: > Leif Johansson [mailto://leifj@sunet.se] writes: > >> I think Nico means that anyone is free to propose work for the IETF and >> given enough support work will get done. > > Just not in this particular Rube Goldberg experiment? I mean that the normal IETF consensus process applies to this WG as to any other part of the IETF. If you feel that that needs to be made explicit in the charter then by all means let us do so. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxjsVYACgkQ8Jx8FtbMZnfXcACgx8K3tciwkpBfSkcc4N2rZw2t dUIAn2zzKi1kyyrkNEKGQFzrSwTN9VP7 =ZSaj -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Aug 12 05:35:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8345A3A6958 for ; Thu, 12 Aug 2010 05:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 6dzaWF-XAngy for ; Thu, 12 Aug 2010 05:35:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id ADB163A6949 for ; Thu, 12 Aug 2010 05:35:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1D16420438; Thu, 12 Aug 2010 08:35:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 26C9F412A; Thu, 12 Aug 2010 08:35:23 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <4C63A923.1080709@mnt.se> <4C63AEE2.4000605@cisco.com> Date: Thu, 12 Aug 2010 08:35:23 -0400 In-Reply-To: <4C63AEE2.4000605@cisco.com> (Klaas Wierenga's message of "Thu, 12 Aug 2010 10:20:50 +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: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:35:01 -0000 >>>>> "Klaas" == Klaas Wierenga writes: Klaas> On 8/12/10 9:56 AM, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> HTTP/HTML. >>>> >>>> If after further analysis Kerberos must be discarded, we can do >>>> so. >>> >>> Sure. My intention is not to leave Kerberos out but to explain >>> why Kerberos is not enough to discard the EAP GSS + AAA + SAML >>> approach. >> >> So can we leave the charter text as it is (in this respect)? In >> general I think less is more when it comes to charter text. Klaas> I think it is fair to state explicitly that we don't want to Klaas> paint ourselves in a corner wrt to the technology choices we Klaas> made. We have a proposed starting point (GSS-API, SAML, EAP, Klaas> AAA) that was met with rough consensus, that shouldn't stop Klaas> us from discussing possible better solutions and adopt them Klaas> if WG consensus says so. I think the current charter proposal does that and does a good job of drawing the line at changes requiring a recharter. --Sam From hartmans@painless-security.com Thu Aug 12 05:37:14 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340523A6A15 for ; Thu, 12 Aug 2010 05:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 jr6rHmXIQ3To for ; Thu, 12 Aug 2010 05:37:13 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7E33C3A6A0E for ; Thu, 12 Aug 2010 05:37: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 7347920120; Thu, 12 Aug 2010 08:37:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7349D412A; Thu, 12 Aug 2010 08:37:38 -0400 (EDT) From: Sam Hartman To: "Glen Zorn" References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <20100811232241.GK5213@oracle.com> <000001cb39f5$05666b00$10334100$@net> <4C63ACC1.4090108@sunet.se> <000801cb39f7$72ec8680$58c59380$@net> Date: Thu, 12 Aug 2010 08:37:38 -0400 In-Reply-To: <000801cb39f7$72ec8680$58c59380$@net> (Glen Zorn's message of "Thu, 12 Aug 2010 15:22:02 +0700") 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: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:37:14 -0000 >>>>> "Glen" == Glen Zorn writes: Glen> Leif Johansson [mailto://leifj@sunet.se] writes: >> I think Nico means that anyone is free to propose work for the >> IETF and given enough support work will get done. Glen> Just not in this particular Rube Goldberg experiment? Well, an outcome of a BOF or WG discussion could be a decision to try and recharter an existing WG. But yes, the charter is intended to scope the work of abfab. --Sam From klaas@cisco.com Thu Aug 12 05:42:04 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 057533A6828 for ; Thu, 12 Aug 2010 05:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 ACttDzEMBkzs for ; Thu, 12 Aug 2010 05:42:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 196593A68AB for ; Thu, 12 Aug 2010 05:42:03 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAGJY0xAZnwM/2dsb2JhbACgO3GfQ5s9hToEiVw X-IronPort-AV: E=Sophos;i="4.55,358,1278288000"; d="scan'208";a="146682162" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2010 12:42:39 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7CCgd4j028092; Thu, 12 Aug 2010 12:42:39 GMT Message-ID: <4C63EC3E.7050300@cisco.com> Date: Thu, 12 Aug 2010 14:42:38 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Sam Hartman References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <4C63A923.1080709@mnt.se> <4C63AEE2.4000605@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:42:04 -0000 On 8/12/10 2:35 PM, Sam Hartman wrote: >>>>>> "Klaas" == Klaas Wierenga writes: > > Klaas> On 8/12/10 9:56 AM, Leif Johansson wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> > >> HTTP/HTML. > >>>> > >>>> If after further analysis Kerberos must be discarded, we can do > >>>> so. > >>> > >>> Sure. My intention is not to leave Kerberos out but to explain > >>> why Kerberos is not enough to discard the EAP GSS + AAA + SAML > >>> approach. > >> > >> So can we leave the charter text as it is (in this respect)? In > >> general I think less is more when it comes to charter text. > > Klaas> I think it is fair to state explicitly that we don't want to > Klaas> paint ourselves in a corner wrt to the technology choices we > Klaas> made. We have a proposed starting point (GSS-API, SAML, EAP, > Klaas> AAA) that was met with rough consensus, that shouldn't stop > Klaas> us from discussing possible better solutions and adopt them > Klaas> if WG consensus says so. > > I think the current charter proposal does that and does a good job of > drawing the line at changes requiring a recharter. well, the discussion on the list suggests that this is not as evident as also I thought it was, so I think there is no harm in making it more explicit. Klaas From dhc@dcrocker.net Thu Aug 12 08:53:51 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861C23A68DC for ; Thu, 12 Aug 2010 08:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.647 X-Spam-Level: X-Spam-Status: No, score=-6.647 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_05=-1.11, GB_I_INVITATION=-2, 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 gKCe-mZtUFUH for ; Thu, 12 Aug 2010 08:53:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id CEBA23A682A for ; Thu, 12 Aug 2010 08:53:49 -0700 (PDT) Received: from [192.168.1.138] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7CFsLTd023426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 08:54:26 -0700 Message-ID: <4C641927.7080005@dcrocker.net> Date: Thu, 12 Aug 2010 08:54:15 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> In-Reply-To: <4C62A18C.9090500@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 Aug 2010 08:54:27 -0700 (PDT) Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 15:53:51 -0000 Folks, Having read the thread so far, there are a number of items I suggest be changed in the charter: 1. What is "federated identity"? The charter does not define it. I take a rough guess, as part of some text below. It's mostly meant as a placeholder, so that those of you working on this will replace it will what you really want/mean. 2. When a charter scopes its work and there has been prior work, the charter needs to make an explicit and firm statement of the role of that work. The usual choices are: a. A specified set of prior work is input to discussion, but the solution space is wide open. b. A specified set of prior work will be given preference, but the working group is entirely free to replace it or any component of it. (The meaning of "preference" is perhaps intentionally vague.) c. A specified set of prior work provides the foundation for the solution specification, but changes and alternatives will be permitted, given a strong benefit in function, performance and/or operation. d. A specified set of prior work is specifies the core of the solution. Changes will be permitted only when a compelling problem or requirement dictates it. There are, perhaps, more choices, but defines the arc. Especially with the debate from the BOF and continuing on this thread, the charter needs to choose among these. The proposed work does, in fact, have a proposed solution. The third paragraph states it and later in the charter the specific draft documents are cited. Specify their precise role, relative to making changes. Otherwise it is going to continue to be peppered with these foundational debates. To the extent that alternative solutions are permitted, the charter needs to make very clear what the criteria for replacement will be. I don't have a technical assessment of the offered set of specifications, but I know that they are well-established and well-deployed and that starting with that sort of base puts a working group far ahead of things, particularly in a problem space that is, well, problematic. In case anyone had not already known, the debate surrounding the BOF and this thread make clear that this effort is in a problematic problem space. Or perhaps more accurately, a problematic solution space. To that end, I suggest choosing alternative d, above. When someone proposes a change, they need to be required to include a compelling statement of efficacy. It should not be enough to call for "considering" an alternative. It needs to be required that the alternative be offered as superior and the case for its superiority stated. 3. Although it isn't followed very well, there's a directive for formulating the first paragraph of a charter, since that one paragraph is circulated separately, such as in the announcement of the working group.[1] The directive really specifies that the paragraph be a summary abstract, giving folks a basic sense of the problem to be tackled, its relevance, and some indication of how it will be solved. Besides being formally required, I find such summary paragraphs useful as an indication of how well a working group understands what it is going to. It isn't easy to write a tight, one-paragraph summary of work that's to be done, so that it's clear and reasonably compelling. To that end, I suggest, replacing the existing first paragraph with something like: Federated identity shares user authorization information among organizations, without specific registration of the individual user at the organization controlling a a remote resource. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet services, such as IMAP, XMPP, SSH, NFS and other non-IETF protocols and not based on Web protocols. The design will combine existing IETF protocols, specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). With the deployment of the solution, a user from one organization will be able to access resources at another organization, given only prior agreement between the organizations, or prior agreement between each organization and a trusted intermediary. Some additional comments: > Abfab Proposed Charter > > Abfab - Application Bridging for Federated Access Beyond web > > Federated identity is today widely deployed for web applications using > such technologies as OpenID, Security Assertion Markup Language (SAML), > OAuth and Information Card (IMI). However, for protocols such as > IMAP, XMPP, SSH, NFS and other non-IETF protocols not based on HTTP/HTML > there is no readily deployable solution for federated identity. > > While work continues elsewhere on basic mechanisms that rely on using an > HTTP/HTML interface to authenticate and authorize non-web applications, > this working group will look at approaches that do not rely on the web, > taking into account user interface concerns and the need to pass > structured data to an appropriate authentication interface, as well as > the need to handle large scale discovery. > > The working group will develop a solution for federated identity for > IETF and non-IETF application protocols by combining SAML, EAP (RFC > 3748) and AAA (RADIUS, Diameter). > > Constraints: > - ------------ > > The working group will ensure that any solution developed has built- > in technical controls for privacy protection. No doubt I'm naive, but I don't really know what that means. "privacy protection" is a remarkably vague term, in real world usage. I suggest a second sentence to explain it, in practical terms. Does it mean encryption? I assume the goal is more interesting than that. > Initially the working group will focus on using GSS-API (RFC2743) to > integrate federated identity into application protocols but other > technologies for application interface are in scope. Adoption of such > solutions by the working group are subject to the normal IETF consensus > and (re)charter process. This bit of flexibility is an opportunity to sink the working group. GSS-API has a difficult enough history, without inviting more painful and unproductive debate. If there is already a candidate choice, name it. If there isn't, you are almost certainly in the realm of research, not engineering. > The working group may not change EAP (beyond the development of EAP > mechanisms) RADIUS or Diameter without establishing consensus with > the appropriate community within the IETF. What is the difference between "change EAP" versus "development of EAP mechanisms"? Does the latter mean "designs that use EAP"? Are there any goals or constraints to the types of changes that will be permitted? Since these are deployed protocols, changes could be extremely disruptive. An example clarification could be that changes will be upward compatible, to protect the installed based. Certainly some comment about possible effects on the installed base for the constituent protocols needs to be made. > The working group will use the following documents as a starting > point for its work: > > - - draft-howlett-eap-gss-00, > - - draft-howlett-radius-saml-attr-00 > - - draft-hartman-gss-eap-naming-00 Here's where to insert explicit language about the role of these drafts. It should be written as a contract to permit or prohibit classes of changes or replacements. > Concerns have been raised that additional work is required in keying > AAA associations in a federated environment. The working group is > chartered to explore these concerns and if needed, specify protocols > that use existing AAA key management mechanisms to address these concerns. > > In addition, the working group will explore the usability and user > interface issues associated with federated authentication. The work is > not chartered to standardize protocols or recommend best current > practice in the area of usability. The working group should explore > the area and produce informational documents describing the issues and > recommending appropriate work for the IETF in this area. Both the topic of identity and the topic of usability are open invitations to wander forever and unpleasantly in a land of controversy and confusion. Worse, as a community, the IETF has a long history of very low competence in usability discussions. Very few participants have a background in UI/UXE/usability designs and the required methodologies for validating them. This is a specialty but it is rarely acknowledged as such in IETF discussions. For example, virtually all discussions of usability that I've seen in the IETF are based on using the speaker as an exemplar. No one participating in the IETF is an example of a typical user. If the group still insists on this charter item, it needs to explain how it will pursue such issues productively. > As future work in dealing with user interface in this area progresses, > the architecture of the system may need to expand to include additional > components or make significant changes to adapt to improvements in > understanding of user interface. In describing architecture work, the > working group will emphasize this possibility of change. What does that last sentence actually mean, in practical terms? > Coordination with other SDOs > - ---------------------------- > > This work will require close coordination with work going on in the > OASIS Security Services Technical Committee (SSTC). There should be > sufficient overlapping participation between the SSTC and this working > group for informal coordination. The chairs of this working group may > work with the SSTC chairs and the IAB in case formal coordination is > required. > > In particular coordination is required with respect to the SAML-RADIUS > binding. > > Deliverables > - ------------ > > The deliverables of the working group are: > > * A document describing applicable use cases. > > * An architecture document describing how the components of the solution > fit together to address the use cases and open issues that will require > future changes to the architecture > > * A standards-track protocol for carrying SAML messages in RADIUS and > Diameter > > * An update to the EAP applicability statement in RFC 3748 describing > the applicability of EAP to application authentication and placing > appropriate requirements on this new EAP use case Application authentication? Doesn't this mean application /user/ authentication? Does it also mean authorization? > * A standards track solution for using EAP methods to provide > authentication within the application "solution"? Is that different from a specification? What will this be, exactly? How is it expected to be used? > * An update to the EMSK root key applicability statement in RFC 5295 > > * A standards-track description of GSS names and name attributes > required by the solution > > * Informational descriptions of usability and user-interface concerns > related to this work Thar be dragons. d/ [1] , Section 2.2: > Description of working group > The focus and intent of the group shall be set forth briefly. By > reading this section alone, an individual should be able to decide > whether this group is relevant to their own work. The first > paragraph must give a brief summary of the problem area, basis, > goal(s) and approach(es) planned for the working group. This > paragraph can be used as an overview of the working group's > effort. -- Dave Crocker Brandenburg InternetWorking bbiw.net From Nicolas.Williams@oracle.com Thu Aug 12 08:59:40 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210513A682E for ; Thu, 12 Aug 2010 08:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 k2azXAw2GFHt for ; Thu, 12 Aug 2010 08:59:39 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3D78D3A67FC for ; Thu, 12 Aug 2010 08:59:39 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7CG0BiA016682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 16:00:13 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 o7BIujAX026819; Thu, 12 Aug 2010 16:00:06 GMT Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 490651501281628773; Thu, 12 Aug 2010 08:59:33 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Aug 2010 08:59:30 -0700 Date: Thu, 12 Aug 2010 10:59:25 -0500 From: Nicolas Williams To: Glen Zorn Message-ID: <20100812155923.GP5213@oracle.com> References: <4C62A18C.9090500@sunet.se> <20100811203443.GH5213@oracle.com> <780F12EC-BC23-4B0A-BF0E-0DCA7E0DF133@um.es> <20100811223644.GJ5213@oracle.com> <20100811232241.GK5213@oracle.com> <000001cb39f5$05666b00$10334100$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001cb39f5$05666b00$10334100$@net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 15:59:40 -0000 On Thu, Aug 12, 2010 at 03:04:39PM +0700, Glen Zorn wrote: > Nico> Also, excluding Kerberos-based solutions from this WG's > Nico> charter's does not mean excluding Kerberos-based solutions > Nico> altogether. > > What does that mean? It means that one can pursue Kerberos-based solutions as either individual submission I-Ds or in other WGs or by chartering a new WG. For example, new pre-authentication mechanisms for Kerberos belong in KRB-WG. Nico -- From hartmans@painless-security.com Thu Aug 12 10:32:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A503A6953 for ; Thu, 12 Aug 2010 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 wQDuF+t8RKXb for ; Thu, 12 Aug 2010 10:32:29 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 53C8F3A6968 for ; Thu, 12 Aug 2010 10:32:29 -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 3EBFF201C7; Thu, 12 Aug 2010 13:33:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 11BB8412A; Thu, 12 Aug 2010 13:32:45 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> Date: Thu, 12 Aug 2010 13:32:44 -0400 In-Reply-To: <4C641927.7080005@dcrocker.net> (Dave CROCKER's message of "Thu, 12 Aug 2010 08:54:15 -0700") 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: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 17:32:30 -0000 >>>>> "Dave" == Dave CROCKER writes: Dave> To that end, I suggest choosing alternative d, above. Dave> When someone proposes a change, they need to be required to Dave> include a compelling statement of efficacy. It should not be Dave> enough to call for "considering" an alternative. It needs to Dave> be required that the alternative be offered as superior and Dave> the case for its superiority stated. Dave, what we were trying to choose was that the set of documents listed as starting points would be accepted as WG items as part of the chartering process with the effect that it would require a consensus decision of the WG to change these documents. I think that is a clear thing to choose; I also believe that to the best of my understanding, it aligns with option B above, so I think we're on the same page. There's one document (draft-howlett-radsec-kmp) that is being submitted as input, but that we believe additional discussion is required before the WG decides whether to adopt that document. I believe that's called out in the charter. I think this is all clear in the charter--I think the debate has mostly been over whether these are the right choices. However text is more clear to those who have been involved. If you think it is unclear, we should fix that. Dave> 3. Although it isn't followed very well, there's a directive Dave> for formulating the first paragraph of a charter, since that Dave> one paragraph is circulated separately, such as in the Dave> announcement of the working group.[1] You learn something new every day. I bet I'm not the only former IESG member who was unaware of this. Dave> paragraph with something like: Dave> Federated identity shares user authorization information Dave> among organizations, without specific registration of the Dave> individual user at the organization controlling a a remote Dave> resource. A number of such mechanisms are in use for the Web. Dave> This working group will specify a federated identity mechanism Dave> for use by other Internet services, such as IMAP, XMPP, SSH, Dave> NFS and other non-IETF protocols and not based on Web Dave> protocols. The design will combine existing IETF protocols, Dave> specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). Dave> With the deployment of the solution, a user from one Dave> organization will be able to access resources at another Dave> organization, given only prior agreement between the Dave> organizations, or prior agreement between each organization Dave> and a trusted intermediary. This seems reasonable. --Sam From dhc@dcrocker.net Thu Aug 12 14:46:50 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC5B3A67B3 for ; Thu, 12 Aug 2010 14:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.395 X-Spam-Level: X-Spam-Status: No, score=-7.395 tagged_above=-999 required=5 tests=[AWL=1.204, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 M+-W4LbOQW2U for ; Thu, 12 Aug 2010 14:46:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id C66043A6A20 for ; Thu, 12 Aug 2010 14:46:25 -0700 (PDT) Received: from [192.168.1.138] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7CLkuFA006650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2010 14:47:02 -0700 Message-ID: <4C646BCA.9080502@dcrocker.net> Date: Thu, 12 Aug 2010 14:46:50 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 Aug 2010 14:47:03 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 21:46:50 -0000 Sam, On 8/12/2010 10:32 AM, Sam Hartman wrote: > Dave> To that end, I suggest choosing alternative d, above. > Dave> When someone proposes a change, they need to be required to > Dave> include a compelling statement of efficacy. ... > Dave, what we were trying to choose was that the set of documents listed > as starting points would be accepted as WG items as part of the > chartering process with the effect that it would require a consensus > decision of the WG to change these documents. > I think that is a clear thing to choose; I also believe that to the best > of my understanding, it aligns with option B above, so I think we're on > the same page. Let me stress that model b is quite different from model d. Model b invites debate about the approach being taken and the solutions being proposed. Depending upon the problem- and solution-spaces, such debate -- especially in the extended form that I think is likely here -- can be healthy or detrimental. My own view is that it's healthy when one or both spaces are not well-understood, since it will tend to force everyone to develop a better and better-shared understanding. If things are already well-understood, this sort of open-ended invitation for alternatives is going to be more problematic than helpful. The folks on the losing side will constantly look for a way to re-open the choices. Security does not have a great track record in the IETF. (To be fair, Internet scale security doesn't have a great track record anywhere.) At Internet scale, point-to-point data protection is finally well established. Anything having serious use of identity information is not. At Internet scale, identity and authorization have already demonstrated that they constitute a very messy topic in which technical progress is challenging to make, and that even coherent discussion is often challenging. That's why I'm pressing so hard to have the charter be especially clear, constrained and firm. An effort like this needs as much help as possible to increase its chance of success. If successful, it is likely to make a major change in the way the Internet is used. Since we really do need that change, that extra help is not for whimsy or ego. If the folks formulating the proposal that the current work is based on intended it merely as an exemplar, with a goal of inviting proposals from the community, that's fine. It won't be efficient or quick, but it's certainly a reasonable goal. I didn't get the impression that that was the goal of this work. Rather, I got the impression that the proposal is meant as a complete solution, and that the purpose of the working group is for refinement and, perhaps, enhancement. That's a completely different goal. It, too, is reasonable. The charter should clearly and forcefully state the goal -- in these kinds of terms -- and should include whatever procedural constraints are appropriate to that goal. I'll state that I think what you've said in your reply does not match what I took to be the actual view about the work that's been submitted. I think that what you've said is more flexible than is intended by the team that developed the proposal. At the least, it will be good to get that clarified. The clarification may well require being more firm and forthright than is comfortable for some folks. I'll suggest that that bit of discomfort can at best be delayed, but not avoided. Suffer it now or suffer it -- probably worse -- later. > I think this is all clear in the charter--I think the debate has mostly > been over whether these are the right choices. Much of what I heard in the BOF was not "here's a specific technical or operational problem with a specific part of the proposal" or "here's an alternative that has the following superior characteristics." Rather I heard "the group should also consider proposal X or mechanism Y." I'm sorry, but that sort of open-ended suggestion is much more appropriate to the situation I cited earlier, when the problems and their solutions are not (yet) all that well understood. Unless I've misunderstood things, that's not the case here. > Dave> 3. Although it isn't followed very well, there's a directive > Dave> for formulating the first paragraph of a charter, since that > Dave> one paragraph is circulated separately, such as in the > Dave> announcement of the working group.[1] > > You learn something new every day. I bet I'm not the only former IESG member > who was unaware of this. Unfortunately, I've tested that a few times over the years and you are correct. On the average, the IETF is quite good at creating procedural text and quite poor at following it. Following it requires quite a bit of extra work... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hartmans@painless-security.com Thu Aug 12 15:00:22 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57C33A6A20 for ; Thu, 12 Aug 2010 15:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z6jdQTPyNat for ; Thu, 12 Aug 2010 15:00:22 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0E7033A67E3 for ; Thu, 12 Aug 2010 15:00:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 03917200B4; Thu, 12 Aug 2010 18:00:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 253D7412A; Thu, 12 Aug 2010 18:00:46 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <9A8AC534-479B-4529-9670-4BE836385C05@cisco.com> <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> <20100810135156.GS5213@oracle.com> <20100810141016.GT5213@oracle.com> Date: Thu, 12 Aug 2010 18:00:46 -0400 In-Reply-To: <20100810141016.GT5213@oracle.com> (Nicolas Williams's message of "Tue, 10 Aug 2010 09:10:16 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-krb-wg@anl.gov, abfab@ietf.org Subject: [abfab] Fast VS gss preauth for Kerberos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:00:22 -0000 Nico have had this discussion a couple of times. I thought I'd write it down so I can remember it in the future. >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> As you know, while I'm a fan of FAST, I'd rather have gone Nicolas> with a GSS-API pre-authentication framework for Kerberos. Nicolas> Of course, by now FAST is sufficiently well implemented Nicolas> that it's probably easier to plug into it than it would be Nicolas> to add a GSS-API pre-auth method to Kerberos... I've been thinking more about FAST vs GSS preauth. As best I can tell they fit together nicely. For example because we have FAST, we can use anything with channel bindings as a preauth we don't need to require gss_wrap. With sufficiently strong gss_wrap style preauth we could have avoided the need for armor keys. However you'd need a fairly strong preauth mechanism for that. For example, I'm not sure SCRAM wouldn't be significantly improved by armor. If you agree that something like armor is necessary, I think GSS preauth adds very little complexity over FAST. You probably could have gotten a simpler encoding if it wasn't for backward compatibility issues. So, we may not have gone very far afield with FAST. From an implementation standpoint I'm definitely happy I was doing FAST not gss-preauth. I avoided the complexity of multi-round-trip state management. From shore@arsc.edu Thu Aug 12 15:04:04 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493263A6A09 for ; Thu, 12 Aug 2010 15:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.592 X-Spam-Level: X-Spam-Status: No, score=-3.592 tagged_above=-999 required=5 tests=[AWL=1.007, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO2pMFxRWmWz for ; Thu, 12 Aug 2010 15:04:03 -0700 (PDT) Received: from arsc.edu (mail1.arsc.edu [199.165.84.229]) by core3.amsl.com (Postfix) with ESMTP id 3B3233A67E3 for ; Thu, 12 Aug 2010 15:04:03 -0700 (PDT) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:75:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id o7CM2m9X000126; Thu, 12 Aug 2010 14:02:48 -0800 (AKDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Melinda Shore In-Reply-To: <4C646BCA.9080502@dcrocker.net> Date: Thu, 12 Aug 2010 14:02:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> <4C646BCA.9080502@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1081) X-CanIt-Geo: No geolocation information available for 2001:480:150:75:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:04:04 -0000 On Aug 12, 2010, at 1:46 PM, Dave CROCKER wrote: > My own view is that it's healthy when one or both spaces are not = well-understood, since it will tend to force everyone to develop a = better and better-shared understanding. If things are already = well-understood, this sort of open-ended invitation for alternatives is = going to be more problematic than helpful. The folks on the losing side = will constantly look for a way to re-open the choices. I was extremely unhappy with the BOF - discussion of alternatives was shut down, there was substantial dissent on a consensus call but consensus was declared anyway with dissenters not given an opportunity to speak up, and several other problems. But, I think Dave's point here is compelling, and it's not that hard to come up with efforts that have been derailed by constant revisitation of key decisions. I tend to think it's not going to be possible to finalize the charter if there's an attempt to pay lip service to being open to alternatives when that openness is actually just procedural, to keep people happy with the process, and not technical. =20 It seems to me that some of the key decisions here were made before the work was brought to the IETF, and that even though I may or may not disagree with some of them, probably what needs to be done here is to nail down those decisions, document them, and get them into the charter. Melinda From hartmans@painless-security.com Thu Aug 12 15:13:27 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C77E3A6A24 for ; Thu, 12 Aug 2010 15:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 HlKCqtBqs1J4 for ; Thu, 12 Aug 2010 15:13:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C5CB73A6A13 for ; Thu, 12 Aug 2010 15:13:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DB23D203C7; Thu, 12 Aug 2010 18:14:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 14519412A; Thu, 12 Aug 2010 18:13:51 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> <4C646BCA.9080502@dcrocker.net> Date: Thu, 12 Aug 2010 18:13:51 -0400 In-Reply-To: <4C646BCA.9080502@dcrocker.net> (Dave CROCKER's message of "Thu, 12 Aug 2010 14:46:50 -0700") 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: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:13:27 -0000 Dave, I think what we (speaking as one of the authors of the proposal want) is: * Agree that we're going to start with our proposal as a work item of the WG. That means you need active agreement to change the proposal. * Put some explicit constraints about technology choice etc into the charter, so that if we succeed we get something that is fundamentally similar to our proposal. * Leave the WG a lot of flexibility with the details of our proposal. * Be open to the idea that it might also be good to work on other proposals that are either extensions of our proposal, solve different problems, etc. However taking on such a proposal should involve a recharter so we can have an explicit point to discuss whether the proposals we are considering adding are good ideas. We'd also presumably want to discuss whether the existing WG is the right place to work on them. We'd presumably consider issues like whether we're taking on too much, whether we can deliver quality results in a timely manner with the things we're considering signing up to do, and whether we have the right people. I believe that constraining the technologies and their roles is sufficient to avoid constant discussion of what approach we're going down. In particular, I believe that if we say we're using EAP to authenticate the subject to a trusted party, using AAA to authenticate and convey information from that party to a relying party, using SAML for authorization and personalization, and using GSS-API for application integration, we have fundamentally captured sufficient constraints. I'd definitely appreciate help saying that in the charter. Also, I'm certainly open to comments about whether that's the wrong thing to say. From dhc@dcrocker.net Thu Aug 12 15:15:57 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70303A6A50 for ; Thu, 12 Aug 2010 15:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 SuvJDDoSBr+9 for ; Thu, 12 Aug 2010 15:15:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id C71ED3A694E for ; Thu, 12 Aug 2010 15:15:56 -0700 (PDT) Received: from [192.168.1.138] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7CMGSGZ007542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2010 15:16:34 -0700 Message-ID: <4C6472B6.6090201@dcrocker.net> Date: Thu, 12 Aug 2010 15:16:22 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> <4C646BCA.9080502@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 12 Aug 2010 15:16:34 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:15:57 -0000 On 8/12/2010 3:13 PM, Sam Hartman wrote: > I'd definitely appreciate help saying that in the charter. Also, I'm > certainly open to comments about whether that's the wrong thing to say. I'd like to emphasize that the second sentence should be the highest priority in writing the charter. Get consensus on that and the rest is mere wordsmithing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Nicolas.Williams@oracle.com Thu Aug 12 15:20:14 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 533A33A6A46 for ; Thu, 12 Aug 2010 15:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.078, 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 MxY+WY1AyBNQ for ; Thu, 12 Aug 2010 15:20:13 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 54A743A6A13 for ; Thu, 12 Aug 2010 15:20:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7CMKkr8004634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 22:20:49 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 o7CEOAKB005687; Thu, 12 Aug 2010 22:20:45 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 512278801281651565; Thu, 12 Aug 2010 15:19:25 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Aug 2010 15:19:25 -0700 Date: Thu, 12 Aug 2010 17:19:20 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100812221920.GY5213@oracle.com> References: <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> <20100810135156.GS5213@oracle.com> <20100810141016.GT5213@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) Cc: ietf-krb-wg@anl.gov, abfab@ietf.org Subject: Re: [abfab] Fast VS gss preauth for Kerberos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:20:14 -0000 On Thu, Aug 12, 2010 at 06:00:46PM -0400, Sam Hartman wrote: > Nico have had this discussion a couple of times. I thought I'd write it > down so I can remember it in the future. Heh. Well, let me present my view as well. First let me address this: > If you agree that something like armor is necessary, I think GSS preauth > adds very little complexity over FAST. You probably could have gotten a > simpler encoding if it wasn't for backward compatibility issues. The complexity trade-off ultimately would lie in composition. FAST provides a mechanism for that, while the GSS-API doesn't-but-could, so anyone wishing to design my ideal would have to provide for composition. The fact that FAST got there first is sufficient that without a need for mechanism composition elsewhere, it won't happen for the GSS-API. But a GSS-API pre-auth mechanism that fits into FAST is certainly feasible, and probably desirable. Now, back to my world view... Ideally the KDC protocol would be like any other application protocol and not directly deal with "reply keys" or any such thing. That is, a client would connect[*], use SASL or GSS-API to mutually authenticate, and use some security layer[**] to do simplified AS exchanges. Neither the AS-REQ nor the AS-REP would contain pre-auth data nor "encrypted parts" (the Ticket itself, would, as usual, have an encrypted part, of course). Here SASL/GSS would provide pre-authentication outside the AS exchange; an additional message pair for negotiating what mechanism to use would be needed. Stackable pseudo-mechanisms would have provided for mechanism composition. Note that in my ideal world the strength of keys that SCRAM could output is irrelevant. What matters is the strength of the keys provided by the underlying channel in combination with the strength of the channel binding. Of course, the strength of SCRAM's channel binding is consonant with the strength of SCRAM's PRF and per-message tokens. [*] UDP could be supported too. [**] TLS, if bound to from the SASL or GSS authentication, or SASL security layers, or GSS-API wrap tokens with confidentiality protection. But... that's not gonna happen. It could, but it's too late. The next ideal case is more or less as you described, with either FAST or stackable GSS-API pseudo-mechanisms providing composition. Nico -- From hartmans@painless-security.com Thu Aug 12 15:27:45 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B5D3A69FF for ; Thu, 12 Aug 2010 15:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.695 X-Spam-Level: X-Spam-Status: No, score=-102.695 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCNva3cpahaa for ; Thu, 12 Aug 2010 15:27:44 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 541FA3A6925 for ; Thu, 12 Aug 2010 15:27:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6C6E7203C7; Thu, 12 Aug 2010 18:28:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 79F38412A; Thu, 12 Aug 2010 18:28:08 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <20100809181025.GD5217@oracle.com> <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> <20100810135156.GS5213@oracle.com> <20100810141016.GT5213@oracle.com> <20100812221920.GY5213@oracle.com> Date: Thu, 12 Aug 2010 18:28:08 -0400 In-Reply-To: <20100812221920.GY5213@oracle.com> (Nicolas Williams's message of "Thu, 12 Aug 2010 17:19:20 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ietf-krb-wg@anl.gov, abfab@ietf.org, Sam Hartman Subject: Re: [abfab] Fast VS gss preauth for Kerberos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:27:45 -0000 Thanks for this write up. I keep forgetting that stackable mechanisms play into your model. From Nicolas.Williams@oracle.com Thu Aug 12 15:36:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53563A6A49 for ; Thu, 12 Aug 2010 15:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 VHYGfV0elRDG for ; Thu, 12 Aug 2010 15:36:57 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 318823A6A6D for ; Thu, 12 Aug 2010 15:36:49 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7CMbAvF000318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 22:37:11 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 o7CHL7rY005343; Thu, 12 Aug 2010 22:37:09 GMT Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 512327501281652555; Thu, 12 Aug 2010 15:35:55 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Aug 2010 15:35:55 -0700 Date: Thu, 12 Aug 2010 17:35:49 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100812223548.GA5213@oracle.com> References: <4ED04531-3291-49AE-A549-23417652CECE@um.es> <20100809220432.GE5213@oracle.com> <20100809232731.GK5213@oracle.com> <3C83A7D7-480D-4EB7-9A53-92240F0D4947@um.es> <20100810135156.GS5213@oracle.com> <20100810141016.GT5213@oracle.com> <20100812221920.GY5213@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100812221920.GY5213@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: ietf-krb-wg@anl.gov, abfab@ietf.org Subject: Re: [abfab] Fast VS gss preauth for Kerberos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:36:59 -0000 I would also add that PKIX has something similar to the ideal that I just described for Kerberos: SACRED. It uses TLS, it uses SASL. It doesn't say anything about channel binding, but easily could. From leifj@sunet.se Thu Aug 12 15:39:15 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882FC3A6A51 for ; Thu, 12 Aug 2010 15:39:15 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nWX3rmLcl5u for ; Thu, 12 Aug 2010 15:39:14 -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 27CEA3A69FF for ; Thu, 12 Aug 2010 15:39:13 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7CMdlrs019136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Aug 2010 00:39:49 +0200 (CEST) Message-ID: <4C647833.1030406@sunet.se> Date: Fri, 13 Aug 2010 00:39:47 +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: abfab@ietf.org References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> <4C646BCA.9080502@dcrocker.net> <4C6472B6.6090201@dcrocker.net> In-Reply-To: <4C6472B6.6090201@dcrocker.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:39:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 12:16 AM, Dave CROCKER wrote: > > > On 8/12/2010 3:13 PM, Sam Hartman wrote: >> I'd definitely appreciate help saying that in the charter. Also, I'm >> certainly open to comments about whether that's the wrong thing to say. > > > I'd like to emphasize that the second sentence should be the highest > priority in writing the charter. I know you said this at the mic during the BoF: clearly list the points of least flexibility in the proposal. I believe this is what Sam is trying to do by saying: "I believe that constraining the technologies and their roles is sufficient to avoid constant discussion of what approach we're going down. In particular, I believe that if we say we're using EAP to authenticate the subject to a trusted party, using AAA to authenticate and convey information from that party to a relying party, using SAML for authorization and personalization, and using GSS-API for application integration, we have fundamentally captured sufficient constraints." Are we just in violent agreement? I agree we need consensus on this point: is the community willing to support formation of a WG with these constraints and I'd like to get to a point in the charter process where we can ask that question. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxkeDMACgkQ8Jx8FtbMZnfhAwCghTyOV2TW4v16YxQMWCgs301S sSYAniJd9foHDUYlc6+d7UaITioeYuZZ =YR8/ -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Thu Aug 12 15:53:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6CE3A683C for ; Thu, 12 Aug 2010 15:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, 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 XmJOvhfuc3pE for ; Thu, 12 Aug 2010 15:53:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EC1B53A67B3 for ; Thu, 12 Aug 2010 15:53:35 -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.2) with ESMTP id o7CMsAdf030713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 22:54:12 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7CMs9t8007149; Thu, 12 Aug 2010 22:54:10 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 491885691281653593; Thu, 12 Aug 2010 15:53:13 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Aug 2010 15:53:12 -0700 Date: Thu, 12 Aug 2010 17:53:07 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20100812225307.GB5213@oracle.com> References: <4C62A18C.9090500@sunet.se> <4C641927.7080005@dcrocker.net> <4C646BCA.9080502@dcrocker.net> <4C6472B6.6090201@dcrocker.net> <4C647833.1030406@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C647833.1030406@sunet.se> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 2 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 22:53:36 -0000 On Fri, Aug 13, 2010 at 12:39:47AM +0200, Leif Johansson wrote: > On 08/13/2010 12:16 AM, Dave CROCKER wrote: > > ... > > I know you said this at the mic during the BoF: clearly list the points > of least flexibility in the proposal. I believe this is what Sam is > trying to do by saying: > > "I believe that constraining the technologies and their roles is > [...]" > > Are we just in violent agreement? > > I agree we need consensus on this point: is the community willing to > support formation of a WG with these constraints and I'd like to get > to a point in the charter process where we can ask that question. I am. Incidentally, and for the record, I have no direct nor indirect interest in any one of the proposals made here (though I am friends with some of the proponents). I've stated my rationale for supporting the proposal on the table (EAP GSS + AAA + SAML). I've also stated my rationales for pursuing this proposal in this WG in spite of, and even to the exclusion (in this WG) of some possible alternatives (Kerberos, ...) or others (OAuth, ...) based on real-world applicability issues (Kerberos, ...) or security principles (OAuth, ...). I hope those are convincing, else someone could convince me. I'm open to OAuth if modified to meet the security principles stated by Sam. Nico -- From leifj@sunet.se Fri Aug 13 00:32:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77F83A6964 for ; Fri, 13 Aug 2010 00:32:09 -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 LJ-Y62pkNX0p for ; Fri, 13 Aug 2010 00:32:06 -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 38A7E3A681B for ; Fri, 13 Aug 2010 00:32:04 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7D7WckO015487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Aug 2010 09:32:40 +0200 (CEST) Message-ID: <4C64F516.8020801@sunet.se> Date: Fri, 13 Aug 2010 09:32:38 +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: abfab@ietf.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 07:32:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've tried my best to summarize the various threads going on, specifically: - - I've used Daves excellent first paragraph (with minor nit) - - I've used Sams text describing the role of EAP, AAA and SAML (3rd p.) - - I've added a paragraph (4th) where I've tried to be explicit (in the light of the discussion between Sam, Glen, Dave and Klaas) about the status of EAP, AAA and SAML in the architecture. - - Minor stylistic nit in 5th p. Abfab Proposed Charter Abfab - Application Bridging for Federated Access Beyond web Federated identity shares user authorization information among organizations, without specific registration of the individual user at the organization controlling a a remote resource. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet services, such as IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web protocols. The design will combine existing IETF protocols, specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). With the deployment of the solution, a user from one organization will be able to access resources at another organization, given only prior agreement between the organizations, or prior agreement between each organization and a trusted intermediary. While work continues elsewhere on basic mechanisms that rely on using an HTTP/HTML interface to authenticate and authorize non-web applications, this working group will look at approaches that do not rely on the web, taking into account user interface concerns and the need to pass structured data to an appropriate authentication interface, as well as the need to handle large scale discovery. The working group will develop a solution for federated identity for IETF and non-IETF application protocols by combining SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML is used for authorization and personalization. The working group may consider other alternative technology for these three roles in the architecture but any change in direction in this respect requires rechartering of the working group. Constraints: - ------------ Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. The working group will ensure that any solution developed has built- in technical controls for privacy protection. The working group may not change EAP (beyond the development of EAP mechanisms), RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - - draft-howlett-eap-gss-00, - - draft-howlett-radius-saml-attr-00 - - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. In addition, the working group will explore the usability and user interface issues associated with federated authentication. The work is not chartered to standardize protocols or recommend best current practice in the area of usability. The working group should explore the area and produce informational documents describing the issues and recommending appropriate work for the IETF in this area. As future work in dealing with user interface in this area progresses, the architecture of the system may need to expand to include additional components or make significant changes to adapt to improvements in understanding of user interface. In describing architecture work, the working group will emphasize this possibility of change. Coordination with other SDOs - ---------------------------- This work will require close coordination with work going on in the OASIS Security Services Technical Committee (SSTC). There should be sufficient overlapping participation between the SSTC and this working group for informal coordination. The chairs of this working group may work with the SSTC chairs and the IAB in case formal coordination is required. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables - ------------ The deliverables of the working group are: * A document describing applicable use cases. * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture * A standards-track protocol for carrying SAML messages in RADIUS and Diameter * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case * A standards track solution for using EAP methods to provide authentication within the application * An update to the EMSK root key applicability statement in RFC 5295 * A standards-track description of GSS names and name attributes required by the solution * Informational descriptions of usability and user-interface concerns related to this work -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxk9RAACgkQ8Jx8FtbMZnc5sACgjZA9qFQLI9PWajoNF5DXWj/O 4NQAnidUYYfyrcoOqvgfFeGRURQ1wh48 =gRBO -----END PGP SIGNATURE----- From alper.yegin@yegin.org Fri Aug 13 02:33:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F292E3A6804 for ; Fri, 13 Aug 2010 02:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.221 X-Spam-Level: X-Spam-Status: No, score=-100.221 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, MSGID_MULTIPLE_AT=1.449, 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 RiDhYZDVE7Or for ; Fri, 13 Aug 2010 02:33:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id BE9BB3A6851 for ; Fri, 13 Aug 2010 02:33:28 -0700 (PDT) Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M5uk5-1P7y4x1Iu9-00yObW; Fri, 13 Aug 2010 05:34:01 -0400 From: "Alper Yegin" To: "'Sam Hartman'" References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> <20100810172037.GZ5213@oracle.com> <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> <029501cb392c$704cd9a0$50e68ce0$@yegin@yegin.org> In-Reply-To: Date: Fri, 13 Aug 2010 12:33:37 +0300 Message-ID: <015901cb3aca$9fd28590$df7790b0$@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 Thread-Index: Acs5UjnMFmAy2EzyRkeTGELatwlqowBdtRZQ Content-Language: en-us X-Provags-ID: V02:K0:KcNkAwBjV6bUk+A8Sm0Yd5Qok+SDvJewbuxuGxyYAgJ WCKGBFDXM9LPBDnX+daObidHn7WV0AipR8bOnL4sRteKxK0Ja0 kWmHPa8OB+tEszJwhM5/5Mljvq55JGIyt91OQ0rHLq/P2REZlH 5POiC2TlMw8qSKpSZeJAXYc3D1s5W7w6KotOh/z0Q146RWk01B wECkqF3cslmZklwvk3pnGOkDl9oeb+UroUBBzepYVU= Cc: abfab@ietf.org, 'Nicolas Williams' Subject: Re: [abfab] Charter: EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:33:30 -0000 Sam, > >>>>> "Alper" == Alper Yegin writes: > > > Alper> * An update to the EMSK root key applicability statement in > Alper> RFC 5295 > > Alper> It is obvious that this is needed for the work to progress, > Alper> but it is not clear when and how the IETF agreed to do that. > > > The IETF hasn't agreed to do that. My point is, it is not even discussed in this community. Last time it was discussed, the decision was the opposite of what is written in the charter. IETF is left at that point. > The IETF would agree to do that by > chartering work to do that; we're having the discussion now about > whether that's a good idea. In particular, if you believe this topic > needs more discussion, you could call that out when the charter goes > out > for external review within the IETF. Shouldn't this be discussed "internally" with the BoF members, and pulling in all the other relevant players from EAP/EMU/PANA/AAA community? > Alper> In ICOS BoF and HO(A)KEY WG formation era (and even > Alper> afterwards), leadership was shooting down proposals because > Alper> they were violating this sacred applicability statement. > > I think I was most of the leadership doing the shooting down:-) I went > back to review my statements at least as far as they went into the > minutes. The statements in the minutes seem correct with what I > remember saying. > > > In those fora, I never said that you cannot change the applicability > statement. I outlined some of the things I think you'd need to do in > order to explain it and why I believed that would be hard. > > When you brought up this issue a few months ago, I explained in my > response why I believe that this proposal meets the criteria I set out > at ICOS and elsewhere. We need to have an elaborative discussion on that. It was not clear to me and several others when you were opposing that at ICOS, and it is still not clear why it is OK now. > I may have made stronger statements at the first ISMS meeting after I > became AD. At least what went into the minutes is consistent with what > I > said at ICOS, although it would not surprise me if some of the shorter > statements I made at the mic were over-simplifications of the entire > position and were not entirely consistent. (I was a new AD at the > first > ISMS meeting; I had only become aware of the applicability issue when > briefed by Bernard shortly before the meeting.) > > I cannot speak for other IETF leadership. It's my understanding that my > position was consistent with the position of other IETF and EAP > leadership. Well, you stand out with your strong position at ICOS. > I believe that everyone in the leadership who expressed concerns about > applicability of EAP is aware of this proposal. Not so, unfortunately. Not that I polled everyone, but I'm aware of one important case. Jari Arkko learned about this EAP applicability change proposal from me when I had a chat with him after the BoF was held in Maastricht. Did you make people aware of this proposal on the EAP/EMU/PANA/AAA mailing lists? > However, I do agree > with you that this is an important issue and we should make shure we > handle it correctly. My point is, before this point gets into the charter, it should be discussed. Alper > > --Sam From lear@cisco.com Fri Aug 13 02:38:51 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0693A68F1 for ; Fri, 13 Aug 2010 02:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fke1PKTycKta for ; Fri, 13 Aug 2010 02:38:50 -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 E01C33A693D for ; Fri, 13 Aug 2010 02:38:49 -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: Av0EAM6vZExAZnwM/2dsb2JhbACDFZ0kcZ9qiVKRcoEmgyFzBIlf X-IronPort-AV: E=Sophos;i="4.55,362,1278288000"; d="scan'208";a="147283433" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Aug 2010 09:39:26 +0000 Received: from dhcp-10-61-96-21.cisco.com (dhcp-10-61-96-21.cisco.com [10.61.96.21]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7D9dP0M002657; Fri, 13 Aug 2010 09:39:26 GMT Message-ID: <4C6512D4.7000801@cisco.com> Date: Fri, 13 Aug 2010 11:39:32 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Leif Johansson References: <4C64F516.8020801@sunet.se> In-Reply-To: <4C64F516.8020801@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:38:51 -0000 Excellent, Leif. I have small suggestions, but I would be happy with this charter if it went forward. In general, this follows my view that charters should be as succinct as necessary, but (to borrow from Einstein) no more so. Please see below. On 8/13/10 9:32 AM, Leif Johansson wrote: On EAP, just to be consistent: > > The working group may not change EAP (beyond the development of EAP > mechanisms), RADIUS or Diameter without establishing consensus with > the appropriate community within the IETF. s/^T/Other than a change to its applicability statement, t/ On UI/CHI: > In addition, the working group will explore the usability and user > interface issues associated with federated authentication. The work is > not chartered to standardize protocols or recommend best current > practice in the area of usability. The working group should explore > the area and produce informational documents describing the issues and > recommending appropriate work for the IETF in this area. > > As future work in dealing with user interface in this area progresses, > the architecture of the system may need to expand to include additional > components or make significant changes to adapt to improvements in > understanding of user interface. In describing architecture work, the > working group will emphasize this possibility of change. Having been the instigator of these paragraphs, I suggest they be removed. Having thought more about it, while I still have substantial UI concerns, I think NOT saying this in the charter is the same as saying it in the charter, so why bother if the result is the same? Or in the alternative, simply reduce to the following: As practical experience and research dictate, the group will document user interface/usability issues that may have impact on the protocol(s) being developed. > > Coordination with other SDOs > ---------------------------- > This work will require close coordination with work going on in the > OASIS Security Services Technical Committee (SSTC). There should be > sufficient overlapping participation between the SSTC and this working > group for informal coordination. The chairs of this working group may > work with the SSTC chairs and the IAB in case formal coordination is > required. > > In particular coordination is required with respect to the SAML-RADIUS > binding. Change to the following: The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with OASIS and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. -- This should address David's concern while leaving open the possibility that the existing profiles will be suitable (I don't think we've gotten to the point of understanding this yet). From lear@cisco.com Fri Aug 13 02:40:16 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3903A693D for ; Fri, 13 Aug 2010 02:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.474 X-Spam-Level: X-Spam-Status: No, score=-110.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 D6+GHwQbq5vr for ; Fri, 13 Aug 2010 02:40:15 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 911523A6804 for ; Fri, 13 Aug 2010 02:40:15 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFGwZExAZnwM/2dsb2JhbACDFZ0kcZ9riVKRc4EmgyFzBIlf X-IronPort-AV: E=Sophos;i="4.55,362,1278288000"; d="scan'208";a="147105355" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 13 Aug 2010 09:40:52 +0000 Received: from dhcp-10-61-96-21.cisco.com (dhcp-10-61-96-21.cisco.com [10.61.96.21]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7D9ep1x003642; Fri, 13 Aug 2010 09:40:51 GMT Message-ID: <4C65132A.1010202@cisco.com> Date: Fri, 13 Aug 2010 11:40:58 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alper Yegin References: <00b601cb357f$7fafd6a0$7f0f83e0$@net> <4C5C371D.1090504@cisco.com> <20100806192356.GZ5213@oracle.com> <56128A8A-6DE6-49FA-A955-E46B7E6DCAAE@cisco.com> <20100806210111.GC5213@oracle.com> <016b01cb3887$eaf36070$c0da2150$%yegin@yegin.org> <20100810133321.GR5213@oracle.com> <4C61805D.6080607@cisco.com> <20100810170102.GX5213@oracle.com> <025801cb38ae$5b0e9b60$112bd220$@osu.edu> <20100810172037.GZ5213@oracle.com> <75763A7B-7336-4611-9B31-002DB74F6972@padl.com> <029501cb392c$704cd9a0$50e68ce0$@yegin@yegin.org> <015901cb3aca$9fd28590$df7790b0$@yegin@yegin.org> In-Reply-To: <015901cb3aca$9fd28590$df7790b0$@yegin@yegin.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, 'Nicolas Williams' Subject: Re: [abfab] Charter: EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:40:16 -0000 Alper, On 8/13/10 11:33 AM, Alper Yegin wrote: > My point is, it is not even discussed in this community. Last time it was > discussed, the decision was the opposite of what is written in the charter. > IETF is left at that point. We are discussing it now. Eliot From Josh.Howlett@ja.net Fri Aug 13 02:44:40 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838FF3A693D for ; Fri, 13 Aug 2010 02:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.218 X-Spam-Level: X-Spam-Status: No, score=-100.218 tagged_above=-999 required=5 tests=[AWL=-0.219, BAYES_50=0.001, 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 Ng4EQjA+bIKF for ; Fri, 13 Aug 2010 02:44:39 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 510FF3A67D7 for ; Fri, 13 Aug 2010 02:44:39 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5E04F4A6B42_C65142BB; Fri, 13 Aug 2010 09:45:15 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 4F56F4A6B5E_C65142AF; Fri, 13 Aug 2010 09:45:14 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Fri, 13 Aug 2010 10:45:22 +0100 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] charter take 3 Thread-Index: AQHLOrnTzmDoUTRQfUOhfmD58ujB6pLfGPsw Date: Fri, 13 Aug 2010 09:45:09 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E6053EAF@EXC001.atlas.ukerna.ac.uk> References: <4C64F516.8020801@sunet.se> In-Reply-To: <4C64F516.8020801@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 09:44:40 -0000 Leif, Looking good; one minor comment: > Federated identity shares user authorization information among > organizations, without specific registration of the individual user at > the organization controlling a a remote resource. Authorisation is only one application of federated identity, and I also thi= nk we could be more explicit about the benefits of federated identity. I su= ggest words to the effect of: "Federated identity is concerned with the controlled sharing of information= about principals, commonly across organisational boundaries. This avoids t= he redundant registration of principals who operate in multiple domains red= ucing administrative overheads (e.g., by simplifying user account managemen= t) and improving usability (e.g., by reducing the number of credentials iss= ued to user principals). It may also prevent the unnecessary exposure of us= er principal information that might be subject to privacy concerns and, dep= ending on jurisdiction, regulatory or statutory control. This information m= ay be used for purposes such as authorisation (i.e., for access to a servic= e) and personalisation (e.g., for customising a principal's experience of t= he service). Josh.=20 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 leifj@mnt.se Fri Aug 13 03:41:21 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FD9C3A698F for ; Fri, 13 Aug 2010 03:41:21 -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 Nre+D-9-6Gqd for ; Fri, 13 Aug 2010 03:41:11 -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 031743A693F for ; Fri, 13 Aug 2010 03:41:08 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DAfgSW022700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Aug 2010 12:41:45 +0200 (CEST) Message-ID: <4C652166.7040701@mnt.se> Date: Fri, 13 Aug 2010 12:41:42 +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: abfab@ietf.org References: <4C64F516.8020801@sunet.se> <4C6512D4.7000801@cisco.com> In-Reply-To: <4C6512D4.7000801@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:41:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 11:39 AM, Eliot Lear wrote: > Excellent, Leif. > > I have small suggestions, but I would be happy with this charter if it > went forward. In general, this follows my view that charters should be > as succinct as necessary, but (to borrow from Einstein) no more so. > > Please see below. > > On 8/13/10 9:32 AM, Leif Johansson wrote: > > > On EAP, just to be consistent: >> >> The working group may not change EAP (beyond the development of EAP >> mechanisms), RADIUS or Diameter without establishing consensus with >> the appropriate community within the IETF. > > s/^T/Other than a change to its applicability statement, t/ > > On UI/CHI: >> In addition, the working group will explore the usability and user >> interface issues associated with federated authentication. The work is >> not chartered to standardize protocols or recommend best current >> practice in the area of usability. The working group should explore >> the area and produce informational documents describing the issues and >> recommending appropriate work for the IETF in this area. >> >> As future work in dealing with user interface in this area progresses, >> the architecture of the system may need to expand to include additional >> components or make significant changes to adapt to improvements in >> understanding of user interface. In describing architecture work, the >> working group will emphasize this possibility of change. > > > Having been the instigator of these paragraphs, I suggest they be > removed. Having thought more about it, while I still have substantial > UI concerns, I think NOT saying this in the charter is the same as > saying it in the charter, so why bother if the result is the same? Or > in the alternative, simply reduce to the following: > > As practical experience and research dictate, the group will document > user interface/usability issues that may have impact on the protocol(s) > being developed. > >> >> Coordination with other SDOs >> ---------------------------- >> This work will require close coordination with work going on in the >> OASIS Security Services Technical Committee (SSTC). There should be >> sufficient overlapping participation between the SSTC and this working >> group for informal coordination. The chairs of this working group may >> work with the SSTC chairs and the IAB in case formal coordination is >> required. >> >> In particular coordination is required with respect to the SAML-RADIUS >> binding. > > > Change to the following: > > The Working Group will work in conjunction with the IAB to establish > appropriate liaison relationships with OASIS and take care that any > changes or profiling required in SAML can be properly coordinated across > the different organizations. > -- > > This should address David's concern while leaving open the possibility > that the existing profiles will be suitable (I don't think we've gotten > to the point of understanding this yet). Personally I think your modifications are good as they make the charter more readable. Unless I hear opposition I'm inclined to apply them. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlIWYACgkQ8Jx8FtbMZndqmQCdExROAgbL6MzuX6taqZUKB9R5 9kMAn2bit5mWwAM5oHW7iO+q9SC8c1Qz =jvS6 -----END PGP SIGNATURE----- From hannes.tschofenig@nsn.com Fri Aug 13 04:00:18 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362E13A69C5 for ; Fri, 13 Aug 2010 04:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p5RYDCJusG3 for ; Fri, 13 Aug 2010 04:00:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 621B63A693F for ; Fri, 13 Aug 2010 04:00:15 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7DB0maQ011353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 13 Aug 2010 13:00:48 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7DB0loD017626; Fri, 13 Aug 2010 13:00:48 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Aug 2010 13:00:36 +0200 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 Date: Fri, 13 Aug 2010 14:00:35 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> In-Reply-To: <4C64F516.8020801@sunet.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] charter take 3 Thread-Index: Acs6ucJhfoU9LbsCQ+SgUb9zhSvjKAAGo3qQ References: <4C64F516.8020801@sunet.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Leif Johansson" , X-OriginalArrivalTime: 13 Aug 2010 11:00:36.0700 (UTC) FILETIME=[C24671C0:01CB3AD6] Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 11:00:18 -0000 Hi Lef,=20 Thanks for getting this going. A few minor comments.=20 > Abfab Proposed Charter >=20 > Abfab - Application Bridging for Federated Access Beyond web >=20 > Federated identity shares user authorization information among > organizations, without specific registration of the individual user at > the organization controlling a a remote resource. I am trying to parse this sentence and I does not make sense to me.=20 First, I think you are trying to say "Federated Identity Management Systems share" (let's assume that such a term exists somewhere) Second, "share ... User identity information and related attributes"=20 (you see that the terminology document that I distributed recently would reallly be useful) What does it mean to say "without specific registration of the individual user at > the organization controlling a a remote resource." A number of such > mechanisms are in use for the Web. This working group will specify a > federated identity mechanism for use by other Internet=20 > services, such as > IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web > protocols. Which non-IETF protocols?=20 I would you would say non-HTTP based protocols.=20 The design will combine existing IETF protocols, > specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter).=20 SAML is not an IETF protocol.=20 Maybe you want to say=20 " The design will combine existing protocols, namely the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML).=20 " (I put SAML as the last item because it is the least important one in the approach discussed on the list. Everything would just work without using SAML as well.) > With the > deployment of the solution, a user from one organization will=20 > be able to > access resources at another organization, given only prior agreement > between the organizations, or prior agreement between each=20 > organization > and a trusted intermediary. >=20 > While work continues elsewhere on basic mechanisms that rely=20 > on using an > HTTP/HTML interface to authenticate and authorize non-web=20 > applications, Authenticate and authorize users for non-HTTP based applications.=20 > this working group will look at approaches that do not rely=20 > on the web, ... On the HTTP-based web.=20 > taking into account user interface concerns and the need to pass > structured data to an appropriate authentication interface, as well as > the need to handle large scale discovery. What do you mean by passing structured data to an appropriate authentication interface?=20 >=20 > The working group will develop a solution for federated identity for > IETF and non-IETF application protocols I would prefer to write "for non-HTTP based protocols".=20 > by combining SAML, EAP (RFC > 3748) and AAA (RADIUS, Diameter). Btw, you said that already previously. Maybe you want to merge the text with the previous paragraph to make it less repetitive.=20 Specifically EAP will be used to > authenticate the subject to a trusted party, AAA (RADIUS and Diameter) > will be used to authenticate and convey information from that=20 > party to a > relying party and SAML is used for authorization and personalization. >=20 > The working group may consider other alternative technology for these > three roles in the architecture but any change in direction in this > respect requires rechartering of the working group ... Other alternative technology for these three communication relationships. >=20 > Constraints: > - ------------ >=20 > Initially the working group will focus on using GSS-API (RFC2743) as Remove the initially=20 > a mechanism for integrating the developed solution for federated > identity into application protocols but other technologies for > application interface are in scope of the working group and may be > adopted as deliverables subject to the normal IETF consensus and > (re)charter process. >=20 > The working group will ensure that any solution developed has built- > in technical controls for privacy protection. >=20 > The working group may not change EAP (beyond the development of EAP > mechanisms), RADIUS or Diameter without establishing consensus with > the appropriate community within the IETF. >=20 > The working group will use the following documents as a starting > point for its work: >=20 > - - draft-howlett-eap-gss-00, > - - draft-howlett-radius-saml-attr-00 > - - draft-hartman-gss-eap-naming-00 >=20 > Concerns have been raised that additional work is required in keying > AAA associations in a federated environment. The working group is > chartered to explore these concerns and if needed, specify protocols > that use existing AAA key management mechanisms to address=20 > these concerns. >=20 > In addition, the working group will explore the usability and user > interface issues associated with federated authentication. The work is > not chartered to standardize protocols or recommend best current > practice in the area of usability. The working group should explore > the area and produce informational documents describing the issues and > recommending appropriate work for the IETF in this area. Hmmm. I am not happy with this text. Where else would you like to do such work in the IETF other than in the group where the experts of the technology are. Why not to work on a document that illustrates the issues and if there are suggestions to make then just make them.=20 >=20 > As future work in dealing with user interface in this area progresses, > the architecture of the system may need to expand to include=20 > additional > components or make significant changes to adapt to improvements in > understanding of user interface. In describing architecture work, the > working group will emphasize this possibility of change. This sounds a bit fuzzy. What do you mean by "additional components"?=20 Are we talking about user interface issues or protocol extensions that simplify operations and management (i.e. the user in the sense of the administor of the system).=20 >=20 > Coordination with other SDOs > - ---------------------------- >=20 > This work will require close coordination with work going on in the > OASIS Security Services Technical Committee (SSTC). There should be > sufficient overlapping participation between the SSTC and this working > group for informal coordination. The chairs of this working group may > work with the SSTC chairs and the IAB in case formal coordination is > required. >=20 > In particular coordination is required with respect to the SAML-RADIUS > binding. So, what do you expect OASIS to do in this work?=20 Review?=20 Be aware of the IETF group?=20 Because of the different organizational structure and membership model I am always concerned when work is spread over different SDOs. I am chairing the KEYPROV working group and we had some interactions with OASIS and I am not sure OASIS has been helpful in any way. Why do you think it is different here?=20 >=20 > Deliverables > - ------------ >=20 > The deliverables of the working group are: >=20 > * A document describing applicable use cases. >=20 > * An architecture document describing how the components of=20 > the solution > fit together to address the use cases and open issues that=20 > will require > future changes to the architecture >=20 > * A standards-track protocol for carrying SAML messages in RADIUS and > Diameter >=20 > * An update to the EAP applicability statement in RFC 3748 describing > the applicability of EAP to application authentication and placing > appropriate requirements on this new EAP use case >=20 > * A standards track solution for using EAP methods to provide > authentication within the application >=20 > * An update to the EMSK root key applicability statement in RFC 5295 >=20 > * A standards-track description of GSS names and name attributes > required by the solution >=20 > * Informational descriptions of usability and user-interface concerns > related to this work Sounds good to me. Are you going to propose milestones as well?=20 Ciao Hannes From Josh.Howlett@ja.net Fri Aug 13 04:02:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA693A69B4 for ; Fri, 13 Aug 2010 04:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.481 X-Spam-Level: X-Spam-Status: No, score=-101.481 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcwF1A3YdgX8 for ; Fri, 13 Aug 2010 04:02:28 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id D590C3A6994 for ; Fri, 13 Aug 2010 04:02:27 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2D0384A6B5E_C652668B; Fri, 13 Aug 2010 11:03:04 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 14BDE4A6B5C_C652667F; Fri, 13 Aug 2010 11:03:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Fri, 13 Aug 2010 12:03:10 +0100 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] charter take 3 Thread-Index: AQHLOrnTzmDoUTRQfUOhfmD58ujB6pLfGPswgAAbswA= Date: Fri, 13 Aug 2010 11:02:58 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E6054000@EXC001.atlas.ukerna.ac.uk> References: <4C64F516.8020801@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E6053EAF@EXC001.atlas.ukerna.ac.uk> In-Reply-To: <40AC324AA6D81B4A8CF133BCFB7526E6053EAF@EXC001.atlas.ukerna.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 11:02:29 -0000 > "Federated identity is concerned with the controlled sharing of > information about principals, commonly across organisational > boundaries. This avoids the redundant registration of principals who > operate in multiple domains reducing administrative overheads (e.g., by > simplifying user account management) and improving usability (e.g., by > reducing the number of credentials issued to user principals). It may > also prevent the unnecessary exposure of user principal information > that might be subject to privacy concerns and, depending on > jurisdiction, regulatory or statutory control. This information may be > used for purposes such as authorisation (i.e., for access to a service) > and personalisation (e.g., for customising a principal's experience of > the service). Leif has privately suggested that this is a bit wordy; here's an abridged v= ersion: "Federated identity facilitates the controlled sharing of information about= principals, commonly across organisational boundaries. This avoids redunda= nt registration of principals who operate in multiple domains, reducing adm= inistrative overheads and improving usability. It may also address privacy = related concerns that, depending on jurisdiction, may be subject to regulat= ory or statutory control. This information may be used for purposes such as= authorisation and personalisation." 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 leifj@sunet.se Fri Aug 13 04:16:32 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90BA3A6358 for ; Fri, 13 Aug 2010 04:16:32 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9VuLgPnT1cF for ; Fri, 13 Aug 2010 04:16:31 -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 675AB3A688E for ; Fri, 13 Aug 2010 04:16:30 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DBH55D027466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 13:17:07 +0200 (CEST) Message-ID: <4C6529B0.2030605@sunet.se> Date: Fri, 13 Aug 2010 13:17:04 +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: Josh Howlett References: <4C64F516.8020801@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E6053EAF@EXC001.atlas.ukerna.ac.uk> <40AC324AA6D81B4A8CF133BCFB7526E6054000@EXC001.atlas.ukerna.ac.uk> In-Reply-To: <40AC324AA6D81B4A8CF133BCFB7526E6054000@EXC001.atlas.ukerna.ac.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 11:16:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 01:02 PM, Josh Howlett wrote: >> "Federated identity is concerned with the controlled sharing of >> information about principals, commonly across organisational >> boundaries. This avoids the redundant registration of principals who >> operate in multiple domains reducing administrative overheads (e.g., by >> simplifying user account management) and improving usability (e.g., by >> reducing the number of credentials issued to user principals). It may >> also prevent the unnecessary exposure of user principal information >> that might be subject to privacy concerns and, depending on >> jurisdiction, regulatory or statutory control. This information may be >> used for purposes such as authorisation (i.e., for access to a service) >> and personalisation (e.g., for customising a principal's experience of >> the service). > > Leif has privately suggested that this is a bit wordy; here's an abridged version: > > "Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability. It may also address privacy related concerns that, depending on jurisdiction, may be subject to regulatory or statutory control. This information may be used for purposes such as authorisation and personalisation." > Josh - was this meant to replace the entire first paragraph? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlKbAACgkQ8Jx8FtbMZnep5gCgpchrHAYgNJ5H8AmODXxnrmgG TdMAoMlxipXNcXGNvHjWcPRwpvIl/w9q =9Ijc -----END PGP SIGNATURE----- From leifj@sunet.se Fri Aug 13 04:29:00 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276483A6358 for ; Fri, 13 Aug 2010 04:29:00 -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 avhs9SNQzxHd for ; Fri, 13 Aug 2010 04:28:58 -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 AB0643A6783 for ; Fri, 13 Aug 2010 04:28:57 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DBTU77027773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 13:29:32 +0200 (CEST) Message-ID: <4C652C9A.7080707@sunet.se> Date: Fri, 13 Aug 2010 13:29:30 +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: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <4C64F516.8020801@sunet.se> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 11:29:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 01:00 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Lef, > > Thanks for getting this going. A few minor comments. > > >> Abfab Proposed Charter >> >> Abfab - Application Bridging for Federated Access Beyond web >> >> Federated identity shares user authorization information among >> organizations, without specific registration of the individual user at >> the organization controlling a a remote resource. > > > I am trying to parse this sentence and I does not make sense to me. > > First, I think you are trying to say "Federated Identity Management > Systems share" > (let's assume that such a term exists somewhere) > > Second, "share ... User identity information and related attributes" > > (you see that the terminology document that I distributed recently would > reallly be useful) > > What does it mean to say "without specific registration of the > individual user at >> the organization controlling a a remote resource." Actually it was Daves paragraph but I suggest you comment on the version Josh just suggested for the first paragraph. It might parse more easily. On this note I urge everyone not to bike-shed on an explanation of what constitutes federated identity. We have plenty of time for that _if_ we can get to a point where we can talk about working group documents ;-) > > > A number of such >> mechanisms are in use for the Web. This working group will specify a >> federated identity mechanism for use by other Internet >> services, such as >> IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web >> protocols. > > > Which non-IETF protocols? > I would you would say non-HTTP based protocols. > There are plenty of protocols not done in the IETF but I take your point and will try to polish that up a bit. > > The design will combine existing IETF protocols, >> specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). > > SAML is not an IETF protocol. > Maybe you want to say god point. > > " > The design will combine existing protocols, namely the Extensible > Authentication Protocol (EAP - RFC 3748), Authentication, Authorization > and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and > the Security Assertion Markup Language (SAML). > " yes. > > (I put SAML as the last item because it is the least important one in > the approach discussed on the list. Everything would just work without > using SAML as well.) > That aside think your version reads better. > >> With the >> deployment of the solution, a user from one organization will >> be able to >> access resources at another organization, given only prior agreement >> between the organizations, or prior agreement between each >> organization >> and a trusted intermediary. >> >> While work continues elsewhere on basic mechanisms that rely >> on using an >> HTTP/HTML interface to authenticate and authorize non-web >> applications, > > Authenticate and authorize users for non-HTTP based applications. > >> this working group will look at approaches that do not rely >> on the web, > > > ... On the HTTP-based web. Imho that would be silly. Everyone knows the web runs on HTTP. > >> taking into account user interface concerns and the need to pass >> structured data to an appropriate authentication interface, as well as >> the need to handle large scale discovery. > > What do you mean by passing structured data to an appropriate > authentication interface? Elliot has suggested dropping those paragraphs actually... > > >> >> The working group will develop a solution for federated identity for >> IETF and non-IETF application protocols > > I would prefer to write "for non-HTTP based protocols". > >> by combining SAML, EAP (RFC >> 3748) and AAA (RADIUS, Diameter). > > > Btw, you said that already previously. Maybe you want to merge the text > with the previous paragraph to make it less repetitive. > possibly. > > > Specifically EAP will be used to >> authenticate the subject to a trusted party, AAA (RADIUS and Diameter) >> will be used to authenticate and convey information from that >> party to a >> relying party and SAML is used for authorization and personalization. >> >> The working group may consider other alternative technology for these >> three roles in the architecture but any change in direction in this >> respect requires rechartering of the working group > > ... Other alternative technology for these three communication > relationships. > > >> >> Constraints: >> - ------------ >> >> Initially the working group will focus on using GSS-API (RFC2743) as > > Remove the initially > Why? There has been lots of discussion on the list about the need to allow for future introduction of new application interface technologies but that the WG would start with GSS-API. Initially is meant to convey precisely this and I've not heard any opposition to it so it stays unless I hear lots more support for dropping it. > >> a mechanism for integrating the developed solution for federated >> identity into application protocols but other technologies for >> application interface are in scope of the working group and may be >> adopted as deliverables subject to the normal IETF consensus and >> (re)charter process. >> >> The working group will ensure that any solution developed has built- >> in technical controls for privacy protection. >> >> The working group may not change EAP (beyond the development of EAP >> mechanisms), RADIUS or Diameter without establishing consensus with >> the appropriate community within the IETF. >> >> The working group will use the following documents as a starting >> point for its work: >> >> - - draft-howlett-eap-gss-00, >> - - draft-howlett-radius-saml-attr-00 >> - - draft-hartman-gss-eap-naming-00 >> >> Concerns have been raised that additional work is required in keying >> AAA associations in a federated environment. The working group is >> chartered to explore these concerns and if needed, specify protocols >> that use existing AAA key management mechanisms to address >> these concerns. >> >> In addition, the working group will explore the usability and user >> interface issues associated with federated authentication. The work is >> not chartered to standardize protocols or recommend best current >> practice in the area of usability. The working group should explore >> the area and produce informational documents describing the issues and >> recommending appropriate work for the IETF in this area. > > > Hmmm. I am not happy with this text. Where else would you like to do > such work in the IETF other than in the group where the experts of the > technology are. Why not to work on a document that illustrates the > issues and if there are suggestions to make then just make them. > I presume you are talking about the last paragraph and not all three? In that case Elliot has suggested dropping that text already (he was the originator of the usability concerns). > >> >> As future work in dealing with user interface in this area progresses, >> the architecture of the system may need to expand to include >> additional >> components or make significant changes to adapt to improvements in >> understanding of user interface. In describing architecture work, the >> working group will emphasize this possibility of change. > > This sounds a bit fuzzy. What do you mean by "additional components"? > Are we talking about user interface issues or protocol extensions that > simplify operations and management (i.e. the user in the sense of the > administor of the system). See above wrt Elliots suggestions. > >> >> Coordination with other SDOs >> - ---------------------------- >> >> This work will require close coordination with work going on in the >> OASIS Security Services Technical Committee (SSTC). There should be >> sufficient overlapping participation between the SSTC and this working >> group for informal coordination. The chairs of this working group may >> work with the SSTC chairs and the IAB in case formal coordination is >> required. >> >> In particular coordination is required with respect to the SAML-RADIUS >> binding. > > So, what do you expect OASIS to do in this work? > Review? > Be aware of the IETF group? Does that have to go in the charter? > > Because of the different organizational structure and membership model I > am always concerned when work is spread over different SDOs. I am > chairing the KEYPROV working group and we had some interactions with > OASIS and I am not sure OASIS has been helpful in any way. Why do you > think it is different here? > >> >> Deliverables >> - ------------ >> >> The deliverables of the working group are: >> >> * A document describing applicable use cases. >> >> * An architecture document describing how the components of >> the solution >> fit together to address the use cases and open issues that >> will require >> future changes to the architecture >> >> * A standards-track protocol for carrying SAML messages in RADIUS and >> Diameter >> >> * An update to the EAP applicability statement in RFC 3748 describing >> the applicability of EAP to application authentication and placing >> appropriate requirements on this new EAP use case >> >> * A standards track solution for using EAP methods to provide >> authentication within the application >> >> * An update to the EMSK root key applicability statement in RFC 5295 >> >> * A standards-track description of GSS names and name attributes >> required by the solution >> >> * Informational descriptions of usability and user-interface concerns >> related to this work > > Sounds good to me. Are you going to propose milestones as well? I think we have to before Sean would be happy :-) Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlLJoACgkQ8Jx8FtbMZndJegCfUjaSrdapHA1NnRq3IAf8ynxF LLsAnjesTRQqTnTsTRMMTt2ekB6b/M7R =h+D3 -----END PGP SIGNATURE----- From leifj@mnt.se Fri Aug 13 04:42:56 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097943A6895 for ; Fri, 13 Aug 2010 04:42:56 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GYH43xLKL3S for ; Fri, 13 Aug 2010 04:42:54 -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 A9FD53A688E for ; Fri, 13 Aug 2010 04:42:54 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DBhPI0007901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 13:43:28 +0200 (CEST) Message-ID: <4C652FDD.5010408@mnt.se> Date: Fri, 13 Aug 2010 13:43:25 +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: "abfab@ietf.org" References: <4C64F516.8020801@sunet.se> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> <4C652C9A.7080707@sunet.se> In-Reply-To: <4C652C9A.7080707@sunet.se> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 11:42:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> taking into account user interface concerns and the need to pass >>> structured data to an appropriate authentication interface, as well as >>> the need to handle large scale discovery. > >> What do you mean by passing structured data to an appropriate >> authentication interface? > > Elliot has suggested dropping those paragraphs actually... Actually I'm wrong. Elliot suggested dropping the usability paragraphs, not this one. Perhaps Klaas can provide some insight as he was the originator of that paragraph. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlL90ACgkQ8Jx8FtbMZndQ6gCggCd3avtyCukMiTnKGa5H/3BV TswAoLejSD2N4w0v2EP36wDC+AbODFlv =LA2T -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Fri Aug 13 06:01:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E7A93A6403 for ; Fri, 13 Aug 2010 06:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.641 X-Spam-Level: X-Spam-Status: No, score=-101.641 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YicIsTtUBd4a for ; Fri, 13 Aug 2010 06:01:22 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 767913A6807 for ; Fri, 13 Aug 2010 06:01:22 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9F7AD4A6B52_C654246B; Fri, 13 Aug 2010 13:01:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 879954A6B42_C654245F; Fri, 13 Aug 2010 13:01:57 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Fri, 13 Aug 2010 14:02:06 +0100 From: Josh Howlett To: Leif Johansson Thread-Topic: [abfab] charter take 3 Thread-Index: AQHLOrnTzmDoUTRQfUOhfmD58ujB6pLfGPswgAAbswD///c4AIAAINjg Date: Fri, 13 Aug 2010 13:01:53 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E6054147@EXC001.atlas.ukerna.ac.uk> References: <4C64F516.8020801@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E6053EAF@EXC001.atlas.ukerna.ac.uk> <40AC324AA6D81B4A8CF133BCFB7526E6054000@EXC001.atlas.ukerna.ac.uk> <4C6529B0.2030605@sunet.se> In-Reply-To: <4C6529B0.2030605@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 13:01:23 -0000 > > "Federated identity facilitates the controlled sharing of information a= bout > principals, commonly across organisational boundaries. This avoids redund= ant > registration of principals who operate in multiple domains, reducing > administrative overheads and improving usability. It may also address pri= vacy > related concerns that, depending on jurisdiction, may be subject to regul= atory > or statutory control. This information may be used for purposes such as > authorisation and personalisation." > > >=20 > Josh - was this meant to replace the entire first paragraph? Err, the first and last sentence of the first paragraph - not very helpful.= Let me try again: "Federated identity facilitates the controlled sharing of information about= principals, commonly across organisational boundaries. This avoids redunda= nt registration of principals who operate in multiple domains, reducing adm= inistrative overheads and improving usability while addressing privacy-rela= ted concerns and regulatory and statutory requirements of some jurisdiction= s. A number of such mechanisms are in use for the Web. This working group = will specify a federated identity mechanism for use by other Internet servi= ces, such as IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based o= n Web protocols. The design will combine existing IETF protocols, specific= ally EAP (RFC 3748) and AAA (RADIUS, Diameter) with SAML. This combination = may be used for purposes such as authorisation and personalisation." 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 leifj@mnt.se Fri Aug 13 06:40:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 195DE3A6912 for ; Fri, 13 Aug 2010 06:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snxco+KJ5k3R for ; Fri, 13 Aug 2010 06:40:57 -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 ACE643A6781 for ; Fri, 13 Aug 2010 06:40:56 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DDfUSM009578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Aug 2010 15:41:32 +0200 (CEST) Message-ID: <4C654B8A.4060901@mnt.se> Date: Fri, 13 Aug 2010 15:41:30 +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: abfab@ietf.org References: <4C64F516.8020801@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E6053EAF@EXC001.atlas.ukerna.ac.uk> <40AC324AA6D81B4A8CF133BCFB7526E6054000@EXC001.atlas.ukerna.ac.uk> <4C6529B0.2030605@sunet.se> <40AC324AA6D81B4A8CF133BCFB7526E6054147@EXC001.atlas.ukerna.ac.uk> In-Reply-To: <40AC324AA6D81B4A8CF133BCFB7526E6054147@EXC001.atlas.ukerna.ac.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 13:40:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 03:01 PM, Josh Howlett wrote: >>> "Federated identity facilitates the controlled sharing of information about >> principals, commonly across organisational boundaries. This avoids redundant >> registration of principals who operate in multiple domains, reducing >> administrative overheads and improving usability. It may also address privacy >> related concerns that, depending on jurisdiction, may be subject to regulatory >> or statutory control. This information may be used for purposes such as >> authorisation and personalisation." >>> >> >> Josh - was this meant to replace the entire first paragraph? > > Err, the first and last sentence of the first paragraph - not very helpful. Let me try again: > > "Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet services, such as IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web protocols. The design will combine existing IETF protocols, specifically EAP (RFC 3748) and AAA (RADIUS, Diameter) with SAML. This combination may be used for purposes such as authorisation and personalisation." > OK combining that with Hannes suggestion about "non-HTTP based protocols" should give us a winner I hope. Thanks! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlS4QACgkQ8Jx8FtbMZnerZACgiBhSO5UBX0uG/Q8A+WWhozPJ q04AoMKlxg81SccqY2ZNq1ppxLCK/tVk =jVq0 -----END PGP SIGNATURE----- From cantor.2@osu.edu Fri Aug 13 08:03:47 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 427373A6846 for ; Fri, 13 Aug 2010 08:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Pyv-xp8Jon for ; Fri, 13 Aug 2010 08:03:46 -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 0FDE43A6804 for ; Fri, 13 Aug 2010 08:03:44 -0700 (PDT) Received: from defang9.it.ohio-state.edu (defang9.it.ohio-state.edu [128.146.216.78]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o7DF4KOB003828; Fri, 13 Aug 2010 11:04:20 -0400 Received: from SNOWDOG ([128.146.178.34]) by defang9.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o7DF4IeD005573; Fri, 13 Aug 2010 11:04:19 -0400 From: "Scott Cantor" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'ext Leif Johansson'" , References: <4C64F516.8020801@sunet.se> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> Date: Fri, 13 Aug 2010 11:04:21 -0400 Organization: The Ohio State University Message-ID: <044601cb3af8$d0a36260$71ea2720$@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: AQHl3Sk3ChI1U+IiJVYTNXb5r9z9vAHrhBxgkpraL1A= Content-language: en-us X-CanIt-Geo: ip=128.146.216.78; 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 Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 15:03:47 -0000 > Authenticate and authorize users for non-HTTP based applications. > > > this working group will look at approaches that do not rely > > on the web, > > ... On the HTTP-based web. Is there a non-HTTP-based web? Perhaps it's better to say "do not rely on HTTP". > > taking into account user interface concerns and the need to pass > > structured data to an appropriate authentication interface, as well as > > the need to handle large scale discovery. > > What do you mean by passing structured data to an appropriate > authentication interface? I think this is talking about the fact that it's not an HTML-based user interface, so the entity doing the credentials collection is not on the server side and doesn't have control over the UI. The Cardspace problem, essentially. > Because of the different organizational structure and membership model I > am always concerned when work is spread over different SDOs. I am > chairing the KEYPROV working group and we had some interactions with > OASIS and I am not sure OASIS has been helpful in any way. Why do you > think it is different here? OASIS is a collection of TCs without any real ties amongst them beyond superficial ones. The results you get will depend on the TC you're dealing with. -- Scott From hartmans@painless-security.com Fri Aug 13 09:19:39 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7363A6A0E for ; Fri, 13 Aug 2010 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 f+PVzFeJuASO for ; Fri, 13 Aug 2010 09:19:39 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E8A103A69F7 for ; Fri, 13 Aug 2010 09:19:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6860E2029D; Fri, 13 Aug 2010 12:20:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8ECFD412A; Fri, 13 Aug 2010 12:19:58 -0400 (EDT) From: Sam Hartman To: "Scott Cantor" References: <4C64F516.8020801@sunet.se> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> <044601cb3af8$d0a36260$71ea2720$@osu.edu> Date: Fri, 13 Aug 2010 12:19:58 -0400 In-Reply-To: <044601cb3af8$d0a36260$71ea2720$@osu.edu> (Scott Cantor's message of "Fri, 13 Aug 2010 11:04:21 -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: abfab@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 16:19:39 -0000 Leif, I think your charter take 3 is fine, with one exception. I object fairly strongly to the fourth paragraph--the one that says we are open to changing direction with a recharter. Obviously, any WG can be rechartered--krb-wg could take on DHCP maintinance with a successful recharter. However, I think going as far as you do in the charter invites exactly the sort of endless spinning Dave warns about. I feel fairly strongly that paragraph should be removed. To the extent we want to explicitly encourage flexibility, we do below. --Sam From leifj@sunet.se Fri Aug 13 11:13:27 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B8A03A6850 for ; Fri, 13 Aug 2010 11:13:27 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ+K8K4w7GhQ for ; Fri, 13 Aug 2010 11:13:25 -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 CFC053A6864 for ; Fri, 13 Aug 2010 11:13:24 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DIDvgb012861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 20:13:59 +0200 (CEST) Message-ID: <4C658B65.6070807@sunet.se> Date: Fri, 13 Aug 2010 20:13:57 +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: Sam Hartman References: <4C64F516.8020801@sunet.se> <3D3C75174CB95F42AD6BCC56E5555B4502E9BEF1@FIESEXC015.nsn-intra.net> <044601cb3af8$d0a36260$71ea2720$@osu.edu> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:13:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 06:19 PM, Sam Hartman wrote: > Leif, I think your charter take 3 is fine, with one exception. > > I object fairly strongly to the fourth paragraph--the one that says we > are open to changing direction with a recharter. Obviously, any WG can > be rechartered--krb-wg could take on DHCP maintinance with a successful > recharter. However, I think going as far as you do in the charter > invites exactly the sort of endless spinning Dave warns about. I feel > fairly strongly that paragraph should be removed. > > To the extent we want to explicitly encourage flexibility, we do below. > > --Sam To tell the truth I was actually a bit iffy about that sentence myself but perhaps I went overboard in my efforts to making things explicit. Obviously there will be a take 4 with some nits here and there and unless I hear strong support for that sentence it goes. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxli2UACgkQ8Jx8FtbMZnf+MwCdHuTz+jie5VRSkFdaRDrciv1r qmUAni3BFy4a1yEfeFJshCZVOVublAWq =XQ4Z -----END PGP SIGNATURE----- From dhc@dcrocker.net Fri Aug 13 11:35:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD123A69A2 for ; Fri, 13 Aug 2010 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 lq75F6zce+-R for ; Fri, 13 Aug 2010 11:34:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id A527C3A6969 for ; Fri, 13 Aug 2010 11:34:49 -0700 (PDT) Received: from [192.168.1.147] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7DIYoEe000777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 11:34:56 -0700 Message-ID: <4C659042.5050000@dcrocker.net> Date: Fri, 13 Aug 2010 11:34:42 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Leif Johansson References: <4C64F516.8020801@sunet.se> In-Reply-To: <4C64F516.8020801@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Aug 2010 11:34:56 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:35:12 -0000 Leif, The charter looks much better. I've still got a few questions, but now they are relatively narrow and specific: On 8/13/2010 12:32 AM, Leif Johansson wrote: > Abfab Proposed Charter > > Abfab - Application Bridging for Federated Access Beyond web > > Federated identity shares user authorization information among > organizations, without specific registration of the individual user at > the organization controlling a a remote resource. A number of such > mechanisms are in use for the Web. This working group will specify a > federated identity mechanism for use by other Internet services, such as > IMAP, XMPP, SSH, NFS and other non-IETF protocols, not based on Web > protocols. The design will combine existing IETF protocols, > specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). With the > deployment of the solution, a user from one organization will be able to > access resources at another organization, given only prior agreement > between the organizations, or prior agreement between each organization > and a trusted intermediary. > > While work continues elsewhere on basic mechanisms that rely on using an > HTTP/HTML interface to authenticate and authorize non-web applications, As noted (or at least implied) by another posting this morning, perhaps this should simply say: ...that rely on using an HTTP/HTML interface for authentication and authorization... > this working group will look at approaches that do not rely on the web, > taking into account user interface concerns and the need to pass > structured data to an appropriate authentication interface, as well as > the need to handle large scale discovery. On reflection, I'm not clear what the purpose of citing the outside work is. The more I re-read this second paragraph, the more I believe it adds no value. I suggest simply deleting it. > The working group will develop a solution for federated identity for > IETF and non-IETF application protocols by combining SAML, EAP (RFC > 3748) and AAA (RADIUS, Diameter). Specifically EAP will be used to > authenticate the subject to a trusted party, AAA (RADIUS and Diameter) > will be used to authenticate and convey information from that party to a > relying party and SAML is used for authorization and personalization. IF there is a practical import to citing "non-IETF" applications, I don't know what it is. The charter should either make that real in technical or process terms, or it should delete the reference to the 'homes' of application specifications. So, I suggest: The working group will specify a federated identity service for use by applications, by combining... > The working group may consider other alternative technology for these > three roles in the architecture but any change in direction in this > respect requires rechartering of the working group. I typically dislike references to hypothetical futures and especially to things that might be considered but which will require rechartering. In this case, however, I think it defines a high barrier for replacing the technical components and it hits the reader in the face with how much effort it will take to climb the barrier. So, I like it. > Constraints: > - ------------ > > Initially the working group will focus on using GSS-API (RFC2743) as > a mechanism for integrating the developed solution for federated > identity into application protocols but other technologies for > application interface are in scope of the working group and may be > adopted as deliverables subject to the normal IETF consensus and > (re)charter process. developed solution for federated identity -> federated identity service (yes, this is the second placed I'm suggesting moving from 'solution' to 'service' and using somewhat more direct language. i think it makes a difference to the reading.) > The working group will ensure that any solution developed has built- > in technical controls for privacy protection. I still have no idea what this means either conceptually or in terms of working group work. > The working group may not change EAP (beyond the development of EAP > mechanisms), RADIUS or Diameter without establishing consensus with > the appropriate community within the IETF. > > The working group will use the following documents as a starting > point for its work: > > - - draft-howlett-eap-gss-00, > - - draft-howlett-radius-saml-attr-00 > - - draft-hartman-gss-eap-naming-00 I'm pretty sure these are more than "starting points". That's a pretty vague term and I think you folks intend something more specific and that it means significant constraints on the changes to these specification that are considered permissible. These are the base specifications. What are the criteria for making changes to them? That's what the charter should say, unless you folks have a different intent. > Concerns have been raised that additional work is required in keying > AAA associations in a federated environment. The working group is > chartered to explore these concerns and if needed, specify protocols > that use existing AAA key management mechanisms to address these concerns. > > In addition, the working group will explore the usability and user > interface issues associated with federated authentication. The work is > not chartered to standardize protocols or recommend best current > practice in the area of usability. The working group should explore > the area and produce informational documents describing the issues and > recommending appropriate work for the IETF in this area. > > As future work in dealing with user interface in this area progresses, > the architecture of the system may need to expand to include additional > components or make significant changes to adapt to improvements in > understanding of user interface. In describing architecture work, the > working group will emphasize this possibility of change. > > Coordination with other SDOs > - ---------------------------- > > This work will require close coordination with work going on in the > OASIS Security Services Technical Committee (SSTC). There should be > sufficient overlapping participation between the SSTC and this working > group for informal coordination. The chairs of this working group may > work with the SSTC chairs and the IAB in case formal coordination is > required. > > In particular coordination is required with respect to the SAML-RADIUS > binding. > > Deliverables > - ------------ > > The deliverables of the working group are: > > * A document describing applicable use cases. > > * An architecture document describing how the components of the solution > fit together to address the use cases and open issues that will require > future changes to the architecture > > * A standards-track protocol for carrying SAML messages in RADIUS and > Diameter > > * An update to the EAP applicability statement in RFC 3748 describing > the applicability of EAP to application authentication and placing > appropriate requirements on this new EAP use case > > * A standards track solution for using EAP methods to provide > authentication within the application > > * An update to the EMSK root key applicability statement in RFC 5295 > > * A standards-track description of GSS names and name attributes > required by the solution > > * Informational descriptions of usability and user-interface concerns > related to this work > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxk9RAACgkQ8Jx8FtbMZnc5sACgjZA9qFQLI9PWajoNF5DXWj/O > 4NQAnidUYYfyrcoOqvgfFeGRURQ1wh48 > =gRBO > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > -- Dave Crocker Brandenburg InternetWorking bbiw.net From leifj@sunet.se Fri Aug 13 11:43:57 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283B83A695B for ; Fri, 13 Aug 2010 11:43:57 -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 CeY0uSLLEfrs for ; Fri, 13 Aug 2010 11:43:56 -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 BC6D93A6359 for ; Fri, 13 Aug 2010 11:43:54 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DIiBKI005219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 20:44:13 +0200 (CEST) Message-ID: <4C65927B.8000204@sunet.se> Date: Fri, 13 Aug 2010 20:44:11 +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: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> In-Reply-To: <4C659042.5050000@dcrocker.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:43:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the review, Dave. You made some good points. >> The working group may consider other alternative technology for these >> three roles in the architecture but any change in direction in this >> respect requires rechartering of the working group. > > I typically dislike references to hypothetical futures and especially to > things that might be considered but which will require rechartering. > > In this case, however, I think it defines a high barrier for replacing > the technical components and it hits the reader in the face with how > much effort it will take to climb the barrier. So, I like it. > I think you and Sam will have to slug it out on this topic. He wants to cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody else has yet another approach :-) >> The working group may not change EAP (beyond the development of EAP >> mechanisms), RADIUS or Diameter without establishing consensus with >> the appropriate community within the IETF. >> >> The working group will use the following documents as a starting >> point for its work: >> >> - - draft-howlett-eap-gss-00, >> - - draft-howlett-radius-saml-attr-00 >> - - draft-hartman-gss-eap-naming-00 > > I'm pretty sure these are more than "starting points". That's a pretty > vague term and I think you folks intend something more specific and that > it means significant constraints on the changes to these specification > that are considered permissible. They are (imho) starting-points within the constraints of the technology choices which have been outlined in the charter so I think it is appropriate to say "starting point" in this case and given that one has read the charter and the drafts I believe the meaning is clear: that given the roles of SAML, EAP and AAA these three documents are starting points for each part of the solution. > > These are the base specifications. What are the criteria for making > changes to them? > Normal IETF WG consensus, but we really can't keep repeating that. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlknsACgkQ8Jx8FtbMZndl/wCfeGmrZbqxBTYmzKeMPf0sbkLw 3ooAoIWnfwAHCqN8Cb/UiXvYOdfeUyaa =/Q+O -----END PGP SIGNATURE----- From dhc@dcrocker.net Fri Aug 13 11:56:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B2A33A6914 for ; Fri, 13 Aug 2010 11:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.936, 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 BHA5iXD7CoQH for ; Fri, 13 Aug 2010 11:56:23 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E92103A68D5 for ; Fri, 13 Aug 2010 11:56:23 -0700 (PDT) Received: from [192.168.1.147] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7DIutHl001818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 11:57:01 -0700 Message-ID: <4C65956F.3040601@dcrocker.net> Date: Fri, 13 Aug 2010 11:56:47 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Leif Johansson References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> In-Reply-To: <4C65927B.8000204@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Aug 2010 11:57:01 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:56:24 -0000 On 8/13/2010 11:44 AM, Leif Johansson wrote: >> In this case, however, I think it defines a high barrier for replacing >> the technical components and it hits the reader in the face with how >> much effort it will take to climb the barrier. So, I like it. > > I think you and Sam will have to slug it out on this topic. He wants to > cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody > else has yet another approach :-) The charter really needs to state fairly clearly what the boundaries of change are, within the charter. It needs to state it forcefully enough to be useful when someone starts distracting the working group with calls for changes that really go beyond what the working group intends. This is a question of clarity about what the working group intends and strong enough language in the charter to be used as an enforcement club. I'd say that there is already plenty of demonstrated need for such a paragraph. As for Sam vs. me, no. Neither of us should matter that much. That's what rough consensus is all about. > > >>> The working group may not change EAP (beyond the development of EAP >>> mechanisms), RADIUS or Diameter without establishing consensus with >>> the appropriate community within the IETF. >>> >>> The working group will use the following documents as a starting >>> point for its work: >>> >>> - - draft-howlett-eap-gss-00, >>> - - draft-howlett-radius-saml-attr-00 >>> - - draft-hartman-gss-eap-naming-00 >> >> I'm pretty sure these are more than "starting points". That's a pretty >> vague term and I think you folks intend something more specific and that >> it means significant constraints on the changes to these specification >> that are considered permissible. > > They are (imho) starting-points within the constraints of the > technology choices which have been outlined in the charter so I > think it is appropriate to say "starting point" in this case and > given that one has read the charter and the drafts I believe the > meaning is clear: that given the roles of SAML, EAP and AAA > these three documents are starting points for each part of the > solution. starting points for discussion? starting points for specification? starting points for refinement? but the actual choices can be anything? whole new specifications will be acceptable? >> These are the base specifications. What are the criteria for making >> changes to them? > > Normal IETF WG consensus, but we really can't keep repeating that. What are the criteria that permits a working group chair to declare a topic out of scope? Most wg chairs are nice folk who tend to let things go more astray than one would later have wished. Clear and firm criteria in a charter make the wg chair's job much clearer about scope and therefore easier to enforce. The alternative is constantly having to pool the wg for rough consensus about scope issue, after scope issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From leifj@sunet.se Fri Aug 13 11:58:43 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A863A6887 for ; Fri, 13 Aug 2010 11:58: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 tfkS1oIBFqd5 for ; Fri, 13 Aug 2010 11:58: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 E95F23A68D5 for ; Fri, 13 Aug 2010 11:58:41 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DIwx7a012100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 20:59:02 +0200 (CEST) Message-ID: <4C6595F3.3040008@sunet.se> Date: Fri, 13 Aug 2010 20:58:59 +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: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> In-Reply-To: <4C65956F.3040601@dcrocker.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:58:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 08:56 PM, Dave CROCKER wrote: > starting points for discussion? starting points for specification? > starting points for refinement? but the actual choices can be > anything? whole new specifications will be acceptable? Yes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxllfMACgkQ8Jx8FtbMZndeUACbBDoHJInznwX6kEoRz4eMlmLE 5woAnA/gh4qEihXzqWNJutGy3vviLwg0 =1oGI -----END PGP SIGNATURE----- From leifj@sunet.se Fri Aug 13 12:19:05 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB6F3A68D5 for ; Fri, 13 Aug 2010 12:19:05 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8Q3ayagiJ+O for ; Fri, 13 Aug 2010 12:19:04 -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 3EE6C3A6867 for ; Fri, 13 Aug 2010 12:19:03 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DJJLG2006296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 21:19:24 +0200 (CEST) Message-ID: <4C659AB9.4080007@sunet.se> Date: Fri, 13 Aug 2010 21:19:21 +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: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> In-Reply-To: <4C65956F.3040601@dcrocker.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:19:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2010 08:56 PM, Dave CROCKER wrote: > > > On 8/13/2010 11:44 AM, Leif Johansson wrote: >>> In this case, however, I think it defines a high barrier for replacing >>> the technical components and it hits the reader in the face with how >>> much effort it will take to climb the barrier. So, I like it. >> >> I think you and Sam will have to slug it out on this topic. He wants to >> cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody >> else has yet another approach :-) > > The charter really needs to state fairly clearly what the boundaries of > change are, within the charter. It needs to state it forcefully enough > to be useful when someone starts distracting the working group with > calls for changes that really go beyond what the working group intends. > This is a question of clarity about what the working group intends and > strong enough language in the charter to be used as an enforcement > club. I'd say that there is already plenty of demonstrated need for > such a paragraph. The argument against is of course that it is redundant and that the IETF process states that you must always have consensus. So given that the scope is clearly expressed, what is the use of a paragraph saying exactly what the IETF process already tells you must happen? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlmrkACgkQ8Jx8FtbMZne9MQCgqjAbfd1s6bTKKjdVh+sC9QnY Sl0AoI8qe9hAg6RKh7+deYmeP9iRQHtR =xv0f -----END PGP SIGNATURE----- From klaas@cisco.com Fri Aug 13 12:53:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265BA3A6986 for ; Fri, 13 Aug 2010 12:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 3SSHVaatqAuT for ; Fri, 13 Aug 2010 12:53:33 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id D84353A694A for ; Fri, 13 Aug 2010 12:53:32 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=[10.55.220.245]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ok0Jl-000Iw2-Sn; Fri, 13 Aug 2010 21:53:30 +0200 References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> Message-Id: <354DD96F-7929-4754-828E-6EAB1D583244@cisco.com> From: Klaas Wierenga To: Leif Johansson In-Reply-To: <4C659AB9.4080007@sunet.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Fri, 13 Aug 2010 21:54:05 +0200 X-Antivirus: no malware found Cc: "abfab@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:53:34 -0000 Sent from my iPad On Aug 13, 2010, at 9:19 PM, "Leif Johansson" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 08/13/2010 08:56 PM, Dave CROCKER wrote: >>=20 >>=20 >> On 8/13/2010 11:44 AM, Leif Johansson wrote: >>>> In this case, however, I think it defines a high barrier for = replacing >>>> the technical components and it hits the reader in the face with = how >>>> much effort it will take to climb the barrier. So, I like it. >>>=20 >>> I think you and Sam will have to slug it out on this topic. He wants = to >>> cut it. I'm iffy. You want to keep it but also cut it. Maybe = somebody >>> else has yet another approach :-) >>=20 >> The charter really needs to state fairly clearly what the boundaries = of >> change are, within the charter. It needs to state it forcefully = enough >> to be useful when someone starts distracting the working group with >> calls for changes that really go beyond what the working group = intends.=20 >> This is a question of clarity about what the working group intends = and >> strong enough language in the charter to be used as an enforcement >> club. I'd say that there is already plenty of demonstrated need for >> such a paragraph. >=20 > The argument against is of course that it is redundant and that the = IETF > process states that you must always have consensus. So given that the > scope is clearly expressed, what is the use of a paragraph saying > exactly what the IETF process already tells you must happen? Well, I think the argument is that some WGs have a clear exploratory = phase in which all options are still at the table, whereas we don't want = to be stalled by endless discussions about alternative solutions that = have no demonstrable benefit, so we might as well raise the barrier = explicit. I know that I have argued for a less restrictive charter = before, but Dave and others have convinced me that it is important that = we have a pretty tight charter. So whereas there is always the option to = recharter in the IETF process, it doesn't hurt to make it clear that we = are not willing to consider one of the many alternatives out there = unless there is a well stated benefit, beyond "have you considered = protocol X or solution Y?". Klaas =20 >=20 >=20 > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkxlmrkACgkQ8Jx8FtbMZne9MQCgqjAbfd1s6bTKKjdVh+sC9QnY > Sl0AoI8qe9hAg6RKh7+deYmeP9iRQHtR > =3Dxv0f > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@sunet.se Fri Aug 13 13:05:41 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0826B3A6A01 for ; Fri, 13 Aug 2010 13:05:40 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1Oc2FO9HNx3 for ; Fri, 13 Aug 2010 13:05:39 -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 353143A68F1 for ; Fri, 13 Aug 2010 13:05:38 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7DK5Hqo003127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 22:05:19 +0200 (CEST) Message-ID: <4C65A57C.1090204@sunet.se> Date: Fri, 13 Aug 2010 22:05:16 +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: Klaas Wierenga References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <354DD96F-7929-4754-828E-6EAB1D583244@cisco.com> In-Reply-To: <354DD96F-7929-4754-828E-6EAB1D583244@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:05:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The argument against is of course that it is redundant and that the IETF > process states that you must always have consensus. So given that the > scope is clearly expressed, what is the use of a paragraph saying > exactly what the IETF process already tells you must happen? > >> Well, I think the argument is that some WGs have a clear exploratory phase in which all options are still at the table, whereas we don't want to be stalled by endless discussions about alternative solutions that have no demonstrable benefit, so we might as well raise the barrier explicit. I know that I have argued for a less restrictive charter before, but Dave and others have convinced me that it is important that we have a pretty tight charter. So whereas there is always the option to recharter in the IETF process, it doesn't hurt to make it clear that we are not willing to consider one of the many alternatives out there unless there is a well stated benefit, beyond "have you considered protocol X or solution Y?". Yeah I get that we need tight scoping and I think we have consensus on that point by now. What I'm (and I think Sam) wondering is why, if we say "we use X" we also need to say "in order to change X to Y you need IETF consensus and a recharter". Isn't that last bit _always_ redundant in the IETF? However I don't care that much about this and am happy with a bit of redundancy if it makes people happy. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxlpXsACgkQ8Jx8FtbMZneWeQCdELSh46rIxq21BrGYS0N7Coss W+8AoMCHUDDFrGEzYzlelDeXmK7mzfmo =4kga -----END PGP SIGNATURE----- From klaas@cisco.com Fri Aug 13 13:40:31 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAEF3A68C2 for ; Fri, 13 Aug 2010 13:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 V27o+ZTj0iZI for ; Fri, 13 Aug 2010 13:40:30 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 5A48D3A6852 for ; Fri, 13 Aug 2010 13:40:30 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=[10.55.220.245]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ok13H-000J9O-J9; Fri, 13 Aug 2010 22:40:31 +0200 References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <354DD96F-7929-4754-828E-6EAB1D583244@cisco.com> <4C65A57C.1090204@sunet.se> Message-Id: <24F82729-C576-4D3F-B5BB-C5DFD743DD4C@cisco.com> From: Klaas Wierenga To: Leif Johansson In-Reply-To: <4C65A57C.1090204@sunet.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Fri, 13 Aug 2010 22:41:08 +0200 X-Antivirus: no malware found Cc: "abfab@ietf.org" , "dcrocker@bbiw.net" Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:40:31 -0000 I guess my liking of chatty protocols shows ;-) If it doesn't hurt = having it in and it makes people happy, let's do that.=20 Klaas Sent from my iPad On Aug 13, 2010, at 10:06 PM, "Leif Johansson" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >=20 >> The argument against is of course that it is redundant and that the = IETF >> process states that you must always have consensus. So given that the >> scope is clearly expressed, what is the use of a paragraph saying >> exactly what the IETF process already tells you must happen? >>=20 >>> Well, I think the argument is that some WGs have a clear exploratory = phase in which all options are still at the table, whereas we don't want = to be stalled by endless discussions about alternative solutions that = have no demonstrable benefit, so we might as well raise the barrier = explicit. I know that I have argued for a less restrictive charter = before, but Dave and others have convinced me that it is important that = we have a pretty tight charter. So whereas there is always the option to = recharter in the IETF process, it doesn't hurt to make it clear that we = are not willing to consider one of the many alternatives out there = unless there is a well stated benefit, beyond "have you considered = protocol X or solution Y?". >=20 > Yeah I get that we need tight scoping and I think we have consensus on > that point by now. >=20 > What I'm (and I think Sam) wondering is why, if we say "we use X" we > also need to say "in order to change X to Y you need IETF consensus > and a recharter". Isn't that last bit _always_ redundant in the IETF? >=20 > However I don't care that much about this and am happy with a bit of > redundancy if it makes people happy. >=20 > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAkxlpXsACgkQ8Jx8FtbMZneWeQCdELSh46rIxq21BrGYS0N7Coss > W+8AoMCHUDDFrGEzYzlelDeXmK7mzfmo > =3D4kga > -----END PGP SIGNATURE----- From dcrocker@bbiw.net Fri Aug 13 11:55:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 056633A68D5 for ; Fri, 13 Aug 2010 11:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.936, 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 fYqNynFBU4uj for ; Fri, 13 Aug 2010 11:55:35 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E070B3A6887 for ; Fri, 13 Aug 2010 11:55:35 -0700 (PDT) Received: from [192.168.1.147] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7DIu6L9001765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 11:56:12 -0700 Message-ID: <4C65953E.6040000@bbiw.net> Date: Fri, 13 Aug 2010 11:55:58 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Leif Johansson References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> In-Reply-To: <4C65927B.8000204@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 13 Aug 2010 11:56:12 -0700 (PDT) X-Mailman-Approved-At: Fri, 13 Aug 2010 13:41:13 -0700 Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:55:37 -0000 On 8/13/2010 11:44 AM, Leif Johansson wrote: >> In this case, however, I think it defines a high barrier for replacing >> the technical components and it hits the reader in the face with how >> much effort it will take to climb the barrier. So, I like it. > > I think you and Sam will have to slug it out on this topic. He wants to > cut it. I'm iffy. You want to keep it but also cut it. Maybe somebody > else has yet another approach :-) The charter really needs to state fairly clearly what the boundaries of change are, within the charter. It needs to state it forcefully enough to be useful when someone starts distracting the working group with calls for changes that really go beyond what the working group intends. This is a question of clarity about what the working group intends and strong enough language in the charter to be used as an enforcement club. I'd say that there is already plenty of demonstrated need for such a paragraph. As for Sam vs. me, no. Neither of us should matter that much. That's what rough consensus is all about. > > >>> The working group may not change EAP (beyond the development of EAP >>> mechanisms), RADIUS or Diameter without establishing consensus with >>> the appropriate community within the IETF. >>> >>> The working group will use the following documents as a starting >>> point for its work: >>> >>> - - draft-howlett-eap-gss-00, >>> - - draft-howlett-radius-saml-attr-00 >>> - - draft-hartman-gss-eap-naming-00 >> >> I'm pretty sure these are more than "starting points". That's a pretty >> vague term and I think you folks intend something more specific and that >> it means significant constraints on the changes to these specification >> that are considered permissible. > > They are (imho) starting-points within the constraints of the > technology choices which have been outlined in the charter so I > think it is appropriate to say "starting point" in this case and > given that one has read the charter and the drafts I believe the > meaning is clear: that given the roles of SAML, EAP and AAA > these three documents are starting points for each part of the > solution. starting points for discussion? starting points for specification? starting points for refinement? but the actual choices can be anything? whole new specifications will be acceptable? >> These are the base specifications. What are the criteria for making >> changes to them? > > Normal IETF WG consensus, but we really can't keep repeating that. What are the criteria that permits a working group chair to declare a topic out of scope? Most wg chairs are nice folk who tend to let things go more astray than one would later have wished. Clear and firm criteria in a charter make the wg chair's job much clearer about scope and therefore easier to enforce. The alternative is constantly having to pool the wg for rough consensus about scope issue, after scope issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hartmans@painless-security.com Fri Aug 13 15:48:48 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71C823A69B0 for ; Fri, 13 Aug 2010 15:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 HgpOuKkDoLQh for ; Fri, 13 Aug 2010 15:48:46 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B5B003A6980 for ; Fri, 13 Aug 2010 15:48:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (cpe-72-224-236-133.maine.res.rr.com [72.224.236.133]) (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 766B92029D; Fri, 13 Aug 2010 18:49:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DB91E412A; Fri, 13 Aug 2010 18:49:15 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> Date: Fri, 13 Aug 2010 18:49:15 -0400 In-Reply-To: <4C65956F.3040601@dcrocker.net> (Dave CROCKER's message of "Fri, 13 Aug 2010 11:56:47 -0700") 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: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 22:48:48 -0000 >>>>> "Dave" == Dave CROCKER writes: Dave> The charter really needs to state fairly clearly what the Dave> boundaries of change are, within the charter. It needs to Dave> state it forcefully enough to be useful when someone starts Dave> distracting the working group with calls for changes that Dave> really go beyond what the working group intends. This is a Dave> question of clarity about what the working group intends and Dave> strong enough language in the charter to be used as an Dave> enforcement club. I'd say that there is already plenty of Dave> demonstrated need for such a paragraph. Dave, I agree with the above paragraph. That's why I want the fourth paragraph to go away. The fourth paragraph states a constraint that I believe is too weak. Other text in the charter states the constraint that I believe is correct. So, I am in completely agreement that we need to state the constraints, I just want to state the right one. From dhc@dcrocker.net Sat Aug 14 08:46:04 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC44D3A69DB for ; Sat, 14 Aug 2010 08:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.513 X-Spam-Level: X-Spam-Status: No, score=-5.513 tagged_above=-999 required=5 tests=[AWL=-0.773, 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 PaOCxxyGoiPF for ; Sat, 14 Aug 2010 08:46:03 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id EA7933A69F9 for ; Sat, 14 Aug 2010 08:46:02 -0700 (PDT) Received: from [192.168.1.166] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7EFkXYM020257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Aug 2010 08:46:39 -0700 Message-ID: <4C66BA51.1020704@dcrocker.net> Date: Sat, 14 Aug 2010 08:46:25 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: abfab@ietf.org References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> In-Reply-To: <4C659AB9.4080007@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 14 Aug 2010 08:46:39 -0700 (PDT) Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Aug 2010 15:46:05 -0000 On 8/13/2010 12:19 PM, Leif Johansson wrote: > So given that the > scope is clearly expressed, what is the use of a paragraph saying > exactly what the IETF process already tells you must happen? Taken to its logical extreme, this means that there is no need for a charter. Everything is subject to working group consensus. The charter is a combination marketing tool and stick. By marketing, I mean telling other folks what is going to be done, so that they can decide whether to authorize it (iesg) or participate in it (contributors.) By stick I mean that it can be used to expedite working group management, aiding chairs in restricting discussion. (More positively, this means aiding chairs in keeping the discussion constructively focused.) Consider the BOF that just took place. Consider the range of comments from the microphone. In particular, consider how /many/ of those comments suggested replacing or adding one or another technology, rather than suggesting evaluation and enhancement of the proposal that motivated the BOF. It's easy to believe that that will happen at a BOF but not aftering chartering, but some working groups are not so lucky. I prefer charters that anticipate the problem continuing, especially when there's some basis for the fear in a particular case. I think this is one of those. Imagine those kinds of "contributions" continuing throughout the life of the working group and the working group's having to do a full discussion and consensus call each time. This does sometimes happen in working groups. It is extremely inefficient and often winds up being a denial of service attack that ultimately discourages serious participants. The alternative is to permit the chairs to immediately declare a contribution out of scope. But this requires that the chairs be able to point to something that declares the scope well enough to withstand a process challenge. That's why I'm pressing for this extra language in the charter. On 8/13/2010 1:05 PM, Leif Johansson wrote: > What I'm (and I think Sam) wondering is why, if we say "we use X" we > also need to say "in order to change X to Y you need IETF consensus > and a recharter". Isn't that last bit _always_ redundant in the IETF? Excellent question. The difference is between stating what forms the starting point versus stating the rules for changing it. What kinds of changes are permitted and what kind are not? On 8/13/2010 3:49 PM, Sam Hartman wrote: > That's why I want the fourth paragraph to go away. The fourth paragraph > states a constraint that I believe is too weak. Other text in the > charter states the constraint that I believe is correct. Oh. I'm assuming that the stronger language that Sam is referring to: > The design will combine existing IETF protocols, > specifically SAML, EAP (RFC 3748) and AAA (RADIUS, Diameter). and > The working group will develop a solution ... by combining SAML, EAP (RFC > 3748) and AAA (RADIUS, Diameter). On reflection, it does seem unlikely that using any other technology components would formally be within scope. Very crisp working group management ought to be able to use these statements to keep the working group in focus. Over time, I've come to appreciate the problem of demanding too much from IETF working group chairs. They need as much help as they can be given, for working groups covering topics that are "interesting". (Interesting means either or both of technically difficult or participant difficult.) I believe this topic qualifies as both and that even if the fourth paragraph is redundant, it will be safer to give the chairs the extra help. I also think that "requires rechartering" is the single most powerful statement that can be made in a charter. It's the highest possible barrier. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hartmans@painless-security.com Mon Aug 16 05:45:03 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF42F3A6915 for ; Mon, 16 Aug 2010 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 LXuHOFNdUj8S for ; Mon, 16 Aug 2010 05:45:02 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B01E53A68E1 for ; Mon, 16 Aug 2010 05:45:01 -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 DD42C200B4; Mon, 16 Aug 2010 08:45:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CFDA7412A; Mon, 16 Aug 2010 08:45:34 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> Date: Mon, 16 Aug 2010 08:45:34 -0400 In-Reply-To: <4C66BA51.1020704@dcrocker.net> (Dave CROCKER's message of "Sat, 14 Aug 2010 08:46:25 -0700") 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: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 12:45:04 -0000 >>>>> "Dave" == Dave CROCKER writes: Dave> That's why I'm pressing for this extra language in the Dave> charter. I wonder if my disagreement isn't simply about the existing language. I read the current fourth paragraph as encouraging people to bring forward proposals to change fundamental technology choices; the bar they need to meet is consensus to recharter. So, I agree with your overall goal, I just question whether the specific text actually accomplishes that goal. One reason I read things this way is that we actually are encouraging people to come forward with sufficiently interesting proposals for additional work--for example a way to integrate into some non-GSS application. The bar for those changes is also a recharter, but it's something that we expect we might want to do. If we want to say that we do not anticipate a need to change the fundamental technology choices, let's just say that. Perhaps something like "As discussed below, the WG is open to adding new ways to interface to applications through the recharter process. The WG does not anticipate revisiting the technology choices in the previous paragraph." My goal is to emphasize theconstraint rather than the procedure for getting around the constraint. Could something like that work for folks? From yoshihiro.ohba@toshiba.co.jp Mon Aug 16 07:03:29 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9F93A689D for ; Mon, 16 Aug 2010 07:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 ijNVwRiu42Tb for ; Mon, 16 Aug 2010 07:03:27 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 7A1E23A67AF for ; Mon, 16 Aug 2010 07:03:27 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id o7GE42jD015051 for ; Mon, 16 Aug 2010 23:04:02 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id o7GE42DZ027722 for abfab@ietf.org; Mon, 16 Aug 2010 23:04:02 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id ZAA27721; Mon, 16 Aug 2010 23:04:02 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id o7GE41Xs009258 for ; Mon, 16 Aug 2010 23:04:01 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o7GE41tb001445; Mon, 16 Aug 2010 23:04:01 +0900 (JST) Received: from [133.199.75.80] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0L7900F290EP61D0@mail.po.toshiba.co.jp> for abfab@ietf.org; Mon, 16 Aug 2010 23:04:01 +0900 (JST) Date: Mon, 16 Aug 2010 23:03:57 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <4C69454D.3020009@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 14:03:29 -0000 The current charter text gives two reasons for rechartering: o Changing the technology choices, i.e, SAML, EAP and AAA. o Adding a new application interface (e.g., for non-GSS applications) under the above technology choices. It does not seem logical (to me) to put the same level of bar for these two types of modifications while we say that in the charter that the latter type of modifications are in the scope: "Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group ..." I think one reason for putting the same level of bar for the two types of modifications is based on whether a solution has been presented or discussed in the BoF. For example, other technology choices and non-GSS application interfaces were not presented in the BoF. This would be a fair reasoning, but on the other hand I am wondering why a WG consensus is not sufficient for the latter type of modifications. Best Regards, Yoshihiro Ohba (2010/08/16 21:45), Sam Hartman wrote: >>>>>> "Dave" == Dave CROCKER writes: > Dave> That's why I'm pressing for this extra language in the > Dave> charter. > > > I wonder if my disagreement isn't simply about the existing language. > > I read the current fourth paragraph as encouraging people to bring > forward proposals to change fundamental technology choices; the bar they > need to meet is consensus to recharter. So, I agree with your overall > goal, I just question whether the specific text actually accomplishes > that goal. > > One reason I read things this way is that we actually are encouraging > people to come forward with sufficiently interesting proposals for > additional work--for example a way to integrate into some non-GSS > application. The bar for those changes is also a recharter, but it's > something that we expect we might want to do. > > If we want to say that we do not anticipate a need to change the > fundamental technology choices, let's just say that. Perhaps something > like "As discussed below, the WG is open to adding new ways to interface > to applications through the recharter process. The WG does not > anticipate revisiting the technology choices in the previous paragraph." > > My goal is to emphasize theconstraint rather than the procedure for > getting around the constraint. > > Could something like that work for folks? > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Mon Aug 16 07:16:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1835D3A69F1 for ; Mon, 16 Aug 2010 07:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 3VvrJp7l6VEz for ; Mon, 16 Aug 2010 07:16:05 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0529D3A686A for ; Mon, 16 Aug 2010 07:15:58 -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 D6314200A3; Mon, 16 Aug 2010 10:16:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CE0D7412A; Mon, 16 Aug 2010 10:16:29 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69454D.3020009@toshiba.co.jp> Date: Mon, 16 Aug 2010 10:16:29 -0400 In-Reply-To: <4C69454D.3020009@toshiba.co.jp> (Yoshihiro Ohba's message of "Mon, 16 Aug 2010 23:03:57 +0900") 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: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 14:16:14 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> The current charter text gives two reasons for Yoshihiro> rechartering: o Changing the technology choices, i.e, Yoshihiro> SAML, EAP and AAA. Yoshihiro> o Adding a new application interface (e.g., for non-GSS Yoshihiro> applications) under the above technology choices. Yoshihiro> It does not seem logical (to me) to put the same level of Yoshihiro> bar for these two types of modifications while we say Yoshihiro> that in the charter that the latter type of modifications Yoshihiro> are in the scope: "Initially the working group will focus Yoshihiro> on using GSS-API (RFC2743) as a mechanism for integrating Yoshihiro> the developed solution for federated identity into Yoshihiro> application protocols but other technologies for Yoshihiro> application interface are in scope of the working group Yoshihiro> ..." I agree with you. I do think that the bar is different. Getting a new application interface added should look like a mini-bof. Someone should present a proposal that is well researched and well defined enough for us to evaluate it. Then we discuss whether it is a good idea and if we think so, propose modifying our charter. The reason we want a charter modification is to give the IESG an opportunity to comment and if the new charter is accepted get the IESG on-board with the new deliverable. We also want to give the IETF as a whole a chance to comment. At a process level, changing the fundamental technology choices would also be a recharter. However, I'd expect that to generally be a much bigger up-hill battle. The difference in the bar is that you're probably going into the discussion of adding a new interface with relatively open minds. You're probably going into the discussion of the fundamental technology choice with a much higher probability that the discussion (at least within the wg) will be closed down fairly quickly and that there will be strong objections. Yoshihiro> I think one reason for putting the same level of bar for Yoshihiro> the two types of modifications is based on whether a Yoshihiro> solution has been presented or discussed in the BoF. For Yoshihiro> example, other technology choices and non-GSS application Yoshihiro> interfaces were not presented in the BoF. This would be Yoshihiro> a fair reasoning, but on the other hand I am wondering Yoshihiro> why a WG consensus is not sufficient for the latter type Yoshihiro> of modifications. >From a management standpoint it's strongly desirable to have a recharter when the work of a WG significantly changes. That gives the rest of the IETF the opportunity to get on board with the work plan. It significantly raises the bar later for someone to claim that work should not have been done. --Sam From dhc@dcrocker.net Mon Aug 16 16:46:37 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A6C3A6827 for ; Mon, 16 Aug 2010 16:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 KQfc8Ul1Uc5O for ; Mon, 16 Aug 2010 16:46:36 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 434B03A67F0 for ; Mon, 16 Aug 2010 16:46:36 -0700 (PDT) Received: from [192.168.1.176] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7GNl6x0004557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 16:47:11 -0700 Message-ID: <4C69CDEE.2010006@dcrocker.net> Date: Mon, 16 Aug 2010 16:46:54 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 16 Aug 2010 16:47:12 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 23:46:37 -0000 On 8/16/2010 5:45 AM, Sam Hartman wrote: > I wonder if my disagreement isn't simply about the existing language. > > I read the current fourth paragraph as encouraging people to bring > forward proposals to change fundamental technology choices; oh. that hadn't occurred to me. > If we want to say that we do not anticipate a need to change the > fundamental technology choices, let's just say that. Perhaps something > like "As discussed below, the WG is open to adding new ways to interface > to applications through the recharter process. The WG does not > anticipate revisiting the technology choices in the previous paragraph." I suggest something simpler and more direct: Any change in the choices for these three technical roles is out of scope for this charter. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From klaas@cisco.com Mon Aug 16 23:48:40 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1983A682F for ; Mon, 16 Aug 2010 23:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 A2NCDqz1fbeX for ; Mon, 16 Aug 2010 23:48:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 76ECD3A6822 for ; Mon, 16 Aug 2010 23:48:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAH/NaUxAZnwN/2dsb2JhbACTJo0VcaFDnBmFNwSJZw X-IronPort-AV: E=Sophos;i="4.55,380,1278288000"; d="scan'208";a="148494040" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2010 06:49:14 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7H6nDA9001747; Tue, 17 Aug 2010 06:49:14 GMT Message-ID: <4C6A30E9.7000601@cisco.com> Date: Tue, 17 Aug 2010 08:49:13 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> In-Reply-To: <4C69CDEE.2010006@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:48:40 -0000 On 8/17/10 1:46 AM, Dave CROCKER wrote: > > > On 8/16/2010 5:45 AM, Sam Hartman wrote: >> I wonder if my disagreement isn't simply about the existing language. >> >> I read the current fourth paragraph as encouraging people to bring >> forward proposals to change fundamental technology choices; > > oh. that hadn't occurred to me. > >> If we want to say that we do not anticipate a need to change the >> fundamental technology choices, let's just say that. Perhaps something >> like "As discussed below, the WG is open to adding new ways to interface >> to applications through the recharter process. The WG does not >> anticipate revisiting the technology choices in the previous paragraph." > > I suggest something simpler and more direct: > > Any change in the choices for these three technical roles is out of > scope for this charter. This strong a statement was not made in the room during the BoF, but consensus is achieved on the mailing list. So please everyone speak up whether this is what we want to do. Klaas From leifj@sunet.se Mon Aug 16 23:54:39 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC903A682F for ; Mon, 16 Aug 2010 23:54:39 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuWWSAxdNsdg for ; Mon, 16 Aug 2010 23:54:38 -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 EF4743A63EC for ; Mon, 16 Aug 2010 23:54:37 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7H6t9v5021713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Aug 2010 08:55:11 +0200 (CEST) Message-ID: <4C6A324A.1090700@sunet.se> Date: Tue, 17 Aug 2010 08:55:06 +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: abfab@ietf.org References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <4C6A30E9.7000601@cisco.com> In-Reply-To: <4C6A30E9.7000601@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:54:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/17/2010 08:49 AM, Klaas Wierenga wrote: > On 8/17/10 1:46 AM, Dave CROCKER wrote: >> >> >> On 8/16/2010 5:45 AM, Sam Hartman wrote: >>> I wonder if my disagreement isn't simply about the existing language. >>> >>> I read the current fourth paragraph as encouraging people to bring >>> forward proposals to change fundamental technology choices; >> >> oh. that hadn't occurred to me. >> >>> If we want to say that we do not anticipate a need to change the >>> fundamental technology choices, let's just say that. Perhaps something >>> like "As discussed below, the WG is open to adding new ways to interface >>> to applications through the recharter process. The WG does not >>> anticipate revisiting the technology choices in the previous paragraph." >> >> I suggest something simpler and more direct: >> >> Any change in the choices for these three technical roles is out of >> scope for this charter. > > This strong a statement was not made in the room during the BoF, but > consensus is achieved on the mailing list. So please everyone speak up > whether this is what we want to do. I agree. We need more people chiming in on this. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxqMkYACgkQ8Jx8FtbMZndL/QCgoDvZFOrDihK44el7riB+JwSS qSAAoKcYguhBATTiyS0AaNxZvHqDz/ej =df5V -----END PGP SIGNATURE----- From lear@cisco.com Tue Aug 17 00:40:31 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47883A67A5 for ; Tue, 17 Aug 2010 00:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.488 X-Spam-Level: X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 QrTFK9QkWcvO for ; Tue, 17 Aug 2010 00:40:30 -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 AA8AE3A68A7 for ; Tue, 17 Aug 2010 00:40:30 -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: AhsFAHLZaUxAZnwM/2dsb2JhbACDFZARjRVxoH2JU5JLgSKDInMEiWc X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208";a="148686514" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2010 07:41:06 +0000 Received: from dhcp-10-55-81-169.cisco.com (dhcp-10-55-81-169.cisco.com [10.55.81.169]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7H7f5Uu013473; Tue, 17 Aug 2010 07:41:05 GMT Message-ID: <4C6A3D18.3070309@cisco.com> Date: Tue, 17 Aug 2010 09:41:12 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> In-Reply-To: <4C69CDEE.2010006@dcrocker.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 07:40:31 -0000 Dave, On 8/17/10 1:46 AM, Dave CROCKER wrote: > I suggest something simpler and more direct: > > Any change in the choices for these three technical roles is out of > scope for this charter. > As I wrote earlier, I do not mind seeing alternative approaches develop. This having been said, I'll suggest that if an idea develops sufficiently that it warrants attention, there are plenty of ways to move forward. And so, +1. Eliot From hartmans@painless-security.com Tue Aug 17 05:38:14 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281C93A694A for ; Tue, 17 Aug 2010 05:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 COHcpEQEIF3f for ; Tue, 17 Aug 2010 05:38:13 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 68D9F3A687E for ; Tue, 17 Aug 2010 05:38: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 80ACF20239; Tue, 17 Aug 2010 08:38:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5FF19412A; Tue, 17 Aug 2010 08:38:43 -0400 (EDT) From: Sam Hartman To: dcrocker@bbiw.net References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> Date: Tue, 17 Aug 2010 08:38:43 -0400 In-Reply-To: <4C69CDEE.2010006@dcrocker.net> (Dave CROCKER's message of "Mon, 16 Aug 2010 16:46:54 -0700") 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: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 12:38:14 -0000 >>>>> "Dave" == Dave CROCKER writes: Dave> Any change in the choices for these three technical roles Dave> is out of scope for this charter. Works for me. From leifj@sunet.se Tue Aug 17 11:27:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730383A686B for ; Tue, 17 Aug 2010 11:27:34 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPUqwql-NLgo for ; Tue, 17 Aug 2010 11:27:33 -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 494C03A6869 for ; Tue, 17 Aug 2010 11:27:32 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7HIS5iG016461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Aug 2010 20:28:07 +0200 (CEST) Message-ID: <4C6AD4B5.30706@sunet.se> Date: Tue, 17 Aug 2010 20:28:05 +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: abfab@ietf.org References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:27:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/17/2010 02:38 PM, Sam Hartman wrote: >>>>>> "Dave" == Dave CROCKER writes: > > > Dave> Any change in the choices for these three technical roles > Dave> is out of scope for this charter. > > Works for me. I'd be happier with some more expressions of support (or at least absense of dissent) but I plan to summarize the current state in a v4 of the charter tomorrow. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxq1LUACgkQ8Jx8FtbMZnfCtQCgyIDUpHDOtYZHc0C0mVYGIok+ Zh0AnizrOmNWWOpX3Pa9ay8XefY+hz2R =Gyqt -----END PGP SIGNATURE----- From yoshihiro.ohba@toshiba.co.jp Tue Aug 17 15:36:14 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADFB3A6853 for ; Tue, 17 Aug 2010 15:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 DmMPTCq9Ysum for ; Tue, 17 Aug 2010 15:36:10 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 090B53A67D7 for ; Tue, 17 Aug 2010 15:36:09 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id o7HMahlH011877 for ; Wed, 18 Aug 2010 07:36:43 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id o7HMahZ7015610 for abfab@ietf.org; Wed, 18 Aug 2010 07:36:43 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id HAA15609; Wed, 18 Aug 2010 07:36:43 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id o7HMahHX022389 for ; Wed, 18 Aug 2010 07:36:43 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o7HMaglw019417; Wed, 18 Aug 2010 07:36:42 +0900 (JST) Received: from [133.196.17.63] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0L7B00LLZIT6X0L0@mail.po.toshiba.co.jp> for abfab@ietf.org; Wed, 18 Aug 2010 07:36:42 +0900 (JST) Date: Wed, 18 Aug 2010 07:36:35 +0900 From: Yoshihiro Ohba In-reply-to: <4C6AD4B5.30706@sunet.se> To: abfab@ietf.org Message-id: <4C6B0EF3.7050803@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <4C6AD4B5.30706@sunet.se> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 22:36:14 -0000 +1 Yoshihiro Ohba (2010/08/18 3:28), Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/17/2010 02:38 PM, Sam Hartman wrote: >>>>>>> "Dave" == Dave CROCKER writes: >> >> >> Dave> Any change in the choices for these three technical roles >> Dave> is out of scope for this charter. >> >> Works for me. > > I'd be happier with some more expressions of support (or at least > absense of dissent) but I plan to summarize the current state in > a v4 of the charter tomorrow. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxq1LUACgkQ8Jx8FtbMZnfCtQCgyIDUpHDOtYZHc0C0mVYGIok+ > Zh0AnizrOmNWWOpX3Pa9ay8XefY+hz2R > =Gyqt > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From Nicolas.Williams@oracle.com Thu Aug 19 10:01:00 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570B83A695D for ; Thu, 19 Aug 2010 10:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 g6cZXiLK4BFY for ; Thu, 19 Aug 2010 10:00:59 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 733003A6A68 for ; Thu, 19 Aug 2010 10:00:59 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7JH1QCo004439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 17:01:27 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 o7JDRUgR009591; Thu, 19 Aug 2010 17:01:25 GMT Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 512671521282237280; Thu, 19 Aug 2010 10:01:20 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 10:01:19 -0700 Date: Thu, 19 Aug 2010 12:01:13 -0500 From: Nicolas Williams To: dcrocker@bbiw.net Message-ID: <20100819170113.GN14409@oracle.com> References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C69CDEE.2010006@dcrocker.net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:01:00 -0000 On Mon, Aug 16, 2010 at 04:46:54PM -0700, Dave CROCKER wrote: > On 8/16/2010 5:45 AM, Sam Hartman wrote: > >If we want to say that we do not anticipate a need to change the > >fundamental technology choices, let's just say that. Perhaps something > >like "As discussed below, the WG is open to adding new ways to interface > >to applications through the recharter process. The WG does not > >anticipate revisiting the technology choices in the previous paragraph." > > I suggest something simpler and more direct: > > Any change in the choices for these three technical roles is out > of scope for this charter. It isn't really possible to bind future charters in this one. The WG and IESG can do what they like in the future. What I think we must do is list the technologies that will be the basis for WG work items. We should also note that work items based on other technologies will require re-chartering, and we should state the requirements that we think those technologies must meet. Even though we can't bind the WG and the IESG to those requirements, stating them will be useful. Nico -- From hartmans@painless-security.com Thu Aug 19 10:04:10 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A54D3A696D for ; Thu, 19 Aug 2010 10:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 j9I1LIFyMpB7 for ; Thu, 19 Aug 2010 10:04:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6E5E23A693D for ; Thu, 19 Aug 2010 10:04:09 -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 9ED1A20229; Thu, 19 Aug 2010 13:04:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D540143FA; Thu, 19 Aug 2010 13:04:33 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> Date: Thu, 19 Aug 2010 13:04:33 -0400 In-Reply-To: <20100819170113.GN14409@oracle.com> (Nicolas Williams's message of "Thu, 19 Aug 2010 12:01:13 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:04:10 -0000 >>>>> "Nicolas" == Nicolas Williams writes: >> Any change in the choices for these three technical roles is out >> of scope for this charter. Nicolas> It isn't really possible to bind future charters in this Nicolas> one. The WG and IESG can do what they like in the future. True. Note that the quoted text doesn't speak about future charters. Nicolas> What I think we must do is list the technologies that will Nicolas> be the basis for WG work items. Nicolas> We should also note that work items based on other Nicolas> technologies will require re-chartering, and we should Nicolas> state the requirements that we think those technologies Nicolas> must meet. Even though we can't bind the WG and the IESG Nicolas> to those requirements, stating them will be useful. I think we do all that. From Nicolas.Williams@oracle.com Thu Aug 19 10:16:44 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C563A67F1 for ; Thu, 19 Aug 2010 10:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 bAuIP-6W9k8J for ; Thu, 19 Aug 2010 10:16:43 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id BDDC73A6953 for ; Thu, 19 Aug 2010 10:16: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.2) with ESMTP id o7JHH8nx013996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 17:17:10 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 o7JF1PDK013976; Thu, 19 Aug 2010 17:17:08 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 512730561282238130; Thu, 19 Aug 2010 10:15:30 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 10:15:28 -0700 Date: Thu, 19 Aug 2010 12:15:24 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100819171523.GP14409@oracle.com> References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@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) Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:16:45 -0000 On Thu, Aug 19, 2010 at 01:04:33PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > >> Any change in the choices for these three technical roles is out > >> of scope for this charter. > > Nicolas> It isn't really possible to bind future charters in this > Nicolas> one. The WG and IESG can do what they like in the future. > > True. Note that the quoted text doesn't speak about future charters. > > Nicolas> What I think we must do is list the technologies that will > Nicolas> be the basis for WG work items. > > Nicolas> We should also note that work items based on other > Nicolas> technologies will require re-chartering, and we should > Nicolas> state the requirements that we think those technologies > Nicolas> must meet. Even though we can't bind the WG and the IESG > Nicolas> to those requirements, stating them will be useful. > > I think we do all that. Do we? I looked at the draft charter posted at start of this thread and saw nothing about mutual authentication nor channel binding, for example. I also saw nothing about the GSS-API mechanism being usable in Internet protocols that support the use of GSS-API mechanisms, or in some subset, therefore I cannot derive a requirement for support of host-based service names, mutual authentication, channel binding, nor per-message tokens from the charter text. It's probably not fatal if the charter fails to say any of those things. But I think it'd be very useful if it did. Nico -- From dhc@dcrocker.net Thu Aug 19 10:19:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A113A68A7 for ; Thu, 19 Aug 2010 10:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, 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 anpjhwnPny-4 for ; Thu, 19 Aug 2010 10:19:07 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E13393A67F1 for ; Thu, 19 Aug 2010 10:19:07 -0700 (PDT) Received: from [192.168.1.225] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7JHJbZU009611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:19:42 -0700 Message-ID: <4C6D6799.4060703@dcrocker.net> Date: Thu, 19 Aug 2010 10:19:21 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nicolas Williams References: <4C64F516.8020801@sunet.se> <4C659042.5050000@dcrocker.net> <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> In-Reply-To: <20100819171523.GP14409@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 19 Aug 2010 10:19:43 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:19:09 -0000 On 8/19/2010 10:15 AM, Nicolas Williams wrote: > Do we? I looked at the draft charter posted at start of this thread and > saw nothing about mutual authentication nor channel binding, for > example. I also saw nothing about the GSS-API mechanism being usable in > Internet protocols that support the use of GSS-API mechanisms, or in > some subset, therefore I cannot derive a requirement for support of > host-based service names, mutual authentication, channel binding, nor > per-message tokens from the charter text. The etiquette, at this stage of this process, is to offer specific draft text changes. It moves discussion from concept to concrete. That usually makes it far easier to resolve the concerns (or dismiss them.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Nicolas.Williams@oracle.com Thu Aug 19 10:23:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3B43A68A7 for ; Thu, 19 Aug 2010 10:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 UyNc7XXwuy3O for ; Thu, 19 Aug 2010 10:23:23 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 64AA53A65A6 for ; Thu, 19 Aug 2010 10:23:23 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7JHNo7X030398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 17:23:52 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 o7JEdx1N032306; Thu, 19 Aug 2010 17:23:50 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 532611961282238599; Thu, 19 Aug 2010 10:23:19 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 10:23:18 -0700 Date: Thu, 19 Aug 2010 12:23:10 -0500 From: Nicolas Williams To: dcrocker@bbiw.net Message-ID: <20100819172310.GR14409@oracle.com> References: <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6D6799.4060703@dcrocker.net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:23:24 -0000 On Thu, Aug 19, 2010 at 10:19:21AM -0700, Dave CROCKER wrote: > The etiquette, at this stage of this process, is to offer specific > draft text changes. Perhaps, but first I wanted to make sure I wasn't missing something. It'd be silly to waste your time on reviewing proposed text if the proposal was redundant as a result of my having missed some detail. Once I'm sure that the proposed charter fails to address this one issue even indirectly, then I'll propose text. Nico -- From hartmans@painless-security.com Thu Aug 19 10:50:17 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606D63A6974 for ; Thu, 19 Aug 2010 10:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 e2MXthJqUcAb for ; Thu, 19 Aug 2010 10:50:16 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 750923A69EB for ; Thu, 19 Aug 2010 10:50:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 41B6C2022C; Thu, 19 Aug 2010 13:50:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 739E443FA; Thu, 19 Aug 2010 13:50:43 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> Date: Thu, 19 Aug 2010 13:50:43 -0400 In-Reply-To: <20100819172310.GR14409@oracle.com> (Nicolas Williams's message of "Thu, 19 Aug 2010 12:23:10 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:50:17 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Aug 19, 2010 at 10:19:21AM -0700, Dave CROCKER wrote: >> The etiquette, at this stage of this process, is to offer >> specific draft text changes. Nicolas> Perhaps, but first I wanted to make sure I wasn't missing Nicolas> something. It'd be silly to waste your time on reviewing Nicolas> proposed text if the proposal was redundant as a result of Nicolas> my having missed some detail. Ah. I was thinking of much higher level things when I thought of requirements. You're right that the issues you mention are not in the current charter. At least with respect to the GSS mechanism, while I'm happy to have those requirements in the charter, I think we have enough GSS people in the group who care about those issues that it won't be a problem. However I do think it would be great to say that interfaces to integrate into applications need to support mutual authentication and channel binding. Could you draft text for that? --Sam From dcrocker@bbiw.net Thu Aug 19 10:57:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB3263A6847 for ; Thu, 19 Aug 2010 10:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.038 X-Spam-Level: X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=0.561, 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 Ljkra5rWyfCU for ; Thu, 19 Aug 2010 10:57:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E03583A67FE for ; Thu, 19 Aug 2010 10:57:27 -0700 (PDT) Received: from [192.168.1.225] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7JHvv84011975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Aug 2010 10:58:02 -0700 Message-ID: <4C6D7094.2000605@bbiw.net> Date: Thu, 19 Aug 2010 10:57:40 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C65927B.8000204@sunet.se> <4C65956F.3040601@dcrocker.net> <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 19 Aug 2010 10:58:03 -0700 (PDT) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 17:57:29 -0000 On 8/19/2010 10:50 AM, Sam Hartman wrote: > I think we have enough GSS people in > the group who care about those issues that it won't be a problem. > However I do think it would be great to say that interfaces to integrate > into applications need to support mutual authentication and channel > binding. Could you draft text for that? My view: A charter that specifies the use of very specific technologies and has barriers against alternatives needs to be complete in the list of technologies. It must not rely on assumptions or the composition of the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Nicolas.Williams@oracle.com Thu Aug 19 11:09:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797213A6899 for ; Thu, 19 Aug 2010 11:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 BRBQA4xmjcd3 for ; Thu, 19 Aug 2010 11:09:19 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E42F23A6967 for ; Thu, 19 Aug 2010 11:09:18 -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.2) with ESMTP id o7JI9k7v007295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 18:09:47 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7JI9jXg017347; Thu, 19 Aug 2010 18:09:46 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 512922651282241331; Thu, 19 Aug 2010 11:08:51 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 11:08:48 -0700 Date: Thu, 19 Aug 2010 13:08:42 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100819180841.GU14409@oracle.com> References: <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@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) Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:09:24 -0000 On Thu, Aug 19, 2010 at 01:50:43PM -0400, Sam Hartman wrote: > Ah. > I was thinking of much higher level things when I thought of > requirements. > You're right that the issues you mention are not in the current charter. I see two places where these are implied: "This working group will specify a federated identity mechanism for use by other Internet services, such as IMAP, XMPP, SSH, NFS and other non-IETF protocols ..." and "Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols ..." The implication is a bit weak for my taste. The fact that these constraints derive from existing Internet protocols is extremely useful, as they are much harder to change than it is to change a WG's charter. Stating these constraints explicitly should be also be useful. They will help folks interested in bringing new work items to this WG (they'll know a priori what features are required). And they will help the WG (and the IESG and the IETF) analyze whether this WG would be a suitable home to such work items. > At least with respect to the GSS mechanism, while I'm happy to have > those requirements in the charter, I think we have enough GSS people in > the group who care about those issues that it won't be a problem. > However I do think it would be great to say that interfaces to integrate > into applications need to support mutual authentication and channel > binding. Could you draft text for that? Here's my proposed text, to be slotted into the constraints section, preferably right after the first paragraph of that section: Note that in order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for GSS_Pseudo_random() is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Nico -- From Nicolas.Williams@oracle.com Thu Aug 19 11:18:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF523A6899 for ; Thu, 19 Aug 2010 11:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 iV3ViayhXO+w for ; Thu, 19 Aug 2010 11:18:08 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 042473A686A for ; Thu, 19 Aug 2010 11:18:07 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7JIITlU006036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 18:18:34 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 o7JDWGSY026903; Thu, 19 Aug 2010 18:18:28 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 532767811282241836; Thu, 19 Aug 2010 11:17:16 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 11:17:15 -0700 Date: Thu, 19 Aug 2010 13:17:11 -0500 From: Nicolas Williams To: Dave CROCKER Message-ID: <20100819181710.GV14409@oracle.com> References: <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> <4C6D7094.2000605@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6D7094.2000605@bbiw.net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:18:09 -0000 On Thu, Aug 19, 2010 at 10:57:40AM -0700, Dave CROCKER wrote: > > On 8/19/2010 10:50 AM, Sam Hartman wrote: > > I think we have enough GSS people in > >the group who care about those issues that it won't be a problem. > >However I do think it would be great to say that interfaces to integrate > >into applications need to support mutual authentication and channel > >binding. Could you draft text for that? > > > My view: > > A charter that specifies the use of very specific technologies and > has barriers against alternatives needs to be complete in the list > of technologies. It must not rely on assumptions or the composition > of the working group. But Sam asked for text nonetheless. I just supplied it. But also, it's better to state "natural" requirements and constraints than it is to merely list some technologies. A GSS-API mechanism based on required technologies might nonetheless fail to meet such natural requirements. The really useful thing here is that the constraints in question are external (which is what I meant by "natural"): they derive from the details of Internet SASL and GSS-API applications. Such constraints are much harder to argue with than mere personal preferences. They also provide much more information to newcomers. Want to know why host-based service names are required? Just look at the GSS-API applications we want to be able to use your GSS-API mechanism in. Don't care to support such applications? Then your mechanism is by definition of no interest to us (and here "us" likely evaluates to the IETF, not just the WG). Nico -- From hartmans@painless-security.com Thu Aug 19 11:25:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B293A686D for ; Thu, 19 Aug 2010 11:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 9ALzcDM5GxVg for ; Thu, 19 Aug 2010 11:25:52 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6C8483A67B2 for ; Thu, 19 Aug 2010 11:25:52 -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 2BB1E2022C; Thu, 19 Aug 2010 14:26:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3ED0443FA; Thu, 19 Aug 2010 14:26:21 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4C659AB9.4080007@sunet.se> <4C66BA51.1020704@dcrocker.net> <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> <20100819180841.GU14409@oracle.com> Date: Thu, 19 Aug 2010 14:26:21 -0400 In-Reply-To: <20100819180841.GU14409@oracle.com> (Nicolas Williams's message of "Thu, 19 Aug 2010 13:08:42 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:25:53 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Here's my proposed text, to be slotted into the constraints section, Nicolas> preferably right after the first paragraph of that section: Nicolas> Note that in order to be usable in all current Internet protocols, Nicolas> GSS-API mechanism must provide the following features: Nicolas> mutual s/GSS-API/GSS-API or SASL Nicolas> authentication, key confirmation, host-based service naming, Nicolas> per-message tokens ("security layers") and channel binding. Support Nicolas> for GSS_Pseudo_random() is desirable, and generally feasible whenever Nicolas> per-message tokens are supported. As a result, all of those features Nicolas> are required for GSS-API mechanisms produced by this WG. I'd like to add: Other application integration strategies are very likely to mirror these Nicolas> constraints. In particular, mutual authentication and Nicolas> support for channel binding are likely to be important for Nicolas> defense against phishing attacks. --Sam Nicolas> Nico Nicolas> -- From Nicolas.Williams@oracle.com Thu Aug 19 11:32:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699E93A697F for ; Thu, 19 Aug 2010 11:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.049, 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 K1WdSwZFLw9K for ; Thu, 19 Aug 2010 11:32:45 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3FF1C3A67F1 for ; Thu, 19 Aug 2010 11:32:45 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7JIX30F012039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 18:33:07 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 o7JBXkEk008287; Thu, 19 Aug 2010 18:33:00 GMT Received: from abhmt010.oracle.com by acsmt353.oracle.com with ESMTP id 513020151282242757; Thu, 19 Aug 2010 11:32:37 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 19 Aug 2010 11:32:37 -0700 Date: Thu, 19 Aug 2010 13:32:32 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100819183231.GW14409@oracle.com> References: <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> <20100819180841.GU14409@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) Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:32:46 -0000 On Thu, Aug 19, 2010 at 02:26:21PM -0400, Sam Hartman wrote: > Nicolas> Here's my proposed text, to be slotted into the constraints section, > Nicolas> preferably right after the first paragraph of that section: > > I'd like to add: > > Other application integration strategies are very likely to mirror > these constraints. In particular, mutual authentication and support > for channel binding are likely to be important for defense against > phishing attacks. Agreed. Also, I think it's worth mentioning SASL/GS2 in the same paragraph. New text: Note that in order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for GSS_Pseudo_random() is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL applications, which can use GSS-API mechanisms through GS2. Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. Nico -- From hartmans@painless-security.com Thu Aug 19 11:35:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A83643A697B for ; Thu, 19 Aug 2010 11:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 ltTCKyz2Cl4C for ; Thu, 19 Aug 2010 11:35:22 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id F3E243A6974 for ; Thu, 19 Aug 2010 11:35:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4EA542022C; Thu, 19 Aug 2010 14:35:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2939843FA; Thu, 19 Aug 2010 14:35:45 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> <20100819180841.GU14409@oracle.com> <20100819183231.GW14409@oracle.com> Date: Thu, 19 Aug 2010 14:35:45 -0400 In-Reply-To: <20100819183231.GW14409@oracle.com> (Nicolas Williams's message of "Thu, 19 Aug 2010 13:32:32 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, dcrocker@bbiw.net Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:35:23 -0000 This text looks good to me. From leifj@sunet.se Fri Aug 20 01:06:54 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922683A6918 for ; Fri, 20 Aug 2010 01:06:54 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgq-cIYeM5eS for ; Fri, 20 Aug 2010 01:06:53 -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 97CDA3A689E for ; Fri, 20 Aug 2010 01:06:51 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7K87NUA028749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2010 10:07:25 +0200 (CEST) Message-ID: <4C6E37BB.2090105@sunet.se> Date: Fri, 20 Aug 2010 10:07:23 +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: "abfab@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------080300090906060600090701" Subject: [abfab] charter take 4 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:06:54 -0000 This is a multi-part message in MIME format. --------------080300090906060600090701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - - Josh's modified intro with Hannes' polish. - - Final version (I hope) on overall WG scope - - Removed UI language (per Elliots suggestion) - - Eliots new language on SDO coordination with Scott's polish - - Mention applicability statements for EAP in constraints section (per Eliots suggestion) I've also drawn up an ambitious schedule in the deliverables section which divides the bulk of the work between the Beijing, Prague and Quebec time-frames. Wouldn't it be nice to set IETF records for focus and speed ;-) ? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxuN7oACgkQ8Jx8FtbMZnc7RQCfT67jVufagCfd/JkUJieR2J8k HKAAn2h6o4yI+Xm04UwUgmBRAMEUaJjM =EIvl -----END PGP SIGNATURE----- --------------080300090906060600090701 Content-Type: text/plain; name="abfab-charter-v4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="abfab-charter-v4.txt" Abfab Proposed Charter Abfab - Application Bridging for Federated Access Beyond web Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML) Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML is used for authorization and personalization. Any change in the choices for these three technical roles is out of scope for this charter. Constraints: ------------ Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC)and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ The deliverables of the working group are: * A document describing applicable use cases. (Dec 2010) * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (Dec 2010) * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011) * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case (May 2011) * A standards track solution for using EAP methods to provide authentication within the application (May 2011) * An update to the EMSK root key applicability statement in RFC 5295 (Aug 2011) * A standards-track description of GSS names and name attributes required by the solution (Aug 2011) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) --------------080300090906060600090701 Content-Type: application/octet-stream; name="abfab-charter-v4.txt.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="abfab-charter-v4.txt.sig" iEYEABECAAYFAkxuN7sACgkQ8Jx8FtbMZneCtgCeKxhMlUtULz/NLJbyPhX/tJZMif8An1vA gAaW/0g76jUcETvqCWL80QuJ --------------080300090906060600090701-- From leifj@sunet.se Fri Aug 20 01:43:44 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333F43A67A5 for ; Fri, 20 Aug 2010 01:43:44 -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 pf2n+X3zyOjy for ; Fri, 20 Aug 2010 01:43:43 -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 A98D33A68A9 for ; Fri, 20 Aug 2010 01:43:41 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7K8iDjb006906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 10:44:15 +0200 (CEST) Message-ID: <4C6E405D.7070902@sunet.se> Date: Fri, 20 Aug 2010 10:44:13 +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: Luke Howard References: <4C6E37BB.2090105@sunet.se> <8EC99B5B-D673-4C65-9E94-87A6016C726E@padl.com> In-Reply-To: <8EC99B5B-D673-4C65-9E94-87A6016C726E@padl.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 4 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:43:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 10:31 AM, Luke Howard wrote: > Hey Leif > > * A standards-track protocol for carrying SAML messages in RADIUS and > Diameter (Dec 2011) ah yes, it should be 2010 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxuQF0ACgkQ8Jx8FtbMZnejQACfQkQPjvJfs7fNsBebTkE4aKVR J5QAnRHMor+gJoBcvNvNTOVYyrmcQ5s/ =FHVR -----END PGP SIGNATURE----- From hartmans@painless-security.com Fri Aug 20 04:56:18 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBA63A6A08 for ; Fri, 20 Aug 2010 04:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 s1-uPY7gd9wc for ; Fri, 20 Aug 2010 04:56:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id DD8933A68AE for ; Fri, 20 Aug 2010 04:56:17 -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 07D03202E8; Fri, 20 Aug 2010 07:56:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B187F43FA; Fri, 20 Aug 2010 07:56:38 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4C6E37BB.2090105@sunet.se> Date: Fri, 20 Aug 2010 07:56:38 -0400 In-Reply-To: <4C6E37BB.2090105@sunet.se> (Leif Johansson's message of "Fri, 20 Aug 2010 10:07:23 +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: "abfab@ietf.org" Subject: Re: [abfab] charter take 4 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:56:18 -0000 >>>>> "Leif" == Leif Johansson writes: You seem to have dropped Nico's input from yesterday. Leif> I've also drawn up an ambitious schedule in the deliverables Leif> section which divides the bulk of the work between the Beijing, Leif> Prague and Quebec time-frames. Wouldn't it be nice to set IETF Leif> records for focus and speed ;-) ? The schedule does not belong in the deliverables section. The deliverables are part of the charter body and limit the scope of the WG's output; changing them requires a recharter. The schedule belongs in a milestones section, which requires chair and AD approval to change. Because of this, the milestones almost always duplicate the deliverables. I'd prefer a charter with Nico's final text from yesterday. I can live with this charter. From leifj@sunet.se Fri Aug 20 05:10:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A2E53A6A8B for ; Fri, 20 Aug 2010 05:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRIfeVMsHfhs for ; Fri, 20 Aug 2010 05:10:26 -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 5D7233A6A18 for ; Fri, 20 Aug 2010 05:10:25 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7KCAv5N027347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Aug 2010 14:10:59 +0200 (CEST) Message-ID: <4C6E70D1.1000000@sunet.se> Date: Fri, 20 Aug 2010 14:10:57 +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: Sam Hartman References: <4C6E37BB.2090105@sunet.se> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 4 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 12:10:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 01:56 PM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > You seem to have dropped Nico's input from yesterday. > > Leif> I've also drawn up an ambitious schedule in the deliverables > Leif> section which divides the bulk of the work between the Beijing, > Leif> Prague and Quebec time-frames. Wouldn't it be nice to set IETF > Leif> records for focus and speed ;-) ? > > The schedule does not belong in the deliverables section. The > deliverables are part of the charter body and limit the scope of the > WG's output; changing them requires a recharter. The schedule belongs > in a milestones section, which requires chair and AD approval to change. > Because of this, the milestones almost always duplicate the > deliverables. Point taken! > > I'd prefer a charter with Nico's final text from yesterday. I can live > with this charter. I confess I missed his proposal. Will dig through email for it. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxucNEACgkQ8Jx8FtbMZneDHgCgowm+FJ+RCzVqdja+mlRa9sOw FiYAnj4H7ebBQNJxnntqY9aLP4wysZr4 =UrDQ -----END PGP SIGNATURE----- From leifj@sunet.se Fri Aug 20 06:51:04 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835563A69D8 for ; Fri, 20 Aug 2010 06:51:04 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t69TGqmnch0W for ; Fri, 20 Aug 2010 06:51:03 -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 2AC873A69AC for ; Fri, 20 Aug 2010 06:51:02 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7KDpXm1003800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Aug 2010 15:51:36 +0200 (CEST) Message-ID: <4C6E8865.6060808@sunet.se> Date: Fri, 20 Aug 2010 15:51:33 +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: abfab@ietf.org References: <4C69CDEE.2010006@dcrocker.net> <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> <20100819180841.GU14409@oracle.com> <20100819183231.GW14409@oracle.com> In-Reply-To: <20100819183231.GW14409@oracle.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:51:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/19/2010 08:32 PM, Nicolas Williams wrote: > Note that in order to be usable in all current Internet protocols, > GSS-API mechanism must provide the following features: mutual > authentication, key confirmation, host-based service naming, > per-message tokens ("security layers") and channel binding. Support > for GSS_Pseudo_random() is desirable, and generally feasible whenever > per-message tokens are supported. As a result, all of those features > are required for GSS-API mechanisms produced by this WG. Note also > that some of these requirements derive from SASL applications, which > can use GSS-API mechanisms through GS2. Other application > integration strategies are very likely to mirror these constraints. > In particular, host-based service naming, mutual authentication and > support for channel binding are likely to be important for defense > against phishing attacks. I'm probably missing something, but why does this not belong in a problem-statement draft instead of in the charter? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxuiGUACgkQ8Jx8FtbMZncGgACeIEzg4ztaTxfH7uR3k3Pn/OJl 9qsAn1qmCPTyGQTgYH5f1QDoumc3TkbX =j/b6 -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Fri Aug 20 09:30:21 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC293A6A8C for ; Fri, 20 Aug 2010 09:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.049, 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 6+BTqmqg1N3U for ; Fri, 20 Aug 2010 09:30:10 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DFB6F3A6ABC for ; Fri, 20 Aug 2010 09:29:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7KGUBkG019492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Aug 2010 16:30:13 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 o7KCBToW002483; Fri, 20 Aug 2010 16:30:11 GMT Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 535646441282321810; Fri, 20 Aug 2010 09:30:10 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 Aug 2010 09:30:09 -0700 Date: Fri, 20 Aug 2010 11:29:38 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20100820162938.GA17097@oracle.com> References: <20100819170113.GN14409@oracle.com> <20100819171523.GP14409@oracle.com> <4C6D6799.4060703@dcrocker.net> <20100819172310.GR14409@oracle.com> <20100819180841.GU14409@oracle.com> <20100819183231.GW14409@oracle.com> <4C6E8865.6060808@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6E8865.6060808@sunet.se> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 3 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:30:22 -0000 On Fri, Aug 20, 2010 at 03:51:33PM +0200, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/19/2010 08:32 PM, Nicolas Williams wrote: > > Note that in order to be usable in all current Internet protocols, > > GSS-API mechanism must provide the following features: mutual > > authentication, key confirmation, host-based service naming, > > per-message tokens ("security layers") and channel binding. Support > > for GSS_Pseudo_random() is desirable, and generally feasible whenever > > per-message tokens are supported. As a result, all of those features > > are required for GSS-API mechanisms produced by this WG. Note also > > that some of these requirements derive from SASL applications, which > > can use GSS-API mechanisms through GS2. Other application > > integration strategies are very likely to mirror these constraints. > > In particular, host-based service naming, mutual authentication and > > support for channel binding are likely to be important for defense > > against phishing attacks. > > I'm probably missing something, but why does this not belong in a > problem-statement draft instead of in the charter? This is about constraints on the output of the WG. Therefore it seems to me that it belongs in the constraints section. The problem statement needs to (and IIRC does) mention the GSS-API connection, but why burden the reader of the problem statement with a lengthy paragraph regarding constraints? Nico -- From leifj@sunet.se Mon Aug 23 00:12:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69383A6951 for ; Mon, 23 Aug 2010 00:12:36 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqa-qoitEUWg for ; Mon, 23 Aug 2010 00:12:35 -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 D184B3A67CC for ; Mon, 23 Aug 2010 00:12:34 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7N7D2Kj019505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Aug 2010 09:13:05 +0200 (CEST) Message-ID: <4C721F7E.9080900@sunet.se> Date: Mon, 23 Aug 2010 09:13:02 +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: Sam Hartman References: <4C6E37BB.2090105@sunet.se> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 4 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 07:12:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 01:56 PM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > You seem to have dropped Nico's input from yesterday. > > Leif> I've also drawn up an ambitious schedule in the deliverables > Leif> section which divides the bulk of the work between the Beijing, > Leif> Prague and Quebec time-frames. Wouldn't it be nice to set IETF > Leif> records for focus and speed ;-) ? > > The schedule does not belong in the deliverables section. The > deliverables are part of the charter body and limit the scope of the > WG's output; changing them requires a recharter. The schedule belongs > in a milestones section, which requires chair and AD approval to change. > Because of this, the milestones almost always duplicate the > deliverables. > > I'd prefer a charter with Nico's final text from yesterday. I can live > with this charter. I would like more statements of support or dissent for this item. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxyH34ACgkQ8Jx8FtbMZnfkxQCgkm8y0cFebDgbxb2M5sRORjUp g0EAoMGfRzKRAgXrmJ31X2BU3t/eFR2A =uVM0 -----END PGP SIGNATURE----- From simon@josefsson.org Mon Aug 23 01:15:56 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764CD3A69B4 for ; Mon, 23 Aug 2010 01:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwYJKgMLh0Ru for ; Mon, 23 Aug 2010 01:15:45 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id B5D323A69A2 for ; Mon, 23 Aug 2010 01:15:43 -0700 (PDT) Received: from mocca (c80-216-27-64.bredband.comhem.se [80.216.27.64]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7N8GCJv012080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Aug 2010 10:16:13 +0200 From: Simon Josefsson To: Leif Johansson References: <4C6E37BB.2090105@sunet.se> <4C721F7E.9080900@sunet.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100823:abfab@ietf.org::/luROTQ5syBCXS67:Bay5 X-Hashcash: 1:22:100823:hartmans@painless-security.com::KnPbEbto0zVtpok5:AYAg X-Hashcash: 1:22:100823:leifj@sunet.se::ODACBNonu8A9422m:PYeZ Date: Mon, 23 Aug 2010 10:16:10 +0200 In-Reply-To: <4C721F7E.9080900@sunet.se> (Leif Johansson's message of "Mon, 23 Aug 2010 09:13:02 +0200") Message-ID: <87occtsq0l.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.1 at yxa-v X-Virus-Status: Clean Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 4 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:15:56 -0000 Leif Johansson writes: > On 08/20/2010 01:56 PM, Sam Hartman wrote: >>>>>>> "Leif" == Leif Johansson writes: >> You seem to have dropped Nico's input from yesterday. >> >> Leif> I've also drawn up an ambitious schedule in the deliverables >> Leif> section which divides the bulk of the work between the Beijing, >> Leif> Prague and Quebec time-frames. Wouldn't it be nice to set IETF >> Leif> records for focus and speed ;-) ? >> >> The schedule does not belong in the deliverables section. The >> deliverables are part of the charter body and limit the scope of the >> WG's output; changing them requires a recharter. The schedule belongs >> in a milestones section, which requires chair and AD approval to change. >> Because of this, the milestones almost always duplicate the >> deliverables. >> >> I'd prefer a charter with Nico's final text from yesterday. I can live >> with this charter. > > I would like more statements of support or dissent for this item. I also liked Nico's text. It may lead to rejecting weaker solutions, but if the need for weaker solutions is strong enough, the charter could be updated to include them eventually. However, I would prefer to focus on a secure solution with good properties now and worry about any compromise proposals later on. /Simon From leifj@sunet.se Tue Aug 24 12:19:06 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC953A693B for ; Tue, 24 Aug 2010 12:19:06 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y7fb5SPyvup for ; Tue, 24 Aug 2010 12:19:05 -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 CFD273A688F for ; Tue, 24 Aug 2010 12:19:04 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7OJJXGi014680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Aug 2010 21:19:36 +0200 (CEST) Message-ID: <4C741B45.6030702@sunet.se> Date: Tue, 24 Aug 2010 21:19:33 +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: "abfab@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------050900080105030406030204" Subject: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 19:19:06 -0000 This is a multi-part message in MIME format. --------------050900080105030406030204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a version with Nicos GSS-API contraints folded in. I've left the Goals and Milestones folded into in the Deliverables section - we can separate them when we reach consensus on the charter. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx0G0AACgkQ8Jx8FtbMZneKmQCfX5TZSGP/9BaAzRPyLiZ7OwRd shAAoI2VKW/lBWfPK8z0vIwmp0wj4HWm =1yeG -----END PGP SIGNATURE----- --------------050900080105030406030204 Content-Type: text/plain; name="abfab-charter-v5.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="abfab-charter-v5.txt" Abfab Proposed Charter Abfab - Application Bridging for Federated Access Beyond web Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML) Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML is used for authorization and personalization. Any change in the choices for these three technical roles is out of scope for this charter. Constraints: ------------ Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for GSS_Pseudo_random() is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL applications, which can use GSS-API mechanisms through GS2. Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC)and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ The deliverables of the working group are: * A document describing applicable use cases. (Dec 2010) * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (Dec 2010) * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011) * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case (May 2011) * A standards track solution for using EAP methods to provide authentication within the application (May 2011) * An update to the EMSK root key applicability statement in RFC 5295 (Aug 2011) * A standards-track description of GSS names and name attributes required by the solution (Aug 2011) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) --------------050900080105030406030204 Content-Type: application/octet-stream; name="abfab-charter-v5.txt.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="abfab-charter-v5.txt.sig" iEYEABECAAYFAkx0G0QACgkQ8Jx8FtbMZned0wCffR9NY1k2DuxsUYetMvHN1Tb6iU4AoKPz g1NJEKnLFEDs8Iu8YJH/9meQ --------------050900080105030406030204-- From Nicolas.Williams@oracle.com Tue Aug 24 12:54:40 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A393A683E for ; Tue, 24 Aug 2010 12:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 4FB0aX1HIbBP for ; Tue, 24 Aug 2010 12:54:39 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3D6893A68E3 for ; Tue, 24 Aug 2010 12:54:39 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7OJt8Br001644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Aug 2010 19:55:10 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 o7OHZTA8018389; Tue, 24 Aug 2010 19:55:08 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 527412811282679645; Tue, 24 Aug 2010 12:54:05 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Aug 2010 12:54:05 -0700 Date: Tue, 24 Aug 2010 14:54:00 -0500 From: Nicolas Williams To: Leif Johansson Message-ID: <20100824195359.GE17097@oracle.com> References: <4C741B45.6030702@sunet.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C741B45.6030702@sunet.se> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 19:54:40 -0000 On Tue, Aug 24, 2010 at 09:19:33PM +0200, Leif Johansson wrote: > Abfab - Application Bridging for Federated Access Beyond web I only have nits, and they're not really worth exploring (e.g., the second sentence of the first paragraph could be replaced with "This is needed for scalability.", but I don't mind all that extra verbiage :). We might need more RFC references in this paragraph: - GSS_Pseudo_random() [RFC4401] - SASL [RFC4422] - GS2 [RFC5801] > In order to be usable in all current Internet protocols, GSS-API > [...] > > The working group will ensure that any solution developed has technical > controls for privacy protection. Presumably that's privacy of protection only for the client/initiator/ user identity and attributes, protection from eavesdroppers. > The deliverables of the working group are: The GSS mechanism itself is missing from this list! :) Otherwise it looks good to me. Cheers, Nico -- From lear@cisco.com Tue Aug 24 13:23:51 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369533A6A64 for ; Tue, 24 Aug 2010 13:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 U2EwnISO5e2m for ; Tue, 24 Aug 2010 13:23:50 -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 343C33A6A5C for ; Tue, 24 Aug 2010 13:23:50 -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: Av0EALbHc0xAZnwN/2dsb2JhbACDF50icaFMiV6SFIEigyJzBIl4 X-IronPort-AV: E=Sophos;i="4.56,264,1280707200"; d="scan'208";a="151442601" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 24 Aug 2010 20:24:23 +0000 Received: from dhcp-10-55-92-238.cisco.com (dhcp-10-55-92-238.cisco.com [10.55.92.238]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7OKOMQt022769; Tue, 24 Aug 2010 20:24:22 GMT Message-ID: <4C742A81.9090506@cisco.com> Date: Tue, 24 Aug 2010 22:24:33 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Leif Johansson References: <4C741B45.6030702@sunet.se> In-Reply-To: <4C741B45.6030702@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 20:23:51 -0000 I'm sorry I couldn't comment sooner, Leif, and while I can live with what is proposed, I do think discussion of particular functions such as GSS_Pseudo_random() is really getting us WAY into the weeds. Do we have to NOW have the discussion of just when GSS_pseudo_random() is appropriate? That seems like a working group item. As such, I prefer "take 4". Eliot On 8/24/10 9:19 PM, Leif Johansson wrote: > > This is a version with Nicos GSS-API contraints folded in. I've left the > Goals and Milestones folded into in the Deliverables section - we can > separate them when we reach consensus on the charter. > > Cheers Leif _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From Nicolas.Williams@oracle.com Tue Aug 24 13:39:44 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1343A6837 for ; Tue, 24 Aug 2010 13:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 MSp1GgZWiHfH for ; Tue, 24 Aug 2010 13:39:16 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 388DC3A683E for ; Tue, 24 Aug 2010 13:38:11 -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.2) with ESMTP id o7OKcaAj031135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Aug 2010 20:38:38 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 o7O9hE4c004951; Tue, 24 Aug 2010 20:38:36 GMT Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 545552351282682238; Tue, 24 Aug 2010 13:37:18 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 24 Aug 2010 13:37:18 -0700 Date: Tue, 24 Aug 2010 15:37:13 -0500 From: Nicolas Williams To: Eliot Lear Message-ID: <20100824203712.GG17097@oracle.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C742A81.9090506@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2010 20:39:44 -0000 On Tue, Aug 24, 2010 at 10:24:33PM +0200, Eliot Lear wrote: > I'm sorry I couldn't comment sooner, Leif, and while I can live with > what is proposed, I do think discussion of particular functions such as > GSS_Pseudo_random() is really getting us WAY into the weeds. Do we have > to NOW have the discussion of just when GSS_pseudo_random() is > appropriate? That seems like a working group item. As such, I prefer > "take 4". That paragraph is carefully worded. It does not say that GSS_Pseudo_random() is required; GSS_Pseudo_random() is optional. That paragraph does list the other GSS-API features that are required. Those features are required because the Internet application protocols that the WG is targeting that use the GSS-API... require those features. Listing those features that are required by such applications is rather useful: it helps explain that the requirements discussed in earlier threads on this list are neither capricious nor constructed in such a way as to keep specific technologies out of scope -- these requirements are an indirect result of the stated primary goal. Dispensing with these requirements would require abandoning that goal. Without stating those requirements the WG will re-live such threads. I much prefer take 5 to take 4, and not just because I contributed that paragraph. Now, I'd not oppose removing the bit about GSS_Pseudo_random(). But it is a useful reminder for the authors that there's really no good excuse to not provide it given that the necessary key exchange is also an implied requirement of per-message token ("security layers") support. If you disagree with specific requirements listed in that paragraph, then we should discuss that. But if you don't, then why remove that paragraph? Nico -- From leifj@sunet.se Wed Aug 25 00:23:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179E53A695A for ; Wed, 25 Aug 2010 00:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMybBlY6NVoB for ; Wed, 25 Aug 2010 00:23:05 -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 804823A6948 for ; Wed, 25 Aug 2010 00:23:04 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7P7NVZM019923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 09:23:33 +0200 (CEST) Message-ID: <4C74C4F3.5070501@sunet.se> Date: Wed, 25 Aug 2010 09:23:31 +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: Nicolas Williams References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> In-Reply-To: <20100824203712.GG17097@oracle.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:23:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/24/2010 10:37 PM, Nicolas Williams wrote: > On Tue, Aug 24, 2010 at 10:24:33PM +0200, Eliot Lear wrote: >> I'm sorry I couldn't comment sooner, Leif, and while I can live with >> what is proposed, I do think discussion of particular functions such as >> GSS_Pseudo_random() is really getting us WAY into the weeds. Do we have >> to NOW have the discussion of just when GSS_pseudo_random() is >> appropriate? That seems like a working group item. As such, I prefer >> "take 4". > > That paragraph is carefully worded. It does not say that > GSS_Pseudo_random() is required; GSS_Pseudo_random() is optional. That > paragraph does list the other GSS-API features that are required. Those > features are required because the Internet application protocols that > the WG is targeting that use the GSS-API... require those features. > > Listing those features that are required by such applications is rather > useful: it helps explain that the requirements discussed in earlier > threads on this list are neither capricious nor constructed in such a > way as to keep specific technologies out of scope -- these requirements > are an indirect result of the stated primary goal. Dispensing with > these requirements would require abandoning that goal. > > Without stating those requirements the WG will re-live such threads. > > I much prefer take 5 to take 4, and not just because I contributed that > paragraph. > > Now, I'd not oppose removing the bit about GSS_Pseudo_random(). But it > is a useful reminder for the authors that there's really no good excuse > to not provide it given that the necessary key exchange is also an > implied requirement of per-message token ("security layers") support. > > If you disagree with specific requirements listed in that paragraph, > then we should discuss that. But if you don't, then why remove that > paragraph? > > Nico Strictly speaking as a participant and in no way as any other kind of animal, real, fictional or mythological I am inclined to agree with Eliot. To me it sounds like part of a very good requirements document for the GSS-API interface which *begs* to be written by Nico :-) I'd be inclined to include _some_ text in the charter to state something along the lines of "The WG must seek guidance on any work on GSS-API mechanisms from the KITTEN working group." This is analogous with our other coordination requirements. However I am also dis-inclined to re-open this can of worms. I am also worried that we're loosing our audience! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx0xPMACgkQ8Jx8FtbMZndKfwCgg61JqCl6Pd2qxGyBEH7YNAIN ku8AoMozrIJDySQjwiKgFtzLz3VRd3aX =Sc4p -----END PGP SIGNATURE----- From lear@cisco.com Wed Aug 25 02:23:38 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64D13A6828 for ; Wed, 25 Aug 2010 02:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.313 X-Spam-Level: X-Spam-Status: No, score=-110.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 0paHEYym3pkN for ; Wed, 25 Aug 2010 02:23:37 -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 A0D5B3A685E for ; Wed, 25 Aug 2010 02:23:37 -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: Av0EAId+dExAZnwM/2dsb2JhbACDF50rcZ9diV6SOIEigyJzBIoD X-IronPort-AV: E=Sophos;i="4.56,267,1280707200"; d="scan'208";a="151643973" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2010 09:24:10 +0000 Received: from dhcp-10-61-110-169.cisco.com (dhcp-10-61-110-169.cisco.com [10.61.110.169]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7P9O9MA023290; Wed, 25 Aug 2010 09:24:09 GMT Message-ID: <4C74E145.1030506@cisco.com> Date: Wed, 25 Aug 2010 11:24:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Nicolas Williams References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> In-Reply-To: <20100824203712.GG17097@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 09:23:38 -0000 On 8/24/10 10:37 PM, Nicolas Williams wrote: > If you disagree with specific requirements listed in that paragraph, > then we should discuss that. But if you don't, then why remove that > paragraph? > Because this is precisely the discussion that should happen IN the working group when there is more code and more experience. We are meant to have a starting point, Nico, and not an end point. And while I agree that we should have constraints on the group, saying that we would begin with a set of documents and that the basis of the work will be GS2/EAP, to me covers the ground adequately. Engineering inside the charter can be taken too far. Eliot From klaas@cisco.com Wed Aug 25 04:46:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7043A6986 for ; Wed, 25 Aug 2010 04:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXLwKBtJNeGa for ; Wed, 25 Aug 2010 04:46:23 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9C8CF3A6AB2 for ; Wed, 25 Aug 2010 04:46:23 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAqgdExAZnwM/2dsb2JhbACgQnGeSpwThTcEigM X-IronPort-AV: E=Sophos;i="4.56,267,1280707200"; d="scan'208";a="151504280" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2010 11:46:56 +0000 Received: from klaas-wierengas-macbook-air-2.local ([144.254.202.228]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PBktxD001557 for ; Wed, 25 Aug 2010 11:46:55 GMT Message-ID: <4C7502AE.8010108@cisco.com> Date: Wed, 25 Aug 2010 13:46:54 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: abfab@ietf.org References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> In-Reply-To: <4C74C4F3.5070501@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 11:46:24 -0000 On 8/25/10 9:23 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/24/2010 10:37 PM, Nicolas Williams wrote: >> On Tue, Aug 24, 2010 at 10:24:33PM +0200, Eliot Lear wrote: >>> I'm sorry I couldn't comment sooner, Leif, and while I can live with >>> what is proposed, I do think discussion of particular functions such as >>> GSS_Pseudo_random() is really getting us WAY into the weeds. Do we have >>> to NOW have the discussion of just when GSS_pseudo_random() is >>> appropriate? That seems like a working group item. As such, I prefer >>> "take 4". >> >> That paragraph is carefully worded. It does not say that >> GSS_Pseudo_random() is required; GSS_Pseudo_random() is optional. That >> paragraph does list the other GSS-API features that are required. Those >> features are required because the Internet application protocols that >> the WG is targeting that use the GSS-API... require those features. >> >> Listing those features that are required by such applications is rather >> useful: it helps explain that the requirements discussed in earlier >> threads on this list are neither capricious nor constructed in such a >> way as to keep specific technologies out of scope -- these requirements >> are an indirect result of the stated primary goal. Dispensing with >> these requirements would require abandoning that goal. >> >> Without stating those requirements the WG will re-live such threads. >> >> I much prefer take 5 to take 4, and not just because I contributed that >> paragraph. >> >> Now, I'd not oppose removing the bit about GSS_Pseudo_random(). But it >> is a useful reminder for the authors that there's really no good excuse >> to not provide it given that the necessary key exchange is also an >> implied requirement of per-message token ("security layers") support. >> >> If you disagree with specific requirements listed in that paragraph, >> then we should discuss that. But if you don't, then why remove that >> paragraph? >> >> Nico > > Strictly speaking as a participant and in no way as any other kind of > animal, real, fictional or mythological I am inclined to agree with > Eliot. > > To me it sounds like part of a very good requirements document for > the GSS-API interface which *begs* to be written by Nico :-) > > I'd be inclined to include _some_ text in the charter to state something > along the lines of "The WG must seek guidance on any work on GSS-API > mechanisms from the KITTEN working group." This is analogous > with our other coordination requirements. > > However I am also dis-inclined to re-open this can of worms. > > I am also worried that we're loosing our audience! I would prefer to leave the first bit that talks about functional requirements (mutual authentication, key confirmation etc.) in (the "what" we want to achieve) and remove the implementation requirements (GSS_Pseudo_random etc., the "how" we want to achieve that). I think the latter is typical something that should be discussed in the WG rather than beforehand. Klaas From hartmans@painless-security.com Wed Aug 25 05:08:59 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E65D83A6B05 for ; Wed, 25 Aug 2010 05:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 9BRqLLvxpEyb for ; Wed, 25 Aug 2010 05:08:59 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 04B633A6AE4 for ; Wed, 25 Aug 2010 05:08:58 -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 3E2E220008; Wed, 25 Aug 2010 08:09:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 322024831; Wed, 25 Aug 2010 08:09:11 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> Date: Wed, 25 Aug 2010 08:09:11 -0400 In-Reply-To: <4C74E145.1030506@cisco.com> (Eliot Lear's message of "Wed, 25 Aug 2010 11:24:21 +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: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:09:00 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> On 8/24/10 10:37 PM, Nicolas Williams wrote: >> If you disagree with specific requirements listed in that paragraph, >> then we should discuss that. But if you don't, then why remove that >> paragraph? >> Eliot> Because this is precisely the discussion that should happen IN the Eliot> working group when there is more code and more experience. We are meant Eliot> to have a starting point, Nico, and not an end point. And while I agree Eliot> that we should have constraints on the group, saying that we would begin Eliot> with a set of documents and that the basis of the work will be GS2/EAP, Eliot> to me covers the ground adequately. Engineering inside the charter can Eliot> be taken too far. Eliot, you're doing a great job of convincing me that we need to be When Nico proposed this text, I thought it was kind of redundant; I thought we were all agreed there. These requirements are things that three people very familiar with GSS have wanted: Simon, Nico and myself. I know for myself that if we work on something that does not meet these constraints I'd consider the work somewhere between completely useless and actively harmful. So, to me, these are the sort of constraints that affect whether the work is worth doing. I agree the text is verbose, and I'd like to avoid saying it in the charter. However, this is exactly a discussion I don't want to have in the WG because it strikes at whether the resulting mechanism will be useful from a security standpoint and at what our scope is. I'm not trying to close down discussion. I'm trying to say that if there is disagreement on this issue it should be handled with the greatest urgency--before we get started. So, I'd like to explore why you believe the discussion should happen in the WG? Do you believe we lack the necessary expertise here? Do you believe that these may not be requirements for our work being useful? From hartmans@painless-security.com Wed Aug 25 05:12:57 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835463A6A7A for ; Wed, 25 Aug 2010 05:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 VwO-ZTNYI4d8 for ; Wed, 25 Aug 2010 05:12:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B7E1A3A68BB for ; Wed, 25 Aug 2010 05:12:56 -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 8E68020008; Wed, 25 Aug 2010 08:13:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9C4C84831; Wed, 25 Aug 2010 08:13:11 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> Date: Wed, 25 Aug 2010 08:13:11 -0400 In-Reply-To: <4C7502AE.8010108@cisco.com> (Klaas Wierenga's message of "Wed, 25 Aug 2010 13:46:54 +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: abfab@ietf.org Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:12:57 -0000 >>>>> "Klaas" == Klaas Wierenga writes: Klaas> I would prefer to leave the first bit that talks about functional Klaas> requirements (mutual authentication, key confirmation etc.) in (the Klaas> "what" we want to achieve) and remove the implementation requirements Klaas> (GSS_Pseudo_random etc., the "how" we want to achieve that). I think Klaas> the latter is typical something that should be discussed in the WG Klaas> rather than beforehand. Can you propose exact text? This might work for me. From lear@cisco.com Wed Aug 25 05:35:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D1D3A6AB2 for ; Wed, 25 Aug 2010 05:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.326 X-Spam-Level: X-Spam-Status: No, score=-110.326 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 rZG28XMrl3hU for ; Wed, 25 Aug 2010 05:35:25 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id CD3D03A6824 for ; Wed, 25 Aug 2010 05:35:24 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJaqdExAZnwN/2dsb2JhbACDF50scZ5OiV6SLoEigyJzBIoD X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151518046" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2010 12:35:43 +0000 Received: from dhcp-10-61-110-169.cisco.com (dhcp-10-61-110-169.cisco.com [10.61.110.169]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7PCZgqa026897; Wed, 25 Aug 2010 12:35:43 GMT Message-ID: <4C750E2B.9070703@cisco.com> Date: Wed, 25 Aug 2010 14:35:55 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:35:28 -0000 Sam, I for one don't understand why a specific PRN call interface needs to be specified at all. Even calling this specific interface guarantees you nothing by way of PRN quality. If someone is really concerned, they're going to have to go under the hood anyway. And so perhaps you or Nico could explain precisely WHY it needs to be in the charter, as opposed to in a document, and even if it's going in a document at least a brief explanation would be in order. Again, I think we're going WAY TOO FAR (not a little- WAY TOO FAR) which leads to the sort of bureaucratic silliness when problems are found with an approach down the road. This would be like adding into Applications Area charter the specific names of commands to be used with their specific connotations. Nobody does that because it's unnecessary. Eliot On 8/25/10 2:09 PM, Sam Hartman wrote: >>>>>> "Eliot" == Eliot Lear writes: > Eliot> On 8/24/10 10:37 PM, Nicolas Williams wrote: > >> If you disagree with specific requirements listed in that paragraph, > >> then we should discuss that. But if you don't, then why remove that > >> paragraph? > >> > > Eliot> Because this is precisely the discussion that should happen IN the > Eliot> working group when there is more code and more experience. We are meant > Eliot> to have a starting point, Nico, and not an end point. And while I agree > Eliot> that we should have constraints on the group, saying that we would begin > Eliot> with a set of documents and that the basis of the work will be GS2/EAP, > Eliot> to me covers the ground adequately. Engineering inside the charter can > Eliot> be taken too far. > > > Eliot, you're doing a great job of convincing me that we need to be When > Nico proposed this text, I thought it was kind of redundant; I thought > we were all agreed there. > > These requirements are things that three people very familiar with GSS > have wanted: Simon, Nico and myself. > > I know for myself that if we work on something that does not meet these > constraints I'd consider the work somewhere between completely useless > and actively harmful. So, to me, these are the sort of constraints that > affect whether the work is worth doing. > > I agree the text is verbose, and I'd like to avoid saying it in the > charter. However, this is exactly a discussion I don't want to have in > the WG because it strikes at whether the resulting mechanism will be > useful from a security standpoint and at what our scope is. I'm not > trying to close down discussion. I'm trying to say that if there is > disagreement on this issue it should be handled with the greatest > urgency--before we get started. > > So, I'd like to explore why you believe the discussion should happen in > the WG? Do you believe we lack the necessary expertise here? Do you > believe that these may not be requirements for our work being useful? > From klaas@cisco.com Wed Aug 25 05:58:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EC53A6AE3 for ; Wed, 25 Aug 2010 05:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fblwnsUlmnWs for ; Wed, 25 Aug 2010 05:58:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 797CF3A6995 for ; Wed, 25 Aug 2010 05:58:42 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH+wdExAZnwM/2dsb2JhbACgRHGfB5wMhTcEigM X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151525891" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2010 12:59:15 +0000 Received: from klaas-wierengas-macbook-air-2.local ([144.254.202.228]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PCxE1X001472; Wed, 25 Aug 2010 12:59:14 GMT Message-ID: <4C7513A1.6020009@cisco.com> Date: Wed, 25 Aug 2010 14:59:13 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 12:58:46 -0000 On 8/25/10 2:13 PM, Sam Hartman wrote: >>>>>> "Klaas" == Klaas Wierenga writes: > > Klaas> I would prefer to leave the first bit that talks about functional > Klaas> requirements (mutual authentication, key confirmation etc.) in (the > Klaas> "what" we want to achieve) and remove the implementation requirements > Klaas> (GSS_Pseudo_random etc., the "how" we want to achieve that). I think > Klaas> the latter is typical something that should be discussed in the WG > Klaas> rather than beforehand. > > Can you propose exact text? This might work for me. I'd propose: "In order to defend against phishing attacks GSS-API mechanism must provide host-based service naming, mutual authentication and support for channel binding" In combination with Leif's suggestion: "The WG must seek guidance on any work on GSS-API mechanisms from the KITTEN working group." I am not so sure about the host-based service naming requirement, but am happy to trust your guidance on this. Klaasd From hartmans@painless-security.com Wed Aug 25 06:29:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F653A69A2 for ; Wed, 25 Aug 2010 06:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, 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 4ieCBNm2DngS for ; Wed, 25 Aug 2010 06:29:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 298E33A69AC for ; Wed, 25 Aug 2010 06:29: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 87F97202C7; Wed, 25 Aug 2010 09:29:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 70E4A4831; Wed, 25 Aug 2010 09:29:24 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> Date: Wed, 25 Aug 2010 09:29:24 -0400 In-Reply-To: <4C750E2B.9070703@cisco.com> (Eliot Lear's message of "Wed, 25 Aug 2010 14:35:55 +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: "abfab@ietf.org" , Nicolas Williams Subject: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 13:29:13 -0000 I'm noticing that the folks who have worked with GSS-API seem more comfortable with Nico's text than the rest of the community. Let me go through Nico's requirements and explain why they're needed in order to accomplish our goals. * Mutual authentication: Required by RFC 4462 in order to work with SSH and RFC 5801 for XMPP, SMTP, IMAP, LDAD, and the like. You introduce MITM attacks for CALDAV, WEBDAV, ATOM and the like if you use GSS to authenticate without mutual authentication. * Channel binding: required by RFC 5801 if we want to support IMAP, XMPP, LDAP, and the like. * Per-message security services (gss_wrap, gss_get_mic, the like): Required by RFC 4462 if we want to support SSH. Required by NFS. Required by CIFS. \ * Host based service naming: Required by RFc 4462 for ssh, RFC 5801 for XMPP, IMAP, SMTP, and the like. Required for CALDAV, WEBDAV, ATOM, and the HTTP protocols. Required by NFS. Probably required by CIFS although that's more complicated. * gss_pseudo_random: Required by some of the JANET applications and by RXGK, the AFS distributed filesystem security class. This is less of a requirement than the previous items, although once you have per-message security, gss_pseudo_random is trivial. * key confirmation: Required for channel binding to provide meaningful security. So, if we don't meet Nico's requirements then we cannot actually work with most of the applications we want to work with. However, for me, that's not the most important motivation. I've been working on security systems that are more resistant to phishing than the web for a long time. These technical requirements will meet the higher level requirements necessary to provide the technical aspects of good phishing defense. It happens these requirements are a fairly good mapping of the most important issues discussed in draft-hartman-webauth-phishing to non-web applications. So, that's why I personally care a lot about these issues and whether these are going to be part of the solution significantly affects how good of an idea I think doing the work is. I can totally appreciate that someone might disagree with me, but I hope you can understand why I care about the issue. From hartmans@painless-security.com Wed Aug 25 06:38:40 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 656AE3A69A2 for ; Wed, 25 Aug 2010 06:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 QyDjKY-G9XcJ for ; Wed, 25 Aug 2010 06:38:39 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8D3393A6989 for ; Wed, 25 Aug 2010 06:38:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 46EF3202C7; Wed, 25 Aug 2010 09:39:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 16C844831; Wed, 25 Aug 2010 09:38:50 -0400 (EDT) From: Sam Hartman To: Klaas Wierenga References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> <4C7513A1.6020009@cisco.com> Date: Wed, 25 Aug 2010 09:38:50 -0400 In-Reply-To: <4C7513A1.6020009@cisco.com> (Klaas Wierenga's message of "Wed, 25 Aug 2010 14:59:13 +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: abfab@ietf.org Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 13:38:40 -0000 >>>>> "Klaas" == Klaas Wierenga writes: Klaas> I'd propose: Klaas> "In order to defend against phishing attacks GSS-API Klaas> mechanism must provide host-based service naming, mutual Klaas> authentication and support for channel binding" Your text is insufficient to work with SSH, NFS, or CIFS. How about: In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens and channel binding. As a result, all of those features are required for GSS-API and SASL mechanisms produced by this WG. Support for GSS_Pseudo_random() is desirable. Other application integration strategies are very likely to mirror these constraints. In particular, service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. Klaas> In combination with Leif's suggestion: Klaas> "The WG must seek guidance on any work on GSS-API Klaas> mechanisms from the KITTEN working group." I don't think this constraint is needed: I think we have sufficient GSS expertise, but can live with it if consensus requires it. Klaas> I am not so sure about the host-based service naming requirement, but Klaas> am happy to trust your guidance on this. It didn't have to be host-based,except that we need to work with deployed code. From lear@cisco.com Wed Aug 25 06:40:01 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 294923A67E5 for ; Wed, 25 Aug 2010 06:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.338 X-Spam-Level: X-Spam-Status: No, score=-110.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 mD57XG4cG0ms for ; Wed, 25 Aug 2010 06:40:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 397B33A69A2 for ; Wed, 25 Aug 2010 06:40:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANO5dExAZnwM/2dsb2JhbACDF50tcZ87iV6SL4EigyJzBIoD X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151548100" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2010 13:40:31 +0000 Received: from dhcp-10-61-110-169.cisco.com (dhcp-10-61-110-169.cisco.com [10.61.110.169]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PDeUcQ026528; Wed, 25 Aug 2010 13:40:31 GMT Message-ID: <4C751D5A.7060809@cisco.com> Date: Wed, 25 Aug 2010 15:40:42 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 13:40:01 -0000 Sam, Perhaps our differences are fairly small then. When I go down your list, I agree with everything you've written at the high level, with one exception: On 8/25/10 3:29 PM, Sam Hartman wrote: > > I'm noticing that the folks who have worked with GSS-API seem more > comfortable with Nico's text than the rest of the community. > Let me go through Nico's requirements and explain why they're needed in > order to accomplish our goals. > > * Mutual authentication Absolutely. > * Channel binding I agree as long as we have a clear understanding of what is being bound. > * Per-message security services I *probably* agree. > (gss_wrap, gss_get_mic, the like): > Required by RFC 4462 if we want to support SSH. Required by > NFS. Required by CIFS. > \ > * Host based service naming At a minimum. > * gss_pseudo_random: Here's the test as to whether it should be in the charter– If I *DON'T* implement it, will you notice on the other side? If not, what's all the commotion? > * key confirmation Ok. See how close we are?! From hartmans@painless-security.com Wed Aug 25 07:01:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26D73A69E9 for ; Wed, 25 Aug 2010 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 twq78M+HL4QI for ; Wed, 25 Aug 2010 07:01:50 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C757E3A6ABC for ; Wed, 25 Aug 2010 07:01:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4E5DE204BA; Wed, 25 Aug 2010 10:02:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 204E14831; Wed, 25 Aug 2010 10:02:04 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> Date: Wed, 25 Aug 2010 10:02:04 -0400 In-Reply-To: <4C751D5A.7060809@cisco.com> (Eliot Lear's message of "Wed, 25 Aug 2010 15:40:42 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 14:01:54 -0000 >>>>> "Eliot" == Eliot Lear writes: >> * Channel binding Eliot> I agree as long as we have a clear understanding of what is being bound. I think we're talking about RFC 5554 and RFC 5056. >> * gss_pseudo_random: Eliot> Here's the test as to whether it should be in the charter– If I *DON'T* Eliot> implement it, will you notice on the other side? If not, what's all the Eliot> commotion? First, while I'd like to end up with this requirement, this is definitely the area where compromise is easiest. However, let me explain what it does then you'll perhaps agree it is desirable. The idea behind gss_pseudo_random is that once you have GSS set up, both sides can get the same value out of gss_pseudo_random. So, assume you have some other cryptographic protocol--you want to encrypt some media, or do something else. Your other protocol works with preshared keys but doesn't handle authentication. Without actually exchanging the key, you can call gss_pseudo_random on both sides and get the same key to fall out. It's a way of safely using the fact that you have a GSS-API context to get good cryptographic keys for other purposes without adding round trips. So, it's absolutely critical that both sides ends up with the same value or the later crypto fails. You might ask whether it would be simpler to just have a function to give the application the GSS-API context key to do with as it liked. It turns out that's bad from a crypto design standpoint: the key might not be of the right format and using the same key for different purposes introduces problems. gss_pseudo_random is relatively easy to use and provides protection against these problems. The down side to gss_pseudo_random is that it's not widely used today. The main reason for that is that it was specified after most applications already supported GSS-API. So it took a long time to get implemented for Kerberos. At this point, you could use it in a new application for Kerberos and have a high enough chance it would be available that it might be worth doing. (You'd have to do extra work on Windows, but that work is possible). See draft-howlett-radsec-kmp for one of a couple of examples of how Moonshot plans to use gss_pseudo_random. From Nicolas.Williams@oracle.com Wed Aug 25 07:36:20 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19903A6A47 for ; Wed, 25 Aug 2010 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 By6+j00f1cqZ for ; Wed, 25 Aug 2010 07:36:14 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3A88A3A69EB for ; Wed, 25 Aug 2010 07:36:13 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PEafmQ019034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 14:36:43 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 o7P5HPuB008621; Wed, 25 Aug 2010 14:36:40 GMT Received: from abhmt014.oracle.com by acsmt353.oracle.com with ESMTP id 530486501282746963; Wed, 25 Aug 2010 07:36:03 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 07:36:00 -0700 Date: Wed, 25 Aug 2010 09:35:52 -0500 From: Nicolas Williams To: Eliot Lear Message-ID: <20100825143552.GK17097@oracle.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C751D5A.7060809@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 14:36:20 -0000 On Wed, Aug 25, 2010 at 03:40:42PM +0200, Eliot Lear wrote: > Sam, > > Perhaps our differences are fairly small then. When I go down your > list, I agree with everything you've written at the high level, with one > exception: > > On 8/25/10 3:29 PM, Sam Hartman wrote: > > > > I'm noticing that the folks who have worked with GSS-API seem more > > comfortable with Nico's text than the rest of the community. > > Let me go through Nico's requirements and explain why they're needed in > > order to accomplish our goals. > > > > * Mutual authentication > > Absolutely. > > > * Channel binding > > I agree as long as we have a clear understanding of what is being bound. RFCs 5056 and 5929. > > * Per-message security services > > I *probably* agree. Without that you lose SSHv2 and NFSv4 support, for example (and GSS-TSIG, and SMB, and...). > > (gss_wrap, gss_get_mic, the like): > > Required by RFC 4462 if we want to support SSH. Required by > > NFS. Required by CIFS. > > \ > > * Host based service naming > > At a minimum. Oh, indeed, it certinly shouldn't be a maximum! There's also domain-based service names, and we can always introduce new types of names. > > * gss_pseudo_random: > > Here's the test as to whether it should be in the charter– If I *DON'T* > implement it, will you notice on the other side? If not, what's all the > commotion? I called it optional. Sam mentions apps that need it, but none are Internet apps (i.e., IETF standards-track apps). What's the harm in listing this as optional? And why do you find it so onerous? > > * key confirmation > > Ok. > > See how close we are?! Very, evidently. I strongly agree with Sam that the paragraph in question needs to stay. Wordsmithing is OK, but the requirements and their rationale need to stay, and the debate over them needs to be had now (we've been having it). Nico -- From Nicolas.Williams@oracle.com Wed Aug 25 07:42:21 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3F43A6A41 for ; Wed, 25 Aug 2010 07:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 wn08LKzgUFCB for ; Wed, 25 Aug 2010 07:42:20 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A0D153A6A47 for ; Wed, 25 Aug 2010 07:42:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PEgogK005196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 14:42:52 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 o7P4DvLe027429; Wed, 25 Aug 2010 14:42:49 GMT Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 548054181282747349; Wed, 25 Aug 2010 07:42:29 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 07:42:28 -0700 Date: Wed, 25 Aug 2010 09:42:22 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100825144220.GL17097@oracle.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 14:42:21 -0000 On Wed, Aug 25, 2010 at 10:02:04AM -0400, Sam Hartman wrote: > >>>>> "Eliot" == Eliot Lear writes: > > >> * Channel binding > > Eliot> I agree as long as we have a clear understanding of what is being bound. > I think we're talking about RFC 5554 and RFC 5056. And RFC5929. > >> * gss_pseudo_random: > > Eliot> Here's the test as to whether it should be in the charter– If I *DON'T* > Eliot> implement it, will you notice on the other side? If not, what's all the > Eliot> commotion? > > First, while I'd like to end up with this requirement, this is > definitely the area where compromise is easiest. However, let me > explain what it does then you'll perhaps agree it is desirable. Your explanation is good, but it can be simplified: GSS_Pseudo_random() is a keyed PRNG, where the key derives from the same shared key material used for GSS per-message tokens (security layers). And the implementation story is wonderful: surely you'll want to re-use RFC4121's (Kerberos) per-message tokens, for why bother designing new ones? If so you'd also be happy to re-use RFC4402 (Kerberos' GSS_Pseudo_random()). Even if you don't want to re-use RFC4121/RFC4402, as long as you have key material shared between the GSS initiator and acceptor (which you need for security layers anyways), it's still trivial to derive a key for a keyed PRNG. Nico -- From lear@cisco.com Wed Aug 25 07:51:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE753A6B1E for ; Wed, 25 Aug 2010 07:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.349 X-Spam-Level: X-Spam-Status: No, score=-110.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 93+A9CKr73ET for ; Wed, 25 Aug 2010 07:51:51 -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 CA3B73A6B1B for ; Wed, 25 Aug 2010 07:51:50 -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: Av0EALLKdExAZnwM/2dsb2JhbACDF50tcZ9miV6SNoEigyJzBIoD X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151768750" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2010 14:52:23 +0000 Received: from dhcp-10-61-110-169.cisco.com (dhcp-10-61-110-169.cisco.com [10.61.110.169]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PEqMIm010388; Wed, 25 Aug 2010 14:52:22 GMT Message-ID: <4C752E32.1090806@cisco.com> Date: Wed, 25 Aug 2010 16:52:34 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Sam Hartman References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 14:51:53 -0000 Sam, Thanks for the explanation. But here's the thing: the specification for gss_pseudo_random doesn't actually explain the algorithmic transformation to get the pseudo-random data. The algorithm isn't standardized. How do two sides, then, end up with the same value? Eliot On 8/25/10 4:02 PM, Sam Hartman wrote: >>>>>> "Eliot" == Eliot Lear writes: > >> * Channel binding > > Eliot> I agree as long as we have a clear understanding of what is being bound. > I think we're talking about RFC 5554 and RFC 5056. > > >> * gss_pseudo_random: > > Eliot> Here's the test as to whether it should be in the charter– If I *DON'T* > Eliot> implement it, will you notice on the other side? If not, what's all the > Eliot> commotion? > > First, while I'd like to end up with this requirement, this is > definitely the area where compromise is easiest. However, let me > explain what it does then you'll perhaps agree it is desirable. > > The idea behind gss_pseudo_random is that once you have GSS set up, both > sides can get the same value out of gss_pseudo_random. So, assume you > have some other cryptographic protocol--you want to encrypt some media, > or do something else. Your other protocol works with preshared keys but > doesn't handle authentication. Without actually exchanging the key, you > can call gss_pseudo_random on both sides and get the same key to fall > out. It's a way of safely using the fact that you have a GSS-API > context to get good cryptographic keys for other purposes without adding > round trips. So, it's absolutely critical that both sides ends up with > the same value or the later crypto fails. > > You might ask whether it would be simpler to just have a function to > give the application the GSS-API context key to do with as it liked. It > turns out that's bad from a crypto design standpoint: the key might not > be of the right format and using the same key for different purposes > introduces problems. gss_pseudo_random is relatively easy to use and > provides protection against these problems. > > The down side to gss_pseudo_random is that it's not widely used today. > The main reason for that is that it was specified after most > applications already supported GSS-API. So it took a long time to get > implemented for Kerberos. At this point, you could use it in a new > application for Kerberos and have a high enough chance it would be > available that it might be worth doing. (You'd have to do extra work on > Windows, but that work is possible). See draft-howlett-radsec-kmp for > one of a couple of examples of how Moonshot plans to use > gss_pseudo_random. > From hartmans@painless-security.com Wed Aug 25 08:03:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A053A6B20 for ; Wed, 25 Aug 2010 08:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7L5Uic6AZ9d for ; Wed, 25 Aug 2010 08:03:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id D25C53A6B1F for ; Wed, 25 Aug 2010 08:03:27 -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 6DB09203CB; Wed, 25 Aug 2010 11:03:58 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 126924831; Wed, 25 Aug 2010 11:03:40 -0400 (EDT) From: Sam Hartman To: Eliot Lear References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> <4C752E32.1090806@cisco.com> Date: Wed, 25 Aug 2010 11:03:40 -0400 In-Reply-To: <4C752E32.1090806@cisco.com> (Eliot Lear's message of "Wed, 25 Aug 2010 16:52:34 +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: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:03:28 -0000 >>>>> "Eliot" == Eliot Lear writes: Eliot> Sam, Eliot> Thanks for the explanation. But here's the thing: the specification for Eliot> gss_pseudo_random doesn't actually explain the algorithmic Eliot> transformation to get the pseudo-random data. The algorithm isn't Eliot> standardized. How do two sides, then, end up with the same value? RFC 4401 provides the application interface. That isn't sufficient to get interop. RFc 4402 describes how to get interop for Kerberos. In particular, it says that you use the pseudo_random operation from your Kerberos encription type So, RFC 4402 tells to you to go read RFC 3961 and do roughly what that says. RFC 3961 does tell you how to get pseudo_random for DEs and 3DES. It sends you off to RFC 3962 for AES. The Kerberos RC4 RFC tells you how to do this for RC4. For GSS-EAP, we plan to inheret the above algorithm, although obviously that's up to the WG. Now, that is kind of a twisty mess of RFCs. We do have interoperability for this: draft-ietf-krb-wg-preauth-framework includes test vectors for krb-fx-cf2, which heavily depends on the RFC 3961 PRF. We did find some issues putting together those test vectors. One of those is that people found it to be a lot of specifications to wade through to get the bits they needed. So, it may well be that the Kerberos and GSS community have some work to do to make this easier to implement,but I am aware of three implementations of the RFC 3961 code and two implementations of RFC 4402. From klaas@cisco.com Wed Aug 25 08:07:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841303A6B14 for ; Wed, 25 Aug 2010 08:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 NklZBaIv3N+d for ; Wed, 25 Aug 2010 08:07:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2C95C3A6B0C for ; Wed, 25 Aug 2010 08:07:35 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAOrOdExAZnwM/2dsb2JhbACTJI0gcaAMnBiFNwSKAw X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151588832" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Aug 2010 15:08:07 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PF86qe019386 for ; Wed, 25 Aug 2010 15:08:07 GMT Message-ID: <4C7531D6.5010705@cisco.com> Date: Wed, 25 Aug 2010 17:08:06 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: abfab@ietf.org References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:07:36 -0000 On 8/25/10 3:29 PM, Sam Hartman wrote: Sam, Thanks for the explanation, very helpful to me at least! Klaas > I'm noticing that the folks who have worked with GSS-API seem more > comfortable with Nico's text than the rest of the community. > Let me go through Nico's requirements and explain why they're needed in > order to accomplish our goals. > > * Mutual authentication: Required by RFC 4462 in order to work with SSH > and RFC 5801 for XMPP, SMTP, IMAP, LDAD, and the like. You introduce > MITM attacks for CALDAV, WEBDAV, ATOM and the like if you use GSS to > authenticate without mutual authentication. > > * Channel binding: required by RFC 5801 if we want to support IMAP, > XMPP, LDAP, and the like. > > * Per-message security services (gss_wrap, gss_get_mic, the like): > Required by RFC 4462 if we want to support SSH. Required by > NFS. Required by CIFS. > \ > * Host based service naming: Required by RFc 4462 for ssh, RFC 5801 for > XMPP, IMAP, SMTP, and the like. Required for CALDAV, WEBDAV, ATOM, and > the HTTP protocols. Required by NFS. Probably required by CIFS > although that's more complicated. > > * gss_pseudo_random: Required by some of the JANET applications and by > RXGK, the AFS distributed filesystem security class. This is less of a > requirement than the previous items, although once you have > per-message security, gss_pseudo_random is trivial. > > * key confirmation: Required for channel binding to provide meaningful > security. > > So, if we don't meet Nico's requirements then we cannot actually work > with most of the applications we want to work with. > > However, for me, that's not the most important motivation. I've been > working on security systems that are more resistant to phishing than the > web for a long time. These technical requirements will meet the higher > level requirements necessary to provide the technical aspects of good > phishing defense. It happens these requirements are a fairly good > mapping of the most important issues discussed in > draft-hartman-webauth-phishing to non-web applications. So, that's why > I personally care a lot about these issues and whether these are going > to be part of the solution significantly affects how good of an idea I > think doing the work is. I can totally appreciate that someone might > disagree with me, but I hope you can understand why I care about the > issue. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Wed Aug 25 08:09:54 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D613A6B27 for ; Wed, 25 Aug 2010 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.882 X-Spam-Level: X-Spam-Status: No, score=-3.882 tagged_above=-999 required=5 tests=[AWL=-1.283, 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 KwZ78hGYwYN3 for ; Wed, 25 Aug 2010 08:09:53 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 8FE103A6B0A for ; Wed, 25 Aug 2010 08:09:53 -0700 (PDT) Received: by us.padl.com with ESMTP id o7PFADrW020178; Wed, 25 Aug 2010 11:10:18 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4C752E32.1090806@cisco.com> Date: Wed, 25 Aug 2010 17:10:16 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> <4C752E32.1090806@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:09:54 -0000 > Thanks for the explanation. But here's the thing: the specification for > gss_pseudo_random doesn't actually explain the algorithmic > transformation to get the pseudo-random data. The algorithm isn't > standardized. How do two sides, then, end up with the same value? It is specified in the concrete GSS mechanism specification. eg. RFC 4402 is for Kerberos. One would be specified here too. -- Luke From Nicolas.Williams@oracle.com Wed Aug 25 08:10:55 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446D73A6B33 for ; Wed, 25 Aug 2010 08:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 9vwMXpxGxKgq for ; Wed, 25 Aug 2010 08:10:51 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CF2D13A6B35 for ; Wed, 25 Aug 2010 08:10:50 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PFBLxt004878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 15:11:23 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 o7PElTq3017509; Wed, 25 Aug 2010 15:11:20 GMT Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 530646611282749072; Wed, 25 Aug 2010 08:11:12 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 08:11:09 -0700 Date: Wed, 25 Aug 2010 10:11:02 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20100825151101.GP17097@oracle.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> <20100825144220.GL17097@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100825144220.GL17097@oracle.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:10:55 -0000 I meant "PRF" not "PRNG". Please excuse that slip. From lear@cisco.com Wed Aug 25 08:14:53 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684D53A6B29 for ; Wed, 25 Aug 2010 08:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.359 X-Spam-Level: X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 rxIpsJloKMMr for ; Wed, 25 Aug 2010 08:14:52 -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 25E2D3A6A01 for ; Wed, 25 Aug 2010 08:14:52 -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: Av0EAI/QdExAZnwM/2dsb2JhbACDF50ucaATiV6SOoEigyJzBIoD X-IronPort-AV: E=Sophos;i="4.56,268,1280707200"; d="scan'208";a="151777838" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Aug 2010 15:15:24 +0000 Received: from dhcp-10-61-110-169.cisco.com (dhcp-10-61-110-169.cisco.com [10.61.110.169]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7PFFNsv022261; Wed, 25 Aug 2010 15:15:24 GMT Message-ID: <4C753397.20509@cisco.com> Date: Wed, 25 Aug 2010 17:15:35 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Luke Howard References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> <4C752E32.1090806@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:14:53 -0000 Ok. I officially Get It. If you want it in the charter, given that there IS interoperability work to be done, I'm cool with that. Thanks for your patience. Eliot On 8/25/10 5:10 PM, Luke Howard wrote: >> Thanks for the explanation. But here's the thing: the specification for >> gss_pseudo_random doesn't actually explain the algorithmic >> transformation to get the pseudo-random data. The algorithm isn't >> standardized. How do two sides, then, end up with the same value? > > It is specified in the concrete GSS mechanism specification. > > eg. RFC 4402 is for Kerberos. One would be specified here too. > > -- Luke > From Nicolas.Williams@oracle.com Wed Aug 25 08:20:02 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1413A6AFD for ; Wed, 25 Aug 2010 08:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 kzGg-xGz3jNp for ; Wed, 25 Aug 2010 08:20:01 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 295113A6A4F for ; Wed, 25 Aug 2010 08:20:01 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PFKSYP003810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 15:20:29 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 o7P33FSR015789; Wed, 25 Aug 2010 15:20:26 GMT Received: from abhmt016.oracle.com by acsmt354.oracle.com with ESMTP id 548180871282749580; Wed, 25 Aug 2010 08:19:40 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 08:19:37 -0700 Date: Wed, 25 Aug 2010 10:19:27 -0500 From: Nicolas Williams To: Luke Howard Message-ID: <20100825151926.GQ17097@oracle.com> References: <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74E145.1030506@cisco.com> <4C750E2B.9070703@cisco.com> <4C751D5A.7060809@cisco.com> <4C752E32.1090806@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) Cc: "abfab@ietf.org" , Eliot Lear Subject: Re: [abfab] Why we need Nico's text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:20:02 -0000 On Wed, Aug 25, 2010 at 05:10:16PM +0200, Luke Howard wrote: > > Thanks for the explanation. But here's the thing: the specification for > > gss_pseudo_random doesn't actually explain the algorithmic > > transformation to get the pseudo-random data. The algorithm isn't > > standardized. How do two sides, then, end up with the same value? > > > It is specified in the concrete GSS mechanism specification. > > eg. RFC 4402 is for Kerberos. One would be specified here too. And we'll almost certainly want to re-use Kerberos', just we'll almost certainly want to re-use Kebreros' per-message tokens. Re-use is a good thing. Now, I agree with Sam's point that we should work to make the generic bits of RFC4121 and RFC4402 more easily re-usable by re-packaging them into new specifications. Implementation-wise we should do the same. Implementation-wise it'd be nice to be able to break up, say, the MIT, and/or Heimdal, and/or Shishi, and/or... krb5 library and mechanism into these components: - re-usable crypto framework (RFC3961, RFC3962) - re-usable GSS internal context crypto bits: - re-usable GSS per-message tokens [RFC4121] - re-usable GSS PRF [RFC4121] - the rest of libkrb5 - the actual krb5 GSS mech so that the last two items could be left out of a distribution of a mechanism that re-uses RFC4121 tokens and RFC4402 PRF. Some implementations may be almost there to a large degree (at least as to the crypto framework). Nico -- From Nicolas.Williams@oracle.com Wed Aug 25 09:22:12 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137DA3A6B44 for ; Wed, 25 Aug 2010 09:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 TgI5lCpy7KqU for ; Wed, 25 Aug 2010 09:22:11 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 255883A6B28 for ; Wed, 25 Aug 2010 09:22:11 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PGMfWv027589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 16:22:43 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 o7PEmXBd022772; Wed, 25 Aug 2010 16:22:41 GMT Received: from abhmt016.oracle.com by acsmt353.oracle.com with ESMTP id 548401581282753306; Wed, 25 Aug 2010 09:21:46 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 09:21:46 -0700 Date: Wed, 25 Aug 2010 11:21:37 -0500 From: Nicolas Williams To: Klaas Wierenga Message-ID: <20100825162136.GX17097@oracle.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7502AE.8010108@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:22:12 -0000 On Wed, Aug 25, 2010 at 01:46:54PM +0200, Klaas Wierenga wrote: > I would prefer to leave the first bit that talks about functional > requirements (mutual authentication, key confirmation etc.) in (the > "what" we want to achieve) and remove the implementation > requirements (GSS_Pseudo_random etc., the "how" we want to achieve > that). I think the latter is typical something that should be > discussed in the WG rather than beforehand. I'm having trouble understanding the distinction between "functional requirements" and "implementation requirements". As far as the GSS-API is concerned, there's no functional/implementation difference between "mutual authentication" and "per-message tokens". They're all features. And they're all features that the relevant Internet applications require. My guess is that the fact that one of these features is called out by a [abstract] function name makes readers think it's an implementation detail. It's not. I should have said "PRF", and I'd bet (if I somehow could) that if I'd written "PRF" instead of the function's name then there'd have been no controversy. In fact, that's the change that I suggest: s/GSS_Pseudo_random/PRF/. Nico -- From hartmans@painless-security.com Wed Aug 25 09:30:13 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC533A6879 for ; Wed, 25 Aug 2010 09:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.012, 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 W-hFKvHYKnw6 for ; Wed, 25 Aug 2010 09:30:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 474083A6A43 for ; Wed, 25 Aug 2010 09:30:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 44DC82043A for ; Wed, 25 Aug 2010 12:30:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B80684831; Wed, 25 Aug 2010 12:30:16 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 25 Aug 2010 12:30:16 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] draft-howlett-eap-gss-00 is going to expire soon X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:30:13 -0000 I'm not entirely sure about what to do here. The charter explicitly calls out -00. Our thinking has changed somewhat and there are definitely changes we'd like to make to the WG. I'd sort of hoped to have those in the WG context. Should I just wait until we have a WG to resubmit and then discuss the changes? From leifj@sunet.se Wed Aug 25 10:13:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6DB3A6B29 for ; Wed, 25 Aug 2010 10:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0x38-64-lmw for ; Wed, 25 Aug 2010 10:13:03 -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 A91AA3A689E for ; Wed, 25 Aug 2010 10:13:01 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7PHDVQv001725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2010 19:13:34 +0200 (CEST) Message-ID: <4C754F3B.60306@sunet.se> Date: Wed, 25 Aug 2010 19:13:31 +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: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] draft-howlett-eap-gss-00 is going to expire soon X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:13:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2010 06:30 PM, Sam Hartman wrote: > > I'm not entirely sure about what to do here. The charter explicitly > calls out -00. Our thinking has changed somewhat and there are > definitely changes we'd like to make to the WG. I'd sort of hoped to > have those in the WG context. Should I just wait until we have a WG to > resubmit and then discuss the changes? What is soon? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkx1TzsACgkQ8Jx8FtbMZnfn2wCYiFEMIot4uLTre2X67bae/rap BgCgsWj+YY1fsCZQDont93rRnVEbgog= =xmCE -----END PGP SIGNATURE----- From klaas@cisco.com Wed Aug 25 10:48:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299FC3A6B5B for ; Wed, 25 Aug 2010 10:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Ei-DLA1IHeqG for ; Wed, 25 Aug 2010 10:48:45 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id C03FD3A6B58 for ; Wed, 25 Aug 2010 10:48:44 -0700 (PDT) Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=[10.55.220.245]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OoK5Q-000O3h-QX; Wed, 25 Aug 2010 19:48:33 +0200 References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> <20100825162136.GX17097@oracle.com> Message-Id: <5E493FDB-BB0A-42FC-B507-5F300289FD11@cisco.com> From: Klaas Wierenga To: Nicolas Williams In-Reply-To: <20100825162136.GX17097@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Wed, 25 Aug 2010 19:50:19 +0200 X-Antivirus: no malware found Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 17:48:46 -0000 Hi Nico, On Aug 25, 2010, at 6:23 PM, "Nicolas Williams" = wrote: > On Wed, Aug 25, 2010 at 01:46:54PM +0200, Klaas Wierenga wrote: >> I would prefer to leave the first bit that talks about functional >> requirements (mutual authentication, key confirmation etc.) in (the >> "what" we want to achieve) and remove the implementation >> requirements (GSS_Pseudo_random etc., the "how" we want to achieve >> that). I think the latter is typical something that should be >> discussed in the WG rather than beforehand. >=20 > I'm having trouble understanding the distinction between "functional > requirements" and "implementation requirements". Let me give an example from a technology area I am more familiar with, = 802.1X and EAP/RADIUS. Functional Requirement: mutual authentication of client and server=20 Technical Implementation: use EAP-TLS (for example) > As far as the GSS-API is concerned, there's no = functional/implementation > difference between "mutual authentication" and "per-message tokens". To me they are of a different order, mutual authentication states that = both ends of the communication need to be able to verify each others = identity, but not how. Whereas per-message tokens are a way of = implementing message integrity/confidentiality, presumably you could = achieve the latter also by using a per-flow token or something like = that. So per-message tokens are to me an implementation choice (with = obvious benefits).=20 Sam's explanation answered for me the question why we would require = these "implementation choices", namely to satisfy requirements from = existing protocols that we want to support with our solution. > They're all features. And they're all features that the relevant > Internet applications require. >=20 > My guess is that the fact that one of these features is called out by = a > [abstract] function name makes readers think it's an implementation > detail. It's not. I should have said "PRF", and I'd bet (if I = somehow > could) that if I'd written "PRF" instead of the function's name then > there'd have been no controversy. >=20 > In fact, that's the change that I suggest: s/GSS_Pseudo_random/PRF/. Actually that would work better for me, because more generic indeed, = though the question remains "why do we need PRF, what does it buy us?" Does this make more sense to you? Klaas=20= From leifj@sunet.se Wed Aug 25 13:15:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76653A6903 for ; Wed, 25 Aug 2010 13:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y488gq-xezdm for ; Wed, 25 Aug 2010 13:15:00 -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 62E403A6AD8 for ; Wed, 25 Aug 2010 13:14:56 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7PKFNS5020586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2010 22:15:28 +0200 (CEST) Message-ID: <4C7579DB.8070607@sunet.se> Date: Wed, 25 Aug 2010 22:15:23 +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: "abfab@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------040007040504060907010401" Subject: [abfab] charter take 6 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:15:07 -0000 This is a multi-part message in MIME format. --------------040007040504060907010401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just minor polish as the result of the discussion on GSS-API constraints. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1edYACgkQ8Jx8FtbMZnc8BQCgjG/qr5MjJmd4WAdxqthzMXfj 6zAAoLPLnHdDcqhXQDTpv6BobT4bD7sp =Pibt -----END PGP SIGNATURE----- --------------040007040504060907010401 Content-Type: text/plain; name="abfab-charter-v6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="abfab-charter-v6.txt" Abfab Proposed Charter Abfab - Application Bridging for Federated Access Beyond web Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML) Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML is used for authorization and personalization. Any change in the choices for these three technical roles is out of scope for this charter. Constraints: ------------ Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for PRF is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL applications, which can use GSS-API mechanisms through GS2. Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC)and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables / Goals and Milestones ----------------------------------- The deliverables of the working group are: * A document describing applicable use cases. (Dec 2010) * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (Dec 2010) * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011) * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case (May 2011) * A standards track solution for using EAP methods to provide authentication within the application (May 2011) * An update to the EMSK root key applicability statement in RFC 5295 (Aug 2011) * A standards-track description of GSS names and name attributes required by the solution (Aug 2011) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) --------------040007040504060907010401 Content-Type: application/octet-stream; name="abfab-charter-v6.txt.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="abfab-charter-v6.txt.sig" iEYEABECAAYFAkx1edsACgkQ8Jx8FtbMZnctXQCgx9NGr8gqiiyHLn0XkCirLCNIEugAmwQd 4t/WihziAIXA7QGttkWHIt64 --------------040007040504060907010401-- From rlmorgan@washington.edu Wed Aug 25 13:22:38 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322D33A6903 for ; Wed, 25 Aug 2010 13:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-5B0QoLsd1O for ; Wed, 25 Aug 2010 13:22:37 -0700 (PDT) Received: from mxout13.cac.washington.edu (mxout13.cac.washington.edu [140.142.32.202]) by core3.amsl.com (Postfix) with ESMTP id 40CEA3A68A7 for ; Wed, 25 Aug 2010 13:22:37 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.205] (may be forged)) by mxout13.cac.washington.edu (8.14.3+UW09.11/8.14.3+UW09.11) with ESMTP id o7PKKSYO008955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Aug 2010 13:20:28 -0700 X-Auth-Received: from D-140-142-21-28.dhcp4.washington.edu (D-140-142-21-28.dhcp4.washington.edu [140.142.21.28]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW09.11/8.14.3+UW09.11) with ESMTP id o7PKKS6c027457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 25 Aug 2010 13:20:28 -0700 Date: Wed, 25 Aug 2010 13:20:28 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@permafrost To: IETF abfab In-Reply-To: <4C741B45.6030702@sunet.se> Message-ID: References: <4C741B45.6030702@sunet.se> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.8.25.200620 X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, FROM_EDU_TLD 0, FROM_NAME_PHRASE 0, INVALID_MSGID_NO_FQDN 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __USER_AGENT 0' Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:22:38 -0000 Draft charter says: Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML is used for authorization and personalization. This SAML text seems insufficient. As far as I can tell there are no plans to use SAML protocol for anything, just SAML message formats encapsulated in RADIUS. And "used for authorization" is profoundly vague. I hope this vagueness is just due to lack of attention rather than lack of clarity on how SAML will be used. So perhaps better text is: ... and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. - RL "Bob" From Nicolas.Williams@oracle.com Wed Aug 25 13:32:21 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70A53A6903 for ; Wed, 25 Aug 2010 13:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 tsngP2RMJPwL for ; Wed, 25 Aug 2010 13:32:19 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6BA643A68D8 for ; Wed, 25 Aug 2010 13:32:19 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PKWmpR006201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 20:32:50 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 o7PInPor006715; Wed, 25 Aug 2010 20:32:48 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 531892561282768333; Wed, 25 Aug 2010 13:32:13 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 13:32:13 -0700 Date: Wed, 25 Aug 2010 15:32:08 -0500 From: Nicolas Williams To: Klaas Wierenga Message-ID: <20100825203208.GZ17097@oracle.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> <20100825162136.GX17097@oracle.com> <5E493FDB-BB0A-42FC-B507-5F300289FD11@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E493FDB-BB0A-42FC-B507-5F300289FD11@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:32:22 -0000 On Wed, Aug 25, 2010 at 07:50:19PM +0200, Klaas Wierenga wrote: > On Aug 25, 2010, at 6:23 PM, "Nicolas Williams" wrote: > > I'm having trouble understanding the distinction between "functional > > requirements" and "implementation requirements". > > Let me give an example from a technology area I am more familiar with, > 802.1X and EAP/RADIUS. > > Functional Requirement: mutual authentication of client and server > Technical Implementation: use EAP-TLS (for example) > > > As far as the GSS-API is concerned, there's no > > functional/implementation difference between "mutual authentication" > > and "per-message tokens". > > To me they are of a different order, mutual authentication states that > both ends of the communication need to be able to verify each others > identity, but not how. Whereas per-message tokens are a way of > implementing message integrity/confidentiality, presumably you could > achieve the latter also by using a per-flow token or something like > that. So per-message tokens are to me an implementation choice (with > obvious benefits). I don't know what "per-flow token" would be. There are only these choices in the GSS world: - per-message tokens - channel binding - nothing The last one, I think we'll all agree, is not a very good choice as the only required to implement option! Now, most GSS apps use per-message tokens, and most SASL apps will be using channel binding only (except for legacy GS1 implementations, which use and will continue to use per-message tokens). I don't see how we could say that we want this new mech to be usable in Internet GSS/SASL apps, say this requires mutual authentication, and not say that this requires per-message tokens (for some apps) and channel binding (for other apps). I think that'd be gaping hole in the requirements list. > Sam's explanation answered for me the question why we would require > these "implementation choices", namely to satisfy requirements from > existing protocols that we want to support with our solution. Right. But they are not implementation choices, they are specification choices; the choice was made when we chose to target those apps. An implementation choice would be to use a C/Java/Python/Ruby/C++/Perl5/ ECMAScript/PHP/Clojure/whatever function/method named anything like 'GSS_Pseudo_random'. That is completely beyond the scope of this WG. The string 'GSS_Pseudo_random' in this context denotes a GSS-API feature, much as GSS_Wrap and GSS_GetMIC would. > > In fact, that's the change that I suggest: s/GSS_Pseudo_random/PRF/. > > Actually that would work better for me, because more generic indeed, > though the question remains "why do we need PRF, what does it buy us?" Sure. > Does this make more sense to you? I understand the desire to s/GSS_Pseudo_random/PRF/. I don't quite understand the rest but I think the issue really is that GSS-API _abstract_ "function" (and type, and constant) names resemble implementation details in the sense of function/class/method/... names for specific programming languages. Rest assured: use of the _abstract_ GSS-API nomenclature implies no requirement for specific implementation choices regarding names, function/method signatures, etcetera in whatever programming language an implementor chooses. (I don't see why an implementor would not use straightforward [or standard, where there is one] bindings of the abstract GSS API to whatever programming language they are using, but hey, that's none of my business.) Nico -- From leifj@sunet.se Wed Aug 25 13:39:27 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E913A68C2 for ; Wed, 25 Aug 2010 13:39:27 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tVS4C1jEpFu for ; Wed, 25 Aug 2010 13:39:26 -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 F30333A6903 for ; Wed, 25 Aug 2010 13:39:24 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7PKdsbZ013484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Aug 2010 22:39:57 +0200 (CEST) Message-ID: <4C757F9A.9090606@sunet.se> Date: Wed, 25 Aug 2010 22:39:54 +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: abfab@ietf.org References: <4C741B45.6030702@sunet.se> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:39:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2010 10:20 PM, RL 'Bob' Morgan wrote: > and SAML message formats are used to carry subject information that > can be used for authorization and personalization by a relying party. I think this makes the text more readable and arguably more correct. I missed it for v6 but unless people have a problem with this it will go into the final (I'm being that optimistic tonight) version. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1f5oACgkQ8Jx8FtbMZnc5iQCfShCxLT8Vay9vvGEtn095Q58t t3AAoJS9uTNv3XS1kz75syXGA/Cu8vH1 =5zBw -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Wed Aug 25 13:43:24 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7B03A6B62 for ; Wed, 25 Aug 2010 13:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 ZiKE6AZgrxal for ; Wed, 25 Aug 2010 13:42:53 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A69763A6942 for ; Wed, 25 Aug 2010 13:42:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o7PKhMHM029598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 20:43:24 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 o7PKhH3R029761; Wed, 25 Aug 2010 20:43:18 GMT Received: from abhmt012.oracle.com by acsmt355.oracle.com with ESMTP id 531923611282768919; Wed, 25 Aug 2010 13:41:59 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Aug 2010 13:41:59 -0700 Date: Wed, 25 Aug 2010 15:41:54 -0500 From: Nicolas Williams To: "RL 'Bob' Morgan" Message-ID: <20100825204154.GA17097@oracle.com> References: <4C741B45.6030702@sunet.se> 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) Cc: IETF abfab Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:43:24 -0000 On Wed, Aug 25, 2010 at 01:20:28PM -0700, RL 'Bob' Morgan wrote: > > Draft charter says: > > Specifically EAP will be used to authenticate the subject to a trusted > party, AAA (RADIUS and Diameter) will be used to authenticate and convey > information from that party to a relying party and SAML is used for > authorization and personalization. > > This SAML text seems insufficient. As far as I can tell there are > no plans to use SAML protocol for anything, just SAML message > formats encapsulated in RADIUS. And "used for authorization" is > profoundly vague. I hope this vagueness is just due to lack of > attention rather than lack of clarity on how SAML will be used. So > perhaps better text is: > > ... and SAML message formats are used to carry subject information that > can be used for authorization and personalization by a relying party. I like your text. I think we could resolve the vagueness by relating these SAML assertions to GSS-API name attributes[*]. However, I fear that this might only serve to confuse those who don't have a deep background in the GSS-API. And either way, the point is that these can be used "for authorization and personalization by a relying party". Nico [*] For the benefit of those who aren't aware of it, "name" and "name attribute" (and "credential", and so on) have very specific meanings in the GSS-API world. A GSS "name" is actually an instance of an abstract API type called "NAME", and it represents a "principal" (a user, a host-based service, etcetera). A "name attribute" refers to attributes of a principal other than its "display name" (a display name is the string that a program would display to a user as being the name of a principal). Name attributes are not yet standard, though they are implemented in shipping products. I could go on. I really need to find the time to author a gentle introduction to the GSS-API as an Informational RFC. Given that this WG will bring a wider audience in contact with the GSS-API (and SASL), it's really about time I got around to that. From hartmans@painless-security.com Wed Aug 25 14:30:44 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2CBC3A6942 for ; Wed, 25 Aug 2010 14:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.012, 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 v-sw1fbelKQK for ; Wed, 25 Aug 2010 14:30:29 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 98F453A689B for ; Wed, 25 Aug 2010 14:30:25 -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 B3BA5203CB; Wed, 25 Aug 2010 17:30:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B24A94831; Wed, 25 Aug 2010 17:30:34 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4C741B45.6030702@sunet.se> <4C757F9A.9090606@sunet.se> Date: Wed, 25 Aug 2010 17:30:34 -0400 In-Reply-To: <4C757F9A.9090606@sunet.se> (Leif Johansson's message of "Wed, 25 Aug 2010 22:39:54 +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: abfab@ietf.org Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:30:44 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 08/25/2010 10:20 PM, RL 'Bob' Morgan wrote: >> and SAML message formats are used to carry subject information that >> can be used for authorization and personalization by a relying party. Leif> I think this makes the text more readable and arguably more correct. I Leif> missed it for v6 but unless people have a problem with this it will go Leif> into the final (I'm being that optimistic tonight) version. Well, we do plan to use the SAML attribute query protocol, and in the current drafts, it is possible to send a SAML authentication request. So, one could quibble about whether it's just SAML message formats or not. However we definitely are using SAML message formats and the rest of the text definitely adds clarity. So, I'm OK with it. From lukeh@padl.com Thu Aug 26 05:11:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09E93A6838 for ; Thu, 26 Aug 2010 05:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.962, 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 w4gefu1hvY6g for ; Thu, 26 Aug 2010 05:11:30 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 2DCF43A6973 for ; Thu, 26 Aug 2010 05:11:29 -0700 (PDT) Received: by us.padl.com with ESMTP id o7QC9bPe007352; Thu, 26 Aug 2010 08:11:56 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20100825204154.GA17097@oracle.com> Date: Thu, 26 Aug 2010 14:12:00 +0200 Content-Transfer-Encoding: 7bit Message-Id: <20F19C7E-9FCD-4C96-8DC1-36A0153BEC7B@padl.com> References: <4C741B45.6030702@sunet.se> <20100825204154.GA17097@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: IETF abfab Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:11:31 -0000 > I think we could resolve the vagueness by relating these SAML assertions > to GSS-API name attributes[*]. However, I fear that this might only Right, and isn't sorting this out part of the work to be accomplished? -- Luke From lukeh@padl.com Thu Aug 26 05:12:26 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742083A69D7 for ; Thu, 26 Aug 2010 05:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=-0.770, 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 isTsP0uTqhii for ; Thu, 26 Aug 2010 05:12:25 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 822E13A698C for ; Thu, 26 Aug 2010 05:12:25 -0700 (PDT) Received: by us.padl.com with ESMTP id o7QC9bPf007352; Thu, 26 Aug 2010 08:12:52 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20100825203208.GZ17097@oracle.com> Date: Thu, 26 Aug 2010 14:12:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <645C2786-6C68-4A33-AF6E-8EFF8FBBAEAD@padl.com> References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> <20100825162136.GX17097@oracle.com> <5E493FDB-BB0A-42FC-B507-5F300289FD11@cisco.com> <20100825203208.GZ17097@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.1 Cc: "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:12:26 -0000 > I don't quite understand the rest but I think the issue really is that > GSS-API _abstract_ "function" (and type, and constant) names resemble > implementation details in the sense of function/class/method/... names > for specific programming languages. Rest assured: use of the = _abstract_ > GSS-API nomenclature implies no requirement for specific = implementation > choices regarding names, function/method signatures, etcetera in > whatever programming language an implementor chooses. Right, if I had no prior GSS-API knowledge, I would likely be making the = same criticism. +1 for Nico's comments above. -- Luke= From klaas@cisco.com Thu Aug 26 05:35:23 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA1F3A6AF3 for ; Thu, 26 Aug 2010 05:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.337 X-Spam-Level: X-Spam-Status: No, score=-10.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 mBg8ZeA-btUj for ; Thu, 26 Aug 2010 05:35:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 668253A6AC4 for ; Thu, 26 Aug 2010 05:35:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABf8dUxAZnwN/2dsb2JhbACgQ3GeXJtfhTcEigI X-IronPort-AV: E=Sophos;i="4.56,273,1280707200"; d="scan'208";a="151945621" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Aug 2010 12:35:52 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7QCZq1o000643; Thu, 26 Aug 2010 12:35:52 GMT Message-ID: <4C765FA7.30105@cisco.com> Date: Thu, 26 Aug 2010 14:35:51 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Luke Howard References: <4C741B45.6030702@sunet.se> <4C742A81.9090506@cisco.com> <20100824203712.GG17097@oracle.com> <4C74C4F3.5070501@sunet.se> <4C7502AE.8010108@cisco.com> <20100825162136.GX17097@oracle.com> <5E493FDB-BB0A-42FC-B507-5F300289FD11@cisco.com> <20100825203208.GZ17097@oracle.com> <645C2786-6C68-4A33-AF6E-8EFF8FBBAEAD@padl.com> In-Reply-To: <645C2786-6C68-4A33-AF6E-8EFF8FBBAEAD@padl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , Nicolas Williams Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:35:23 -0000 On 8/26/10 2:12 PM, Luke Howard wrote: >> I don't quite understand the rest but I think the issue really is that >> GSS-API _abstract_ "function" (and type, and constant) names resemble >> implementation details in the sense of function/class/method/... names >> for specific programming languages. Rest assured: use of the _abstract_ >> GSS-API nomenclature implies no requirement for specific implementation >> choices regarding names, function/method signatures, etcetera in >> whatever programming language an implementor chooses. > > Right, if I had no prior GSS-API knowledge, I would likely be making the same criticism. > > +1 for Nico's comments above. ok, criticism "withdrawn" ;-) Klaas From Josh.Howlett@ja.net Thu Aug 26 09:07:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7C53A69E9 for ; Thu, 26 Aug 2010 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.409 X-Spam-Level: X-Spam-Status: No, score=-100.409 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_50=0.001, 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 S6EwGio-s5Gl for ; Thu, 26 Aug 2010 09:07:28 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id CD6333A69E3 for ; Thu, 26 Aug 2010 09:07:27 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 379604A6B32_C76915FB; Thu, 26 Aug 2010 16:07:59 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 24EB94A6B5C_C76915DF; Thu, 26 Aug 2010 16:07:57 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001.atlas.ukerna.ac.uk ([::1]) with mapi; Thu, 26 Aug 2010 17:08:06 +0100 From: Josh Howlett To: Sam Hartman , Leif Johansson Thread-Topic: [abfab] charter take 5 Thread-Index: AQHLRJzAZuq+TOGV+0e1guilWp9snZLz56JA Date: Thu, 26 Aug 2010 16:07:54 +0000 Message-ID: <40AC324AA6D81B4A8CF133BCFB7526E605930A@EXC001.atlas.ukerna.ac.uk> References: <4C741B45.6030702@sunet.se> <4C757F9A.9090606@sunet.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] charter take 5 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 16:07:28 -0000 > However we definitely are using SAML message formats and the rest of > the > text definitely adds clarity. > So, I'm OK with it. +1 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 hartmans@painless-security.com Fri Aug 27 07:29:08 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DC63A6908 for ; Fri, 27 Aug 2010 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, 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 o-j6sXe1m78f for ; Fri, 27 Aug 2010 07:29:07 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 034F43A6809 for ; Fri, 27 Aug 2010 07:29:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 950492043A for ; Fri, 27 Aug 2010 10:29:36 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3FC4A4761; Fri, 27 Aug 2010 10:29:14 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 27 Aug 2010 10:29:14 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:29:08 -0000 I've heard a distinct lack of screaming.. Are we done? From klaas@cisco.com Fri Aug 27 07:32:12 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 875353A6978 for ; Fri, 27 Aug 2010 07:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 JEju0BDsfT1c for ; Fri, 27 Aug 2010 07:32:06 -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 140EB3A696B for ; Fri, 27 Aug 2010 07:31:41 -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: AkQFAAJpd0xAZnwN/2dsb2JhbACTNI0lcZ95m36FNwSKCQ X-IronPort-AV: E=Sophos;i="4.56,278,1280707200"; d="scan'208";a="152606942" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Aug 2010 14:32:14 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8715.cisco.com [10.55.220.246]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7REWDnO018121 for ; Fri, 27 Aug 2010 14:32:13 GMT Message-ID: <4C77CC6D.70800@cisco.com> Date: Fri, 27 Aug 2010 16:32:13 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 14:32:12 -0000 On 8/27/10 4:29 PM, Sam Hartman wrote: Sam, > I've heard a distinct lack of screaming.. > Are we done? I believe so Klaas From leifj@sunet.se Fri Aug 27 08:56:35 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3963A6AAA for ; Fri, 27 Aug 2010 08:56:35 -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 pHWgqPw8KRvY for ; Fri, 27 Aug 2010 08:56:34 -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 AA06E3A6985 for ; Fri, 27 Aug 2010 08:56:31 -0700 (PDT) Received: from [78.78.28.252] ([78.78.28.252]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7RFut2K018984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Aug 2010 17:57:01 +0200 (CEST) Message-ID: <4C77E046.6090208@sunet.se> Date: Fri, 27 Aug 2010 17:56:54 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: abfab@ietf.org References: <4C77CC6D.70800@cisco.com> In-Reply-To: <4C77CC6D.70800@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------010208070508080208090403" Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 15:56:35 -0000 This is a multi-part message in MIME format. --------------010208070508080208090403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/2010 04:32 PM, Klaas Wierenga wrote: > On 8/27/10 4:29 PM, Sam Hartman wrote: > > Sam, > >> I've heard a distinct lack of screaming.. >> Are we done? > > I believe so I've sent the last version (attached) which includes RLBobs SAML text to Sean. Lets see what happens next... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx34EEACgkQ8Jx8FtbMZnflIwCggzVGpugESAXvoTh35D3sjim+ MSUAoLuq0oJKL0NMidkhBNin2q/kJfF2 =Qeqd -----END PGP SIGNATURE----- --------------010208070508080208090403 Content-Type: text/plain; name="abfab-charter-v6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="abfab-charter-v6.txt" Abfab Proposed Charter Abfab - Application Bridging for Federated Access Beyond web Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter. Constraints: ------------ Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for PRF is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL applications, which can use GSS-API mechanisms through GS2. Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC)and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables / Goals and Milestones ----------------------------------- The deliverables of the working group are: * A document describing applicable use cases. (Dec 2010) * An architecture document describing how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (Dec 2010) * A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011) * An update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case (May 2011) * A standards track solution for using EAP methods to provide authentication within the application (May 2011) * An update to the EMSK root key applicability statement in RFC 5295 (Aug 2011) * A standards-track description of GSS names and name attributes required by the solution (Aug 2011) * Informational descriptions of usability and user-interface concerns related to this work (Aug 2011) --------------010208070508080208090403 Content-Type: application/octet-stream; name="abfab-charter-v6.txt.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="abfab-charter-v6.txt.sig" iEYEABECAAYFAkx34EUACgkQ8Jx8FtbMZncS8gCgpuF+fJ474M421W6F2UIvD04VTlIAnRR9 1hcYjD5tAFh8sbdmVDi7sCGD --------------010208070508080208090403-- From simon@josefsson.org Fri Aug 27 12:10:18 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105BC3A6ABE for ; Fri, 27 Aug 2010 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gEzwk1jKrpb for ; Fri, 27 Aug 2010 12:10:08 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 427AC3A6A29 for ; Fri, 27 Aug 2010 12:10:07 -0700 (PDT) Received: from mocca (94.191.150.218.bredband.tre.se [94.191.150.218]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RJAQqm007904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Aug 2010 21:10:31 +0200 From: Simon Josefsson To: Leif Johansson References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100827:abfab@ietf.org::cgTwWOcYLmcJzbVf:6Re7 X-Hashcash: 1:22:100827:leifj@sunet.se::CMykEJZc3CCIiwgH:Ldkt Date: Fri, 27 Aug 2010 21:10:24 +0200 In-Reply-To: <4C77E046.6090208@sunet.se> (Leif Johansson's message of "Fri, 27 Aug 2010 17:56:54 +0200") Message-ID: <878w3rhnxb.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: abfab@ietf.org Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 19:10:18 -0000 Leif Johansson writes: > On 08/27/2010 04:32 PM, Klaas Wierenga wrote: >> On 8/27/10 4:29 PM, Sam Hartman wrote: >> >> Sam, >> >>> I've heard a distinct lack of screaming.. >>> Are we done? >> >> I believe so Me too. Nit picking: > Specifically EAP will be used to authenticate the subject to a trusted > party, AAA (RADIUS and Diameter) will be used to authenticate and convey > information from that party to a relying party and SAML and SAML message > formats are used to carry subject information that can be used for > authorization and personalization by a relying party. Any change in the > choices for these three technical roles is out of scope for this charter. I do not understand the last sentence. s/charter/WG/? The sentence seems redundant to me. Anything that is inconsistent with the WG charter is out of scope by definition? /Simon From leifj@mnt.se Sat Aug 28 02:57:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3AFE3A6853 for ; Sat, 28 Aug 2010 02:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fs7ZRDnruZR for ; Sat, 28 Aug 2010 02:57:27 -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 90B243A6850 for ; Sat, 28 Aug 2010 02:57:26 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7S9vtXp007643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Aug 2010 11:57:57 +0200 (CEST) Message-ID: <4C78DDA3.6020007@mnt.se> Date: Sat, 28 Aug 2010 11:57:55 +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: abfab@ietf.org References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <878w3rhnxb.fsf@mocca.josefsson.org> In-Reply-To: <878w3rhnxb.fsf@mocca.josefsson.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 09:57:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I do not understand the last sentence. s/charter/WG/? The sentence > seems redundant to me. Anything that is inconsistent with the WG > charter is out of scope by definition? > Replacing "charter" with "WG" is indeed a minor nit. The other point is not and it has been discussed at length on this list already. Personally I don't want to open up that can or worms again. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx43aMACgkQ8Jx8FtbMZnfsVgCgr4mrQFroLfIdJFRKDG6TkyOW zGwAoJxdS3rBdb0NNLLWmA88Ae2Y6OP/ =2yS9 -----END PGP SIGNATURE----- From simon@josefsson.org Sat Aug 28 07:54:21 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E813A67CC for ; Sat, 28 Aug 2010 07:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc6E+1atxEjJ for ; Sat, 28 Aug 2010 07:54: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 C6A883A68ED for ; Sat, 28 Aug 2010 07:54:20 -0700 (PDT) Received: from mocca (79.138.128.189.bredband.tre.se [79.138.128.189]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7SEsdp7009379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 28 Aug 2010 16:54:43 +0200 From: Simon Josefsson To: Leif Johansson References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <878w3rhnxb.fsf@mocca.josefsson.org> <4C78DDA3.6020007@mnt.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100828:leifj@mnt.se::yDvM07KrsFPM9l4A:EcJt X-Hashcash: 1:22:100828:abfab@ietf.org::V2bgaoM0t+Sx/CEP:HyfC Date: Sat, 28 Aug 2010 16:54:38 +0200 In-Reply-To: <4C78DDA3.6020007@mnt.se> (Leif Johansson's message of "Sat, 28 Aug 2010 11:57:55 +0200") Message-ID: <87eidioki9.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at yxa-v X-Virus-Status: Clean Cc: abfab@ietf.org Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 14:54:22 -0000 Leif Johansson writes: > Replacing "charter" with "WG" is indeed a minor nit. The other > point is not and it has been discussed at length on this list > already. Personally I don't want to open up that can or worms > again. Oops, I wasn't aware of that. Then I don't have any further comments on the charter. /Simon From hazelton@doit.wisc.edu Sat Aug 28 18:58:11 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FEA23A6934 for ; Sat, 28 Aug 2010 18:58:11 -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 BqTxzyArK5N0 for ; Sat, 28 Aug 2010 18:58:10 -0700 (PDT) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by core3.amsl.com (Postfix) with ESMTP id 41DDF3A6942 for ; Sat, 28 Aug 2010 18:58:09 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0L7W009005HTUU00@smtpauth3.wiscmail.wisc.edu> for abfab@ietf.org; Sat, 28 Aug 2010 20:58:41 -0500 (CDT) Received: from [10.0.1.3] (75-135-72-39.dhcp.mdsn.wi.charter.com [75.135.72.39]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0L7W007ST5HR0U10@smtpauth3.wiscmail.wisc.edu> for abfab@ietf.org; Sat, 28 Aug 2010 20:58:40 -0500 (CDT) Date: Sat, 28 Aug 2010 20:58:39 -0500 From: Keith Hazelton In-reply-to: <4C77E046.6090208@sunet.se> To: abfab Message-id: <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> X-Mailer: Apple Mail (2.1081) X-Spam-Score-Internal: ******* X-Spam-PmxInfo: Server=avs-13, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.8.29.14516, SenderIP=10.0.1.3 References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> X-Mailman-Approved-At: Sun, 29 Aug 2010 00:50:19 -0700 Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 01:58:11 -0000 I notice that all other delivery estimates are in chronological order. Should the following: "* A standards-track protocol for carrying SAML messages in RADIUS and Diameter (Dec 2011)" read Dec 2010? --Keith _______________ On Aug 27, 2010, at 10:56 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/27/2010 04:32 PM, Klaas Wierenga wrote: >> On 8/27/10 4:29 PM, Sam Hartman wrote: >> >> Sam, >> >>> I've heard a distinct lack of screaming.. >>> Are we done? >> >> I believe so > > I've sent the last version (attached) which includes RLBobs SAML text to > Sean. Lets see what happens next... > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkx34EEACgkQ8Jx8FtbMZnflIwCggzVGpugESAXvoTh35D3sjim+ > MSUAoLuq0oJKL0NMidkhBNin2q/kJfF2 > =Qeqd > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@mnt.se Sun Aug 29 00:52:18 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0EA3A67C2 for ; Sun, 29 Aug 2010 00:52:18 -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 qoMiXNSU6Pvi for ; Sun, 29 Aug 2010 00:52: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 20A823A67BE for ; Sun, 29 Aug 2010 00:52:16 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7T7qiXP010155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Aug 2010 09:52:47 +0200 (CEST) Message-ID: <4C7A11CC.5030003@mnt.se> Date: Sun, 29 Aug 2010 09:52:44 +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: abfab@ietf.org References: <4C77CC6D.70800@cisco.com> <4C77E046.6090208@sunet.se> <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> In-Reply-To: <6FD45918-3383-4EEE-B45B-25E576D3A9AC@doit.wisc.edu> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] So are we done? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 07:52:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2010 03:58 AM, Keith Hazelton wrote: > I notice that all other delivery estimates are in chronological order. Should the following: > > "* A standards-track protocol for carrying SAML messages in RADIUS and > Diameter (Dec 2011)" > > read Dec 2010? Yes, somebody already pointed that out and it will go into the published version. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx6EcwACgkQ8Jx8FtbMZndN0wCaA6SLNpkL+iRzUkq3QJca7D+1 xMgAmwZycF/hol04Md9rnv5hMPFYoDWf =fJFX -----END PGP SIGNATURE-----