From diameter-admin@frascone.com Sat Nov 1 06:02:06 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03861 for ; Sat, 1 Nov 2003 06:02:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A9255801F0 for ; Sat, 1 Nov 2003 05:02:14 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 71F1C5801BA for ; Sat, 1 Nov 2003 05:00:46 -0600 (CST) Date: Sat, 01 Nov 2003 05:00:46 -0600 Message-ID: <20031101110046.13736.15308.Mailman@wolverine> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.frascone.com To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, eap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com ohweow http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-admin@frascone.com Sun Nov 2 10:37:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18756 for ; Sun, 2 Nov 2003 10:37:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9CCC580027; Sun, 2 Nov 2003 09:37:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 42AF1580014; Sun, 2 Nov 2003 09:37:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57A2F580014 for ; Sun, 2 Nov 2003 09:36:42 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 08FA8580012 for ; Sun, 2 Nov 2003 09:36:41 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA2ExRs28195 for ; Sun, 2 Nov 2003 06:59:27 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP WG Last call on EAP State Machine draft Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 2 Nov 2003 06:59:27 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is to announce EAP WG Last Call on the EAP State Machine draft, prior to requesting IESG approval to publish it as an Informational RFC. The draft is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt EAP WG Last Call will complete on November 19, 2003. Please send your comments to eap@frascone.com, in the format recommended in the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 2 12:16:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20373 for ; Sun, 2 Nov 2003 12:16:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 418B1580012; Sun, 2 Nov 2003 11:17:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D21A1580018; Sun, 2 Nov 2003 11:17:01 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C207580018 for ; Sun, 2 Nov 2003 11:16:03 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C3B7C580012 for ; Sun, 2 Nov 2003 11:16:01 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA2GcmO01374 for ; Sun, 2 Nov 2003 08:38:48 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 190: Inconsistent capitalization Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 2 Nov 2003 08:38:48 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 190: Inconsistent Capitalization Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 11/2/2003 Reference: Document: RFC2284bis Comment type: 'E'ditorial Priority: '1' Should fix Section: Various Rationale/Explanation of issue: The term 'Code' is inconsistently capitalized. When this refers to the Code field in the EAP header, it should be capitalized. Also the term should not be used when referring to other fields, since this is confusing. Section 2.2: "EAP packets with codes of Success or Failure" => "EAP packets with Codes of Success or Failure" Section 5.7: "Expanded Nak and Legacy Nak packets share the same code, but must be treated differently because they have a different format." => "Expanded Nak and Legacy Nak packets share the same Type, but must be treated differently because they have a different format." Section 6.2: "Method Type 255 is allocated for Experimental use, such as testing of new EAP methods before a permanent Type code is allocated." => "Method Type 255 is allocated for Experimental use, such as testing of new EAP methods before a permanent Type is allocated." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 3 08:57:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01920 for ; Mon, 3 Nov 2003 08:57:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26C42580134; Mon, 3 Nov 2003 07:57:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE842580019; Mon, 3 Nov 2003 07:57:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9E17580019 for ; Mon, 3 Nov 2003 07:56:23 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 90CDD580017 for ; Mon, 3 Nov 2003 07:56:19 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA3DIsX07707 for ; Mon, 3 Nov 2003 05:18:57 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP WG agenda for IETF 58, Take Seven Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 3 Nov 2003 05:18:54 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Extensible Authentication Protocol (eap) WG Chair(s): Bernard Aboba Jari Arkko Monday, November 10, 2003 1930 - 2200 Preliminaries (10 minutes) Agenda Bashing Bluesheets Minutes Document Status Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html WG Work Items (70 minutes) ------------- RFC 2284bis (10 minutes), Henrik Lefkowetz http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-07.d.html EAP State Machine (20 minutes), Pasi Eronen http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt EAP Key Framework, Bernard Aboba (40 minutes) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt Drafts relating to WG work items (30 minutes) -------------------------------- Network Selection, Farid Adrangi (10 minutes) http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt EAP Key Derivation for Multiple Applications, Joe Salowey (10 minutes) http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt The Compound Binding Problem, Jose Puthenkulam (10 minutes) http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt EAP methods - Status & Issues (20 minutes) ----------------------------- PEAPv2, Jose Salowey (5 minutes) http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt EAP SIM/AKA, Pasi Eronen (5 minutes) http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt EAP Smartcard, Pascal Urien (5 minutes) http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt EAP-IKEv2, Hannes Tschofenig (5 minutes) http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-02.txt Roadmap (10 minutes), WG Chairs and ADs _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 3 11:10:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08518 for ; Mon, 3 Nov 2003 11:10:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AA5A580134; Mon, 3 Nov 2003 10:10:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EBB25580019; Mon, 3 Nov 2003 10:10:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFBCB580019 for ; Mon, 3 Nov 2003 10:09:26 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A63D3580017 for ; Mon, 3 Nov 2003 10:09:25 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3F36C6A904; Mon, 3 Nov 2003 18:09:23 +0200 (EET) Message-ID: <3FA67CB5.8020808@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com, "Puthenkulam, Jose P" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] binding draft issues 64, 65, 70, 88, 89, 123, new1, new2 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 03 Nov 2003 18:05:09 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have taken a look at the issues I filed earlier on the binding draft and their resolution in the new documents. I'm fine with the resolutions of issues 88, 89, 123 which I filed myself or were filed by my colleagues. I'm also personally fine with the resolutions of the other open issues 64, 65, 70, though it would be better if Bernard and Dan could also confirm that they are OK with them. In addition, I have performed a new review of the draft version 04, with the comments available at: http://www.piuha.net/~jarkko/publications/eap/binding-04-review.txt Most of these issues are editorial in nature, and I think that the document is in general in relatively good shape. However, one bigger issue is whether section 4 should stay in the document -- currently it goes into quite deep level of detail including specific format extensions of PEAP, which itself isn't and RFC. I would suggest deleting section 4 and only keep a some key general parts from it. For Bernard's issue list, I'll provide below two separate issues, the editorial and section4 issues: Submitter name: Jari Arkko Submitter email address: jarkko@piuha.net Date first submitted: Nov 3, 2003 Reference: http://www.piuha.net/~jarkko/publications/eap/binding-04-review.txt Document: EAP Binding Comment type: 'E'ditorial Priority: '1' Should fix Section: Multiple Rationale/Explanation of issue: See reference for details. Submitter name: Jari Arkko Submitter email address: jarkko@piuha.net Date first submitted: Nov 3, 2003 Reference: http://www.piuha.net/~jarkko/publications/eap/binding-04-review.txt Document: EAP Binding Comment type: 'T'echnical Priority: 'S' Must fix Section: Multiple Rationale/Explanation of issue: Section 4 seems to go in too specific details about PEAP extensions. Consider cutting it to just the general parts, e.g. CSK derivation. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 3 13:33:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13894 for ; Mon, 3 Nov 2003 13:32:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7E60580017; Mon, 3 Nov 2003 12:33:06 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DBEB0580027; Mon, 3 Nov 2003 12:33:01 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD458580027 for ; Mon, 3 Nov 2003 12:32:59 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5E218580017 for ; Mon, 3 Nov 2003 12:32:58 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA3HtbS23528 for ; Mon, 3 Nov 2003 09:55:38 -0800 From: Bernard Aboba To: eap@frascone.com Subject: Re: [eap] binding draft issues 64, 65, 70, 88, 89, 123, new1, new2 In-Reply-To: <20031103180003.10854.6820.Mailman@wolverine> Message-ID: References: <20031103180003.10854.6820.Mailman@wolverine> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 3 Nov 2003 09:55:37 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I'm fine with the resolutions of issues 88, 89, 123 > which I filed myself or were filed by my colleagues. OK. I've marked these as resolved. > I'm also personally fine with the resolutions of > the other open issues 64, 65, 70, though it would > be better if Bernard and Dan could also confirm that > they are OK with them. I believe that Issue 65 and 70 are resolved, but the organization of the first section still needs work so I will keep #64 open. > I would suggest deleting section 4 and only keep a some > key general parts from it. I agree. Much of the material in this section belongs in the PEAP draft (and in fact seems to have been copied there in the latest version). All that is really needed here is general guidance on how a solution can be constructed. There are a number of other WGs now dealing with the MiTM problem (IKEv2, NFS CCM, etc.) so that this could be generally helpful. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 3 13:58:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14672 for ; Mon, 3 Nov 2003 13:57:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01D89580135; Mon, 3 Nov 2003 12:58:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E822C580027; Mon, 3 Nov 2003 12:58:01 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19141580027 for ; Mon, 3 Nov 2003 12:57:58 -0600 (CST) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by mail.frascone.com (Postfix) with ESMTP id EC1D9580017 for ; Mon, 3 Nov 2003 12:57:56 -0600 (CST) Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA3IvtXA009222 for ; Mon, 3 Nov 2003 18:57:55 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.12.9-20030918-01/8.11.6/d: large-inner.mc,v 1.5 2003/10/14 21:47:05 root Exp $) with SMTP id hA3IvDJk017118 for ; Mon, 3 Nov 2003 18:57:14 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110310575232653 for ; Mon, 03 Nov 2003 10:57:52 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Nov 2003 10:57:52 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] binding draft issues 64, 65, 70, 88, 89, 123, new1, new2 Message-ID: Thread-Topic: [eap] binding draft issues 64, 65, 70, 88, 89, 123, new1, new2 Thread-Index: AcOiOPe5S7ri98I6SleZPSD+y7wxKAAAaz7Q From: "Puthenkulam, Jose P" To: X-OriginalArrivalTime: 03 Nov 2003 18:57:52.0689 (UTC) FILETIME=[62445A10:01C3A23C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 3 Nov 2003 10:57:51 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks Jari & Bernard for help in closing the old issues. Also thanks for your detailed review of the 04 draft. Will try to address them in the next revision. Regarding the section 4 reference solution, will try to see how best to address your suggestions. best regards, jose > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Monday, November 03, 2003 9:56 AM > To: eap@frascone.com > Subject: Re: [eap] binding draft issues 64, 65, 70, 88, 89,=20 > 123, new1, new2 >=20 >=20 > > I'm fine with the resolutions of issues 88, 89, 123 > > which I filed myself or were filed by my colleagues. >=20 > OK. I've marked these as resolved. >=20 > > I'm also personally fine with the resolutions of > > the other open issues 64, 65, 70, though it would > > be better if Bernard and Dan could also confirm that > > they are OK with them. >=20 > I believe that Issue 65 and 70 are resolved, but the=20 > organization of the > first section still needs work so I will keep #64 open. >=20 > > I would suggest deleting section 4 and only keep a some > > key general parts from it. >=20 > I agree. Much of the material in this section belongs in the=20 > PEAP draft > (and in fact seems to have been copied there in the latest version). >=20 > All that is really needed here is general guidance on how a=20 > solution can > be constructed. There are a number of other WGs now dealing=20 > with the MiTM > problem (IKEv2, NFS CCM, etc.) so that this could be=20 > generally helpful. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 4 13:40:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27025 for ; Tue, 4 Nov 2003 13:40:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D15158012C; Tue, 4 Nov 2003 12:40:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11C37580132; Tue, 4 Nov 2003 12:40:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9EB66580132 for ; Tue, 4 Nov 2003 12:39:30 -0600 (CST) Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 1870F58012C for ; Tue, 4 Nov 2003 12:39:29 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id hA4Id8qm028543; Tue, 4 Nov 2003 13:39:08 -0500 From: John Vollbrecht To: Joseph Salowey , eap@frascone.com Subject: RE: [eap] Issue 189: Handling of the identity response Message-ID: <13031197.1067953149@dhcp60-10.merit.edu> In-Reply-To: <01ff01c3a001$59ee0b50$0200000a@amer.cisco.com> References: <01ff01c3a001$59ee0b50$0200000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 04 Nov 2003 13:39:09 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Friday, October 31, 2003 2:50 PM -0800 Joseph Salowey wrote: > > > > The first case - where the method uses the Identity Response > > data from the > > previous request as an identity does not seem right. In > > thinking about it > > I am not sure it actually happens in any implementations [as > > opposed to > > selecting the method instance based on the Response Data]. > > [Joe] I was under the impression that EAP-OTP required the identity. > They do require and identity, but it is not clear it is the EAP identity response but the identity as processed by the NAS and (if necessary) inserted in the RADIUS identity attribute. I think this is the same as MD5. This is a bit fuzzy, and I seem to recall some conversation about this. However, I don't see how it would work if, for example, something like Broker/joe@company.com were used. Certainly the user would not understand "Broker". -- John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 5 19:07:16 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02377 for ; Wed, 5 Nov 2003 19:07:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C291A580130; Wed, 5 Nov 2003 18:07:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56B4958012C; Wed, 5 Nov 2003 18:07:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FEA858012C for ; Wed, 5 Nov 2003 18:07:00 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C0DAB580012 for ; Wed, 5 Nov 2003 18:06:57 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hA5NTPY15281 for ; Wed, 5 Nov 2003 15:29:26 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] 802.1X/EAP State Machine Issues (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 5 Nov 2003 15:29:25 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Note the following excerpts from recent 802.1X ballots, relating to issues with the 802.1X and EAP state machines. NAME: Les Bell COMMENT TYPE: TR CLAUSE: 9.4.1.1.3 PAGE: 76 LINE: 19 COMMENT START: The value txPeriod is not used in any of the state machines. I think this may now belong to the EAP state machine, which is not in this document, so it should not be referenced in this section. COMMENT END: SUGGESTED CHANGES START: Remove the definition of txPeriod from this section and section 9.4.1.2.2. Deprecate the equivalent MIB object, dot1xAuthTxPeriod. Update the reference for this object in the MIB to 802.1X-2001. SUGGESTED CHANGES END: NAME: Les Bell COMMENT TYPE: TR CLAUSE: 9.4.1.1.3 PAGE: 76 LINE: 25 COMMENT START: The value maxReq is not used in any of the state machines. I think this may now belong to the EAP state machine, which is not in this document, so it should not be referenced in this section. COMMENT END: SUGGESTED CHANGES START: Remove the definition of maxReq from this section and section 9.4.1.2.2. Deprecate the equivalent MIB object, dot1xAuthMaxReq. Update the reference for this object in the MIB to 802.1X-2001. SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.1.9 PAGE: 40 LINE: 13 COMMENT START: Definition appears missing. COMMENT END: SUGGESTED CHANGES START: Figure 4-6 refers to "txWhen" but this does not appear defined anywhere. Should the reference be removed or should a definition be added? Or did I miss the definition? SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.9.4 PAGE: 61 LINE: 38-42 COMMENT START: As noted in the EAP state machine document, the eapSuccess state can be reached without receiving an EAP Success and the eapFail state can be reached without receiving an EAP Failure. So I think the text is misleading. COMMENT END: SUGGESTED CHANGES START: Recommend that this be rephrased to say: "If the higher layer indicates that authentication has been successful (eapSuccess) then the state machine transitions to the SUCCESS state. If the higher layer indicates that authentication has been unsuccessful (eapFail) then the state machine transitions to the FAIL state." SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.2.2 PAGE: 45 LINE: 21 COMMENT START: The definition of eapolEap does not take into account the Code field in the EAP packet. For example, the Backend authenticator (Figure 8-15) machine should not transition from REQUEST to RESPONSE state based on receipt of *any* EAP packet, only EAP packets with Code=2 (Response). Similarly, only packets with Code=1 (Request), 3 (Success) or 4 (Failure) are relevant to the Supplicant state machine. COMMENT END: SUGGESTED CHANGES START: Change definition to the following: eapolEap. This variable is set TRUE by an external entity if an EAPOL PDU carrying a Packet Type of EAP-Packet, and an appropriate Code field is received. In the Backend Authentication State Machine, eapolEap is set TRUE when Code=2 (Response). In the Supplicant State Machine, eapolEap is set TRUE when Code=1 (Request), 3 (Success) or 4 (Failure). SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.4.1.1 PAGE: 50 LINE: 15 COMMENT START: The definition of portMode does not seem right since the values in the text do not include the value "portControl" included in Figure 8-10. I suspect that this was actually the definition of portControl, and that the definition of portMode was ommitted. COMMENT END: SUGGESTED CHANGES START: Change "portMode" to "portControl". Add definition of portMode, which according to Figure 8-10 can take the value "portControl". SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.4 PAGE: 49 LINE: 19 COMMENT START: The transition should be from the HELD state to the RESTART state on quietWhile==0, not to the CONNECTING state. Once this is done it is not clear why RESTART and CONNECTING need to be separate states. COMMENT END: SUGGESTED CHANGES START: Change arrow from HELD to CONNECTING on quietWhile==0 to point to the RESTART state instead. Merge the RESTART and CONNECTING states into a CONNECTING state. SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.4.6 PAGE: 53 LINE: 11 COMMENT START: I don't understand why the Authenticator PAE state machine transitions from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It seems like the only cases in which this can occur are the canned Success or canned Failure cases. COMMENT END: SUGGESTED CHANGES START: Change the text to "If the higher layer is ready to send an initial EAP-Request message, the state machine transitions to the AUTHENTICATING state." SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.4 PAGE: 49 LINE: 27 COMMENT START: I don't understand why the Authenticator PAE state machine transitions from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It seems like the only cases in which this can occur are the canned Success or canned Failure cases. COMMENT END: SUGGESTED CHANGES START: Delete eapSuccess || eapFail from Figure 8-10 as a condition for the transition from CONNECTING to AUTHENTICATING. SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.11.4 PAGE: 67 LINE: 19 COMMENT START: I don't understand why the Supplicant PAE state machine transitions from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It seems like the only cases in which this can occur are the canned Success or canned Failure cases. COMMENT END: SUGGESTED CHANGES START: Delte the sentence: "If the higher layer has decided it is satisfied with an eapSuccess or eapFail, the Supplicant transitions directly to the AUTHENTICATING state." SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.11 PAGE: 65 LINE: 23 COMMENT START: I don't understand why the Supplicant PAE state machine transitions from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It seems like the only cases in which this can occur are the canned Success or canned Failure cases. COMMENT END: SUGGESTED CHANGES START: Delete eapSuccess || eapFail from Figure 8-17 as a condition for the transition fromnCONNECTING to AUTHENTICATING. SUGGESTED CHANGES END: NAME: Bernard Aboba COMMENT TYPE: T CLAUSE: 8.2.11 PAGE: 65 LINE: 15 COMMENT START: A transition is made to RESTART state from several states (CONNECTING, AUTHENTICATED, HELD) based on receipt of *any* EAP packet (eapolEap). It seems like this should only occur if an EAP Request is received and EAP indicates that methodState==INIT within the EAP state machine. COMMENT END: SUGGESTED CHANGES START: Change the condition for transition to RESTART from "eapolEap" to "eapolEap && methodState==INIT". Include definition of the methodState variable from the EAP state machine. SUGGESTED CHANGES END: _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Nov 8 19:10:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01883 for ; Sat, 8 Nov 2003 19:10:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0CCC2580010; Sat, 8 Nov 2003 18:10:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EEAFD580014; Sat, 8 Nov 2003 18:10:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49FA3580014 for ; Sat, 8 Nov 2003 18:09:13 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5CF99580010 for ; Sat, 8 Nov 2003 18:09:11 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 173FE6A901; Sun, 9 Nov 2003 02:09:08 +0200 (EET) Message-ID: <3FAD80D2.9040805@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Salowey , Pasi Eronen Cc: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] review of draft-salowey-eap-key-deriv-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 09 Nov 2003 01:48:34 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joe, Pasi, I took a look at your draft draft-salowey-eap-key-deriv-02.txt. It looks quite reasonable to me -- thanks for working on it! -- though I do have some comments: Substantial: 1. The goal of the draft. Is there an intent that some of this should be discussed in the eap-keying document? Or would this be a later extension to that? Or just for our information? 2. If the security ADs wanted us to name current keys generated from EAP, I think its likely that they will require AMSKs be named as well. A discussion of the naming is missing, though the EMSK itself is named in the document. 3. I'm not sure I like the idea of EMSK Name being derived from KDF(EMSK), if there are alternatives. Would it be possible to name the EMSK by the EAP SA Name defined in eap-keying (derived from nonces), concanated with, say, "EMSK". Similarly, we could name each AMSK as the name of the EMSK, concatenated with "AMSK" and the key label and application data? 4. Section 3.1, what is the unit of "O"? Bytes or bits? 5. Section 3.3 fails to discuss that if EMSK is going to be useful, there's probably going to be some state kept in the AAA server. Editorial: 1. Section 1.2, last paragraph. Missing "." at the end. 2. Section 2.1, s/MSUT/MUST/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 9 01:34:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08892 for ; Sun, 9 Nov 2003 01:34:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D52AB580010; Sun, 9 Nov 2003 00:34:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA2E3580016; Sun, 9 Nov 2003 00:34:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8B90580134 for ; Tue, 4 Nov 2003 13:00:04 -0600 (CST) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail.frascone.com (Postfix) with ESMTP id 25DD7580132 for ; Tue, 4 Nov 2003 13:00:01 -0600 (CST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AH6MQ-0002NX-Gu; Tue, 04 Nov 2003 13:57:02 -0500 X-test-idtracker: no To: IETF-Announce: ; Cc: eap@frascone.com From: The IESG Reply-To: iesg@ietf.org Message-Id: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REVISED Last Call: 'Extensible Authentication Protocol (EAP)' to Proposed Standard Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 04 Nov 2003 13:57:02 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The IESG has received a request from the Extensible Authentication Protocol WG to consider the following document: - 'Extensible Authentication Protocol (EAP)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-26. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 9 03:53:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23698 for ; Sun, 9 Nov 2003 03:53:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB9E0580010; Sun, 9 Nov 2003 02:53:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B9146580016; Sun, 9 Nov 2003 02:53:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF54A580016 for ; Sun, 9 Nov 2003 02:52:18 -0600 (CST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id CD5B0580010 for ; Sun, 9 Nov 2003 02:52:16 -0600 (CST) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hA98qbGg018104 for ; Sun, 9 Nov 2003 08:52:37 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hA98hfQ21847 for ; Sun, 9 Nov 2003 08:43:42 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003110900520217184 ; Sun, 09 Nov 2003 00:52:02 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 9 Nov 2003 00:52:02 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] REVISED Last Call: 'Extensible Authentication Protocol (EAP)' to Proposed Standard Message-ID: Thread-Topic: [eap] REVISED Last Call: 'Extensible Authentication Protocol (EAP)' to Proposed Standard Thread-Index: AcOmi4opOvIPqwp4S1eR7b4MVol3fQAEe7AA From: "Puthenkulam, Jose P" To: Cc: X-OriginalArrivalTime: 09 Nov 2003 08:52:02.0380 (UTC) FILETIME=[BE45E0C0:01C3A69E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 9 Nov 2003 00:52:01 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable In section 7.2 [c] Replace "acknowledged result indications" with "protected result indications". It makes more sense to have the EAP method indicate its result in a protected manner than making sure the result is acknowledged. Also for section 7.4 Man-in-the-middle attacks would it not be appropriate to add an informative reference to the EAP Binding Draft and the Nokia Mitm paper. best regards, jose > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of The IESG > Sent: Tuesday, November 04, 2003 10:57 AM > Cc: eap@frascone.com > Subject: [eap] REVISED Last Call: 'Extensible Authentication=20 > Protocol (EAP)' to Proposed Standard >=20 >=20 > The IESG has received a request from the Extensible=20 > Authentication Protocol=20 > WG to consider the following document: >=20 > - 'Extensible Authentication Protocol (EAP)' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-26. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 9 08:30:29 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28078 for ; Sun, 9 Nov 2003 08:30:14 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8C8A58001A; Sun, 9 Nov 2003 07:30:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8AF3F580016; Sun, 9 Nov 2003 07:30:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AAF0B580016 for ; Sun, 9 Nov 2003 07:29:57 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id B3739580010 for ; Sun, 9 Nov 2003 07:29:55 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 636F86A909; Sun, 9 Nov 2003 15:29:53 +0200 (EET) Message-ID: <3FAE2607.3010100@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Salowey Cc: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] some comments on draft-josefsson-pppext-eap-tls-eap-07 (peapv2) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 09 Nov 2003 13:33:27 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I read this document on the way to Minneapolis, and have some questions and comments: Substantial: 1. Section 1, identity protection. Wouldn't it still be possible to have an active attack against identity protection? This seems possible - if one of the other servers trusted by the CA wants to intervene (or do you require specific server cert?) - if the client won't or can't (network access case) check the CRL and the server's key has been compromised 2. Section 1, protected termination and dos attacks. I wonder if there still exists a dos attack where the attacker simply injects some bad TLS records into the stream. Will this cause a disconnect or is there some protection against that? 3. Section 2, the possibility of running zero EAP methods in part 2. What would be the usefulness of that over running EAP TLS? The ability to send TLVs? 4. Section 2.2.2.1, why is it just a "should" to decide that a tunnel compromise error has occurred when an invalid Crypto-Binding-TLV is received? And where does it say what actions "tunnel compromise error" implies? 5. I wonder if the protocol specification would be clearer with a state machine. I'm not 100% convinced that all the cases have been covered in the text, and its hard to visualize what is happening. Maybe its just me, but... 6. Section 4.7, Connection-Binding TLV. This is very interesting! You say that the actual parameters are defined by the link layers. But this does not appear to suffice for the definition of the format on how they are carried in this TLV, or? How would we know which parameters and in which order are sent here unless the 802.11i, for instance, explicitly said that SSID and MAC address were carried inside PEAPv2 in a particular way? 7. What is the purpose and semantics of the URI TLV? 8. I'm not sure if Section 5.2 contains enough information about the version negotiation and potential downgrade attacks involved in PEAPv2 - PEAPv1 choice. 9. Section 5.8 says "Hence, the recommended solution is to always deploy authentication methods with protection of PEAPv2." Hmm... I would formulate this slightly differently if the intent is to avoid mitm problems: "Hence, the recommended solution is to deploy authentication methods for a given user either always with the protection of PEAPv2 or never with PEAPv2." Editorial: 1. Draft name would probably be more descriptive if it contained "peap". 2. Recommended author limit has been exceeded, I think. 3. Section 2.4 has some duplication, e.g. the paragraphs starting with "a single tls record may be up to 16384...". --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 9 12:27:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04357 for ; Sun, 9 Nov 2003 12:26:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 77FB6580010; Sun, 9 Nov 2003 11:27:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6A249580016; Sun, 9 Nov 2003 11:27:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D1AE7580016 for ; Sun, 9 Nov 2003 11:26:36 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id F1A77580010 for ; Sun, 9 Nov 2003 11:26:32 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 762AE6A905; Sun, 9 Nov 2003 19:26:31 +0200 (EET) Message-ID: <3FAE567E.2000300@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Puthenkulam, Jose P" Cc: eap@frascone.com, iesg@ietf.org Subject: Re: [eap] REVISED Last Call: 'Extensible Authentication Protocol (EAP)' to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 09 Nov 2003 17:00:14 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Puthenkulam, Jose P wrote: > In section 7.2 [c] > > Replace "acknowledged result indications" with "protected result > indications". It makes more sense to have the EAP method indicate its > result in a protected manner than making sure the result is > acknowledged. Ok. The term is defined in 7.2.1, and the text already requires protection, I agree that the name "protected result indications" would be appropriate. Need to change the name then in both 7.2 and 7.2.1 as well as in a few other places in the document... > Also for section 7.4 Man-in-the-middle attacks would it not be > appropriate to add an informative reference to the EAP Binding Draft and > the Nokia Mitm paper. Yes, this would be appropriate. Thanks for your comments. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 9 16:46:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11646 for ; Sun, 9 Nov 2003 16:46:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 25D07580019; Sun, 9 Nov 2003 15:47:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09280580016; Sun, 9 Nov 2003 15:47:01 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A991E580017 for ; Sun, 9 Nov 2003 15:46:57 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id D9A99580016 for ; Sun, 9 Nov 2003 15:46:55 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B5C306A905 for ; Sun, 9 Nov 2003 23:46:54 +0200 (EET) Message-ID: <3FAEB4CE.3090105@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] presentations for ietf-58 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 09 Nov 2003 23:42:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Presentations for IETF-58 EAP session will be available at http://www.piuha.net/~jarkko/publications/eap/ietf-58/ (Not all are there yet -- presenters, please send in yours...) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 9 22:49:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23917 for ; Sun, 9 Nov 2003 22:48:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8DCE658001A; Sun, 9 Nov 2003 21:49:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91EA2580017; Sun, 9 Nov 2003 21:49:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD445580017 for ; Sun, 9 Nov 2003 21:48:31 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9363E580010 for ; Sun, 9 Nov 2003 21:48:29 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAA3AYP05904 for ; Sun, 9 Nov 2003 19:10:34 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 193: Peer SM review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 9 Nov 2003 19:10:34 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 193: Peer SM review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: Nov 8, 2003 Reference: Document: SM-01 Comment type: T Priority: S Section: 2, 4 Rationale/Explanation of issue: pp. 5, first paragraph "pass EAP messages to a Backend Server where the real Authentication Method resides" As is made clear later, the pass-through authenticator does *not* forward all EAP messages to the backend authentication server, only EAP-Responses. Rephrase to: "pass EAP-Response messages to a Backend Server where the Authentication Method resides" Third paragraph: The implication is the EAP method demultiplexing depends on the lower layer. This is not the case because all EAP implementations on all media must support demultiplexing (whether they support an authenticator or peer listener is another issue). Suggest replacing the paragraph with: "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes incoming EAP packets. Packets with Code=2 (Response) are delivered to the Authenticator state machine, while packets with Code=1 (Request), 3 (Success) or 4 (Failure) are delivered to the Peer state machine." Page 9, Figure 3. The notation used later (Figure 6) is more clear than the use of the "|" operator as in Figure 3. I'd recommend adopting the Figure 6 notation everywhere. It would appear to me that methodState is a variable that needs to be exported from the peer to the lower layer. This is so that lower layer state machines such as 802.1X can know whether their own state machines should be affected or not. The INITIALIZE state does not initialize all variables. Non-initialized variables include: eapKeyData = NONE eapKeyAvailable = FALSE eapSuccess = FALSE eapFail = FALSE methodState = NONE selectedMethod = NONE decision = FAIL The initialization values seem important since transitions can be based on them before they are initialized. Re-initializing variables in the INITIALIZE state is a bit different from giving the variables initial values before they are ever used. Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE state. I assume this means that this variable can be assigned one of two values, at the implementation's descretion. I think we want this variable initialized to FAIL. There is a transition from the IDLE state to the SUCCESS and FAILURE states. This occurs without appearing to require receipt of a packet. I think that this can't be the case; something has to be received at some point for the peer to leave idleWhile OR it is a situation where the peer is testing whether the authenticator is EAP-capable (e.g. a wired LAN application). The transition to FAILURE state occurs when an alternative indication of Rejection occurs (e.g. Disassociate); when the idleWhile timer runs out and the decision is not an unconditional success; when an alternative indication of success is available but the decision is FAIL. There is also a transition from the IDLE state to the SUCCESS state. This can occur when the idleWhile timer runs out and the decision is an unconditional success; or when an alternative indication of success is available and the decision is not FAILURE. It seems that the INITIALIZE state will need to have the correct default values or these transitions may not occur correctly. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 08:10:23 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18429 for ; Mon, 10 Nov 2003 08:10:18 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DF0C580027; Mon, 10 Nov 2003 07:10:12 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5982A580017; Mon, 10 Nov 2003 07:10:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E515C580017 for ; Mon, 10 Nov 2003 07:09:44 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C5228580010 for ; Mon, 10 Nov 2003 07:09:31 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAACVWD06413 for ; Mon, 10 Nov 2003 04:31:33 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 194: Standalone Authenticator SM review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 04:31:32 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 194: Standalone Authenticator SM review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: Nov 8, 2003 Reference: Document: SM-01 Comment type: T Priority: S Section: 5, 5.1 Rationale/Explanation of issue: pp. 17, page 52 m.getTimeout prototype should be after the paragraph explaining what m.buildReq does, not before. pp. 15, Figure 4 Shouldn't there be a function in SEND_REQUEST state to actually hand the packet over to the lower layer? The Type code for NAK and EXPANDED_NAK are the same, so that the definition of respMethod should probably be modified. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 08:48:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19199 for ; Mon, 10 Nov 2003 08:47:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5DA75580010; Mon, 10 Nov 2003 07:48:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DEDC580017; Mon, 10 Nov 2003 07:48:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80AE2580017 for ; Mon, 10 Nov 2003 07:47:08 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8718B580010 for ; Mon, 10 Nov 2003 07:47:06 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 098146A903; Mon, 10 Nov 2003 15:47:04 +0200 (EET) Message-ID: <3FAF95D6.2000402@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 193: Peer SM review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:42:46 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Issue 193: Peer SM review > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 8, 2003 > Reference: > Document: SM-01 > Comment type: T > Priority: S > Section: 2, 4 > Rationale/Explanation of issue: > > pp. 5, first paragraph > > "pass EAP messages to a Backend Server where the real Authentication > Method resides" > > As is made clear later, the pass-through authenticator does *not* forward > all EAP messages to the backend authentication server, only EAP-Responses. > Rephrase to: > > "pass EAP-Response messages to a Backend Server where the Authentication > Method resides" > > Third paragraph: > > The implication is the EAP method demultiplexing depends on the lower > layer. This is not the case because all EAP implementations on all media > must support demultiplexing (whether they support an authenticator or > peer listener is another issue). > > Suggest replacing the paragraph with: > > "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes > incoming EAP packets. Packets with Code=2 (Response) are delivered to the > Authenticator state machine, while packets with Code=1 (Request), 3 > (Success) or 4 (Failure) are delivered to the Peer state machine." > > Page 9, Figure 3. > > The notation used later (Figure 6) is more clear than the use of the "|" > operator as in Figure 3. I'd recommend adopting the Figure 6 notation > everywhere. I'm fine with either format. > It would appear to me that methodState is a variable that needs to be > exported from the peer to the lower layer. This is so that lower layer > state machines such as 802.1X can know whether their own state machines > should be affected or not. > > The INITIALIZE state does not initialize all variables. Non-initialized > variables > include: > > eapKeyData = NONE > eapKeyAvailable = FALSE > eapSuccess = FALSE > eapFail = FALSE > methodState = NONE > selectedMethod = NONE > decision = FAIL > > The initialization values seem important since transitions can be based on > them before they are initialized. Re-initializing variables in the > INITIALIZE state is a bit different from giving the variables initial > values before they are ever used. Ok. > Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE state. > I assume this means that this variable can be assigned one of two values, > at the implementation's descretion. I think we want this variable Section 3.1 gives the notation. > initialized to FAIL. Is this about potentially allowing success even without a single method run? I agree that FAIL seems appropriate. > There is a transition from the IDLE state to the SUCCESS and FAILURE > states. This occurs without appearing to require receipt of a packet. I > think that this can't be the case; something has to be received at some > point for the peer to leave idleWhile OR it is a situation where the peer I think the transition is essentially a timer running to zero, i.e. idleWhile == 0. That would be appropriate transition imho. > is testing whether the authenticator is EAP-capable (e.g. > a wired LAN application). > > The transition to FAILURE state occurs when an alternative indication of > Rejection occurs (e.g. Disassociate); when the idleWhile timer runs out > and the decision is not an unconditional success; when an alternative > indication of success is available but the decision is FAIL. Yes. > There is also a transition from the IDLE state to the SUCCESS state. > This can occur when the idleWhile timer runs out and the decision is > an unconditional success; or when an alternative indication of success > is available and the decision is not FAILURE. Yes. > It seems that the INITIALIZE state will need to have the correct default > values or these transitions may not occur correctly. I agree. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 09:03:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19879 for ; Mon, 10 Nov 2003 09:02:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82766580010; Mon, 10 Nov 2003 08:03:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 835BC580017; Mon, 10 Nov 2003 08:03:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEEED580017 for ; Mon, 10 Nov 2003 08:02:19 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7B227580010 for ; Mon, 10 Nov 2003 08:02:18 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 28FE46A903; Mon, 10 Nov 2003 16:02:17 +0200 (EET) Message-ID: <3FAF9967.9030108@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 194: Standalone Authenticator SM review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:57:59 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Issue 194: Standalone Authenticator SM review > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 8, 2003 > Reference: > Document: SM-01 > Comment type: T > Priority: S > Section: 5, 5.1 > Rationale/Explanation of issue: > pp. 17, page 52 > > m.getTimeout prototype should be after the paragraph > explaining what m.buildReq does, not before. Right. Just split the paragraph into the two sentences and put the m.getTimeout in between. > pp. 15, Figure 4 > > Shouldn't there be a function in SEND_REQUEST state > to actually hand the packet over to the lower layer? I think the style of the specification is that you just set a variable, and the lower layer magically reads it. > The Type code for NAK and EXPANDED_NAK > are the same, so that the definition of > respMethod should probably be modified. Yes. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 14:24:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07167 for ; Mon, 10 Nov 2003 14:23:45 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85079580010; Mon, 10 Nov 2003 13:23:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6F8F580017; Mon, 10 Nov 2003 13:23:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E01C580017 for ; Mon, 10 Nov 2003 13:22:50 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 59677580010 for ; Mon, 10 Nov 2003 13:22:48 -0600 (CST) Received: from sandelman.ottawa.on.ca ([2002:8281:8932::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAAJOkD23836 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 10 Nov 2003 14:25:00 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAJCauX001004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Nov 2003 13:13:46 -0600 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAADmGqv001692; Mon, 10 Nov 2003 08:52:31 -0500 To: eap@frascone.com Cc: aland@nitros9.org, mah@eunet.at Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <1691.1068472096@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP state machine Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 08:48:16 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- I read the EAP state machine draft this morning in the airport. I had printed it, since reading diagrams on the computer is not very pleasant. My comments: 1) presentation. a) Please make the diagrams use non-zero-width lines in the boxes. Zero-width lines do not always render perfectly with all tools/printers. True, it is bugs in some tools, and in some printers and some printer drivers. But it is not always fixable. Specifically, I experience that some sides of the boxes are not being drawn. The PDF is fine, btw. The Postscript is not. I am not certain where the problem originates, or where the postscript was generated. (I recall that diagrams that I did with other tools with zero-width lines did not import into MS-Office 2000 either) b) please write the conditionals, with one condition per line. i.e. A && B && C || D rather than A && B && C || D. You may even want to use a somewhat unorthodox, but often more clear format of: A && B && C || D (FreeS/WAN's pluto uses this style for its C code. It weirded me out at first, but I've come to appreciate it a bit) 2) authority >3.3 Document authority > > Should a conflict exist between the interpretation of a state > diagram and either the corresponding global transition tables > or the textual description associated with the state machine, > the state diagram takes precedence. When a discrepancy occurs > between any part of this document (text or diagram) and any of the > related documents ([I-D.ietf-eap-rfc2284bis], [RFC3579], etc.) the > latter (the other document) is considered authoritative and takes > precedence. I am concerned that the diagram, which can't easily be quoted, displayed or edited is considered authoritative. In addition, while 2223 is slightly vague about which version is considered authoritative, draft-rfceditor-editor-rfc2223bis-07 is pretty clear: The ASCII plain text version (and its .txt.pdf facsimile) is always the official specification, and it must adequately and completely define the technical content. (A very few exceptions have been made over the 30 year history of RFCs, allowing a definitive PostScript (.ps) version with no .txt version.) The primacy of the ASCII version typically requires that the critical diagrams and packet formats be rendered as "ASCII art" in the .txt version. The above text would seem to contradict this. I am also concerned that this document is not authoritative vs the other documents. I believe that each state in the diagram should have a paragraph explaining it, its entry conditions and exit conditions. 3) Standalone authenticator State machine - retransmit state There is no text for me to quote to discuss this, so I can't really point at anything, nor can I offer "alternative text" either. There is a major problem with this state. It can not be implemented in some transports. The major one is radius. A radius server (which would be the EAP Requestor) does not initiate new messages on its own. It also does not retransmit ever. Rather, it relies on the client to resend its request, and it will retransmit the reply. EAP does not easily fit into this, and this state machine shows nothing. One might say that this is radius' problem. Perhaps. But, it needs to be documented, and I believe that it has effects on the client (peer) state machine as well. So, I do not agree that this document is ready for last call. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6+W+YqHRg3pndX9AQH8gQP/WP6hDumYvv4RRGTv2sJeisvO6xCcLsI9 +qfcmxTBqp6vXUeGGOZ4bSKitMOtaOmUf1m10P2jHsOSZBauovuc9kQzU1UiwMwi iKEFTjxfdcwRPyVxzzgGGlcgjM1HzGXy6ddaB1LaChbAvgdNDdWW3Hi/tt9w31oW +ZpHY87F648= =7Jky -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 14:54:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08888 for ; Mon, 10 Nov 2003 14:54:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47125580023; Mon, 10 Nov 2003 13:54:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18D9C580018; Mon, 10 Nov 2003 13:54:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D968580018 for ; Mon, 10 Nov 2003 13:53:03 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 7B004580010 for ; Mon, 10 Nov 2003 13:53:00 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAAJq0F1018070; Tue, 11 Nov 2003 04:52:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAAJq0m0021192; Tue, 11 Nov 2003 04:52:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA21189 ; Tue, 11 Nov 2003 04:52:00 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA21093; Tue, 11 Nov 2003 04:51:59 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA15435; Tue, 11 Nov 2003 04:51:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hAAJpw9X014744; Tue, 11 Nov 2003 04:51:59 +0900 (JST) Received: from steelhead ([159.119.168.155]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HO500E1GJ6JIS@tsbpo1.po.toshiba.co.jp>; Tue, 11 Nov 2003 04:51:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AJI2g-0007FG-00; Mon, 10 Nov 2003 11:49:42 -0800 From: Yoshihiro Ohba Subject: Re: [eap] EAP state machine In-reply-to: <1691.1068472096@marajade.sandelman.ottawa.on.ca> To: Michael Richardson Cc: eap@frascone.com, aland@nitros9.org, mah@eunet.at Message-id: <20031110194941.GH27208@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <1691.1068472096@marajade.sandelman.ottawa.on.ca> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:49:41 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi, On Mon, Nov 10, 2003 at 08:48:16AM -0500, Michael Richardson wrote: > 3) Standalone authenticator State machine - retransmit state > > There is no text for me to quote to discuss this, so I can't really > point at anything, nor can I offer "alternative text" either. > > There is a major problem with this state. It can not be implemented in some > transports. The major one is radius. A radius server (which would be the EAP > Requestor) does not initiate new messages on its own. Standalone authenticator does not use any AAA protocol (RADIUS, Diameter, etc.), So I don't undersand why RADIUS comes into the picture here. Yoshihiro Ohba > > It also does not retransmit ever. Rather, it relies on the client to resend > its request, and it will retransmit the reply. EAP does not easily fit into > this, and this state machine shows nothing. > > One might say that this is radius' problem. Perhaps. But, it needs to be > documented, and I believe that it has effects on the client (peer) state > machine as well. > > So, I do not agree that this document is ready for last call. > > ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ > > > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBP6+W+YqHRg3pndX9AQH8gQP/WP6hDumYvv4RRGTv2sJeisvO6xCcLsI9 > +qfcmxTBqp6vXUeGGOZ4bSKitMOtaOmUf1m10P2jHsOSZBauovuc9kQzU1UiwMwi > iKEFTjxfdcwRPyVxzzgGGlcgjM1HzGXy6ddaB1LaChbAvgdNDdWW3Hi/tt9w31oW > +ZpHY87F648= > =7Jky > -----END PGP SIGNATURE----- > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 17:19:13 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17098 for ; Mon, 10 Nov 2003 17:19:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51335580010; Mon, 10 Nov 2003 16:19:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3772580017; Mon, 10 Nov 2003 16:19:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEBDB580017 for ; Mon, 10 Nov 2003 16:18:30 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id D375E580010 for ; Mon, 10 Nov 2003 16:18:28 -0600 (CST) Received: from sandelman.ottawa.on.ca ([2002:8281:8932::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAAMLT524544 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 10 Nov 2003 17:21:35 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAKmQu9004247 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Nov 2003 14:48:26 -0600 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAKmMAh004243; Mon, 10 Nov 2003 14:48:25 -0600 To: Yoshihiro Ohba , eap@frascone.com Cc: aland@nitros9.org, mah@eunet.at Subject: Re: [eap] EAP state machine In-reply-to: Your message of "Mon, 10 Nov 2003 11:49:41 PST." <20031110194941.GH27208@steelhead> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <4241.1068497301@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:48:21 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> On Mon, Nov 10, 2003 at 08:48:16AM -0500, Michael Richardson Yoshihiro> wrote: >> 3) Standalone authenticator State machine - retransmit state >> >> There is no text for me to quote to discuss this, so I can't really >> point at anything, nor can I offer "alternative text" either. >> >> There is a major problem with this state. It can not be implemented in >> some transports. The major one is radius. A radius server (which would >> be the EAP Requestor) does not initiate new messages on its own. Yoshihiro> Standalone authenticator does not use any AAA protocol Yoshihiro> (RADIUS, Diameter, etc.), So I don't undersand why RADIUS Yoshihiro> comes into the picture here. Uh, what? EAP doesn't live on a wire. It lives in other protocols. For instance, this is a "standalone" server - it doesn't talk to any "backend" |-------------------------EAP------------------| supplicant AP--------radius--------server +-------- 802x ------+ ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP6/5lIqHRg3pndX9AQEZowP+Kwg5/LB1qZk30+Zz32kfACMIs2lnsYux ZGgFFwL77R+9rqGS2/BWUwlTrr66TdFbpgR0smxUlgYbpEy8z5ftY/Snuc09xNo4 rzu40sLKebFji9L5QETQqyL67tUdlJA7cdOy6KlsnSEOgBwetonHU7p/5cqTtibT mvZPEl5KEq0= =djIQ -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 17:32:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17924 for ; Mon, 10 Nov 2003 17:32:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99599580010; Mon, 10 Nov 2003 16:32:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 29960580017; Mon, 10 Nov 2003 16:32:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA3BD580018 for ; Mon, 10 Nov 2003 16:31:47 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id C3F09580010 for ; Mon, 10 Nov 2003 16:31:45 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAAMUxF1029994; Tue, 11 Nov 2003 07:30:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAAMUxEF018726; Tue, 11 Nov 2003 07:30:59 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA18725 ; Tue, 11 Nov 2003 07:30:59 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA02837; Tue, 11 Nov 2003 07:30:58 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA19936; Tue, 11 Nov 2003 07:30:58 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hAAMUv9X028272; Tue, 11 Nov 2003 07:30:57 +0900 (JST) Received: from steelhead ([159.119.168.188]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HO500J6WQJI96@tsbpo1.po.toshiba.co.jp>; Tue, 11 Nov 2003 07:30:56 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AJKX3-0007Ts-00; Mon, 10 Nov 2003 14:29:13 -0800 From: Yoshihiro Ohba Subject: Re: [eap] EAP state machine In-reply-to: <4241.1068497301@marajade.sandelman.ottawa.on.ca> To: Michael Richardson Cc: Yoshihiro Ohba , eap@frascone.com, aland@nitros9.org, mah@eunet.at Message-id: <20031110222913.GL27208@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20031110194941.GH27208@steelhead> <4241.1068497301@marajade.sandelman.ottawa.on.ca> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:29:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, Nov 10, 2003 at 02:48:21PM -0600, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> On Mon, Nov 10, 2003 at 08:48:16AM -0500, Michael Richardson > Yoshihiro> wrote: > >> 3) Standalone authenticator State machine - retransmit state > >> > >> There is no text for me to quote to discuss this, so I can't really > >> point at anything, nor can I offer "alternative text" either. > >> > >> There is a major problem with this state. It can not be implemented in > >> some transports. The major one is radius. A radius server (which would > >> be the EAP Requestor) does not initiate new messages on its own. > > Yoshihiro> Standalone authenticator does not use any AAA protocol > Yoshihiro> (RADIUS, Diameter, etc.), So I don't undersand why RADIUS > Yoshihiro> comes into the picture here. > > Uh, what? > > EAP doesn't live on a wire. It lives in other protocols. > > For instance, this is a "standalone" server - it doesn't talk to any > "backend" > > > |-------------------------EAP------------------| > > supplicant AP--------radius--------server > +-------- 802x ------+ When we use the word "standalone", it points to EAP authenticator that shows a basic, non-passthrough authenticator's behavior, as described in section 2 of the state machines draft. In the above example, AP acts as a passthrough authenticator, and the RADIUS server is a "backend" server to the passthough authenticator, not a "standalone" authenticator. (AP is talking to the backend server). Yoshihiro Ohba > > > ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBP6/5lIqHRg3pndX9AQEZowP+Kwg5/LB1qZk30+Zz32kfACMIs2lnsYux > ZGgFFwL77R+9rqGS2/BWUwlTrr66TdFbpgR0smxUlgYbpEy8z5ftY/Snuc09xNo4 > rzu40sLKebFji9L5QETQqyL67tUdlJA7cdOy6KlsnSEOgBwetonHU7p/5cqTtibT > mvZPEl5KEq0= > =djIQ > -----END PGP SIGNATURE----- > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 17:40:06 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18243 for ; Mon, 10 Nov 2003 17:40:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A31158001A; Mon, 10 Nov 2003 16:40:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27E0C580017; Mon, 10 Nov 2003 16:40:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 808EF580017 for ; Mon, 10 Nov 2003 16:39:25 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 617E9580010 for ; Mon, 10 Nov 2003 16:39:23 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2D0A76A902; Tue, 11 Nov 2003 00:39:21 +0200 (EET) Message-ID: <3FB0128C.5060708@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Cc: eap@frascone.com, aland@nitros9.org, mah@eunet.at Subject: Re: [eap] EAP state machine References: <1691.1068472096@marajade.sandelman.ottawa.on.ca> In-Reply-To: <1691.1068472096@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 11 Nov 2003 00:34:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > I read the EAP state machine draft this morning in the airport. > > I had printed it, since reading diagrams on the computer is not very > pleasant. My comments: > > 1) presentation. > > a) Please make the diagrams use non-zero-width lines in the boxes. Agree, but I'm not even sure we need postscript versions. > b) please write the conditionals, with one condition per line. > i.e. A && > B && > C || > D Agree. > rather than A && B && > C || D. > > You may even want to use a somewhat unorthodox, but often more clear > format of: > A > && B > && C > || D Uh. > (FreeS/WAN's pluto uses this style for its C code. It weirded me out at > first, but I've come to appreciate it a bit) > > 2) authority > > >>3.3 Document authority >> >> Should a conflict exist between the interpretation of a state >> diagram and either the corresponding global transition tables >> or the textual description associated with the state machine, >> the state diagram takes precedence. When a discrepancy occurs >> between any part of this document (text or diagram) and any of the >> related documents ([I-D.ietf-eap-rfc2284bis], [RFC3579], etc.) the >> latter (the other document) is considered authoritative and takes >> precedence. > > > I am concerned that the diagram, which can't easily be quoted, displayed > or edited is considered authoritative. In addition, while 2223 is slightly > vague about which version is considered authoritative, > draft-rfceditor-editor-rfc2223bis-07 is pretty clear: > > The ASCII plain text version (and its .txt.pdf facsimile) is > always the official specification, and it must adequately and > completely define the technical content. (A very few exceptions > have been made over the 30 year history of RFCs, allowing a > definitive PostScript (.ps) version with no .txt version.) The > primacy of the ASCII version typically requires that the critical > diagrams and packet formats be rendered as "ASCII art" in the .txt > version. We are working with the RFC editor to figure out what to do in our particular case. Our statemachines aren't easily representable in ASCII art, so we do have a problem. Or should we publish state *tables* in ASCII, and an associated PDF version. But *if* we can figure out a way to do this in ASCII, then I would agree with you that it should be the authorative one. Just don't know if its possible in this case. > The above text would seem to contradict this. > > I am also concerned that this document is not authoritative vs the other > documents. > > I believe that each state in the diagram should have a paragraph explaining > it, its entry conditions and exit conditions. Hmm... I think most of the explanations of why things are done in a certain way are in 2284bis. We had some explanations in earlier versions of the state machine document too, but it was hard to get them synchronized with the diagrams. Personally, I find it easies to grasp the semantics from the diagram. Additional text does not help, it hurts. > 3) Standalone authenticator State machine - retransmit state > > There is no text for me to quote to discuss this, so I can't really > point at anything, nor can I offer "alternative text" either. > > There is a major problem with this state. It can not be implemented in some > transports. The major one is radius. A radius server (which would be the EAP > Requestor) does not initiate new messages on its own. > > It also does not retransmit ever. Rather, it relies on the client to resend > its request, and it will retransmit the reply. EAP does not easily fit into > this, and this state machine shows nothing. > > One might say that this is radius' problem. Perhaps. But, it needs to be > documented, and I believe that it has effects on the client (peer) state > machine as well. Well, the functionality split in the passthrough case is non-trivial. When the authenticator is standalone, all of EAP is terminated in the same node. However, with a passthrough some parts of the termination (such as retransmission) are done in the passthrough and the rest in the backend authenticator. So I would agree with Yoshi that you shouldn't apply the standalone authenticator diagram in the case of radius. Then you should apply the Figure 7 diagram in the passsthrough and the backend auth diagram in the RADIUS server. > So, I do not agree that this document is ready for last call. Hey, we got you reading it, didn't we ;-) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 17:59:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19279 for ; Mon, 10 Nov 2003 17:58:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7395D580010; Mon, 10 Nov 2003 16:59:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2BD15580018; Mon, 10 Nov 2003 16:59:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87AB2580018 for ; Mon, 10 Nov 2003 16:58:27 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 6426B580010 for ; Mon, 10 Nov 2003 16:58:25 -0600 (CST) Received: from sandelman.ottawa.on.ca ([2002:8281:8932::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAAN1Tt24734 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 10 Nov 2003 18:01:32 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAMuVTq002842 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Nov 2003 16:56:32 -0600 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAMuU7w002838; Mon, 10 Nov 2003 16:56:31 -0600 To: jari.arkko@piuha.net Cc: eap@frascone.com, aland@nitros9.org, mah@eunet.at Subject: Re: [eap] EAP state machine In-reply-to: Your message of "Tue, 11 Nov 2003 00:34:52 +0200." <3FB0128C.5060708@piuha.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <2837.1068504990@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 16:56:30 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> But *if* we can figure out a way to do this in ASCII, then I Jari> would agree with you that it should be the authorative one. Jari> Just don't know if its possible in this case. My opinion is that each state needs to have text explaining it. It should explain how you enter the state, and the conditions to exit it. Instead, this document seems to spend a lot of space explaining a lot of variables, but doesn't seem to shed any light on the problem. Is this document modeled after some IEEE document format? >> One might say that this is radius' problem. Perhaps. But, it needs to be >> documented, and I believe that it has effects on the client (peer) state >> machine as well. Jari> Well, the functionality split in the passthrough case is non-trivial. Jari> When the authenticator is standalone, all of EAP is terminated in the Jari> same node. However, with a passthrough some parts of the termination Jari> (such as retransmission) are done in the passthrough and the rest Jari> in the backend authenticator. No. You don't understand radius then. A radius server, which is where the EAP would be terminated CAN NOT RETRANSMIT. It can only respond to retransmissions from the client. Jari> So I would agree with Yoshi that you shouldn't apply the standalone Jari> authenticator diagram in the case of radius. Then you should apply Jari> the Figure 7 diagram in the passsthrough and the backend auth diagram Jari> in the RADIUS server. I don't understand why. The EAP is inside the Radius server. Jari> Hey, we got you reading it, didn't we ;-) Actually, it got printed before the last call got issued. I have to be at IPSP as well, so I won't be there at some point. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7AXmoqHRg3pndX9AQEQ8QP+K2bHsUnyk4g23wUaTzhQNllCipCAW+4/ Ik/LynLcsAjtHSSwSL2BPMof+gyG3YLRs9kVrjbJ39vjsI1ARiH2HLkJLJbUasi/ srm9KigJdwYFjmUnHGIWHTbfCgYL7DyP2Pw7VCLiFUadc5xXyf4m2jjq1jdotFSn bpeGapEYY3c= =dXEF -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 18:08:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20236 for ; Mon, 10 Nov 2003 18:08:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14FB2580023; Mon, 10 Nov 2003 17:09:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A0C6580018; Mon, 10 Nov 2003 17:09:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F264F580018 for ; Mon, 10 Nov 2003 17:08:29 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 14288580019 for ; Mon, 10 Nov 2003 17:08:28 -0600 (CST) Received: from sandelman.ottawa.on.ca ([2002:8281:8932::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAANBVt24765 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 10 Nov 2003 18:11:32 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAN6vTq003100 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 10 Nov 2003 17:06:57 -0600 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAAN6v9v003097; Mon, 10 Nov 2003 17:06:57 -0600 To: Yoshihiro Ohba Cc: eap@frascone.com, aland@nitros9.org, mah@eunet.at Subject: Re: [eap] EAP state machine In-reply-to: Your message of "Mon, 10 Nov 2003 14:29:13 PST." <20031110222913.GL27208@steelhead> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <3096.1068505617@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 17:06:57 -0600 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> When we use the word "standalone", it points to EAP Yoshihiro> authenticator that shows a basic, non-passthrough Yoshihiro> authenticator's behavior, as described in section 2 of the Yoshihiro> state machines draft. Yoshihiro> In the above example, AP acts as a passthrough authenticator, Yoshihiro> and the RADIUS server is a "backend" server to the passthough Yoshihiro> authenticator, not a "standalone" authenticator. (AP is Yoshihiro> talking to the backend server). okay. I understand the terminology now. I don't see anything in the backend state machine to accomplish retransmission. It says that the radius server retransmits... but so what? When it retransmits, it will be sending a response to the previous EAP request, NOT the current one, so the IDs won't match, etc. ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP7AaD4qHRg3pndX9AQGkIgP9HZAMG800CjVA9pT7WY/nyiRBIHgCgUdI XDiHOJy6xvmR1VVI/auR7L14KydgGhvmhiL0JIlZM2BgZOHdfwLLqs6fgAPSqZ7B UWQp0riJem6VIwyqXvhkiVULBifQeexLWJ7dmtGYzmUvixq/AVVDcgLaMpEpFkTT Qv31hFJPLMs= =5juS -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 18:13:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21038 for ; Mon, 10 Nov 2003 18:13:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7C49580023; Mon, 10 Nov 2003 17:14:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54E85580018; Mon, 10 Nov 2003 17:14:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 40EE4580018 for ; Mon, 10 Nov 2003 17:13:52 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 17F15580010 for ; Mon, 10 Nov 2003 17:13:50 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAAMZo109558 for ; Mon, 10 Nov 2003 14:35:50 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 196: Peer SM Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:35:50 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 196: Peer SM Issues Submitter name: Ashwin Palekar Submitter email address: ashwinp@microsoft.com Date first submitted: Nov 10, 2003 Reference: Document: SM-01 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: In Figure 3, it is not clear from the diagrams that SUCCESS and FAILURE are terminal states; perhaps a function call is necessary to cause the packet to be sent. EapTunnelled should probably be a function call rather than a variable, so that there is no confusion that it is set when the tunnelled method is selected and applies to either cleartext or tunnelled packets. The EapTunnelled variable does not describe the behavior of current tunneled methods such as PEAP. For example the state IDENTITY is reached from the RECEIVED state if (selectedMethod == NONE || EapTunnelled). However inside PEAP, an Identity can't be sent when a method has been selected and isn't complete. Similarly, the transition from RECEIVED to GET_METHOD seems to occur on EapTunnell == TRUE even if a method has previously been selected and is in progress. This seems wrong. Suggest adding a getIdentity() call in the IDENTITY state, which can take into account the information that the peer has available, in order to determine the appropriate identity to put into the EAP-Response/Identity. This could include, for example, "hints" in the EAP-Request/Identity, default settings in the peer, etc. The state machine doesn't appear to suppport sequences of authentication methods within tunnels. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 18:14:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21145 for ; Mon, 10 Nov 2003 18:14:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 876C2580010; Mon, 10 Nov 2003 17:15:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 69FBE580019; Mon, 10 Nov 2003 17:15:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A18FF580023 for ; Mon, 10 Nov 2003 17:14:40 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3F92A580010 for ; Mon, 10 Nov 2003 17:14:34 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAAMaVQ09616 for ; Mon, 10 Nov 2003 14:36:31 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 195: Backend Authenticator SM review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:36:31 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 195: Backend Authenticator SM review Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: Nov 8, 2003 Reference: Document: SM-01 Comment type: T Priority: S Section: Multiple Rationale/Explanation of issue: pp. 21, Section 6 It's draft-ietf-eap-statemachine-01.pdf, not .ps, no? pp. 22, Figure 5 respMethod has the same value if it is a NAK or an expanded NAK. pp. 23 The definition of aaaMethodTimeout should make it clear that this method-provided hint is not used to control the AAA timeout, only the value of the Session-Timeout attribute sent by AAA. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 10 18:23:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21810 for ; Mon, 10 Nov 2003 18:22:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52C09580109; Mon, 10 Nov 2003 17:23:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 140CA580017; Mon, 10 Nov 2003 17:23:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 074E2580017 for ; Mon, 10 Nov 2003 17:22:37 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id E2701580010 for ; Mon, 10 Nov 2003 17:22:34 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAANKmF1018326; Tue, 11 Nov 2003 08:20:48 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAANKm0G018085; Tue, 11 Nov 2003 08:20:48 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA18084 ; Tue, 11 Nov 2003 08:20:48 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA23668; Tue, 11 Nov 2003 08:20:47 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA12082; Tue, 11 Nov 2003 08:20:47 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hAANKk9X011817; Tue, 11 Nov 2003 08:20:46 +0900 (JST) Received: from steelhead ([159.119.168.188]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HO500L65SUKZ9@tsbpo1.po.toshiba.co.jp>; Tue, 11 Nov 2003 08:20:45 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AJLJD-0007aK-00; Mon, 10 Nov 2003 15:18:59 -0800 From: Yoshihiro Ohba Subject: Re: [eap] EAP state machine In-reply-to: <3096.1068505617@marajade.sandelman.ottawa.on.ca> To: Michael Richardson Cc: Yoshihiro Ohba , eap@frascone.com, aland@nitros9.org, mah@eunet.at Message-id: <20031110231858.GN27208@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <20031110222913.GL27208@steelhead> <3096.1068505617@marajade.sandelman.ottawa.on.ca> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:18:58 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Mon, Nov 10, 2003 at 05:06:57PM -0600, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> When we use the word "standalone", it points to EAP > Yoshihiro> authenticator that shows a basic, non-passthrough > Yoshihiro> authenticator's behavior, as described in section 2 of the > Yoshihiro> state machines draft. > > Yoshihiro> In the above example, AP acts as a passthrough authenticator, > Yoshihiro> and the RADIUS server is a "backend" server to the passthough > Yoshihiro> authenticator, not a "standalone" authenticator. (AP is > Yoshihiro> talking to the backend server). > > okay. I understand the terminology now. OK. > > I don't see anything in the backend state machine to accomplish > retransmission. It says that the radius server retransmits... but so what? In Figure 5 (EAP Backend Authenticator State Machine), there is no "RETRANSMIT" state unlike standalone authenticator. So the diagram indicates that the backend authenticator does not perform timer-based retransmission. (i.e., we actually understand the RADIUS behavior.) Yoshihiro Ohba > > When it retransmits, it will be sending a response to the previous EAP > request, NOT the current one, so the IDs won't match, etc. > > ] Collecting stories about my dad: http://www.sandelman.ca/cjr/ | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBP7AaD4qHRg3pndX9AQGkIgP9HZAMG800CjVA9pT7WY/nyiRBIHgCgUdI > XDiHOJy6xvmR1VVI/auR7L14KydgGhvmhiL0JIlZM2BgZOHdfwLLqs6fgAPSqZ7B > UWQp0riJem6VIwyqXvhkiVULBifQeexLWJ7dmtGYzmUvixq/AVVDcgLaMpEpFkTT > Qv31hFJPLMs= > =5juS > -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 11:59:06 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27294 for ; Wed, 12 Nov 2003 11:59:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80EA1580027; Wed, 12 Nov 2003 10:59:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19CD9580018; Wed, 12 Nov 2003 10:59:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C94B4580017 for ; Wed, 12 Nov 2003 10:58:16 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 00716580010 for ; Wed, 12 Nov 2003 10:58:11 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hACGK1725323 for ; Wed, 12 Nov 2003 08:20:01 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 198: Other EAP Peer SM Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 08:20:00 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 198: Other EAP Peer SM issues Submitter name: Ashwin Palekar Submitter email address: ashwinp@microsoft.com Date first submitted: Nov 11, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-November/001831.html Document: SM-01 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: The IDENTITY method is independent of the method being negotiated. How do we deal with the case where different methods require different identities? During EAP authentication sequences, the server can ask for different identities for different eap methods how does the client know which identity it is supposed to provide? clientTimeout who is responsible for setting this? Is this set per request, per eap host, or is it based on some other criteria? eapTunnelled. Who sets this? It is not clear to me. Does the SM behavior when eapTunnelled is set really correspond to that of existing tunneled methods? I don't think so. Is portEnabled condition generic enough? Can it apply to any media, such as PPP? Why do we have allowNotification condition? Whats the use case that a specific eap method turns it on/off? Or is this an EAP setting? Chapter 4.2, in methodState=Done, it says The method always continues at this point. I think it should be ends instead. This document only provides timeout and keys to application. In protocols such as PEAP, other information is also returned such as EAP TLV. So perhaps the text on interfaces between EAP and methods should be clear that this is extensible. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 11:59:47 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27322 for ; Wed, 12 Nov 2003 11:59:45 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2DA6B58001A; Wed, 12 Nov 2003 10:59:22 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65E23580018; Wed, 12 Nov 2003 10:59:11 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A31B4580017 for ; Wed, 12 Nov 2003 10:58:54 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 9BDE4580010 for ; Wed, 12 Nov 2003 10:58:52 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hACGKg025362 for ; Wed, 12 Nov 2003 08:20:43 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 199: Full authenticator SM issue Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 08:20:42 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 199: Full authenticator SM issue Submitter name: Ashwin Palekar Submitter email address: ashwinp@microsoft.com Date first submitted: Nov 11, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-November/001832.html Document: SM-01 Comment type: T Priority: S Section: 7 Rationale/Explanation of issue: Can the EAP server forward to other servers if it cannot negotiate authentication? The EAP full authenticator seems to allow Pass-through in this case. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 12:16:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28282 for ; Wed, 12 Nov 2003 12:16:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F8F1580010; Wed, 12 Nov 2003 11:16:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEECE580018; Wed, 12 Nov 2003 11:16:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A9BC580010 for ; Wed, 12 Nov 2003 11:15:22 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 0C664580018 for ; Wed, 12 Nov 2003 11:15:18 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DB85B6A903; Wed, 12 Nov 2003 19:15:13 +0200 (EET) Message-ID: <3FB2699E.6070901@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 199: Full authenticator SM issue References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 19:10:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Issue 199: Full authenticator SM issue > Submitter name: Ashwin Palekar > Submitter email address: ashwinp@microsoft.com > Date first submitted: Nov 11, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-November/001832.html > Document: SM-01 > Comment type: T > Priority: S > Section: 7 > Rationale/Explanation of issue: > > Can the EAP server forward to other servers if it cannot negotiate > authentication? The EAP full authenticator seems to allow Pass-through in > this case. Do you mean the case where EAP is forwarded first to a RADIUS server, and then that forwards it *again* to yet another RADIUS server? I think this should be allowed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 12:23:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28462 for ; Wed, 12 Nov 2003 12:23:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92C3C580010; Wed, 12 Nov 2003 11:23:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0963580018; Wed, 12 Nov 2003 11:23:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFF10580018 for ; Wed, 12 Nov 2003 11:22:13 -0600 (CST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.frascone.com (Postfix) with ESMTP id BB195580010 for ; Wed, 12 Nov 2003 11:22:06 -0600 (CST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 09:22:02 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 12 Nov 2003 09:22:06 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Nov 2003 09:21:40 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 09:22:08 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 12 Nov 2003 09:22:02 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 Nov 2003 09:22:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 199: Full authenticator SM issue Message-ID: <340B5AC242DEF44AAFCD6DC102B51CD30385AC66@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [eap] Issue 199: Full authenticator SM issue Thread-Index: AcOpQLvGhZEVpCfATSqSB4ysrBOJJgAADGfw From: "Ashwin Palekar" To: , "Bernard Aboba" Cc: X-OriginalArrivalTime: 12 Nov 2003 17:22:01.0398 (UTC) FILETIME=[7BF2BD60:01C3A941] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 09:22:00 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable This is the case where EAP is forwarded to first RADIUS server; which tries to negotiate EAP methods with peer. If the client NAKs all the EAP methods proposed, the first RADIUS server forwards it to yet another RADIUS server. -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Jari Arkko Sent: Wednesday, November 12, 2003 9:11 AM To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 199: Full authenticator SM issue Bernard Aboba wrote: > Issue 199: Full authenticator SM issue > Submitter name: Ashwin Palekar > Submitter email address: ashwinp@microsoft.com > Date first submitted: Nov 11, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-November/001832.html > Document: SM-01 > Comment type: T > Priority: S > Section: 7 > Rationale/Explanation of issue: >=20 > Can the EAP server forward to other servers if it cannot negotiate > authentication? The EAP full authenticator seems to allow Pass-through in > this case. Do you mean the case where EAP is forwarded first to a RADIUS server, and then that forwards it *again* to yet another RADIUS server? I think this should be allowed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 14:24:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02742 for ; Wed, 12 Nov 2003 14:24:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67C3C58001A; Wed, 12 Nov 2003 13:24:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C155F580017; Wed, 12 Nov 2003 13:24:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4649F580017 for ; Wed, 12 Nov 2003 13:23:02 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 7669D580010 for ; Wed, 12 Nov 2003 13:23:00 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F10CE6A904; Wed, 12 Nov 2003 21:22:55 +0200 (EET) Message-ID: <3FB2878C.7030006@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ashwin Palekar Cc: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Issue 199: Full authenticator SM issue References: <340B5AC242DEF44AAFCD6DC102B51CD30385AC66@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <340B5AC242DEF44AAFCD6DC102B51CD30385AC66@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 21:18:36 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Ashwin Palekar wrote: > This is the case where EAP is forwarded to first RADIUS server; which > tries to negotiate EAP methods with peer. If the client NAKs all the EAP > methods proposed, the first RADIUS server forwards it to yet another > RADIUS server. Yes. I have looked at the state machine again, and now I believe it does not support this (and that is OK). The way that I read the state machines is that the full machine is for the NAS that either does the authentication itself or forwards it to a RADIUS server. But the RADIUS server side should follow only the backend machine. And the backend machine does not have a transition to send the authentication somewhere else. Pasi, John, & co -- is this your interpretation too? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 14:55:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04203 for ; Wed, 12 Nov 2003 14:54:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B24B658001A; Wed, 12 Nov 2003 13:55:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC06D580017; Wed, 12 Nov 2003 13:55:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EFAE580010 for ; Wed, 12 Nov 2003 13:54:05 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 6A032580018 for ; Wed, 12 Nov 2003 13:54:03 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hACJrue9014298; Thu, 13 Nov 2003 04:53:56 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hACJruxe020577; Thu, 13 Nov 2003 04:53:56 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA20574 ; Thu, 13 Nov 2003 04:53:55 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA11241; Thu, 13 Nov 2003 04:53:55 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA13231; Thu, 13 Nov 2003 04:53:53 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hACJrron022664; Thu, 13 Nov 2003 04:53:53 +0900 (JST) Received: from steelhead ([159.119.168.73]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HO90005M8LR4X@tsbpo1.po.toshiba.co.jp>; Thu, 13 Nov 2003 04:53:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AK13A-0001Ri-00; Wed, 12 Nov 2003 11:53:12 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Issue 199: Full authenticator SM issue In-reply-to: <340B5AC242DEF44AAFCD6DC102B51CD30385AC66@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> To: Ashwin Palekar Cc: jari.arkko@piuha.net, Bernard Aboba , eap@frascone.com Message-id: <20031112195312.GB885@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <340B5AC242DEF44AAFCD6DC102B51CD30385AC66@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 11:53:12 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) In this case, the second RADIUS server will receive a Nak while it is in "PICK_UP_METHOD" state. There are two issues: - Does RFC3579 allow "pickup" operation when the initial EAP-Response is a Nak? I think the document is a bit vague on this (at least it does not seem to prohibit the case). - If the above question is yes, how does the backend authenticator state machine work in this case? I think there would need a state transition from "PICK_UP_METHOD" to "NAK" state to explicitly support the case. Yoshihiro Ohba On Wed, Nov 12, 2003 at 09:22:00AM -0800, Ashwin Palekar wrote: > This is the case where EAP is forwarded to first RADIUS server; which > tries to negotiate EAP methods with peer. If the client NAKs all the EAP > methods proposed, the first RADIUS server forwards it to yet another > RADIUS server. > > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf > Of Jari Arkko > Sent: Wednesday, November 12, 2003 9:11 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Issue 199: Full authenticator SM issue > > Bernard Aboba wrote: > > Issue 199: Full authenticator SM issue > > Submitter name: Ashwin Palekar > > Submitter email address: ashwinp@microsoft.com > > Date first submitted: Nov 11, 2003 > > Reference: > > > http://mail.frascone.com/pipermail/public/eap/2003-November/001832.html > > Document: SM-01 > > Comment type: T > > Priority: S > > Section: 7 > > Rationale/Explanation of issue: > > > > Can the EAP server forward to other servers if it cannot negotiate > > authentication? The EAP full authenticator seems to allow Pass-through > in > > this case. > > Do you mean the case where EAP is forwarded first to a RADIUS server, > and then that forwards it *again* to yet another RADIUS server? > > I think this should be allowed. > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 15:06:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05059 for ; Wed, 12 Nov 2003 15:05:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E29F2580010; Wed, 12 Nov 2003 14:06:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 671BE580017; Wed, 12 Nov 2003 14:06:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66392580017 for ; Wed, 12 Nov 2003 14:05:25 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id A9009580010 for ; Wed, 12 Nov 2003 14:05:23 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hACK5Me9018119; Thu, 13 Nov 2003 05:05:22 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hACK5McD026534; Thu, 13 Nov 2003 05:05:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA26533 ; Thu, 13 Nov 2003 05:05:22 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA15041; Thu, 13 Nov 2003 05:05:21 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA21283; Thu, 13 Nov 2003 05:05:21 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hACK5Kon001634; Thu, 13 Nov 2003 05:05:20 +0900 (JST) Received: from steelhead ([159.119.168.73]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HO90009J94OEB@tsbpo1.po.toshiba.co.jp>; Thu, 13 Nov 2003 05:05:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AK1DS-0001Sn-00; Wed, 12 Nov 2003 12:03:50 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Issue 199: Full authenticator SM issue In-reply-to: <3FB2878C.7030006@piuha.net> To: Jari Arkko Cc: Ashwin Palekar , Bernard Aboba , eap@frascone.com Message-id: <20031112200350.GC885@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <340B5AC242DEF44AAFCD6DC102B51CD30385AC66@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <3FB2878C.7030006@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 12:03:50 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Wed, Nov 12, 2003 at 09:18:36PM +0200, Jari Arkko wrote: > Ashwin Palekar wrote: > >This is the case where EAP is forwarded to first RADIUS server; which > >tries to negotiate EAP methods with peer. If the client NAKs all the EAP > >methods proposed, the first RADIUS server forwards it to yet another > >RADIUS server. > > Yes. > > I have looked at the state machine again, and now I believe > it does not support this (and that is OK). > > The way that I read the state machines is that the full > machine is for the NAS that either does the authentication > itself or forwards it to a RADIUS server. But the RADIUS > server side should follow only the backend machine. And > the backend machine does not have a transition to send > the authentication somewhere else. Pasi, John, & co -- > is this your interpretation too? I think that, if the first RADIUS server uses full authenticator state machine, with setting retransmission timer an infinite value (to prohibit timer-based retransmission), it is possible to support the scenario on the first RADIUS server. Yoshihiro Ohba > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 12 19:50:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20137 for ; Wed, 12 Nov 2003 19:50:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A63EB580019; Wed, 12 Nov 2003 18:50:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70D69580017; Wed, 12 Nov 2003 18:50:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BC3D580017 for ; Wed, 12 Nov 2003 18:49:04 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6F796580010 for ; Wed, 12 Nov 2003 18:49:02 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAD0Ao320372 for ; Wed, 12 Nov 2003 16:10:51 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Analysis of DoS Attack on EAP State Machine (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 12 Nov 2003 16:10:50 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) ---------- Forwarded message ---------- Date: Wed, 12 Nov 2003 16:23:31 -0700 From: Jim Burns To: Bernard Aboba Cc: Paul Congdon Subject: 802.1X Rev D7.1 State Machine Comment 30 Hello Bernard, We have analyzed your comment 30 on 802.1X Rev D7.1 (reappears below) and would like to discuss our understanding with you. If you feel it would be useful to forward this to the EAP state machine folks please feel free to do so. ------------------------------------------------------------------ Summary: The summary of our analysis is that you were either attempting to ensure that the 802.1X and EAP state machines stayed synchronized or that you wished to avoid a denial of service attack. If it was the former, this is already handled by passing through the RESTART state and the two state machines handshaking on the eapRestart variable. If it is the latter, then we agree that you have detected a potential denial of service attack against EAP running over EAPoL, but that security is not compromised and the state machines continue to operate. In addition, the changes required to prevent this denial of service attack would be extensive and would not prevent other denial of service attacks so is not worth the effort in the current revision of 802.1X. Although Link Security will certainly be taking on this and other issues. Due to this analysis we have rejected this comment, but we want to pass along our complete analysis. ------------------------------------------------------------------ Details: Bernard's original comment 30: CLAUSE: 8.2.11 PAGE: 65 LINE: 15 COMMENT START: A transition is made to RESTART state from several states (CONNECTING, AUTHENTICATED, HELD) based on receipt of *any* EAP packet (eapolEap). It seems like this should only occur if an EAP Request is received and EAP indicates that method- State==INIT within the EAP state machine. COMMENT END: SUGGESTED CHANGES START: Change the condition for transition to RESTART from "eapolEap" to "eapolEap && methodState==INIT". Include definition of the methodState variable from the EAP state machine. SUGGESTED CHANGES END: ----------------------------------------------------------------- 802.1X Philosophy: We are a transport for EAP and carry out this transport without intruding on the EAP header which means that EAP may freely change without affecting the transport on which it is carried. It is our assumption that EAP is prepared to handle the arrival of unexpected EAP frames and the EAP state machines reflect this and the connection between the two machines allow EAP to indicate an unexpected frame without causing a problem in the machines. Our analysis of what happens today if an unexpected eapolEAP frame arrives: SUPPLICANT STATE MACHINES (FS=Front End Supplicant, BS=Back End Supplicant) - Assume we begin in 1X FS CONNECTING - eapEAPOL frame arrives, assume it is an unexpected EAP for a supplicant, such as an EAP response , it could just as easily be a bogus EAP request (either maliciously created or a glitch) - 1X FS RESTART - set eapRestart - EAP DISABLED - reset eapRestart - EAP INITIALIZE - EAP IDLE - 1X FS AUTHENTICATING - set suppStart - 1X BS REQUEST - set eapReq - EAP RECEIVED - attempts to parse eapReq, fails due to it being a response - EAP DISCARD - reset eapReq, set eapNoResp - EAP IDLE - begin idleWhile Timeout set to ClientTimeout - 1X BS RECEIVE - begin authWhile Timeout set to authPeriod <<< at this point, either we receive an EAP request, another unexpected EAP frame, EAP times out or 1X times out >>> ** If we receive an EAP request then, assuming it is a valid first request then we will authenticate. ** If we receive another unexpected EAP frame then we will repeat beginning at the EAP RECEIVED state above ** If EAP times out then: - EAP Failure - set eapFail - 1X BS FAIL - set suppFail - 1X BS IDLE - reset suppStart - 1X FS HELD - after held period - 1X FS CONNECTING ** If 1X times out then: - 1X BS TIMEOUT - set suppTimeout - 1X BS IDLE - reset suppStart - 1X FS CONNECTING The are no differences in the above state machine traces for the case that you start in the HELD or AUTHENTICATED other than the starting state. So in all the cases, the DoS attack of sending an unexpected EAP frame will result in an attempt to do another authentication. If there had been a pre-existing authenticated connection (in the case that we began in the AUTHENTICATED state) this connection will not be broken during the reauthentication. Furthermore, if we begin in the AUTHENTICATED state, the DoS attack is made less likely in .11i because the EAPOL frame will arrive encrypted using the current keys and will be more difficult for a malicious attacker to spoof an EAPOL frame. So, this attack appears to mostly be against clients who have not begun authentication (are in the CONNECTING state) or who have failed an authentication (are in the HELD state). Sincerely, Jim Burns _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 13 14:52:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15274 for ; Thu, 13 Nov 2003 14:52:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12EA0580027; Thu, 13 Nov 2003 13:52:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD881580018; Thu, 13 Nov 2003 13:52:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFA62580018 for ; Thu, 13 Nov 2003 13:51:13 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 99911580010 for ; Thu, 13 Nov 2003 13:51:11 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hADJpAe9020608; Fri, 14 Nov 2003 04:51:10 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hADJpAf6001676; Fri, 14 Nov 2003 04:51:10 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA01667 ; Fri, 14 Nov 2003 04:51:09 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA15023; Fri, 14 Nov 2003 04:51:09 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA25887; Fri, 14 Nov 2003 04:51:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hADJp8on015310; Fri, 14 Nov 2003 04:51:08 +0900 (JST) Received: from steelhead ([159.119.168.170]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HOB003RL356ME@tsbpo1.po.toshiba.co.jp>; Fri, 14 Nov 2003 04:51:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AKNSv-0002Jf-00; Thu, 13 Nov 2003 11:49:17 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Issue 193: Peer SM review In-reply-to: To: Bernard Aboba Cc: eap@frascone.com Message-id: <20031113194917.GD6934@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 13 Nov 2003 11:49:17 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I have one comment in line. On Sun, Nov 09, 2003 at 07:10:34PM -0800, Bernard Aboba wrote: > Issue 193: Peer SM review > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 8, 2003 > Reference: > Document: SM-01 > Comment type: T > Priority: S > Section: 2, 4 > Rationale/Explanation of issue: > > pp. 5, first paragraph > > "pass EAP messages to a Backend Server where the real Authentication > Method resides" > > As is made clear later, the pass-through authenticator does *not* forward > all EAP messages to the backend authentication server, only EAP-Responses. > Rephrase to: > > "pass EAP-Response messages to a Backend Server where the Authentication > Method resides" > > Third paragraph: > > The implication is the EAP method demultiplexing depends on the lower > layer. This is not the case because all EAP implementations on all media > must support demultiplexing (whether they support an authenticator or > peer listener is another issue). > > Suggest replacing the paragraph with: > > "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes > incoming EAP packets. Packets with Code=2 (Response) are delivered to the > Authenticator state machine, while packets with Code=1 (Request), 3 > (Success) or 4 (Failure) are delivered to the Peer state machine." > > Page 9, Figure 3. > > The notation used later (Figure 6) is more clear than the use of the "|" > operator as in Figure 3. I'd recommend adopting the Figure 6 notation > everywhere. > > It would appear to me that methodState is a variable that needs to be > exported from the peer to the lower layer. This is so that lower layer > state machines such as 802.1X can know whether their own state machines > should be affected or not. I don't think exposing methodState to the lower layer is a good idea. Since the state machine draft is an informational document, an implementation can be based on yet another state machine that realizes the same on-the-wire behavior but uses a different set of states. If a lower layer requires such internal state exposition, I believe there is something wrong with the lower layer design... Yoshihiro Ohba > > The INITIALIZE state does not initialize all variables. Non-initialized > variables > include: > > eapKeyData = NONE > eapKeyAvailable = FALSE > eapSuccess = FALSE > eapFail = FALSE > methodState = NONE > selectedMethod = NONE > decision = FAIL > > The initialization values seem important since transitions can be based on > them before they are initialized. Re-initializing variables in the > INITIALIZE state is a bit different from giving the variables initial > values before they are ever used. > > Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE state. > I assume this means that this variable can be assigned one of two values, > at the implementation's descretion. I think we want this variable > initialized to FAIL. > > There is a transition from the IDLE state to the SUCCESS and FAILURE > states. This occurs without appearing to require receipt of a packet. I > think that this can't be the case; something has to be received at some > point for the peer to leave idleWhile OR it is a situation where the peer > is testing whether the authenticator is EAP-capable (e.g. > a wired LAN application). > > The transition to FAILURE state occurs when an alternative indication of > Rejection occurs (e.g. Disassociate); when the idleWhile timer runs out > and the decision is not an unconditional success; when an alternative > indication of success is available but the decision is FAIL. > > There is also a transition from the IDLE state to the SUCCESS state. > This can occur when the idleWhile timer runs out and the decision is > an unconditional success; or when an alternative indication of success > is available and the decision is not FAILURE. > > It seems that the INITIALIZE state will need to have the correct default > values or these transitions may not occur correctly. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 13 17:24:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24517 for ; Thu, 13 Nov 2003 17:24:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E316E580027; Thu, 13 Nov 2003 16:24:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9CF0580019; Thu, 13 Nov 2003 16:24:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AF2AB580019 for ; Thu, 13 Nov 2003 16:23:32 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DC7EA580018 for ; Thu, 13 Nov 2003 16:23:30 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hADLjEk30773 for ; Thu, 13 Nov 2003 13:45:14 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Slides from IETF58 EAP WG Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 13 Nov 2003 13:45:14 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The slides from the EAP WG presentations at IETF 58 are available here: http://www.drizzle.com/~aboba/IETF58/EAP.zip _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aczpress@mail.com Fri Nov 14 01:15:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14515 for ; Fri, 14 Nov 2003 01:15:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKXFM-0006uZ-00 for eap-archive@ietf.org; Fri, 14 Nov 2003 01:15:56 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AKX5o-0006kU-02 for eap-archive@ietf.org; Fri, 14 Nov 2003 01:06:04 -0500 Received: from [219.145.220.144] (helo=ietf.org) by manatick with smtp (Exim 4.24) id 1AKWzj-0001Sw-Mp for eap-archive@ietf.org; Fri, 14 Nov 2003 00:59:49 -0500 Reply-To: "ConstruNews" From: "Temas "Patrulhados"" To: eap-archive@ietf.org Subject: Lindenberg: opiniões "politicamente incorretas" vêm sendo marginalizadas ref.: azb X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Fri, 14 Nov 2003 00:59:49 -0500

hpq EnEspañol - InEnglish

Temas "patrulhados"

Opiniões "politicamente incorretas" vêm sendo marginalizadas no debate nacional, diz Lindenberg

* Patrulhamento...

Em meios empresariais e religiosos continua repercutindo o livro "Os católicos e a economia de mercado", de autoria de Adolpho Lindenberg. O trabalho denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, comentários, livros, reportagens e opiniões "politicamente incorretas", não afinadas com as assim denominadas "causas sociais". Noutras palavras, os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".

* Antídoto

O antídoto para esta situação de violência psicológica e espiritual consiste na difusão - por meios alternativos, se preciso for - de informações idôneas, capazes de esclarecer a opinião pública e provocar debates construtivos. Com efeito, uma vez rompidos os anteparos da censura, cada um em seu próprio ambiente poderá, sem medo, manifestar sua opinião sobre os assuntos 'patrulhados'. É a proposta inovadora de um programa de libertação ideológica, impulsionado pela coragem, em defesa do esclarecimento popular.

* Esclarecimento!

Esse programa tem alcance prático, especialmente para os católicos. O destaque que, há muitos anos, a mídia vem dando aos pronunciamentos de bispos e sacerdotes (em geral ligados à CNBB), que favorecem as invasões de terras promovidas pelos MST, bem como às repetidas críticas à Área de Livre Comércio das Américas (ALCA), às privatizações, à alegada ameaça das multinacionais e do capital estrangeiro, e até mesmo ao plantio de transgênicos, apresenta dois inconvenientes sérios. Em primeiro lugar, tais pronunciamentos podem criar a impressão de que a maioria do Episcopado e dos setores mais responsáveis do Clero brasileiro pensa como esses prelados. Em segundo, de que as teses da Teologia da Libertação têm fundamentos sólidos na doutrina católica. Tudo isso tem muita importância prática. Com efeito, na vasta rede de movimentos contestatários, ativa no país inteiro, a ala progressista religiosa se sobressai hoje como o setor mais ativo e mais radical nas proposições.

* Temáticas

Diante deste cenário e visando alertar a opinião pública católica, o livro acima citado procura debater as seguintes temáticas:

- Capitalismo, globalização, neoliberalismo e privatizações seriam os grandes responsáveis pelos bolsões de misérias, desigualdades sociais e dependência externa (isto é, dos Estados Unidos)?

- Os programas sociais estatais seriam a solução para combater a fome, o analfabetismo, o atraso e a indigência das classes mais pobres do Brasil?

- O materialismo, o anonimato, a exclusão social, o relacionamento burocrático entre as pessoas são causados muito especialmente pelo crescimento desordenado das cidades ou sobretudo pela descristianização de nossos hábitos?

* Informe-se!

Informe-se desses assuntos - e ainda de vários outros - no livro "Os católicos e a economia de mercado". Você pode adquiri-lo, clicando nos links abaixo. E complemente seus dados com artigos de Adolpho Lindenberg que lhe serão enviados gratuitamente (clique nos links abaixo). O autor analisa tais assuntos com base na doutrina social católica, expressa nas encíclicas: discorre sobre as relações entre a economia e a moral, liberdade e responsabilidade dos atos econômicos, direito de propriedade, respeito às leis naturais no mercado, liceidade do lucro, assistência social, relações humanas na empresa e na vida civil.

* Destaque

E, por fim, um ponto com merecido destaque em "Os católicos e a economia de mercado": como as reivindicações "sociais" têm como fim o socorro aos necessitados e a diminuição de desigualdades sociais, é indispensável ter em vista que esse objetivo só poderia ser alcançado com a elevação significativa do padrão de vida do povo (para o autor, por uma dose maior de capitalismo autêntico) e sobretudo pela recristianização da sociedade. A assistência aos necessitados deve, além do mais, sempre que possível, ter um tom pessoal, familiar, típico das sociedades orgânicas harmonicamente diferenciadas, das quais ainda se encontram reflexos vivos em antigas cidades do interior brasileiro. Ali ainda hoje subsistem hospitais, creches, asilos, de iniciativa religiosa e particular, que atendem aos necessitados de modo mais humano e eficaz que a assistência estatal prestada nas grandes metrópoles.

LINKS DE OPINIÃO:

Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 30 de novembro, usando qualquer um dos três links seguintes, serão sorteados 10 exemplares do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).

Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)

Lindenberg:Discordo (idem)

Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)

LINKS PARA ADQUIRIR O LIVRO

Lindenberg:DesejoAdquirirLivroEditora (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais SEDEX)

Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 30 de novembro: R$ 8,80)

LINKS PARA RECEBER ARTIGOS GRATUITOS:

PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)

GratuitamenteArtigosAnteriores

GratuitamenteProximosArtigos

GratuitamenteTodosOsArtigos

Para solicitar alguns títulos específicos:

Artigo1 "Acabemos com mais uma exclusão: o Brasil precisa ouvir a voz do Clero sem-microfone"

Artigo2 "Moral e Economia"

Artigo3 "Assistência Social e Capitalismo não precisam estar em guerra: podem dar o abraço da paz"

Artigo4 "Intervencionismo estatal e fermentação revolucionária versus assistência particular e personalizada"

Próximos temas:

"Capitalismo, globalização, neoliberalismo, privatizações"

"Economia de Mercado, Neoliberalismo"

"Estatização da Economia"

LINK DE REMOÇÃO

ConstruNews:Remover eap-archive@ietf.org

LINK PARA TOMAR CONTATO COM LINDENBERG

Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)

A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews

 

 

From eap-admin@frascone.com Fri Nov 14 20:57:33 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09425 for ; Fri, 14 Nov 2003 20:57:30 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D07C3580018; Fri, 14 Nov 2003 19:57:17 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1ECAF580138; Fri, 14 Nov 2003 19:57:10 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2150D580018 for ; Fri, 14 Nov 2003 19:56:42 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 052F0580014 for ; Fri, 14 Nov 2003 19:56:40 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAF1ucA13326 for ; Sat, 15 Nov 2003 03:56:38 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sat, 15 Nov 2003 03:56:37 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 17:56:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: EAP Codepoints Thread-Index: AcOqxIeZDTGNX4/5Ql6CmGlImjzevAAVwn2w From: To: X-OriginalArrivalTime: 15 Nov 2003 01:56:36.0367 (UTC) FILETIME=[B3B0A1F0:01C3AB1B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP Codepoints Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 14 Nov 2003 20:56:35 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi All, Apparently, I said something at the EAP meeting in Minneapolis that has caused some confusion about the IANA allocation of EAP codepoints. Just to erase any confusion, I want to make it clear that I support the current wording in the EAP draft -- that EAP codepoints should be allocated on the basis of expert review. This represents an increase in scrutiny from the current policy (first-come-first-served), which I think is appropriate. I do not believe that EAP codepoints should require an IETF standard, and I do believe that it would be appropriate to allocate EAP codepoints in some situations (vendor-specific or environment-specific) where it wouldn't make sense to produce an IETF standard.=20 I do hope that the WG will consider standardizing secure, general=20 purpose EAP methods in the future, but I do not believe that we should require a standards-track document in order to obtain a=20 codepoint. If there are any questions about this, please ask. Margaret _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Nov 15 01:41:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15792 for ; Sat, 15 Nov 2003 01:40:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 460CE580027; Sat, 15 Nov 2003 00:41:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C7D2580018; Sat, 15 Nov 2003 00:41:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D0249580018 for ; Sat, 15 Nov 2003 00:40:49 -0600 (CST) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by mail.frascone.com (Postfix) with ESMTP id 4BC26580016 for ; Sat, 15 Nov 2003 00:40:48 -0600 (CST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id D13BF1C01DF3; Sat, 15 Nov 2003 01:40:47 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id CACAC1C00A7D; Sat, 15 Nov 2003 01:40:47 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Sat, 15 Nov 2003 01:40:47 -0500 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: Yoshihiro Ohba , Bernard Aboba Cc: eap@frascone.com Subject: RE: [eap] Issue 193: Peer SM review MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 15 Nov 2003 01:40:44 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I agree completely with Yoshihiro. The lower layer (e.g. 802.1X) does not want to know what EAP method is running. Ideally, the lower layers might even want to support another authentication protocol other than EAP (though this is not an explicit design objective of 802.1aa now called 802.1X-D7.1). Tying the interface between the layers with method specific details is not a good idea. Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Yoshihiro Ohba > Sent: Thursday, November 13, 2003 11:49 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Issue 193: Peer SM review > > > I have one comment in line. > > On Sun, Nov 09, 2003 at 07:10:34PM -0800, Bernard Aboba wrote: > > Issue 193: Peer SM review > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: Nov 8, 2003 > > Reference: > > Document: SM-01 > > Comment type: T > > Priority: S > > Section: 2, 4 > > Rationale/Explanation of issue: > > > > pp. 5, first paragraph > > > > "pass EAP messages to a Backend Server where the real > Authentication > > Method resides" > > > > As is made clear later, the pass-through authenticator does *not* > > forward all EAP messages to the backend authentication server, only > > EAP-Responses. Rephrase to: > > > > "pass EAP-Response messages to a Backend Server where the > > Authentication Method resides" > > > > Third paragraph: > > > > The implication is the EAP method demultiplexing depends on > the lower > > layer. This is not the case because all EAP implementations on all > > media must support demultiplexing (whether they support an > > authenticator or peer listener is another issue). > > > > Suggest replacing the paragraph with: > > > > "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes > > incoming EAP packets. Packets with Code=2 (Response) are > delivered to > > the Authenticator state machine, while packets with Code=1 > (Request), > > 3 > > (Success) or 4 (Failure) are delivered to the Peer state machine." > > > > Page 9, Figure 3. > > > > The notation used later (Figure 6) is more clear than the > use of the > > "|" operator as in Figure 3. I'd recommend adopting the Figure 6 > > notation everywhere. > > > > It would appear to me that methodState is a variable that > needs to be > > exported from the peer to the lower layer. This is so that > lower layer > > state machines such as 802.1X can know whether their own state > > machines should be affected or not. > > I don't think exposing methodState to the lower layer is a > good idea. Since the state machine draft is an informational > document, an implementation can be based on yet another state > machine that realizes the same on-the-wire behavior but uses > a different set of states. If a lower layer requires such > internal state exposition, I believe there is something wrong > with the lower layer design... > > Yoshihiro Ohba > > > > > > > The INITIALIZE state does not initialize all variables. > > Non-initialized variables > > include: > > > > eapKeyData = NONE > > eapKeyAvailable = FALSE > > eapSuccess = FALSE > > eapFail = FALSE > > methodState = NONE > > selectedMethod = NONE > > decision = FAIL > > > > The initialization values seem important since transitions can be > > based on them before they are initialized. Re-initializing > variables > > in the INITIALIZE state is a bit different from giving the > variables > > initial values before they are ever used. > > > > Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE > > state. I assume this means that this variable can be > assigned one of > > two values, at the implementation's descretion. I think we > want this > > variable initialized to FAIL. > > > > There is a transition from the IDLE state to the SUCCESS > and FAILURE > > states. This occurs without appearing to require receipt of > a packet. > > I think that this can't be the case; something has to be > received at > > some point for the peer to leave idleWhile OR it is a > situation where > > the peer is testing whether the authenticator is > EAP-capable (e.g. a > > wired LAN application). > > > > The transition to FAILURE state occurs when an alternative > indication > > of Rejection occurs (e.g. Disassociate); when the idleWhile > timer runs > > out and the decision is not an unconditional success; when an > > alternative indication of success is available but the decision is > > FAIL. > > > > There is also a transition from the IDLE state to the > SUCCESS state. > > This can occur when the idleWhile timer runs out and the > decision is > > an unconditional success; or when an alternative indication > of success > > is available and the decision is not FAILURE. > > > > It seems that the INITIALIZE state will need to have the correct > > default values or these transitions may not occur correctly. > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 17 14:03:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28599 for ; Mon, 17 Nov 2003 14:03:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4356958013A; Mon, 17 Nov 2003 13:03:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCB0258013B; Mon, 17 Nov 2003 13:03:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E415580139 for ; Mon, 17 Nov 2003 13:02:09 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id CE98B580136 for ; Mon, 17 Nov 2003 13:02:06 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hAHJ23e9009460; Tue, 18 Nov 2003 04:02:03 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hAHJ23pr017704; Tue, 18 Nov 2003 04:02:03 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id EAA17703 ; Tue, 18 Nov 2003 04:02:03 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id EAA13138; Tue, 18 Nov 2003 04:02:03 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id EAA05044; Tue, 18 Nov 2003 04:02:02 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hAHJ21on004716; Tue, 18 Nov 2003 04:02:02 +0900 (JST) Received: from steelhead ([159.119.168.87]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HOI00ES7FJCZG@tsbpo1.po.toshiba.co.jp>; Tue, 18 Nov 2003 04:02:01 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ALobH-0006cy-00; Mon, 17 Nov 2003 10:59:51 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Issue 198: Other EAP Peer SM Issues In-reply-to: To: Bernard Aboba Cc: eap@frascone.com Message-id: <20031117185951.GD24363@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 17 Nov 2003 10:59:51 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Wed, Nov 12, 2003 at 08:20:00AM -0800, Bernard Aboba wrote: > Issue 198: Other EAP Peer SM issues > Submitter name: Ashwin Palekar > Submitter email address: ashwinp@microsoft.com > Date first submitted: Nov 11, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-November/001831.html > Document: SM-01 > Comment type: T > Priority: S > Section: 4 > Rationale/Explanation of issue: > > The IDENTITY method is independent of the method being negotiated. How do > we deal with the case where different methods require different > identities? The case is supposed to be handled by each method with defining method-specific identity handling. It might be better to explicitly mention this in the statemachines draft. > > During EAP authentication sequences, the server can ask for different > identities for different eap methods how does the client know which > identity it is supposed to provide? The same as above. > > clientTimeout who is responsible for setting this? Is this set per > request, per eap host, or is it based on some other criteria? I think the draft is not clear on this. The current peer state machine reads that idleWhile variable is set to clientTimerout value even when the peer receives an invalid EAP message, which should not actually change the timer value. Speaking about my EAP peer implementation, the clientTimeout can be set either by applications that use the EAP peer state machine or by EAP methods. The idleWhile timer is set only when the state enters "IDLE" state from "INITIALIZE" state. > > eapTunnelled. Who sets this? It is not clear to me. > > Does the SM behavior when eapTunnelled is set really correspond to that of > existing tunneled methods? I don't think so. I agree. The variable eapTunnelled is defined without describing how sequence of methods inside a tunneling method can be supported with this state machine. I think we need to do one of the following: o Remove eapTunneled variable. o Describe details on how sequence of methods inside a tunneling method is supported. If doing the latter is a hard thing, I would suggest just removing the eapTunneled variable. But if the latter can be easily done, it might be helpful to describe more about sequencing. > > Is portEnabled condition generic enough? Can it apply to any media, such > as PPP? I don't think portEnabled condition is generic enough. PANA and IKEv2 do not have a notion of port. My implementation uses more generic "Start()" and "Restart()" functions in the API, which modify portEnabled and eapRestart conditions (i.e., the variables are used just to follow the state machine draft, not really necessary IMHO.) > > Why do we have allowNotification condition? Whats the use case that a > specific eap method turns it on/off? Or is this an EAP setting? According to the description in section 5.2 of RFC2284bis, this is basically eap method settings (except that EAP peer state machine just initializes the condition to TRUE). > > Chapter 4.2, in methodState=Done, it says The method always continues at > this point. I think it should be ends instead. I agree. > > This document only provides timeout and keys to application. In protocols > such as PEAP, other information is also returned such as EAP TLV. So > perhaps the text on interfaces between EAP and methods should be clear > that this is extensible. Perhaps if we add the following text in section 8 "Implementation Considerations", that should be sufficient: "Implementations may define an additional interface to pass method-specific information between methods and applications. Such method-specific interface definition can be left to implementations and thus is not defined in this document." Yoshihiro Ohba > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 17 16:57:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07765 for ; Mon, 17 Nov 2003 16:56:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E97E58010A; Mon, 17 Nov 2003 15:57:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7A99F58012E; Mon, 17 Nov 2003 15:57:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55BEC58012E for ; Mon, 17 Nov 2003 15:56:53 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3518E58010A for ; Mon, 17 Nov 2003 15:56:51 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAHLHuV14011 for ; Mon, 17 Nov 2003 13:18:10 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 200: Endpoint verification Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 17 Nov 2003 13:17:56 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 200: Endpoint verification Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: Nov 17, 2003 Reference: Document: RFC2284bis-06 Comment type: T Priority: S Section: 4 Rationale/Explanation of issue: The Security Claims section doesn't include a claim for a solution to the "Lying NAS" problem, and this attack is not included in the threat model either. Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following security claim: Endpoint verification: No Add to Section 7.1: [10] An attacker acting as an authenticator may provide inconsistent information to the EAP peer and server. This includes impersonating another authenticator, or communicating incorrect information via out-of-band mechanisms such as via a AAA or lower layer protocol. Add the following definition to section 7.2.1: Endpoint verification The verification within an EAP method of endpoint identifiers communicated out of band, such as via a AAA or lower layer protocol. Add Section 7.15: 7.15 Endpoint Verification It is possible for a compromised or poorly implemented EAP authenticator to communicate inconsistent information to the EAP peer and server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms such as via a AAA or lower layer protocol. Where EAP is used in passthrough mode, the EAP peer typically does not verify the identity of the authenticator, it only verifies that the authenticator is trusted by the EAP server. This lack of endpoint verification creates a potential security vulnerability. While [RFC3579] Section 4.3.7 describes how an EAP authenticator providing incorrect information to a AAA server (such as a forged NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address attributes) can be detected, it is possible for the AP to provide the correct information to the AAA server while communicating incorrect information to the EAP peer via a lower layer protocol. For example, it is possible for an authenticator to utilize another authenticator's Calling-Station-Id in communicating with the EAP peer, or for the authenticator to provide incorrect information on the peer's Calling-Station-Id to the AAA server. In order to address this vulnerability, EAP methods may support a protected exchange of endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such an exchange, the EAP server could match the Called-Station-Id and Calling-Station-Id provided by the EAP peer against that provided by the authenticator via the AAA protocol. Similarly, if the peer is provided with the authenticator's NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address via the lower layer protocol, it could provide this information to the EAP server via the EAP method, allowing the EAP server to match it against the equivalent information provided by the authenticator via the AAA protocol. Where discrepancies exist, these SHOULD be logged. Add to non-normative references: [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", RFC 3162, August 2001. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 18 10:15:08 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25023 for ; Tue, 18 Nov 2003 10:15:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 29A61580138; Tue, 18 Nov 2003 09:15:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AA050580139; Tue, 18 Nov 2003 09:15:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 596C5580138 for ; Tue, 18 Nov 2003 09:14:01 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id EF644580014 for ; Tue, 18 Nov 2003 09:13:58 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAIFY8o06720 for ; Tue, 18 Nov 2003 07:34:11 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Propsoed resolution to Issue 201: Some NITs Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 18 Nov 2003 07:34:07 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 201 is enclosed below. The proposed resolution is as follows: Replace "acknowledged result indications" with "protected result indications" throughout the document. In Section 7.4, change: Where EAP is tunneled within another protocol that omits peer authentication, there exists a potential vulnerability to man-in-the-middle attack. To: Where EAP is tunneled within another protocol that omits peer authentication, there exists a potential vulnerability to man-in-the-middle attack. For details, see [BINDING] and [MiTM]. Change: [b] Requiring cryptographic binding between the EAP tunneling protocol and the tunneled EAP methods. Where cryptographic binding is supported, a mechanism is also needed to protect against downgrade attacks that would bypass it. To: [b] Requiring cryptographic binding between the EAP tunneling protocol and the tunneled EAP methods. Where cryptographic binding is supported, a mechanism is also needed to protect against downgrade attacks that would bypass it. For further details on cryptographic binding, see [BINDING]. Add the following informative references: [BINDING] Puthenkulam, J., et al., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04.txt, Internet draft (work in progress), October 2003. [MITM] N. Asokan, Valtteri Niemi and Kaisa Nyberg, Man-in-the-middle in tunneled authentication protocols, Technical Report 2002/163, IACR ePrint archive, October 2002. Available from http://eprint.iacr.org/2002/163 ------------------------------------------------ Issue 201: Some NITs Submitter name: Jose Puthenkulam Submitter email address: jose.p.puthenkulam@intel.com Date first submitted: Nov 17, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-November/001814.html Document: RFC2284bis-06 Comment type: E Priority: 1 Section: 7.2, 7.4 Rationale/Explanation of issue: In section 7.2 [c] Replace "acknowledged result indications" with "protected result indications". It makes more sense to have the EAP method indicate its result in a protected manner than making sure the result is acknowledged. Also for section 7.4 Man-in-the-middle attacks would it not be appropriate to add an informative reference to the EAP Binding Draft and the Nokia Mitm paper. [Jari Arkko] Ok. The term is defined in 7.2.1, and the text already requires protection, I agree that the name "protected result indications" would be appropriate. Need to change the name then in both 7.2 and 7.2.1 as well as in a few other places in the document... > Also for section 7.4 Man-in-the-middle attacks would it not be > appropriate to add an informative reference to the EAP Binding Draft and > the Nokia Mitm paper. Yes, this would be appropriate. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 18 10:28:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25697 for ; Tue, 18 Nov 2003 10:28:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2452580014; Tue, 18 Nov 2003 09:28:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 78299580139; Tue, 18 Nov 2003 09:28:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5257F580138 for ; Tue, 18 Nov 2003 09:27:47 -0600 (CST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 65334580014 for ; Tue, 18 Nov 2003 09:27:45 -0600 (CST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id hAIFRt1o015479; Tue, 18 Nov 2003 15:27:56 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAIFLKn11886; Tue, 18 Nov 2003 15:21:20 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003111807270415887 ; Tue, 18 Nov 2003 07:27:04 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Nov 2003 07:27:04 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] Propsoed resolution to Issue 201: Some NITs Message-ID: Thread-Topic: [eap] Propsoed resolution to Issue 201: Some NITs Thread-Index: AcOt5st8dNJpLkDVTjywgw1p1wWAAwAAXpSw From: "Puthenkulam, Jose P" To: "Bernard Aboba" , X-OriginalArrivalTime: 18 Nov 2003 15:27:04.0873 (UTC) FILETIME=[6BC70990:01C3ADE8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 18 Nov 2003 07:27:04 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The resolution and changes look good. best regards, jose > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Tuesday, November 18, 2003 7:34 AM > To: eap@frascone.com > Subject: [eap] Propsoed resolution to Issue 201: Some NITs >=20 >=20 > The text of Issue 201 is enclosed below. The proposed=20 > resolution is as > follows: >=20 > Replace "acknowledged result indications" with "protected result > indications" throughout the document. >=20 > In Section 7.4, change: >=20 > Where EAP is tunneled within another protocol that omits peer > authentication, there exists a potential vulnerability to > man-in-the-middle attack. >=20 > To: >=20 > Where EAP is tunneled within another protocol that omits peer > authentication, there exists a potential vulnerability to > man-in-the-middle attack. For details, see [BINDING] and [MiTM]. >=20 > Change: >=20 > [b] Requiring cryptographic binding between the EAP tunneling=20 > protocol and > the tunneled EAP methods. Where cryptographic binding is supported, a > mechanism is also needed to protect against downgrade attacks=20 > that would > bypass it. >=20 > To: >=20 > [b] Requiring cryptographic binding between the EAP tunneling=20 > protocol and > the tunneled EAP methods. Where cryptographic binding is supported, a > mechanism is also needed to protect against downgrade attacks=20 > that would > bypass it. For further details on cryptographic binding,=20 > see [BINDING]. >=20 > Add the following informative references: >=20 > [BINDING] Puthenkulam, J., et al., "The Compound=20 > Authentication Binding > Problem", draft-puthenkulam-eap-binding-04.txt, > Internet draft (work in progress), October 2003. >=20 > [MITM] N. Asokan, Valtteri Niemi and Kaisa Nyberg,=20 > Man-in-the-middle in > tunneled authentication protocols, > Technical Report 2002/163, IACR ePrint archive, October 2002.=20 > Available > from http://eprint.iacr.org/2002/163 >=20 > ------------------------------------------------ > Issue 201: Some NITs > Submitter name: Jose Puthenkulam > Submitter email address: jose.p.puthenkulam@intel.com > Date first submitted: Nov 17, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-November/00 1814.html Document: RFC2284bis-06 Comment type: E Priority: 1 Section: 7.2, 7.4 Rationale/Explanation of issue: In section 7.2 [c] Replace "acknowledged result indications" with "protected result indications". It makes more sense to have the EAP method indicate its result in a protected manner than making sure the result is acknowledged. Also for section 7.4 Man-in-the-middle attacks would it not be appropriate to add an informative reference to the EAP Binding Draft and the Nokia Mitm paper. [Jari Arkko] Ok. The term is defined in 7.2.1, and the text already requires protection, I agree that the name "protected result indications" would be appropriate. Need to change the name then in both 7.2 and 7.2.1 as well as in a few other places in the document... > Also for section 7.4 Man-in-the-middle attacks would it not be > appropriate to add an informative reference to the EAP Binding Draft and > the Nokia Mitm paper. Yes, this would be appropriate. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 18 10:36:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26134 for ; Tue, 18 Nov 2003 10:36:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 812BB58013A; Tue, 18 Nov 2003 09:37:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B935958013B; Tue, 18 Nov 2003 09:37:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFF7758013A for ; Tue, 18 Nov 2003 09:36:17 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 44B5D580138 for ; Tue, 18 Nov 2003 09:36:16 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAIFuTK07930 for ; Tue, 18 Nov 2003 07:56:29 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] REMINDER: Use of [Issue] Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 18 Nov 2003 07:56:28 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Recently when updating the EAP Issues list, I found I had missed a few issues. My apologies to the submitters. In reviewing the web archive for submitted issues, I typically scan for the string "[Issue]" in the subject line, assuming that other postings are not document change requests. The issues I missed did not have [Issue] in the subject line, so I did not pick them out when glancing through the web archive. In order to make sure your issue is properly tracked and added to the Issues list, please add "[Issue]" to the subject line when requesting a change to a document. Thanks! Bernard _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 18 10:39:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26323 for ; Tue, 18 Nov 2003 10:39:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C1E75801AB; Tue, 18 Nov 2003 09:39:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10DD95801A7; Tue, 18 Nov 2003 09:39:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4CA05801A9 for ; Tue, 18 Nov 2003 09:39:00 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 1E2C85801A7 for ; Tue, 18 Nov 2003 09:38:58 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 56A546A90A; Tue, 18 Nov 2003 17:38:55 +0200 (EET) Message-ID: <3FBA3C0C.4090401@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" Cc: Bernard Aboba , Kroeselberg Dirk , Henrik Levkowetz Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] eap wg minutes from ietf-58 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 18 Nov 2003 17:34:36 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Preliminary Minutes of the Extensible Authentication Protocol (eap) WG at IETF-58 Time: Monday, November 10, 2003 at 1930-2200 Chairs: Bernard Aboba Jari Arkko Minutes: Dirk Kroeselberg (Dirk.kroeselberg@web.de) Henrik Levkowetz (henrik@levkowetz.com) Edited by Jari Arkko (jarkko@piuha.net) URLs: Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html Presentations: http://www.drizzle.com/~aboba/IETF58/EAP.zip Preliminaries ============= - Agenda Bashing. No comments on the agenda. - Bluesheets going around and note takers assigned. - Document Status. Jari summarized the document status: o EAP base spec passed WG last call, is in IETF last call. o EAP state machine (informational) is in WG last call. o EAP keying framework has been adopted as WG document. There is still a number of open issues, needs more work than the other docs. o EAP over Radius (2289bis) approved, now RFC 3579. o Method documents: Approval of methods needs to wait for completion of base EAP specifications. Currently not in EAP WG charter to work on methods. Future methods might be specified either as individual submissions, Informational documents outside the WG or as chartered EAP WG work WG Work Items -- RFC 2284bis, Henrik Levkowetz ============================================== - http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-07.d.html - 3rd last call on the document was held in September. There are two open issues left: 1) Handling of Identity response 2) Editorial comments by J. Puthenkulam Margaret missed her editorial comments among the open issues, but these were already fixed. No other questions. WG Work Items -- EAP State Machine, Pasi Eronen =============================================== - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt - Now in WG last call. Next steps: Handle issues from last call, and publish as informational. - Draft describes state machine for EAP peer and EAP authenticator. No changes on peer side since IETF-57. - The approach for the authenticator now is changed, due to comments on AAA interaction: three state machines: o Standalone (no pass-through or AAA) o Backend (Interfaces to AAA module (RFC3579, Diameter), EAP methods). o Full authenticator (Interfaces to lower layer (matching 802.1X-REV), EAP methods, AAA module) - Discussion: o Bernard: What is the difference for handling tunneled methods (tunneled variable)? Pasi Eronen: If you are not inside the tunnel, you are not allowed to do multiple authentication methods. Complicated, tunneled-variable will be taken out. Joe: Makes me somewhat nervous to have that in there. Bernard: For now, should be in there to stimulate discussion. o I'd also like to say that the quality is very good, and thank the authors, and tell people to set aside 4+4 hours and go and read it. WG Work Items -- EAP Key Framework, Bernard Aboba ================================================= - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt - Normative statements relating to EAP moved to RFC2284bis. As a result, EAP methods no longer depend on keying framework. Substantial revisions are in progress, currently the draft lacks a threat model. - Open issues: o 15 (key distr. Insecure), o 179 (EAP PRF), and o 187 (Service SAs). - Security issues are: o Key scoping: AAA protocols authenticate at NAS granularity Client may not be able to recognize NAS scope without assistance from the lower layer. Possible solutions: . AAA agent checks . Logging . Key Mixing . Method-specific binding o Correctness in fast handoff & context transfer o Lying NAS Problem - There were no questions. Related Work -- Network Discovery and Selection, Farid Adrangi & Pasi Eronen ============================================================================ - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt - Discussion scoping by Jari: there's been previous question marks on whether this functionality is needed. Since feedback is required from other organizations, and we don't have much time for discussion in the meeting, we will assume that network selection is needed. Lets use the meeting time to discuss what alternatives we have for providing this feature. - Problem: Even if you select an AP (based on e.g. SSID) you haven't selected a mediating network which will carry your traffic back to your home network - Farid presented examples of mediating networks, such as iPass, 3GPP-VPLMN, GRIC. Home service network is e.g. wireless provider. Access networks are public hotspot. Problem is not AP selection in hotspot. EAP-based client needs information on which home network /mediating networks are affiliated to the access network. The proposed solution complies with the EAP spec and uses EAP-Identity Requests to deliver network information. - Proposed solution is to use a "decorated NAI" inside the Identity Response, on first or subsequent Identity Request. Identity Request may carry information about the network which makes it possible for the peer to select an appropriate NAI (if more than one is available). - There is a 3GPP dependency for this work (3GPP TSG CN). - Related presentation by Pasi Eronen: Based on a discussion between Jari, Bernard, Pasi. o But other solutions are possible, e.g. SSID-based. o Suffix routing on a NAI is better than prefix routing. o If an eap-layer based solution is used, EAP identity request hints are probably OK. o The network cannot always ( and maybe should not ) do the selection. So information has to be provided to the users. o If you try to encode the mediary network information into virtual AP's ssid's, the amount of beacons needed might end up consuming a significant part of the bandwidth. o On the other hand, if you have to associate with each of a large number of APs, and start a EAP exchange with each in order to get the information about - Discussion: Margaret Wasserman: Are there lessons to learn from loose source routing? Can we become victims of single points of failure? Pete: Seems we are limiting us to a solution which doesn't scale very well. And I'm not sure we should be doing this at all. Bernard: Today we have internet connectivity and DNS-based routing. This was not possible with RADIUS. Why are we doing this? It looks like there is no layer-2 alternative that can handle all cases. Margaret: Assume I can choose based on some string between mediating networks. Does not seem to be right as there should be some policy. Do we gain something over the existing solutions today? Farid: These policies can be pushed to the subsciber device from the home network Farooq: It's the home network which has to settle the roaming cost. Farid: Some users may care about QoS, some about cost. Policy can be pushed by the user's home network. Margaret: There are other WGs that investigated the concept, should be looked at as well. Bernard Aboba: Take it to the list. Jari: We have a cost factor in selecting the right network. End users care about the cost. - Strawpoll: Should this be solved in the IETF? Consensus that the problem is worth solving. Should the EAP WG solve the problem? Consensus that it should be solved in WG, but less strong than for the first question. - Comment by Pasi: There are solutions that do not involve EAP at all. But EAP WG could be a good place to explore this. Related Work -- EAP Key Derivation for Multiple Applications, Joe Salowey ========================================================================= - http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt - Changed the draft name to "EMSK usage guidelines" - 2284bis defines the EMSK. Several applications have been suggested that use the EMSK (eap-keying, aaaarch-handoff, eap-protectedtlv) The current proposal should either be incorporated into key framework draft, or the keying framework should reference it. - Jari: May be a separate specification as well. Joe: Key framework itself references EMSK. So either take that out, or reference it. Russ: Its just two pages, merge it in. Jari: Ok Related Work - The Compound Binding Problem, Farid Adrangi (on behalf of Jose Puthenkulam) ========================================================================================== - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt - Status update for 04 version of the draft: mostly editorial improvements. Three issues (64, 191, 192) are still open. Some crypto experts have reviewed the draft, no issues so far. Timeline is to resolve open issues this year. Revise section 4, synchronize with keying framework. Submit for final review in January, close in February 04. - Issue: The EMSK may not be the best thing to use for the compound bindings. We need to look a this - Bernard: We started looking at this because many other groups needed something like this. Now IKEv2 is doing something similar, and .... is doing something similar. Right now it seems like the IETF is going violently in different directions and we get incompatibilities. An there may be different views of whether there is a problem. - Russ Housley: True, need solution, proposal to formulate this in a few slides for broader presentation in SAAG. Farid: his has already been done in former IETFs. Bernard: We got no input then. EAP methods - EAP SIM/AKA, Pasi Eronen ====================================== - http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt - http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt - No open issues with the drafts. It is part of 3GPP Release 6 WLAN inter-working. EAP/SIM products are available, deployment is beginning. Plan is to do individual submissions as informational, once EAP base docs finalized. No implications to 2284bis, state machine or keying framework. EAP Methods -- PEAPv2, Jose Salowey =================================== - http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07.txt - Recently submitted draft -07. Features are complete. Added support for sequences of EAP methods. Supports inner method binding. Goal is to submit as informational. Currently WG item not requested. - Margaret: All drafts are planned to be published as informational. I wonder about this. Bernard: It took so long to get this WG started that much work was already more or less done, and it may be hard for people to give up change control now, and make these WG documents. Pasi: Correct with respect to EAP/SIM and EAP/AKA EAP METHODS - EAP-IKEv2, Dirk Kroeselberg ========================================= - http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-02.txt - A number of issues have been improved in the update, e.g. error handling, fragmentation. There are still open issues like optimizing the no. of messages, security claims section. Another update planned before next IETF to address these issues. - Michael Richardson: Tunneling seems to be complicated, suggestion remove support of tunneled methods or to detail use case. Dirk: True, but applies to all tunneled methods. Is only an optional feature in IKEv2. - Bernard: Is it intended to handle address assignment in EAP-IKEv2, do we need that? Bernard: Are all identity payloads needed? Is IKEv2 a limitation in terms of identity payloads? Dirk: Need to check this. EAP Methods - EAP Smartcard, Pascal Urien ========================================= - http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt - Goal of the proposal is to support EAP in smartcards. No discussion. Roadmap discussion (10 minutes), WG Chairs and ADs ================================================== - Steven Hayes: (clarifying 3GPP position) 3GPP requires the two methods discussed, and network selection. Otherwise there are no further requirements on EAP. Request to publish EAP-SIM and EAP-AKA as informational. - Someone: Are the available methods sufficient to progress the documents to Draft Standard? Margaret: Good point. Especially for the keying framework, a method that uses all the features is required. Bernard: There is no standard method required for this, just the use of the features with any method. Russ: Requirement is two independent interoperable methods. Bernard: You can show interoperability without having particular methods showing them Margaret: Are all the methods done informational forever? So what does the EAP WG do - wait till somebody comes along with a method to be standardized? Bernard: There is one standardized mandatory method Russ: But that one doesn't exercise all features. Bernard: Somebody has to ask for a standardization effort. Margaret: There is no interoperability without using informational RFCs. Bernard: The same issue (mandate one method) has been brought to the group by 802.11. Pasi: Could update EAP-TLS as this is the only key-generating RFC method. Current status is experimental, however. Jari: Some defined methods should be standardized in their second revision, e.g. EAP-TLS. Margaret: We don't have the rule that because something has been deployed, it can't be a standards track document! Donald: It almost seems like everything developed outside never is to become IETF standards. We have some examples where v2 of some documents have become - after rework - standards track documents. Margaret: How will expert review differ from the expert review done for standards track documents. Bernard: The intention is to basically raise the bar for new methods, as many have already been allocated, but about 70 percent do not have a useful documentation (expert review is defined in 2284bis). Bernard: If you already have a type code, it's not even sure that the need for expert review will get triggered. Even if you have a code allocated, that's not a guarantee that the RFC editor would publish a document, he could decide this is awful. (Editor's note: Margaret later sent this e-mail to the list: "Apparently, I said something at the EAP meeting in Minneapolis that has caused some confusion about the IANA allocation of EAP codepoints. Just to erase any confusion, I want to make it clear that I support the current wording in the EAP draft -- that EAP codepoints should be allocated on the basis of expert review. This represents an increase in scrutiny from the current policy (first- come- first- served), which I think is appropriate. I do not believe that EAP codepoints should require an IETF standard, and I do believe that it would be appropriate to allocate EAP codepoints in some situations (vendor-specific or environment-specific) where it wouldn't make sense to produce an IETF standard. I do hope that the WG will consider standardizing secure, general purpose EAP methods in the future, but I do not believe that we should require a standards-track document in order to obtain a codepoint.") Chris Elliot: I'd really like to se you take on methods work. Meeting adjourned. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 18 16:48:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19649 for ; Tue, 18 Nov 2003 16:48:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E2FC9580139; Tue, 18 Nov 2003 15:48:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D0C75801AB; Tue, 18 Nov 2003 15:48:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09AAE5801AB for ; Tue, 18 Nov 2003 15:47:37 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id F3F86580139 for ; Tue, 18 Nov 2003 15:47:34 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAIM7Ad30673; Tue, 18 Nov 2003 14:07:10 -0800 From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, eap@frascone.com In-Reply-To: <3F9BF2FE.9090304@piuha.net> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3859@esebe023.ntc.nokia.com> <3F9BF2FE.9090304@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: resolution to issue 161 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 18 Nov 2003 14:07:10 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Since the EAP peer/auth listener terms are used in the below text > a number of times, do we need a definition for them? Perhaps. The intended meaning is roughly equivalent to the "Suppliant PAE" and "Authenticator PAE" in 802.1x. > > Where the pass-through device implements an EAP peer listener, > > it will not forward to the backend authentication server > > EAP Request (Code=1), Success (Code=3) or Failure (Code=4) > > packets in order to act on them locally. The use of the > > RADIUS protocol for encapsulation of EAP in pass-through > > operation is described in [RFC3579]. > > I had to read the above paragraph a few times to understand > what you are saying. So this is an EAP peer-side passthrough? > Or an EAP passthrough authenticator with an EAP peer side to > the other direction? A pass-through device can act as an EAP peer as well as an authenticator. For example, an AP could need to authenticate to a switch in order to be allowed to connect to the wired network. In this case, it will act locally on any EAP-Requests it receives; it will never act as a pass-through for Code=2 packets, regardless of whether the AAA protocol supports peer pass-through or not. This is because an EAP peer or authenticator can only take one action on an EAP packet: act on it, forward it, or drop it. If it chooses to act on the packet, then it cannot also forward it. Does this help? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 04:26:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09927 for ; Wed, 19 Nov 2003 04:26:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D381D58001A; Wed, 19 Nov 2003 03:27:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38DDB5801AD; Wed, 19 Nov 2003 03:27:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CC285801AD for ; Wed, 19 Nov 2003 03:26:04 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id D682858001A for ; Wed, 19 Nov 2003 03:26:01 -0600 (CST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJ9Px626113 for ; Wed, 19 Nov 2003 11:25:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 11:25:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 19 Nov 2003 11:25:58 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 11:25:57 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 199: Full authenticator SM issue X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122325@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 199: Full authenticator SM issue Thread-Index: AcOpVxVRb4nZ52U+TxuQ5Jr1nKtBwgFJpTBw From: To: , X-OriginalArrivalTime: 19 Nov 2003 09:25:57.0737 (UTC) FILETIME=[23923590:01C3AE7F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 11:25:56 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Yoshihiro Ohba wrote: >=20 > In this case, the second RADIUS server will receive a Nak while=20 > it is in "PICK_UP_METHOD" state. There are two issues: >=20 > - Does RFC3579 allow "pickup" operation when the initial=20 > EAP-Response is a Nak? I think the document is a bit vague on=20 > this (at least it does not seem to prohibit the case). I don't think RFC3579 discusses the case where the EAP conversation is "switched" from one RADIUS server to another (it doesn't prohibit it either). It does allow the case where the initial EAP-Response is a Nak: =20 "Where the initial EAP-Request sent by the NAS is for an authentication Type (4 or greater), the peer MAY respond with a Nak indicating that it would prefer another authentication method that is not implemented locally. In this case, the NAS SHOULD send Access-Request encapsulating the received EAP-Response/Nak." > - If the above question is yes, how does the backend > authenticator state machine work in this case? I think there > would need a state transition from "PICK_UP_METHOD" to "NAK" > state to explicitly support the case. There is already a transition from INITIALIZE to NAK that=20 does this. There is currently no text explicitly discussing how a backend might pass EAP messages to another backend. However, I'm not sure that this is really needed (at least in the state machine doc): in this case, the first backend really works as an ordinary=20 RADIUS proxy (and not as EAP passthrough NAS). So, I propose that we close issue 199 with no changes to the document. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 04:52:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10471 for ; Wed, 19 Nov 2003 04:52:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B5DFB58001A; Wed, 19 Nov 2003 03:53:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFC2258012D; Wed, 19 Nov 2003 03:53:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DCAF5801A8 for ; Wed, 19 Nov 2003 03:52:48 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id DD67858012D for ; Wed, 19 Nov 2003 03:52:45 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJ9qiA12106 for ; Wed, 19 Nov 2003 11:52:45 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 11:52:44 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 11:52:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C38A2@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 198: Other EAP Peer SM Issues Thread-Index: AcOtPYtL969VTwhgRsKsBKwroNHF5ABRTidQ From: To: , Cc: X-OriginalArrivalTime: 19 Nov 2003 09:52:44.0617 (UTC) FILETIME=[E158A390:01C3AE82] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 11:52:44 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Proposed resolution to issue 198: Other EAP Peer SM issues - Remove all references to EapTunnelled (it does not adequately define behavior of existing tunneled methods, and we don't even need to describe their behavior in this document). - Change in Section 4.1.1 (portEnabled) from: "Indicates that there is a valid port to use for the communication. If at any point the port is not available, portEnabled is set to FALSE and the state machine transitions to DISABLED (or BACKEND_DISABLED)." to "Indicates that the EAP peer state machine should be ready for communication. This is set to TRUE when the EAP conversation is started by the lower layer. If at any point the communication port or session is not available, portEnabled is set to FALSE and the state machine transitions to DISABLED." =20 - Change in Section 5.1.1 (portEnabled) from "Indicates that there is a valid port to use for the communication. If at any point the port is not available, portEnabled is set to FALSE and the state machine transitions to DISABLED." =20 to=20 "Indicates that the EAP authenticator state machine should be ready for communication. This is set to TRUE when the EAP conversation is started by the lower layer. If at any point the communication port or session is not available, portEnabled is set to FALSE and the state machine transitions to DISABLED." - Change in Section 4.1.3 (ClientTimeout) from: "Configurable amount of time to wait for a valid request before aborting." =20 to "Configurable amount of time to wait for a valid request before aborting, initialized by implementation-specific=20 means (e.g. a configuration setting)." - Change in Section 4.2 from "methodState=3DDONE: The method always continues at this point, (or the peer sees no point in continuing it)." to "methodState=3DDONE: The method never continues at this point (or the peer sees no point in continuing it)." - Add to Section 8 (implementation considerations): "Implementations may define an additional interfaces to pass method-specific information between methods and lower layers. These interfaces are beyond the scope of this document." Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 12:16:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27699 for ; Wed, 19 Nov 2003 12:16:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D5365801A6; Wed, 19 Nov 2003 11:17:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF94C580135; Wed, 19 Nov 2003 11:17:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53809580135 for ; Wed, 19 Nov 2003 11:16:09 -0600 (CST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id E0B5358012D for ; Wed, 19 Nov 2003 11:16:06 -0600 (CST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2003 09:16:28 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAJHG3w5015618; Wed, 19 Nov 2003 09:16:03 -0800 (PST) Received: from jsaloweyw2k01 ([128.107.168.59]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 09:21:09 -0800 From: "Joseph Salowey" To: , "'Pasi Eronen'" Cc: Message-ID: <003801c3aec0$cf11f400$3ba86b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <3FAD80D2.9040805@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 19 Nov 2003 17:21:09.0539 (UTC) FILETIME=[85EDEF30:01C3AEC1] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: review of draft-salowey-eap-key-deriv-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 09:16:02 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Jari, Thanks for the review, comments below: > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Saturday, November 08, 2003 3:49 PM > To: Joe Salowey; Pasi Eronen > Cc: eap@frascone.com > Subject: review of draft-salowey-eap-key-deriv-02.txt > > > > Joe, Pasi, > > I took a look at your draft draft-salowey-eap-key-deriv-02.txt. > It looks quite reasonable to me -- thanks for working on it! > -- though I do have some comments: > > Substantial: > > 1. The goal of the draft. Is there an intent that some of this > should be discussed in the eap-keying document? Or would this > be a later extension to that? Or just for our information? > [Joe] I'll be submitting issues to incorporate most of the content into the key framework document. > 2. If the security ADs wanted us to name current keys generated > from EAP, I think its likely that they will require AMSKs > be named as well. A discussion of the naming is missing, though > the EMSK itself is named in the document. > [Joe] Yes, more of a discussion of naming is needed. > 3. I'm not sure I like the idea of EMSK Name being derived from > KDF(EMSK), if there are alternatives. Would it be possible to > name the EMSK by the EAP SA Name defined in eap-keying (derived > from nonces), concanated with, say, "EMSK". Similarly, we could > name each AMSK as the name of the EMSK, concatenated with "AMSK" > and the key label and application data? [Joe] I don't like the proposal either. The problem is that the EAP SA name is not concretely defined. I'm not sure you can define this for all methods in general. We need to place a requirement on methods that if they are going to generate additional keys they must also export an EAP-SA name. > > 4. Section 3.1, what is the unit of "O"? Bytes or bits? > [Joe] Should be bytes > 5. Section 3.3 fails to discuss that if EMSK is going to be > useful, there's probably going to be some state kept in > the AAA server. > [Joe] true > Editorial: > > 1. Section 1.2, last paragraph. Missing "." at the end. > > 2. Section 2.1, s/MSUT/MUST/ > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 13:33:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01799 for ; Wed, 19 Nov 2003 13:32:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2A775801A4; Wed, 19 Nov 2003 12:33:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F27B6580130; Wed, 19 Nov 2003 12:33:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F21C358010A for ; Wed, 19 Nov 2003 12:32:32 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C002758001A for ; Wed, 19 Nov 2003 12:32:30 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAJIpcF10511; Wed, 19 Nov 2003 10:51:38 -0800 From: Bernard Aboba To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: Yoshihiro Ohba , eap@frascone.com Subject: RE: [eap] Issue 193: Peer SM review In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 10:51:38 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thanks. In reviewing the state machines again, I think I agree with you. They function even if the 802.1X state machine does not differentiate between an EAP Request and an EAP Response. On Sat, 15 Nov 2003, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > I agree completely with Yoshihiro. The lower layer (e.g. 802.1X) does not > want to know what EAP method is running. Ideally, the lower layers might > even want to support another authentication protocol other than EAP (though > this is not an explicit design objective of 802.1aa now called 802.1X-D7.1). > Tying the interface between the layers with method specific details is not a > good idea. > > > Paul > > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Yoshihiro Ohba > > Sent: Thursday, November 13, 2003 11:49 AM > > To: Bernard Aboba > > Cc: eap@frascone.com > > Subject: Re: [eap] Issue 193: Peer SM review > > > > > > I have one comment in line. > > > > On Sun, Nov 09, 2003 at 07:10:34PM -0800, Bernard Aboba wrote: > > > Issue 193: Peer SM review > > > Submitter name: Bernard Aboba > > > Submitter email address: aboba@internaut.com > > > Date first submitted: Nov 8, 2003 > > > Reference: > > > Document: SM-01 > > > Comment type: T > > > Priority: S > > > Section: 2, 4 > > > Rationale/Explanation of issue: > > > > > > pp. 5, first paragraph > > > > > > "pass EAP messages to a Backend Server where the real > > Authentication > > > Method resides" > > > > > > As is made clear later, the pass-through authenticator does *not* > > > forward all EAP messages to the backend authentication server, only > > > EAP-Responses. Rephrase to: > > > > > > "pass EAP-Response messages to a Backend Server where the > > > Authentication Method resides" > > > > > > Third paragraph: > > > > > > The implication is the EAP method demultiplexing depends on > > the lower > > > layer. This is not the case because all EAP implementations on all > > > media must support demultiplexing (whether they support an > > > authenticator or peer listener is another issue). > > > > > > Suggest replacing the paragraph with: > > > > > > "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes > > > incoming EAP packets. Packets with Code=2 (Response) are > > delivered to > > > the Authenticator state machine, while packets with Code=1 > > (Request), > > > 3 > > > (Success) or 4 (Failure) are delivered to the Peer state machine." > > > > > > Page 9, Figure 3. > > > > > > The notation used later (Figure 6) is more clear than the > > use of the > > > "|" operator as in Figure 3. I'd recommend adopting the Figure 6 > > > notation everywhere. > > > > > > It would appear to me that methodState is a variable that > > needs to be > > > exported from the peer to the lower layer. This is so that > > lower layer > > > state machines such as 802.1X can know whether their own state > > > machines should be affected or not. > > > > I don't think exposing methodState to the lower layer is a > > good idea. Since the state machine draft is an informational > > document, an implementation can be based on yet another state > > machine that realizes the same on-the-wire behavior but uses > > a different set of states. If a lower layer requires such > > internal state exposition, I believe there is something wrong > > with the lower layer design... > > > > Yoshihiro Ohba > > > > > > > > > > > > The INITIALIZE state does not initialize all variables. > > > Non-initialized variables > > > include: > > > > > > eapKeyData = NONE > > > eapKeyAvailable = FALSE > > > eapSuccess = FALSE > > > eapFail = FALSE > > > methodState = NONE > > > selectedMethod = NONE > > > decision = FAIL > > > > > > The initialization values seem important since transitions can be > > > based on them before they are initialized. Re-initializing > > variables > > > in the INITIALIZE state is a bit different from giving the > > variables > > > initial values before they are ever used. > > > > > > Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE > > > state. I assume this means that this variable can be > > assigned one of > > > two values, at the implementation's descretion. I think we > > want this > > > variable initialized to FAIL. > > > > > > There is a transition from the IDLE state to the SUCCESS > > and FAILURE > > > states. This occurs without appearing to require receipt of > > a packet. > > > I think that this can't be the case; something has to be > > received at > > > some point for the peer to leave idleWhile OR it is a > > situation where > > > the peer is testing whether the authenticator is > > EAP-capable (e.g. a > > > wired LAN application). > > > > > > The transition to FAILURE state occurs when an alternative > > indication > > > of Rejection occurs (e.g. Disassociate); when the idleWhile > > timer runs > > > out and the decision is not an unconditional success; when an > > > alternative indication of success is available but the decision is > > > FAIL. > > > > > > There is also a transition from the IDLE state to the > > SUCCESS state. > > > This can occur when the idleWhile timer runs out and the > > decision is > > > an unconditional success; or when an alternative indication > > of success > > > is available and the decision is not FAILURE. > > > > > > It seems that the INITIALIZE state will need to have the correct > > > default values or these transitions may not occur correctly. > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 14:05:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03975 for ; Wed, 19 Nov 2003 14:05:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 511E1580014; Wed, 19 Nov 2003 13:05:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA9A958001A; Wed, 19 Nov 2003 13:05:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A731C58001A for ; Wed, 19 Nov 2003 13:04:42 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 06D2C580014 for ; Wed, 19 Nov 2003 13:04:41 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAJJOlM12383 for ; Wed, 19 Nov 2003 11:24:47 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Question on EAP SM Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 11:24:47 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, the transition from AUTHENTICATING state appears to be controlled in part by the value of the authSuccess and authFail variables. However, these variables do not appear to be set in the corresponding EAP authenticator state machines, either in Figure 4, 5 or 6. Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 14:24:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05169 for ; Wed, 19 Nov 2003 14:24:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCCD5580014; Wed, 19 Nov 2003 13:25:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B87358010A; Wed, 19 Nov 2003 13:25:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C429458010A for ; Wed, 19 Nov 2003 13:24:59 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 1822A580014 for ; Wed, 19 Nov 2003 13:24:58 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAJJOv4u002678; Wed, 19 Nov 2003 14:24:57 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Question on EAP SM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 14:24:57 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I could be wrong, but my understanding is that authSuccess and authFail are set in the Backend authenticator 1x state machine (p. 59) after eapSuccess or eapFail are set. These ARE set in the Authenticator state machine as I read it. Is this wrong? nick On Wed, 19 Nov 2003, Bernard Aboba wrote: > In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, > the transition from AUTHENTICATING state appears to be controlled in part > by the value of the authSuccess and authFail variables. However, these > variables do not appear to be set in the corresponding EAP authenticator > state machines, either in Figure 4, 5 or 6. > > Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 14:41:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05852 for ; Wed, 19 Nov 2003 14:41:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C879580014; Wed, 19 Nov 2003 13:41:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CAAF58010A; Wed, 19 Nov 2003 13:41:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC92158013A for ; Wed, 19 Nov 2003 13:40:12 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 2CF8A580014 for ; Wed, 19 Nov 2003 13:40:11 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAJJeA4u003207; Wed, 19 Nov 2003 14:40:10 -0500 (EST) From: Nick Petroni To: Cc: Subject: Re: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38A2@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 14:40:10 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I agree with the proposed changes. nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Wed, 19 Nov 2003 Pasi.Eronen@nokia.com wrote: > Proposed resolution to issue 198: Other EAP Peer SM issues > > - Remove all references to EapTunnelled (it does not adequately > define behavior of existing tunneled methods, and we don't even > need to describe their behavior in this document). > > - Change in Section 4.1.1 (portEnabled) from: > > "Indicates that there is a valid port to use for the > communication. If at any point the port is not available, > portEnabled is set to FALSE and the state machine transitions > to DISABLED (or BACKEND_DISABLED)." > > to > > "Indicates that the EAP peer state machine should be ready for > communication. This is set to TRUE when the EAP conversation is > started by the lower layer. If at any point the communication > port or session is not available, portEnabled is set to FALSE > and the state machine transitions to DISABLED." > > - Change in Section 5.1.1 (portEnabled) from > > "Indicates that there is a valid port to use for the > communication. If at any point the port is not available, > portEnabled is set to FALSE and the state machine transitions > to DISABLED." > > to > > "Indicates that the EAP authenticator state machine should be > ready for communication. This is set to TRUE when the EAP > conversation is started by the lower layer. If at any point > the communication port or session is not available, > portEnabled is set to FALSE and the state machine transitions > to DISABLED." > > - Change in Section 4.1.3 (ClientTimeout) from: > > "Configurable amount of time to wait for a valid request > before aborting." > > to > > "Configurable amount of time to wait for a valid request > before aborting, initialized by implementation-specific > means (e.g. a configuration setting)." > > - Change in Section 4.2 from > > "methodState=DONE: The method always continues at this point, > (or the peer sees no point in continuing it)." > > to > > "methodState=DONE: The method never continues at this point > (or the peer sees no point in continuing it)." > > - Add to Section 8 (implementation considerations): > > "Implementations may define an additional interfaces to pass > method-specific information between methods and lower layers. > These interfaces are beyond the scope of this document." > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 14:45:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05984 for ; Wed, 19 Nov 2003 14:45:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83E68580014; Wed, 19 Nov 2003 13:46:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5C9958010A; Wed, 19 Nov 2003 13:46:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3A4A58010A for ; Wed, 19 Nov 2003 13:45:25 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id B3E09580014 for ; Wed, 19 Nov 2003 13:45:24 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAJJjO4u003335; Wed, 19 Nov 2003 14:45:24 -0500 (EST) From: Nick Petroni To: Cc: , Subject: RE: [eap] Issue 199: Full authenticator SM issue In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122325@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 14:45:24 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > So, I propose that we close issue 199 with no changes to the > document. agree. Regards, nick > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 15:28:08 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09817 for ; Wed, 19 Nov 2003 15:28:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E051858001A; Wed, 19 Nov 2003 14:28:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CEA3F58010A; Wed, 19 Nov 2003 14:28:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 796A158010A for ; Wed, 19 Nov 2003 14:27:22 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id E3CE3580014 for ; Wed, 19 Nov 2003 14:27:20 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 560766A90E; Wed, 19 Nov 2003 22:27:18 +0200 (EET) Message-ID: <3FBBC884.9060703@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey Cc: "'Pasi Eronen'" , eap@frascone.com References: <003801c3aec0$cf11f400$3ba86b80@amer.cisco.com> In-Reply-To: <003801c3aec0$cf11f400$3ba86b80@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: review of draft-salowey-eap-key-deriv-02.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 21:46:12 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Joseph Salowey wrote: >>3. I'm not sure I like the idea of EMSK Name being derived from >> KDF(EMSK), if there are alternatives. Would it be possible to >> name the EMSK by the EAP SA Name defined in eap-keying (derived >> from nonces), concanated with, say, "EMSK". Similarly, we could >> name each AMSK as the name of the EMSK, concatenated with "AMSK" >> and the key label and application data? > > > [Joe] I don't like the proposal either. The problem is that the EAP SA > name is not concretely defined. I'm not sure you can define this for > all methods in general. We need to place a requirement on methods that > if they are going to generate additional keys they must also export an > EAP-SA name. Yes, that's right. Ok, I'll settle for your current text then on that. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 15:34:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10499 for ; Wed, 19 Nov 2003 15:34:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3133C58013A; Wed, 19 Nov 2003 14:35:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E04C258001A; Wed, 19 Nov 2003 14:35:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D973F58001A for ; Wed, 19 Nov 2003 14:34:26 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id C901D580014 for ; Wed, 19 Nov 2003 14:34:24 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAJKsRX17469; Wed, 19 Nov 2003 12:54:27 -0800 From: Bernard Aboba To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Question on EAP SM In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 12:54:26 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Yes, they are set in Figure 8-15 in the Backend Authenticator SM. However, these are set based on the eapFail and eapSuccess variables. Is that right? This seems to imply that it is EAP that determines the success or failure of the Authenticator SM, when in fact is the decision communicated by the AAA protocol (Accept/Reject). For example, in the EAP Authenticator SM (Figure 5), the variables aaaEapFail and aaaEapSuccess are set. Shouldn't these variables cause the transition from RESPONSE state to SUCCESS or FAILURE state in Figure 8-15 in 802.1X, instead of eapFail and eapSuccess? On Wed, 19 Nov 2003, Nick Petroni wrote: > I could be wrong, but my understanding is that authSuccess and authFail > are set in the Backend authenticator 1x state machine (p. 59) after > eapSuccess or eapFail are set. These ARE set in the Authenticator state > machine as I read it. > > Is this wrong? > > nick > > On Wed, 19 Nov 2003, Bernard Aboba wrote: > > > In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, > > the transition from AUTHENTICATING state appears to be controlled in part > > by the value of the authSuccess and authFail variables. However, these > > variables do not appear to be set in the corresponding EAP authenticator > > state machines, either in Figure 4, 5 or 6. > > > > Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 16:02:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11519 for ; Wed, 19 Nov 2003 16:02:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95BB25801A2; Wed, 19 Nov 2003 15:03:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10D5558001A; Wed, 19 Nov 2003 15:03:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6139B58001A for ; Wed, 19 Nov 2003 15:02:40 -0600 (CST) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id 19548580014 for ; Wed, 19 Nov 2003 15:02:34 -0600 (CST) Received: (qmail 2313 invoked from network); 19 Nov 2003 21:02:28 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.223) by deneb.mtghouse.com with SMTP; 19 Nov 2003 21:02:28 -0000 Message-ID: <3FBBDA66.4040700@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Burns Cc: Nick Petroni , Bernard Aboba , eap@frascone.com Subject: Re: [eap] Question on EAP SM References: <3FBBD4C1.8060202@mtghouse.com> In-Reply-To: <3FBBD4C1.8060202@mtghouse.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 16:02:30 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nick, Actually, Bernard's statement has reminded that in fact I should have said: eapSuccess and eapFail are the variables between 1X and *Higher Layer* (which according to 2284bis this will be AAA, not EAP). authSuccess and authFail are variables between the 802.1X front end and 802.1X back end authenticator state machines. A subtle but very important distinction. Jim B. Jim Burns wrote: > Nick, > Correct. > eapSuccess and eapFail are the variables between the 1X and EAP > machine. > authSuccess and authFail are variables between the 802.1X front end > and 802.1X back end authenticator state machines. > Sincerely, > Jim B. > > Nick Petroni wrote: > >> I could be wrong, but my understanding is that authSuccess and authFail >> are set in the Backend authenticator 1x state machine (p. 59) after >> eapSuccess or eapFail are set. These ARE set in the Authenticator state >> machine as I read it. >> >> Is this wrong? >> >> nick >> >> On Wed, 19 Nov 2003, Bernard Aboba wrote: >> >> >> >>> In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, >>> the transition from AUTHENTICATING state appears to be controlled in >>> part >>> by the value of the authSuccess and authFail variables. However, these >>> variables do not appear to be set in the corresponding EAP >>> authenticator >>> state machines, either in Figure 4, 5 or 6. >>> >>> Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. >>> _______________________________________________ >>> eap mailing list >>> eap@frascone.com >>> http://mail.frascone.com/mailman/listinfo/eap >>> >>> >> >> >> _______________________________________________ >> eap mailing list >> eap@frascone.com >> http://mail.frascone.com/mailman/listinfo/eap >> >> >> > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 16:05:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11627 for ; Wed, 19 Nov 2003 16:05:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6AE855801AD; Wed, 19 Nov 2003 15:06:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D289958010A; Wed, 19 Nov 2003 15:06:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5CE0E5801A1 for ; Wed, 19 Nov 2003 15:05:10 -0600 (CST) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id E5A7358010A for ; Wed, 19 Nov 2003 15:05:06 -0600 (CST) Received: (qmail 29983 invoked from network); 19 Nov 2003 20:38:24 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.223) by deneb.mtghouse.com with SMTP; 19 Nov 2003 20:38:24 -0000 Message-ID: <3FBBD4C1.8060202@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Petroni Cc: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Question on EAP SM References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 15:38:25 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Nick, Correct. eapSuccess and eapFail are the variables between the 1X and EAP machine. authSuccess and authFail are variables between the 802.1X front end and 802.1X back end authenticator state machines. Sincerely, Jim B. Nick Petroni wrote: >I could be wrong, but my understanding is that authSuccess and authFail >are set in the Backend authenticator 1x state machine (p. 59) after >eapSuccess or eapFail are set. These ARE set in the Authenticator state >machine as I read it. > >Is this wrong? > >nick > >On Wed, 19 Nov 2003, Bernard Aboba wrote: > > > >>In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, >>the transition from AUTHENTICATING state appears to be controlled in part >>by the value of the authSuccess and authFail variables. However, these >>variables do not appear to be set in the corresponding EAP authenticator >>state machines, either in Figure 4, 5 or 6. >> >>Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. >>_______________________________________________ >>eap mailing list >>eap@frascone.com >>http://mail.frascone.com/mailman/listinfo/eap >> >> >> > >_______________________________________________ >eap mailing list >eap@frascone.com >http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 16:12:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11880 for ; Wed, 19 Nov 2003 16:12:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E44A7580014; Wed, 19 Nov 2003 15:13:06 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A131758012E; Wed, 19 Nov 2003 15:13:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDE2A58012E for ; Wed, 19 Nov 2003 15:12:54 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id CD59B580014 for ; Wed, 19 Nov 2003 15:12:52 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAJLWrF19943; Wed, 19 Nov 2003 13:32:53 -0800 From: Bernard Aboba To: Jim Burns Cc: Nick Petroni , eap@frascone.com Subject: Re: [eap] Question on EAP SM In-Reply-To: <3FBBDA66.4040700@mtghouse.com> Message-ID: References: <3FBBD4C1.8060202@mtghouse.com> <3FBBDA66.4040700@mtghouse.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 13:32:52 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I'm not sure how this works because eapSuccess and eapFail are not set in the EAP SM as a result of AAA activity. So this isn't quite right, I think. On Wed, 19 Nov 2003, Jim Burns wrote: > Nick, > Actually, Bernard's statement has reminded that in fact I should have > said: > eapSuccess and eapFail are the variables between 1X and *Higher > Layer* (which according to 2284bis this will be AAA, not EAP). > authSuccess and authFail are variables between the 802.1X front > end and 802.1X back end authenticator state machines. > A subtle but very important distinction. > Jim B. > > Jim Burns wrote: > > > Nick, > > Correct. > > eapSuccess and eapFail are the variables between the 1X and EAP > > machine. > > authSuccess and authFail are variables between the 802.1X front end > > and 802.1X back end authenticator state machines. > > Sincerely, > > Jim B. > > > > Nick Petroni wrote: > > > >> I could be wrong, but my understanding is that authSuccess and authFail > >> are set in the Backend authenticator 1x state machine (p. 59) after > >> eapSuccess or eapFail are set. These ARE set in the Authenticator state > >> machine as I read it. > >> > >> Is this wrong? > >> > >> nick > >> > >> On Wed, 19 Nov 2003, Bernard Aboba wrote: > >> > >> > >> > >>> In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, > >>> the transition from AUTHENTICATING state appears to be controlled in > >>> part > >>> by the value of the authSuccess and authFail variables. However, these > >>> variables do not appear to be set in the corresponding EAP > >>> authenticator > >>> state machines, either in Figure 4, 5 or 6. > >>> > >>> Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. > >>> _______________________________________________ > >>> eap mailing list > >>> eap@frascone.com > >>> http://mail.frascone.com/mailman/listinfo/eap > >>> > >>> > >> > >> > >> _______________________________________________ > >> eap mailing list > >> eap@frascone.com > >> http://mail.frascone.com/mailman/listinfo/eap > >> > >> > >> > > > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 16:13:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12001 for ; Wed, 19 Nov 2003 16:13:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 505D55801A1; Wed, 19 Nov 2003 15:14:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73E545801A2; Wed, 19 Nov 2003 15:14:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A88115801A2 for ; Wed, 19 Nov 2003 15:14:00 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 215775801A1 for ; Wed, 19 Nov 2003 15:13:59 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAJLDw4u005959; Wed, 19 Nov 2003 16:13:58 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Question on EAP SM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 16:13:58 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Bernard, Maybe this is a subtle, but important point but I think you need to convince me of it. I am not completely understanding the objection. Your initial comment was that authSuccess and authFail are not set in the EAP state machine, but now you are asking why the EAP state machine leads directly to them being set? I think I am misunderstanding. As for AAA making the decision, eapFail/eapSucess get set based on the response aaaFail or aaaSuccess in figure 7. Figures 4 and 6 are the case where AAA is not used. can you clarify? thanks, nick Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Wed, 19 Nov 2003, Bernard Aboba wrote: > Yes, they are set in Figure 8-15 in the Backend Authenticator SM. > However, these are set based on the eapFail and eapSuccess variables. > > Is that right? This seems to imply that it is EAP that determines the > success or failure of the Authenticator SM, when in fact is the decision > communicated by the AAA protocol (Accept/Reject). > > For example, in the EAP Authenticator SM (Figure 5), the variables > aaaEapFail and aaaEapSuccess are set. Shouldn't these variables cause the > transition from RESPONSE state to SUCCESS or FAILURE state in Figure 8-15 > in 802.1X, instead of eapFail and eapSuccess? > > On Wed, 19 Nov 2003, Nick Petroni wrote: > > > I could be wrong, but my understanding is that authSuccess and authFail > > are set in the Backend authenticator 1x state machine (p. 59) after > > eapSuccess or eapFail are set. These ARE set in the Authenticator state > > machine as I read it. > > > > Is this wrong? > > > > nick > > > > On Wed, 19 Nov 2003, Bernard Aboba wrote: > > > > > In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, > > > the transition from AUTHENTICATING state appears to be controlled in part > > > by the value of the authSuccess and authFail variables. However, these > > > variables do not appear to be set in the corresponding EAP authenticator > > > state machines, either in Figure 4, 5 or 6. > > > > > > Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 16:15:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12275 for ; Wed, 19 Nov 2003 16:15:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED1E4580014; Wed, 19 Nov 2003 15:16:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C210B58001A; Wed, 19 Nov 2003 15:16:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C224C5801B4 for ; Wed, 19 Nov 2003 15:15:30 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 50ED15801A6 for ; Wed, 19 Nov 2003 15:15:29 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAJLFS4u005984; Wed, 19 Nov 2003 16:15:28 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Jim Burns , Subject: Re: [eap] Question on EAP SM In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 16:15:28 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) why are they not? the only authenticator code that interracts with AAA is figure 7 and that clearly shows eapFail/eapSucces being driven from aaaFail/aaaSuccess, no? Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Wed, 19 Nov 2003, Bernard Aboba wrote: > I'm not sure how this works because eapSuccess and eapFail are not set in > the EAP SM as a result of AAA activity. So this isn't quite right, I > think. > > On Wed, 19 Nov 2003, Jim Burns wrote: > > > Nick, > > Actually, Bernard's statement has reminded that in fact I should have > > said: > > eapSuccess and eapFail are the variables between 1X and *Higher > > Layer* (which according to 2284bis this will be AAA, not EAP). > > authSuccess and authFail are variables between the 802.1X front > > end and 802.1X back end authenticator state machines. > > A subtle but very important distinction. > > Jim B. > > > > Jim Burns wrote: > > > > > Nick, > > > Correct. > > > eapSuccess and eapFail are the variables between the 1X and EAP > > > machine. > > > authSuccess and authFail are variables between the 802.1X front end > > > and 802.1X back end authenticator state machines. > > > Sincerely, > > > Jim B. > > > > > > Nick Petroni wrote: > > > > > >> I could be wrong, but my understanding is that authSuccess and authFail > > >> are set in the Backend authenticator 1x state machine (p. 59) after > > >> eapSuccess or eapFail are set. These ARE set in the Authenticator state > > >> machine as I read it. > > >> > > >> Is this wrong? > > >> > > >> nick > > >> > > >> On Wed, 19 Nov 2003, Bernard Aboba wrote: > > >> > > >> > > >> > > >>> In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, > > >>> the transition from AUTHENTICATING state appears to be controlled in > > >>> part > > >>> by the value of the authSuccess and authFail variables. However, these > > >>> variables do not appear to be set in the corresponding EAP > > >>> authenticator > > >>> state machines, either in Figure 4, 5 or 6. > > >>> > > >>> Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. > > >>> _______________________________________________ > > >>> eap mailing list > > >>> eap@frascone.com > > >>> http://mail.frascone.com/mailman/listinfo/eap > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> eap mailing list > > >> eap@frascone.com > > >> http://mail.frascone.com/mailman/listinfo/eap > > >> > > >> > > >> > > > > > > > > > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 16:20:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12902 for ; Wed, 19 Nov 2003 16:20:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 364455801B0; Wed, 19 Nov 2003 15:21:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A05EC58001A; Wed, 19 Nov 2003 15:21:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCACF58001A for ; Wed, 19 Nov 2003 15:20:47 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 10745580014 for ; Wed, 19 Nov 2003 15:20:46 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAJLed220373; Wed, 19 Nov 2003 13:40:39 -0800 From: Bernard Aboba To: Nick Petroni Cc: Jim Burns , eap@frascone.com Subject: Re: [eap] Question on EAP SM In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 13:40:39 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Yes, I understand figure 7 and this seems to make sense. But Figure 5 is for the Backend Authenticator state machine and Section 6 mentions AAA, yet the eapFail/eapSuccess variables aren't driven in the same way. I'm not sure why this is the case. On Wed, 19 Nov 2003, Nick Petroni wrote: > why are they not? the only authenticator code that interracts with AAA is > figure 7 and that clearly shows eapFail/eapSucces being driven from > aaaFail/aaaSuccess, no? > > Nick L. Petroni, Jr. > Graduate Student, Computer Science > Maryland Information Systems Security Lab > University of Maryland > http://www.cs.umd.edu/~npetroni > > On Wed, 19 Nov 2003, Bernard Aboba wrote: > > > I'm not sure how this works because eapSuccess and eapFail are not set in > > the EAP SM as a result of AAA activity. So this isn't quite right, I > > think. > > > > On Wed, 19 Nov 2003, Jim Burns wrote: > > > > > Nick, > > > Actually, Bernard's statement has reminded that in fact I should have > > > said: > > > eapSuccess and eapFail are the variables between 1X and *Higher > > > Layer* (which according to 2284bis this will be AAA, not EAP). > > > authSuccess and authFail are variables between the 802.1X front > > > end and 802.1X back end authenticator state machines. > > > A subtle but very important distinction. > > > Jim B. > > > > > > Jim Burns wrote: > > > > > > > Nick, > > > > Correct. > > > > eapSuccess and eapFail are the variables between the 1X and EAP > > > > machine. > > > > authSuccess and authFail are variables between the 802.1X front end > > > > and 802.1X back end authenticator state machines. > > > > Sincerely, > > > > Jim B. > > > > > > > > Nick Petroni wrote: > > > > > > > >> I could be wrong, but my understanding is that authSuccess and authFail > > > >> are set in the Backend authenticator 1x state machine (p. 59) after > > > >> eapSuccess or eapFail are set. These ARE set in the Authenticator state > > > >> machine as I read it. > > > >> > > > >> Is this wrong? > > > >> > > > >> nick > > > >> > > > >> On Wed, 19 Nov 2003, Bernard Aboba wrote: > > > >> > > > >> > > > >> > > > >>> In IEEE 802.1XD7.1, page 49 in the Authenticator PAE state machine, > > > >>> the transition from AUTHENTICATING state appears to be controlled in > > > >>> part > > > >>> by the value of the authSuccess and authFail variables. However, these > > > >>> variables do not appear to be set in the corresponding EAP > > > >>> authenticator > > > >>> state machines, either in Figure 4, 5 or 6. > > > >>> > > > >>> Note that Figure 5 does set the aaaEapFail and aaaEapSuccess variables. > > > >>> _______________________________________________ > > > >>> eap mailing list > > > >>> eap@frascone.com > > > >>> http://mail.frascone.com/mailman/listinfo/eap > > > >>> > > > >>> > > > >> > > > >> > > > >> _______________________________________________ > > > >> eap mailing list > > > >> eap@frascone.com > > > >> http://mail.frascone.com/mailman/listinfo/eap > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 19 23:12:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02646 for ; Wed, 19 Nov 2003 23:11:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F02358010A; Wed, 19 Nov 2003 22:11:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D115858012E; Wed, 19 Nov 2003 22:11:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1608F58010A for ; Wed, 19 Nov 2003 22:10:07 -0600 (CST) Received: from internaut.com (unknown [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5BA2B58001A for ; Wed, 19 Nov 2003 22:08:29 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAK4Rvs11488 for ; Wed, 19 Nov 2003 20:27:57 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 202: Peer-to-peer cleanup Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 19 Nov 2003 20:27:57 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 202: Peer-to-peer cleanup Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: Nov 19, 2003 Reference: Document: RFC2284bis-06 Comment type: E Priority: 1 Section: 2.2, 2.3, 2.4, 7.2.1 Rationale/Explanation of issue: This is an issue to cleanup wording on peer-to-peer topics. This responds to issues raised by Jari Arkko relating to the term "peer listener" and "authenticator listener". On rethinking the terminology it appears to me that the terms "peer layer" and "authenticator layer" serve just as well. In Section 2.2, change: "Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer listener, if present. EAP packets with Code=2 (Response) are delivered to the EAP authenticator listener, if present. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator listener, or both." To: "Within EAP, the Code field functions much like a protocol number in IP. It is assumed that the EAP layer demultiplexes incoming EAP packets according to the Code field. Received EAP packets with Code=1 (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer layer, if implemented. EAP packets with Code=2 (Response) are delivered to the EAP authenticator layer, if implemented. Within EAP, the Type field functions much like a port number in UDP or TCP. It is assumed that the EAP peer and authenticator layers demultiplex incoming EAP packets according to their Type, and deliver them only to the EAP method corresponding to that Type. An EAP method implementation on a host may register to receive packets from the peer or authenticator layer, or both, depending on which role(s) it supports." In Section 2.3, change: "When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator listener to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it. The forwarding decision is based on examination of the Code, Identifier and Length fields. Since a "pass-through authenticator" only forwards to the backend authentication server EAP packets received from the peer and destined for its authenticator listener, pass-through authenticator implementations MUST be capable of forwarding to the backend authentication server EAP packet received from the peer with Code=2 (Response). They also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Since pass-through authenticators rely on a backend authenticator server to implement methods, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision, except where the authenticator implements one or more authentication methods locally. In this case, the authenticator may examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST be default forward EAP packets of any Type. The forwarding model is illustrated in Figure 2. Since EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer listener, unless a host implements an EAP peer listener, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS[RFC3579] and Diameter[DIAM-EAP]. " To: "When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it. A host receiving an EAP packet may only do one of three things with it: act on it, drop it, or forward it. The forwarding decision is typically based only on examination of the Code, Identifier and Length fields. A pass-through authenticator implementation MUST be capable of forwarding to the backend authentication server EAP packets received from the peer with Code=2 (Response). It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type. EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Therefore unless a host implements an EAP peer layer, these packets will be silently discarded. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore unless a host implements an EAP authenticator layer, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS[RFC3579] and Diameter[DIAM-EAP]. The forwarding model is illustrated in Figure 2." In Section 2.4, change: "Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time; in this case it is necessary to both peers to implement both EAP authenticator and peer listeners. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols and link layers may not support this. For example, EAP-TLS[RFC2716] is a client-server protocol requiring a different certificate profile for the client and server. This implies that a host supporting both the EAP-TLS peer and authenticator roles would need to implement both peer and authenticator listeners; would need to support both the peer and authenticator roles in the EAP-TLS implementation; would need to be provisioned with two distinct certificates, one appropriate for each role." To: "Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time, in which case it is necessary for both peers to implement EAP authenticator and peer layers. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols and link layers may not support this. For example, EAP-TLS[RFC2716] is a client-server protocol with a different certificate profile for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers; support both peer and authenticator roles in the EAP-TLS implementation; and provision two distinct certificates, one appropriate for each role." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 20 15:10:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22325 for ; Thu, 20 Nov 2003 15:10:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01ED7580239; Thu, 20 Nov 2003 14:10:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDA3F58023E; Thu, 20 Nov 2003 14:10:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37ED958023E for ; Thu, 20 Nov 2003 14:09:27 -0600 (CST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 8E89D580239 for ; Thu, 20 Nov 2003 14:09:25 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id hAKK9OsM025858; Thu, 20 Nov 2003 15:09:24 -0500 From: John Vollbrecht To: Pasi.Eronen@nokia.com, yohba@tari.toshiba.com, aboba@internaut.com Cc: eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues Message-ID: <9547917.1069340962@dhcp60-10.merit.edu> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38A2@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6010C38A2@esebe023.ntc.nokia.com > X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 20 Nov 2003 15:09:27 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Wednesday, November 19, 2003 11:52 AM +0200 Pasi.Eronen@nokia.com wrote: > Proposed resolution to issue 198: Other EAP Peer SM issues > > - Remove all references to EapTunnelled (it does not adequately > define behavior of existing tunneled methods, and we don't even > need to describe their behavior in this document). > I like all the changes except the removing of EapTunnelled. It is set if EAP is running in tunnelled mode and hence allowed to do method sequencing. I think this is a marker that says that sequences are not allowed on unprotected connections, but are (or are not forbidden) in protected connections. I see no reason to take this out. EAP is not constrained to run in an unprotected mode, and this indicates that everything should be the same in protected mode, except that method sequences are possible. > - Change in Section 4.1.1 (portEnabled) from: > > "Indicates that there is a valid port to use for the > communication. If at any point the port is not available, > portEnabled is set to FALSE and the state machine transitions > to DISABLED (or BACKEND_DISABLED)." > > to > > "Indicates that the EAP peer state machine should be ready for > communication. This is set to TRUE when the EAP conversation is > started by the lower layer. If at any point the communication > port or session is not available, portEnabled is set to FALSE > and the state machine transitions to DISABLED." > > - Change in Section 5.1.1 (portEnabled) from > > "Indicates that there is a valid port to use for the > communication. If at any point the port is not available, > portEnabled is set to FALSE and the state machine transitions > to DISABLED." > > to > > "Indicates that the EAP authenticator state machine should be > ready for communication. This is set to TRUE when the EAP > conversation is started by the lower layer. If at any point > the communication port or session is not available, > portEnabled is set to FALSE and the state machine transitions > to DISABLED." > > - Change in Section 4.1.3 (ClientTimeout) from: > > "Configurable amount of time to wait for a valid request > before aborting." > > to > > "Configurable amount of time to wait for a valid request > before aborting, initialized by implementation-specific > means (e.g. a configuration setting)." > > - Change in Section 4.2 from > > "methodState=DONE: The method always continues at this point, > (or the peer sees no point in continuing it)." > > to > > "methodState=DONE: The method never continues at this point > (or the peer sees no point in continuing it)." > > - Add to Section 8 (implementation considerations): > > "Implementations may define an additional interfaces to pass > method-specific information between methods and lower layers. > These interfaces are beyond the scope of this document." > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 20 16:28:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28660 for ; Thu, 20 Nov 2003 16:28:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3757158001A; Thu, 20 Nov 2003 15:28:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BAD4558012D; Thu, 20 Nov 2003 15:28:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E77A58012D for ; Thu, 20 Nov 2003 15:27:02 -0600 (CST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 4E2AC58001A for ; Thu, 20 Nov 2003 15:27:00 -0600 (CST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 13:27:36 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAKLQqw5028636 for ; Thu, 20 Nov 2003 13:26:57 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.225]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 20 Nov 2003 13:31:59 -0800 From: "Joseph Salowey" To: Message-ID: <007301c3afad$036b9110$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 20 Nov 2003 21:31:59.0456 (UTC) FILETIME=[BACAC600:01C3AFAD] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Issue] Comments on EAP-Peer state machine Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 20 Nov 2003 13:26:51 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 11/20/2003 Reference: Document: State Machine Comment type: 'E'ditorial Priority: '1' Should fix Section: 4.x Rationale/Explanation of issue: 1. portEnabled portEnabled seems very .1x/PPP specific. EAP is being used in cases such as IKE and PANA where this concept may a bit more abstract. Perhaps we can change the name of the variable and/or expand its definition to include other cases. Suggestion: Perhaps "indicates that a lower layer communcation channel has been established". 2. EAPTunneled The behavior inside tunnels needs to be defined by the tunnel as there are severl ways you can handle EAP within a tunnel. I think we decided to remove this variable at the meeting, but I want to mae sure we track it. In PEAPv2 we started out with a behavior similar to what is described in the state machine, but in order to make sure the policy on the peer and authenticator stayed in sync we introduced itermediate result indicators which I think change the state machine a little. Suggestion: Remove variable. We could explore this in an apppendix or a separate document. 3. Interface to method The interface to the method seems too complicated. First I don't think that intCheck should be a different process. Integrity checking is done as part of the method processing. Also methods aren't required to ingore packets, some methods with ignore some problems and return errors on others. I think this behavior should be incorporated into m.process. On a separate but related note it seems that the method state and decision is very complex. I don't really see the need for the independent methodState and decision variables. M.process() should return one of serverl possible results: IGNORE, CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. MethodState should be able to take on CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. I don't think a separate decision variable is necessary. Suggestion In method: methodResult = m.process(eapRespData) If (methodResult != IGNORE) { methodState = methodResult allowNotifications = TRUE|FALSE eapRespData = m.buildResponse(reqID) if (methodState == SUCCESS || methodState == COND_SUCCESS) { eapKeyData = NONE|m.getKey() } } Transition to discard: (methodResult == IGNORE) Combine methodState and decision transition conditions 4. Idle timer It seems that there is a problem with the idle timer. It would be possible for the peer to never time out if it keeps on receiving packets that it discards. This is not so good. Suggestion: Perhaps the client timeout should be set outside the IDLE state in the INITIALIZE state and in the METHOD or SEND_RESPONSE state. 5. rxSuccess and rxFailure Shouldn't rxSuccess and rxFailure check to see if (reqId == lastReqID)? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 20 16:47:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00397 for ; Thu, 20 Nov 2003 16:47:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41B6B58012E; Thu, 20 Nov 2003 15:47:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2BBA580019; Thu, 20 Nov 2003 15:47:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 263D0580019 for ; Thu, 20 Nov 2003 15:46:52 -0600 (CST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 46BCA580010 for ; Thu, 20 Nov 2003 15:46:50 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id hAKLklsM016365; Thu, 20 Nov 2003 16:46:48 -0500 From: John Vollbrecht To: jari.arkko@piuha.net, "eap@frascone.com" Cc: Bernard Aboba , Kroeselberg Dirk , Henrik Levkowetz Subject: Re: [eap] eap wg minutes from ietf-58 Message-ID: <9886023.1069346810@dhcp60-10.merit.edu> In-Reply-To: <3FBA3C0C.4090401@piuha.net> References: <3FBA3C0C.4090401@piuha.net> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 20 Nov 2003 16:46:50 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks very much for the good notes. I have cut and pasted some comments below. --On Tuesday, November 18, 2003 5:34 PM +0200 Jari Arkko wrote: > > Preliminary Minutes of the Extensible Authentication Protocol (eap) WG at > IETF-58 > > Time: Monday, November 10, 2003 at 1930-2200 > > Chairs: Bernard Aboba > Jari Arkko > > Minutes: Dirk Kroeselberg (Dirk.kroeselberg@web.de) > Henrik Levkowetz (henrik@levkowetz.com) > Edited by Jari Arkko (jarkko@piuha.net) > > URLs: Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html > Presentations: http://www.drizzle.com/~aboba/IETF58/EAP.zip > > . . > o Method documents: Approval of methods needs to wait for > completion of base EAP specifications. Currently not in EAP WG > charter to work on methods. Future methods might be specified > either as individual submissions, Informational documents outside > the WG or as chartered EAP WG work > When will the group decide whether to work on methods? Seems like this is very close. > WG Work Items -- RFC 2284bis, Henrik Levkowetz > ============================================== > > - > http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rf > c2284bis-07.d.html > > - 3rd last call on the document was held in September. There are two > open issues left: > > 1) Handling of Identity response > 2) Editorial comments by J. Puthenkulam . . I think the identity response should be worked on by the group for the long term, but not as part of 2284bis. > WG Work Items -- EAP State Machine, Pasi Eronen > =============================================== > > - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.pdf > - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-01.txt > > - Now in WG last call. Next steps: Handle issues from last call, and > publish as informational. > > - Draft describes state machine for EAP peer and EAP > authenticator. No changes on peer side since IETF-57. > > - The approach for the authenticator now is changed, due to comments > on AAA interaction: three state machines: > > o Standalone (no pass-through or AAA) > > o Backend (Interfaces to AAA module (RFC3579, Diameter), EAP > methods). > > o Full authenticator (Interfaces to lower layer (matching > 802.1X-REV), EAP methods, AAA module) > > - Discussion: > > o Bernard: What is the difference for handling tunneled methods > (tunneled variable)? Pasi Eronen: If you are not inside the > tunnel, you are not allowed to do multiple authentication > methods. Complicated, tunneled-variable will be taken out. > Joe: Makes me somewhat nervous to have that in there. > Bernard: For now, should be in there to stimulate discussion. > As I noted in response to Pasi, I think this should stay in as well. I think it says that tunnelled and non-tunnelled EAP and EAP methods have the same structure, except that tunnelled methods are allowed to do sequences of methods. > o I'd also like to say that the quality is very good, and thank the > authors, and tell people to set aside 4+4 hours and go and read > it. > > WG Work Items -- EAP Key Framework, Bernard Aboba > ================================================= > > - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt > > - Normative statements relating to EAP moved to RFC2284bis. As a > result, EAP methods no longer depend on keying framework. > Substantial revisions are in progress, currently the draft lacks a > threat model. > > - Open issues: > > o 15 (key distr. Insecure), > o 179 (EAP PRF), and > o 187 (Service SAs). > > - Security issues are: > > o Key scoping: AAA protocols authenticate at NAS granularity Client > may not be able to recognize NAS scope without assistance from > the lower layer. Possible solutions: > > . AAA agent checks > . Logging > . Key Mixing > . Method-specific binding > > o Correctness in fast handoff & context transfer > > o Lying NAS Problem > > - There were no questions. > I think this is good work, and is making progress. I am confused about why it is not needed for methods, especially methods that generate, and possibly keep keys. I would like to see at least one required to implement method that generates and keeps keys for anyone who implements such capabilities. I don't care much which method is required, but I think that TLS could be one since it is widely implemented, or I personally think requiring an Archie method, or an IKEv2 method would be good. I think such a requirement should go at least with implementing the Key Framework RFC. I also would suggest that the document might be helped with a framework that shows as outside the EAP/RADIUS framework, but that EAP/RADIUS is one place that it can be used. > > Related Work -- Network Discovery and Selection, Farid Adrangi & Pasi > Eronen > ========================================================================= > === > > - > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-a > nd-selection-00.txt > > - Discussion scoping by Jari: there's been previous question marks on > whether this functionality is needed. Since feedback is required > from other organizations, and we don't have much time for > discussion in the meeting, we will assume that network selection is > needed. Lets use the meeting time to discuss what alternatives we > have for providing this feature. > > - Problem: Even if you select an AP (based on e.g. SSID) you haven't > selected a mediating network which will carry your traffic back to > your home network > > - Farid presented examples of mediating networks, such as iPass, > 3GPP-VPLMN, GRIC. Home service network is e.g. wireless > provider. Access networks are public hotspot. Problem is not AP > selection in hotspot. EAP-based client needs information on which > home network /mediating networks are affiliated to the access > network. The proposed solution complies with the EAP spec and uses > EAP-Identity Requests to deliver network information. > > - Proposed solution is to use a "decorated NAI" inside the Identity > Response, on first or subsequent Identity Request. Identity Request > may carry information about the network which makes it possible for > the peer to select an appropriate NAI (if more than one is > available). > > - There is a 3GPP dependency for this work (3GPP TSG CN). > > - Related presentation by Pasi Eronen: Based on a discussion between > Jari, Bernard, Pasi. > > o But other solutions are possible, e.g. SSID-based. > > o Suffix routing on a NAI is better than prefix routing. > > o If an eap-layer based solution is used, EAP identity request > hints are probably OK. > > o The network cannot always ( and maybe should not ) do the > selection. So information has to be provided to the users. > > o If you try to encode the mediary network information into virtual > AP's ssid's, the amount of beacons needed might end up consuming > a significant part of the bandwidth. > > o On the other hand, if you have to associate with each of a large > number of APs, and start a EAP exchange with each in order to get > the information about > > - Discussion: > > Margaret Wasserman: Are there lessons to learn from loose source > routing? Can we become victims of single points of failure? > > Pete: Seems we are limiting us to a solution which doesn't scale > very well. And I'm not sure we should be doing this at all. > > Bernard: Today we have internet connectivity and DNS-based > routing. This was not possible with RADIUS. Why are we doing this? > It looks like there is no layer-2 alternative that can handle all > cases. > > Margaret: Assume I can choose based on some string between > mediating networks. Does not seem to be right as there should be > some policy. Do we gain something over the existing solutions > today? > > Farid: These policies can be pushed to the subsciber device > from the home network > > Farooq: It's the home network which has to settle the roaming > cost. > > Farid: Some users may care about QoS, some about cost. Policy can > be pushed by the user's home network. Margaret: There are other > WGs that investigated the concept, should be looked at as well. > Bernard Aboba: Take it to the list. > > Jari: We have a cost factor in selecting the right network. End > users care about the cost. > > - Strawpoll: > > Should this be solved in the IETF? Consensus that the problem is > worth solving. > > Should the EAP WG solve the problem? Consensus that it should be > solved in WG, but less strong than for the first question. > > - Comment by Pasi: There are solutions that do not involve EAP at > all. But EAP WG could be a good place to explore this. I think a question is who interprets the identity and how is it used. Do we expect the identiy response to be kept whole for the method but brokenup by the NAS for routing? This seems a big question, which I think should not be included in 2284bis, but possibly considered by the working group. > > > Related Work -- EAP Key Derivation for Multiple Applications, Joe Salowey > ========================================================================= > > - http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-02.txt > > - Changed the draft name to "EMSK usage guidelines" > > - 2284bis defines the EMSK. Several applications have been suggested > that use the EMSK (eap-keying, aaaarch-handoff, eap-protectedtlv) > The current proposal should either be incorporated into key > framework draft, or the keying framework should reference it. > > - Jari: May be a separate specification as well. Joe: Key framework > itself references EMSK. So either take that out, or reference it. > Russ: Its just two pages, merge it in. Jari: Ok > > Related Work - The Compound Binding Problem, Farid Adrangi (on behalf of > Jose Puthenkulam) > ========================================================================= > ================= > > - > http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt > > - Status update for 04 version of the draft: mostly editorial > improvements. Three issues (64, 191, 192) are still open. Some > crypto experts have reviewed the draft, no issues so far. Timeline > is to resolve open issues this year. Revise section 4, synchronize > with keying framework. Submit for final review in January, close in > February 04. > > - Issue: The EMSK may not be the best thing to use for the compound > bindings. We need to look a this > > - Bernard: We started looking at this because many other groups > needed something like this. Now IKEv2 is doing something similar, > and .... is doing something similar. Right now it seems like the > IETF is going violently in different directions and we get > incompatibilities. An there may be different views of whether there > is a problem. Can someone describe the different directions? > > - Russ Housley: True, need solution, proposal to formulate this in a > few slides for broader presentation in SAAG. Farid: his has > already been done in former IETFs. Bernard: We got no input then. > > > EAP methods - EAP SIM/AKA, Pasi Eronen > ====================================== > > - > http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt > - http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt > > - No open issues with the drafts. It is part of 3GPP Release 6 WLAN > inter-working. EAP/SIM products are available, deployment is > beginning. Plan is to do individual submissions as informational, > once EAP base docs finalized. No implications to 2284bis, state > machine or keying framework. > > > EAP Methods -- PEAPv2, Jose Salowey > =================================== > > - > http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07 > .txt > > - Recently submitted draft -07. Features are complete. Added support > for sequences of EAP methods. Supports inner method binding. Goal > is to submit as informational. Currently WG item not requested. > This draft is very long, and for me sometimes confusing. I would like to see an overview of what the overall flow is, including key generation and use, how the innner and outer keys are bound, how methods are sequenced, whether remote authorization over the tunnel is permitted (and what the reasoning is- perhaps this is here, but I am not finding it). I also am confused about what the crypto binding TLV does and why it is necessary. I think a diagram in a PDF document would be very helpful in this case, along with a text document, like the State Machine doc. > - Margaret: All drafts are planned to be published as > informational. I wonder about this. Bernard: It took so long to get > this WG started that much work was already more or less done, and > it may be hard for people to give up change control now, and make > these WG documents. Pasi: Correct with respect to EAP/SIM and > EAP/AKA > > EAP METHODS - EAP-IKEv2, Dirk Kroeselberg > ========================================= > > - http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-02.txt > > - A number of issues have been improved in the update, e.g. error > handling, fragmentation. There are still open issues like > optimizing the no. of messages, security claims section. Another > update planned before next IETF to address these issues. > > - Michael Richardson: Tunneling seems to be complicated, suggestion > remove support of tunneled methods or to detail use case. Dirk: > True, but applies to all tunneled methods. Is only an optional > feature in IKEv2. > > - Bernard: Is it intended to handle address assignment in EAP-IKEv2, > do we need that? Bernard: Are all identity payloads needed? Is > IKEv2 a limitation in terms of identity payloads? Dirk: Need to > check this. > Can just the initial authentication part of IKEv2 be used as a "norm", not including other payloads? Is the "normal" authentication in IKEv2 (not EAP) without Intellectual Property hindrances? > > EAP Methods - EAP Smartcard, Pascal Urien > ========================================= > > - http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-03.txt > > - Goal of the proposal is to support EAP in smartcards. No > discussion. > > > Roadmap discussion (10 minutes), WG Chairs and ADs > ================================================== > > - Steven Hayes: (clarifying 3GPP position) 3GPP requires the two > methods discussed, and network selection. Otherwise there are no > further requirements on EAP. Request to publish EAP-SIM and EAP-AKA > as informational. > > - Someone: Are the available methods sufficient to progress the > documents to Draft Standard? > > Margaret: Good point. Especially for the keying framework, a method > that uses all the features is required. > > Bernard: There is no standard method required for this, just the > use of the features with any method. > > Russ: Requirement is two independent interoperable methods. > > Bernard: You can show interoperability without having particular > methods showing them > > Margaret: Are all the methods done informational forever? So what > does the EAP WG do - wait till somebody comes along with a method > to be standardized? > > Bernard: There is one standardized mandatory method > > Russ: But that one doesn't exercise all features. > > Bernard: Somebody has to ask for a standardization effort. > > Margaret: There is no interoperability without using informational > RFCs. > > Bernard: The same issue (mandate one method) has been brought to > the group by 802.11. > > Pasi: Could update EAP-TLS as this is the only key-generating RFC > method. Current status is experimental, however. > > Jari: Some defined methods should be standardized in their second > revision, e.g. EAP-TLS. > > Margaret: We don't have the rule that because something has been > deployed, it can't be a standards track document! > > Donald: It almost seems like everything developed outside never is > to become IETF standards. We have some examples where v2 of some > documents have become - after rework - standards track documents. > > Margaret: How will expert review differ from the expert review done > for standards track documents. > > Bernard: The intention is to basically raise the bar for new > methods, as many have already been allocated, but about 70 percent > do not have a useful documentation (expert review is defined in > 2284bis). > > Bernard: If you already have a type code, it's not even sure that > the need for expert review will get triggered. Even if you have a > code allocated, that's not a guarantee that the RFC editor would > publish a document, he could decide this is awful. > > (Editor's note: Margaret later sent this e-mail to the list: > "Apparently, I said something at the EAP meeting in Minneapolis > that has caused some confusion about the IANA allocation of EAP > codepoints. > > Just to erase any confusion, I want to make it clear that I > support the current wording in the EAP draft -- that EAP > codepoints should be allocated on the basis of expert review. > This represents an increase in scrutiny from the current policy > (first- come- first- served), which I think is appropriate. I > do not believe that EAP codepoints should require an IETF > standard, and I do believe that it would be appropriate to > allocate EAP codepoints in some situations (vendor-specific or > environment-specific) where it wouldn't make sense to produce an > IETF standard. > > I do hope that the WG will consider standardizing secure, > general purpose EAP methods in the future, but I do not believe > that we should require a standards-track document in order to > obtain a codepoint.") > > Chris Elliot: I'd really like to se you take on methods work. > > Meeting adjourned. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 00:56:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18821 for ; Fri, 21 Nov 2003 00:56:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D0065801A5; Thu, 20 Nov 2003 23:56:13 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 984675801B0; Thu, 20 Nov 2003 23:56:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FE1C5801B0 for ; Thu, 20 Nov 2003 23:55:55 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B6F0F5801A5 for ; Thu, 20 Nov 2003 23:55:52 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAL6Fo403936 for ; Thu, 20 Nov 2003 22:15:50 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 20 Nov 2003 22:15:49 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 189 is enclosed below. The proposed fix is as follows: In Section 5.1, change: "Since Identity Requests and Responses are not protected, from a privacy perspective, it may be preferable for protected method-specific Identity exchanges to be used instead. Where the peer is configured to only accept authentication methods supporting protected identity exchanges, the peer MAY provide an abbreviated Identity Response (such as omitting the peer-name portion of the NAI [RFC2486]). For further discussion of identity protection, see Section 7.3." To the following: "It is RECOMMENDED that the Identity Response be used primarily for routing purposes and that EAP Methods SHOULD include an method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. Identity Requests and Responses are not protected, so from a privacy perspective it is preferable for an EAP method to include its own protected identity exchange. The Identity Response may not be the appropriate identity for the method; it may have been truncated or obfuscated so as to provide privacy; or it may have been decorated for routing purposes. Where the peer is configured to only accept authentication methods supporting protected identity exchanges, the peer MAY provide an abbreviated Identity Response (such as omitting the peer-name portion of the NAI [RFC2486]). For further discussion of identity protection, see Section 7.3. -------------------------------------------------------- Issue 189: Handling of the Identity Response Submitter name: Joe Salowey Submitter email address: jsalowey@cisco.com Date first submitted: 10/30/3003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-October/001787.html, http://mail.frascone.com/pipermail/public/eap/2003-October/001788.html Document: RFC2284bis Comment type: 'E'ditorial Priority: '1' Should fix Section: Section 5.1 and Section 2.2 Rationale/Explanation of issue: The data in the EAP-Identity Response method is typically provided to a method for processing. There are several reasons why a method may not be able to process this identity. First the identity may not be the appropriate identity for the method chosen by the server. Second the identity may have been decorated to ensure that it is routed correctly to the appropriate EAP-Server. The recommendation is to suggest that the EAP-Identity response be used primarily for routing and method selection. EAP-Methods should provided a separate mechanism for obtaining identity and not rely upon the identity response. Many proposed methods already have a way to do this. Requested change: Modify the following text in section 2.2: "Since some EAP authentication methods may wish to access the Identity, implementations SHOULD make the Identity Request and Response accessible to authentication methods (Types 4 or greater) in addition to the Identity method. However, it is recommended that future EAP Methods not rely upon the identity received in the Identity Response and have an alternate way of obtaining identity. There are several reasons why a method may not be able to process this identity; the identity may not be the appropriate identity for the method chosen by the server, the identity may have been decorated to ensure that it is routed correctly to the appropriate EAP-Server, or the identity may have been truncated or obfuscated for privacy reasons. It is recommended that the identity be used primarily for routing the request to an appropriate EAP server and that the identity response be ignored by the EAP Method. The Identity Type is discussed in Section 5.1." I 'm not sure we need to add anything to section 5.1 (although I think the implementation note needs to be fixed). There may be security considerations: in order to prevent mechanisms from revealing too much information about valid users method implementations may always ignore the identity response and use the mechanism specific identity query. The reason is that the Data in the Identity Response may not be the appropriate identity for the method chosen by the server: the identity may have been decorated to ensure that it is routed correctly by a NAS or Proxy AAAA Server to the appropriate EAP-Server, or the identity may have been truncated or obfuscated for privacy reasons. It is recommended that the Identity Response Data be used primarily for routing the request to an appropriate EAP server and/or selecting an EAP method, and that the Identity Response Data be ignored by subsequent the EAP Method. Identity Type is discussed in Section 5.1. [John Vollbrecht] how about: When an EAP Identity Method is used, Data in the EAP-Identity Response is typically provided to subsequent EAP Methods. The subsequent Method MAY use this in its processing its algorithm. Note that the information in the Identity Response is primarily used for routiing following EAP requests and for selecting a method to process the request. A method SHOULD NOT use information in the Identity response as the actual Identity to be authenticated. [Joe] I'm not sure about the last sentence. The SHOULD NOT may conflict with the previous MAY. How about. "A method SHOULD provide a method specific means for obtaining identity so it does not have to rely upon the information in identity response. [John] I understand your point. I was trying to say that the algorithm MAY use the information, otherwise why would we give it to him? However, it should not use it as the method's identity. Note that it may use the identity or identity as modified by the NAS to select which EAP method to use. That is different than using it in the method. [Joe] Isn't the method section is done before the method gets the identity? Some existing methods may require the identity that is why it should be provided to the method. I think we want to discourage reliance on the identity response in methods moving forward. [John] I think the Identity may be used by some methods (actually I am not sure this is true) which are capable of doing whatever treating of the method to get its meaning. However some methods may also use the identity from the RADIUS User-ID to get the identity. These are not the same, as the NAS may modify the EAP Identity data to support RADIUS proxy routing. I am thinking the second case [routing] is governed by a set of rules agreed to by the organization of clients and NASs not covered in this spec. This is ok. The first case - where the method uses the Identity Response data from the previous request as an identity does not seem right. In thinking about it I am not sure it actually happens in any implementations [as opposed to selecting the method instance based on the Response Data]. I think this is what you are saying should be discouraged, and I am wondering if it is SHOULD or MUST not. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 02:38:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03710 for ; Fri, 21 Nov 2003 02:37:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 841A558012B; Fri, 21 Nov 2003 01:38:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27CF0580127; Fri, 21 Nov 2003 01:38:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9824580127 for ; Fri, 21 Nov 2003 01:37:25 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8D448580126 for ; Fri, 21 Nov 2003 01:37:23 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C7BF86A90F; Fri, 21 Nov 2003 09:37:18 +0200 (EET) Message-ID: <3FBDBFAA.9060708@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] Issue 202: Peer-to-peer cleanup References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 09:32:58 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Issue 202: Peer-to-peer cleanup > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 19, 2003 > Reference: > Document: RFC2284bis-06 > Comment type: E > Priority: 1 > Section: 2.2, 2.3, 2.4, 7.2.1 > Rationale/Explanation of issue: > > This is an issue to cleanup wording on peer-to-peer topics. This responds > to issues raised by Jari Arkko relating to the term "peer listener" and > "authenticator listener". On rethinking the terminology it appears to me > that the terms "peer layer" and "authenticator layer" serve just as well. Sounds good. > In Section 2.2, change: > > "Within EAP, the Code field functions much like a protocol number in IP. > It is assumed that the EAP layer demultiplexes incoming EAP packets > according to the Code field. Received EAP packets with Code=1 (Request), 3 > (Success) and 4 (Failure) are delivered by the EAP layer to the EAP peer > listener, if present. EAP packets with Code=2 (Response) are delivered to > the EAP authenticator listener, if present. Within EAP, the Type field > functions much like a port number in UDP or TCP. It is assumed that the > EAP peer and authenticator layers demultiplex incoming EAP packets > according to their Type, and deliver them only to the EAP method > corresponding to that Type. An EAP method implementation on a host may > register to receive packets from the peer or authenticator listener, or > both." > > To: > > "Within EAP, the Code field functions much like a protocol > number in IP. It is assumed that the EAP layer demultiplexes incoming EAP > packets according to the Code field. Received EAP packets with Code=1 > (Request), 3 (Success) and 4 (Failure) are delivered by the EAP layer to > the EAP peer layer, if implemented. EAP packets with Code=2 (Response) are > delivered to the EAP authenticator layer, if implemented. Within EAP, the > Type field functions much like a port number in UDP or TCP. It is assumed > that the EAP peer and authenticator layers demultiplex incoming EAP > packets according to their Type, and deliver them only to the EAP method > corresponding to that Type. An EAP method implementation on a host may > register to receive packets from the peer or authenticator layer, or both, maybe s/layer/layers/? > depending on which role(s) it supports." > > In Section 2.3, change: > > "When operating as a "pass-through authenticator", an authenticator > performs checks on the Code, Identifier and Length fields as described in > Section 4.1. It forwards EAP packets received from the peer and destined > to its authenticator listener to the backend authentication server; > packets received from the backend authentication server destined to the > peer are forwarded to it. The forwarding decision is based on examination > of the > Code, Identifier and Length fields. Since a "pass-through authenticator" > only forwards to the backend authentication server EAP packets received > from the peer and destined for its authenticator listener, pass-through > authenticator implementations MUST be capable of forwarding to the backend > authentication server EAP packet received from the peer with Code=2 > (Response). They also MUST be capable of receiving EAP packets from the > backend authentication server and forwarding EAP packets of Code=1 > (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Since > pass-through authenticators rely on a backend authenticator server to > implement methods, the EAP method layer header fields (Type, Type-Data) > are not examined as part of the forwarding decision, except where the > authenticator implements one or more authentication methods locally. In > this case, the authenticator may examine the Type field to determine > whether to act on the packet itself or forward it. Compliant pass-through > authenticator implementations MUST be default forward EAP packets of any > Type. The forwarding model is illustrated in Figure 2. Since EAP packets > received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are > demultiplexed by the EAP layer and delivered to the peer listener, unless > a host implements an EAP peer listener, these packets will be silently > discarded. The behavior of a "pass-through peer" is undefined within this > specification, and is unsupported by AAA protocols such as RADIUS[RFC3579] > and Diameter[DIAM-EAP]. " > > To: > > "When operating as a "pass-through > authenticator", an authenticator performs checks on the Code, Identifier > and Length fields as described in Section 4.1. It forwards EAP packets > received from the peer and destined to its authenticator layer to the > backend authentication server; packets received from the backend > authentication server destined to the peer are forwarded to it. A host > receiving an EAP packet may only do one of three things with it: act on > it, drop it, or forward it. The forwarding decision is typically based > only on examination of the Code, Identifier and Length fields. A > pass-through authenticator implementation MUST be capable of forwarding to > the backend authentication server EAP packets received from the peer with > Code=2 (Response). It also MUST be capable of receiving EAP packets from > the backend authentication server and forwarding EAP packets of Code=1 > (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Unless the > authenticator implements one or more authentication methods locally which > support the authenticator role, the EAP method layer header fields (Type, > Type-Data) are not examined as part of the forwarding decision. Where the > authenticator supports local authentication methods, it MAY examine the > Type field to determine whether to act on the packet itself or forward it. > Compliant pass-through authenticator implementations MUST by default > forward EAP packets of any Type. EAP packets received with Code=1 > (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the > EAP layer and delivered to the peer layer. Therefore unless a host > implements an EAP peer layer, these packets will be silently discarded. > Similarly, EAP packets received with Code=2 (Response) are demultiplexed > by the EAP layer and delivered to the authenticator layer. Therefore > unless a host implements an EAP authenticator layer, these packets will be > silently discarded. The behavior of a "pass-through peer" is undefined > within this specification, and is unsupported by AAA protocols such as > RADIUS[RFC3579] and Diameter[DIAM-EAP]. The forwarding model is > illustrated in Figure 2." Good. > In Section 2.4, change: > > "Since EAP is a > peer-to-peer protocol, an independent and simultaneous authentication may > take place in the reverse direction (depending on the capabilities of the > lower layer). Both peers may act as authenticators and authenticatees at > the same time; in this case it is necessary to both peers to implement > both EAP authenticator and peer listeners. In addition, the EAP method > implementations on both peers must support both authenticator and peer > functionality. Although EAP supports peer-to-peer operation, some EAP > implementations, methods, AAA protocols and link layers may not support > this. For example, EAP-TLS[RFC2716] is a client-server protocol requiring > a different certificate profile for the client and server. This implies > that a host supporting both the EAP-TLS peer and authenticator roles would > need to implement both peer and authenticator listeners; would need to > support both the peer and authenticator roles in the EAP-TLS > implementation; would need to be provisioned with two distinct > certificates, one appropriate for each role." > > To: > > "Since EAP is a > peer-to-peer protocol, an independent and simultaneous authentication may > take place in the reverse direction (depending on the capabilities of the > lower layer). Both peers may act as authenticators and authenticatees at > the same time, in which case it is necessary for both peers to implement > EAP authenticator and peer layers. In addition, the EAP method > implementations on both peers must support both authenticator and peer > functionality. Although EAP supports peer-to-peer operation, some EAP > implementations, methods, AAA protocols and link layers may not support > this. For example, EAP-TLS[RFC2716] is a client-server protocol with a > different certificate profile for the client and server. This implies that > a host supporting peer-to-peer authentication with EAP-TLS would need to > implement both the EAP peer and authenticator layers; support both peer > and authenticator roles in the EAP-TLS implementation; and provision two > distinct certificates, one appropriate for each role." Good. (Sent an editorial nit in another e-mail). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 07:33:29 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11762 for ; Fri, 21 Nov 2003 07:33:26 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6105A580130; Fri, 21 Nov 2003 06:33:19 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8313E580126; Fri, 21 Nov 2003 06:33:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A5C4580127 for ; Fri, 21 Nov 2003 06:32:26 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 6E536580017 for ; Fri, 21 Nov 2003 06:32:21 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hALCWIA06967 for ; Fri, 21 Nov 2003 14:32:18 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 21 Nov 2003 14:32:17 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 14:32:17 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 14:32:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: draft-urien-eap-smartcard-03.txt Thread-Index: AcOwK3+ySmqIWoZ9QWaYuHfT8eggew== From: To: X-OriginalArrivalTime: 21 Nov 2003 12:32:17.0724 (UTC) FILETIME=[803057C0:01C3B02B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] draft-urien-eap-smartcard-03.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 14:32:17 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi everyone, Here are some questions about draft-urien-eap-smartcard-03.txt. The subscriber profile is a service that can be used to retrieve the EAP = types that the smart card implements, right? I suppose the supplicant software can easily enumerate the all the EAP methods that are available = beforehand. But I find it confusing that the draft talks about identity = selection=20 rather than EAP type selection. Shouldn't the supplicant software select the active EAP method rather than an identity?=20 Maybe the subscriber profile could contain a short description of=20 the EAP method so that could be shown by the supplicant UI. Have you considered EAP method negotiation in cases when=20 some methods are implemented by the smart card and others by supplicant software? I think this topic deserves some discussion in this = draft. If the supplicant first tries a software EAP method, and later receives=20 an EAP request of some other type, the software could forward the EAP = request to the smart card. In this case, does the terminal first need to cycle = the identities to find the correct EAP type, or can the EAP packet be directly forwarded to the card? If the smart card method is not the first method to try during EAP method negotiation, then there might not be an EAP identity round at all, so the smart card authentication should start directly with an EAP request other than identity. So it should be possible to by-pass the identity services. Or does the supplicant software need to fake an EAP identity request and then ignore the response in order=20 to get the smart card's state initialized? IPR notices: I believe the correct thing to do is to refer to the IETF = IPR pages (http://www.ietf.org/ipr.html) for an up-to-date listing of IPR = statements, and declare all IPR there. There is already one patent statement pertaining = to this=20 document: http://www.ietf.org/ietf/IPR/NOKIA-EAP-SMARTCARD.txt Regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 07:35:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11806 for ; Fri, 21 Nov 2003 07:35:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF87D580135; Fri, 21 Nov 2003 06:35:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6BB3580127; Fri, 21 Nov 2003 06:35:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 48CD1580128 for ; Fri, 21 Nov 2003 06:34:39 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 93CC4580127 for ; Fri, 21 Nov 2003 06:34:31 -0600 (CST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hALCYU618900 for ; Fri, 21 Nov 2003 14:34:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 14:34:27 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 21 Nov 2003 14:34:28 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues Thread-Index: AcOvojcIBFqM7zuDTziydwGfbFKUUwAiCJ2w From: To: , , Cc: X-OriginalArrivalTime: 21 Nov 2003 12:34:28.0653 (UTC) FILETIME=[CE3A85D0:01C3B02B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 14:34:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable John Vollbrecht wrote: > > > Proposed resolution to issue 198: Other EAP Peer SM issues > > > > - Remove all references to EapTunnelled (it does not adequately > > define behavior of existing tunneled methods, and we don't even > > need to describe their behavior in this document). > > I like all the changes except the removing of EapTunnelled. It is > set if EAP is running in tunnelled mode and hence allowed to do > method sequencing. I think this is a marker that says that > sequences are not allowed on unprotected connections, but are (or > are not forbidden) in protected connections. I see no reason to > take this out. EAP is not constrained to run in an unprotected > mode, and this indicates that everything should be the same in > protected mode, except that method sequences are possible. Ashwin Palekar thought that there actually are other differences,=20 and the current SM (with the EapTunnelled flag) doesn't correctly=20 describe the behavior of existing tunneled methods (and Yoshihiro=20 seemed to agree with him). I think they're right... there are some tricky issues relating to e.g. interrupting a method that hasn't yet finished and dealing=20 with methods that have protected result indications. 2284bis does _not_ specify how to handle these issues, so I=20 think the state machine document should not specify them either. Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 07:48:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12102 for ; Fri, 21 Nov 2003 07:48:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FA1D58012E; Fri, 21 Nov 2003 06:48:12 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55B1B580127; Fri, 21 Nov 2003 06:48:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2945C580126 for ; Fri, 21 Nov 2003 06:47:13 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 8321D580017 for ; Fri, 21 Nov 2003 06:47:06 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hALCl5A25929 for ; Fri, 21 Nov 2003 14:47:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Nov 2003 14:47:04 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 21 Nov 2003 14:47:04 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C38A7@esebe023.ntc.nokia.com> Thread-Topic: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response Thread-Index: AcOv9F8Bj3v3a8qVS5a+J2z34wc6ewAOLG6Q From: To: , X-OriginalArrivalTime: 21 Nov 2003 12:47:04.0055 (UTC) FILETIME=[907BB870:01C3B02D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 14:47:03 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: >=20 > The text of Issue 189 is enclosed below. The proposed fix is=20 > as follows: > >=20 > To the following: >=20 > "It is RECOMMENDED that the Identity Response be used primarily > for routing purposes and that EAP Methods SHOULD include an > method-specific mechanism for obtaining the identity, so that > they do not have to rely on the Identity Response. Identity > Requests and Responses are not protected, so from a privacy > perspective it is preferable for an EAP method to include its > own protected identity exchange. The Identity Response may > not be the appropriate identity for the method; it may have > been truncated or obfuscated so as to provide privacy; or it > may have been decorated for routing purposes. Where the peer > is configured to only accept authentication methods > supporting protected identity exchanges, the peer MAY > provide an abbreviated Identity Response (such as omitting > the peer-name portion of the NAI [RFC2486]). For further > discussion of identity protection, see Section 7.3. This omits the point that Identity Response is also used to select which method to use. I suggest we rephrase the beginning something like this: "It is RECOMMENDED that the Identity Response be used primarily=20 for routing purposes and selecting which EAP Method to use. =20 EAP Methods SHOULD include an method-specific..." Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 09:44:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15305 for ; Fri, 21 Nov 2003 09:44:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79BF7580129; Fri, 21 Nov 2003 08:44:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4B02580126; Fri, 21 Nov 2003 08:44:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68180580126 for ; Fri, 21 Nov 2003 08:43:17 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8DFA6580014 for ; Fri, 21 Nov 2003 08:43:15 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DA6AF6A909; Fri, 21 Nov 2003 16:43:14 +0200 (EET) Message-ID: <3FBE237E.6060706@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: jrv@umich.edu, eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues References: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 16:38:54 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > John Vollbrecht wrote: > >>>Proposed resolution to issue 198: Other EAP Peer SM issues >>> >>>- Remove all references to EapTunnelled (it does not adequately >>> define behavior of existing tunneled methods, and we don't even >>> need to describe their behavior in this document). >> >>I like all the changes except the removing of EapTunnelled. It is >>set if EAP is running in tunnelled mode and hence allowed to do >>method sequencing. I think this is a marker that says that >>sequences are not allowed on unprotected connections, but are (or >>are not forbidden) in protected connections. I see no reason to >>take this out. EAP is not constrained to run in an unprotected >>mode, and this indicates that everything should be the same in >>protected mode, except that method sequences are possible. > > > Ashwin Palekar thought that there actually are other differences, > and the current SM (with the EapTunnelled flag) doesn't correctly > describe the behavior of existing tunneled methods (and Yoshihiro > seemed to agree with him). > > I think they're right... there are some tricky issues relating to > e.g. interrupting a method that hasn't yet finished and dealing > with methods that have protected result indications. Not to mention the *very* tricky issues such as the AND/OR success schemes provided by PEAP. If I understood it correctly, you get to choose either requiring all methods in the sequence to be succesful, or just one one of them. I'm not quite sure, however, because like John I had trouble understanding the big picture in the PEAP document. That document also needs a state machine... and that state machine can then deal with issues such as the eapTunneled variable ;-) > 2284bis does _not_ specify how to handle these issues, so I > think the state machine document should not specify them either. I agree. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 09:50:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15607 for ; Fri, 21 Nov 2003 09:49:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1534A580129; Fri, 21 Nov 2003 08:50:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CCDD1580126; Fri, 21 Nov 2003 08:50:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BBCD3580126 for ; Fri, 21 Nov 2003 08:49:14 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id D1072580014 for ; Fri, 21 Nov 2003 08:49:12 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hALEnB4u007340; Fri, 21 Nov 2003 09:49:11 -0500 (EST) From: Nick Petroni To: Jari Arkko Cc: Subject: Re: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues In-Reply-To: <3FBE237E.6060706@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 09:49:11 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > > 2284bis does _not_ specify how to handle these issues, so I > > think the state machine document should not specify them either. > > I agree. for what it's worth, I think this is the key factor. The other arguments are convincing as well. I vote keep it out. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 11:04:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19215 for ; Fri, 21 Nov 2003 11:04:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 54AA4580128; Fri, 21 Nov 2003 10:05:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D48B580018; Fri, 21 Nov 2003 10:05:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5FCB580018 for ; Fri, 21 Nov 2003 10:04:34 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A16C5580014 for ; Fri, 21 Nov 2003 10:04:32 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hALGOPc07096; Fri, 21 Nov 2003 08:24:26 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 08:24:25 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Ashwin Palekar thought that there actually are other differences, > and the current SM (with the EapTunnelled flag) doesn't correctly > describe the behavior of existing tunneled methods (and Yoshihiro > seemed to agree with him). > > I think they're right... there are some tricky issues relating to > e.g. interrupting a method that hasn't yet finished and dealing > with methods that have protected result indications. > > 2284bis does _not_ specify how to handle these issues, so I > think the state machine document should not specify them either. Yes. I believe that PEAPv2, EAP-TTLS and EAP-IKEv2 behave somewhat differently in terms of their state machines, so that a single eapTunnelled flag doesn't adequately describe the behavior of all tunnelled methods. I support removing the eapTunnelled variable. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 11:07:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19341 for ; Fri, 21 Nov 2003 11:07:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 168ED580129; Fri, 21 Nov 2003 10:08:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33557580126; Fri, 21 Nov 2003 10:08:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B12E580126 for ; Fri, 21 Nov 2003 10:07:53 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 2EEF6580014 for ; Fri, 21 Nov 2003 10:07:52 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hALGRAd07249; Fri, 21 Nov 2003 08:27:10 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38A7@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C38A7@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 08:27:10 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > This omits the point that Identity Response is also used to > select which method to use. I suggest we rephrase the beginning > something like this: > > "It is RECOMMENDED that the Identity Response be used primarily > for routing purposes and selecting which EAP Method to use. > EAP Methods SHOULD include an method-specific..." I've changed the proposed text to reflect this. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 11:34:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20368 for ; Fri, 21 Nov 2003 11:34:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 804F4580014; Fri, 21 Nov 2003 10:35:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 851DB580018; Fri, 21 Nov 2003 10:35:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14B65580018 for ; Fri, 21 Nov 2003 10:34:04 -0600 (CST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id 1E384580014 for ; Fri, 21 Nov 2003 10:34:02 -0600 (CST) Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2003 08:34:14 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hALGXoiN000124; Fri, 21 Nov 2003 08:33:50 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.225]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 08:38:58 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Cc: Subject: RE: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response Message-ID: <00d901c3b04d$3ea97850$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 21 Nov 2003 16:38:58.0170 (UTC) FILETIME=[F5F12DA0:01C3B04D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 08:33:49 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Thanks Bernard, this looks good. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Friday, November 21, 2003 8:27 AM > To: Pasi.Eronen@nokia.com > Cc: eap@frascone.com > Subject: RE: [eap] Proposed Resolution to Issue 189: Handling > of the Identity Response > > > > This omits the point that Identity Response is also used to select > > which method to use. I suggest we rephrase the beginning something > > like this: > > > > "It is RECOMMENDED that the Identity Response be used primarily > > for routing purposes and selecting which EAP Method to use. > > EAP Methods SHOULD include an method-specific..." > > I've changed the proposed text to reflect this. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 11:53:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21669 for ; Fri, 21 Nov 2003 11:53:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01FA0580128; Fri, 21 Nov 2003 10:54:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2921F580018; Fri, 21 Nov 2003 10:54:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DF58580018 for ; Fri, 21 Nov 2003 10:53:24 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id B9BE2580014 for ; Fri, 21 Nov 2003 10:53:22 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hALHDIZ10019 for ; Fri, 21 Nov 2003 09:13:18 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Completion of WG last call on the EAP State Machine document Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 09:13:18 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) EAP WG last call has completed on the EAP State Machine document, draft-ietf-eap-statemachine-01.pdf. 8 issues were raised: 193, 194, 195, 196, 197, 198, 199, and 203. For details, see: http://www.drizzle.com/~aboba/EAP/eapissues.html The issues were substantitive enough that once they are resolved and an -02 document is published, we will go through EAP WG last call again. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 12:06:13 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22586 for ; Fri, 21 Nov 2003 12:06:07 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 21436580135; Fri, 21 Nov 2003 11:06:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D463580126; Fri, 21 Nov 2003 11:06:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D6FC580014 for ; Fri, 21 Nov 2003 11:05:49 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id C61FC580126 for ; Fri, 21 Nov 2003 11:05:38 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hALH5Se9024854; Sat, 22 Nov 2003 02:05:28 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hALH5Sl8023243; Sat, 22 Nov 2003 02:05:28 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA23240 ; Sat, 22 Nov 2003 02:05:28 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA07573; Sat, 22 Nov 2003 02:05:27 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA07675; Sat, 22 Nov 2003 02:05:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hALH5Qon018305; Sat, 22 Nov 2003 02:05:26 +0900 (JST) Received: from steelhead ([159.119.168.215]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HOP00AULOT0VG@tsbpo1.po.toshiba.co.jp>; Sat, 22 Nov 2003 02:05:25 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ANEhN-0002N5-00; Fri, 21 Nov 2003 09:04:01 -0800 From: Yoshihiro Ohba Subject: Re: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues In-reply-to: To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, eap@frascone.com Message-id: <20031121170400.GR10038@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 09:04:01 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, Nov 21, 2003 at 08:24:25AM -0800, Bernard Aboba wrote: > > Ashwin Palekar thought that there actually are other differences, > > and the current SM (with the EapTunnelled flag) doesn't correctly > > describe the behavior of existing tunneled methods (and Yoshihiro > > seemed to agree with him). > > > > I think they're right... there are some tricky issues relating to > > e.g. interrupting a method that hasn't yet finished and dealing > > with methods that have protected result indications. > > > > 2284bis does _not_ specify how to handle these issues, so I > > think the state machine document should not specify them either. > > Yes. I believe that PEAPv2, EAP-TTLS and EAP-IKEv2 behave somewhat > differently in terms of their state machines, so that a single > eapTunnelled flag doesn't adequately describe the behavior of all > tunnelled methods. > > I support removing the eapTunnelled variable. I agree. Yoshihiro Ohba _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 14:37:14 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28185 for ; Fri, 21 Nov 2003 14:37:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D78D0580018; Fri, 21 Nov 2003 13:37:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99F09580126; Fri, 21 Nov 2003 13:37:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2FF4C580126 for ; Fri, 21 Nov 2003 13:36:42 -0600 (CST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 37CD3580018 for ; Fri, 21 Nov 2003 13:36:37 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id hALJaXCw025361; Fri, 21 Nov 2003 14:36:33 -0500 From: John Vollbrecht To: Pasi.Eronen@nokia.com, yohba@tari.toshiba.com, aboba@internaut.com Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues Message-ID: <179276.1069425387@dhcp60-10.merit.edu> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6122327@esebe023.ntc.nokia.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 14:36:27 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Friday, November 21, 2003 2:34 PM +0200 Pasi.Eronen@nokia.com wrote: > John Vollbrecht wrote: > > > > > Proposed resolution to issue 198: Other EAP Peer SM issues > > > > > > - Remove all references to EapTunnelled (it does not adequately > > > define behavior of existing tunneled methods, and we don't even > > > need to describe their behavior in this document). > > > > I like all the changes except the removing of EapTunnelled. It is > > set if EAP is running in tunnelled mode and hence allowed to do > > method sequencing. I think this is a marker that says that > > sequences are not allowed on unprotected connections, but are (or > > are not forbidden) in protected connections. I see no reason to > > take this out. EAP is not constrained to run in an unprotected > > mode, and this indicates that everything should be the same in > > protected mode, except that method sequences are possible. > > Ashwin Palekar thought that there actually are other differences, > and the current SM (with the EapTunnelled flag) doesn't correctly > describe the behavior of existing tunneled methods (and Yoshihiro > seemed to agree with him). > > I think they're right... there are some tricky issues relating to > e.g. interrupting a method that hasn't yet finished and dealing > with methods that have protected result indications. > I agree that some tricky tunnelling issues may exist when tunnelling, but in principal a method that runs on outside a tunnell should run inside. If we are saying that one does something different inside a tunnel then it seems that tunnelled EAP and EAP are quite different, and then we should wait to get tunnelled EAP sorted out before doing methods. If there are reasons for not including this, I would at least like to know some specifics. I would think we could have something now that is restrictive and expand later in a draft for tunnelled EAP to support expanded issues like interrupted methods and handling protected results. > 2284bis does _not_ specify how to handle these issues, so I > think the state machine document should not specify them either. > I agree. The tunnelled attribute limits what can be done untunnelled. It doesn't add anything. What do you think? -- John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 14:38:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28234 for ; Fri, 21 Nov 2003 14:38:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6EDFE580018; Fri, 21 Nov 2003 13:38:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C4AD580127; Fri, 21 Nov 2003 13:38:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 094E1580018 for ; Fri, 21 Nov 2003 13:37:32 -0600 (CST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id 5C820580127 for ; Fri, 21 Nov 2003 13:37:24 -0600 (CST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Nov 2003 11:37:56 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALJbIAt001964; Fri, 21 Nov 2003 11:37:18 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.225]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 11:42:25 -0800 From: "Joseph Salowey" To: Cc: Message-ID: <00ea01c3b066$dfe2ee90$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3FAE2607.3010100@piuha.net> X-OriginalArrivalTime: 21 Nov 2003 19:42:26.0022 (UTC) FILETIME=[97221860:01C3B067] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: some comments on draft-josefsson-pppext-eap-tls-eap-07 (peapv2) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 11:37:17 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Jari, Thanks for the review. Comments inline below. Thanks, Joe > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Sunday, November 09, 2003 3:33 AM > To: Joe Salowey > Cc: eap@frascone.com > Subject: some comments on > draft-josefsson-pppext-eap-tls-eap-07 (peapv2) > > > > I read this document on the way to Minneapolis, and have > some questions and comments: > > Substantial: > > 1. Section 1, identity protection. Wouldn't it still be > possible to have an active attack against identity protection? > This seems possible > - if one of the other servers trusted by the CA > wants to intervene (or do you require specific > server cert?) > - if the client won't or can't (network access case) > check the CRL and the server's key has been compromised [Joe] Yes, if the client fails to correctly authenticate and authorize the server then attacks on identity are possible. PEAP does not require a particular certificate profile, it is currently up to the deployment. Individaul servers could authenticated, but it is not clear that that is generally required. It is also possible for the client and server to support TLS extensison to use OSCP for certificate validation. > 3. Section 2, the possibility of running zero EAP methods > in part 2. What would be the usefulness of that over > running EAP TLS? The ability to send TLVs? > [Joe] EAP-TLS requires client authentication. PEAP can be run with server only authentication and provide anonymous access to the client. The ability to send TLVs is also very very useful > 5. I wonder if the protocol specification would be clearer > with a state machine. I'm not 100% convinced that all > the cases have been covered in the text, and its hard > to visualize what is happening. Maybe its just me, but... > [Joe] this would probably be helpful. > 6. Section 4.7, Connection-Binding TLV. This is very > interesting! You say that the actual parameters are > defined by the link layers. But this does not appear > to suffice for the definition of the format on how > they are carried in this TLV, or? How would we know > which parameters and in which order are sent here > unless the 802.11i, for instance, explicitly said that > SSID and MAC address were carried inside PEAPv2 in > a particular way? > [Joe] The connection binding TLV is meant to provide a way to bind PEAP to lower layer parameters. The exact information is specific to the application that is using PEAP such as 802.11i or IKE or ???. We also need to describe a bit more about the processing of this data since the EAP-Server may not have enough information to validate it. In general I think this information would be provide to the AAA code as "authenticated channel attributes" since the AAA portion of the system would have a better idea of what to do with them. > 7. What is the purpose and semantics of the URI TLV? > [Joe] Good question. Maybe Ashwin can provide more details. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 14:38:49 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28259 for ; Fri, 21 Nov 2003 14:38:47 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83A07580129; Fri, 21 Nov 2003 13:38:27 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 154ED5801A4; Fri, 21 Nov 2003 13:38:17 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4E0D580127 for ; Fri, 21 Nov 2003 13:37:39 -0600 (CST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 172FE580018 for ; Fri, 21 Nov 2003 13:37:35 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id hALJbWCw025534; Fri, 21 Nov 2003 14:37:32 -0500 From: John Vollbrecht To: Pasi.Eronen@nokia.com, aboba@internaut.com, eap@frascone.com Subject: RE: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response Message-ID: <182833.1069425447@dhcp60-10.merit.edu> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38A7@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A6010C38A7@esebe023.ntc.nokia.com > X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 14:37:27 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I like this -- John --On Friday, November 21, 2003 2:47 PM +0200 Pasi.Eronen@nokia.com wrote: > Bernard Aboba wrote: > > > > The text of Issue 189 is enclosed below. The proposed fix is > > as follows: > > > > > > > To the following: > > > > "It is RECOMMENDED that the Identity Response be used primarily > > for routing purposes and that EAP Methods SHOULD include an > > method-specific mechanism for obtaining the identity, so that > > they do not have to rely on the Identity Response. Identity > > Requests and Responses are not protected, so from a privacy > > perspective it is preferable for an EAP method to include its > > own protected identity exchange. The Identity Response may > > not be the appropriate identity for the method; it may have > > been truncated or obfuscated so as to provide privacy; or it > > may have been decorated for routing purposes. Where the peer > > is configured to only accept authentication methods > > supporting protected identity exchanges, the peer MAY > > provide an abbreviated Identity Response (such as omitting > > the peer-name portion of the NAI [RFC2486]). For further > > discussion of identity protection, see Section 7.3. > > This omits the point that Identity Response is also used to > select which method to use. I suggest we rephrase the beginning > something like this: > > "It is RECOMMENDED that the Identity Response be used primarily > for routing purposes and selecting which EAP Method to use. > EAP Methods SHOULD include an method-specific..." > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 14:44:06 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28391 for ; Fri, 21 Nov 2003 14:44:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F4193580126; Fri, 21 Nov 2003 13:44:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BE76580127; Fri, 21 Nov 2003 13:44:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0362C580126 for ; Fri, 21 Nov 2003 13:43:30 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 18482580018 for ; Fri, 21 Nov 2003 13:43:26 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hALJhO4u015470; Fri, 21 Nov 2003 14:43:24 -0500 (EST) From: Nick Petroni To: John Vollbrecht Cc: Subject: RE: [eap] Proposed Resolution to Issue 189: Handling of the Identity Response In-Reply-To: <182833.1069425447@dhcp60-10.merit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 14:43:24 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) agreed. Nick L. Petroni, Jr. Graduate Student, Computer Science Maryland Information Systems Security Lab University of Maryland http://www.cs.umd.edu/~npetroni On Fri, 21 Nov 2003, John Vollbrecht wrote: > > I like this -- John > > --On Friday, November 21, 2003 2:47 PM +0200 Pasi.Eronen@nokia.com wrote: > > > Bernard Aboba wrote: > > > > > > The text of Issue 189 is enclosed below. The proposed fix is > > > as follows: > > > > > > > > > > > To the following: > > > > > > "It is RECOMMENDED that the Identity Response be used primarily > > > for routing purposes and that EAP Methods SHOULD include an > > > method-specific mechanism for obtaining the identity, so that > > > they do not have to rely on the Identity Response. Identity > > > Requests and Responses are not protected, so from a privacy > > > perspective it is preferable for an EAP method to include its > > > own protected identity exchange. The Identity Response may > > > not be the appropriate identity for the method; it may have > > > been truncated or obfuscated so as to provide privacy; or it > > > may have been decorated for routing purposes. Where the peer > > > is configured to only accept authentication methods > > > supporting protected identity exchanges, the peer MAY > > > provide an abbreviated Identity Response (such as omitting > > > the peer-name portion of the NAI [RFC2486]). For further > > > discussion of identity protection, see Section 7.3. > > > > This omits the point that Identity Response is also used to > > select which method to use. I suggest we rephrase the beginning > > something like this: > > > > "It is RECOMMENDED that the Identity Response be used primarily > > for routing purposes and selecting which EAP Method to use. > > EAP Methods SHOULD include an method-specific..." > > > > Best regards, > > Pasi > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 14:51:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28563 for ; Fri, 21 Nov 2003 14:51:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B637A580018; Fri, 21 Nov 2003 13:51:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BCB8580126; Fri, 21 Nov 2003 13:51:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A459A580126 for ; Fri, 21 Nov 2003 13:50:58 -0600 (CST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id B0A0F580018 for ; Fri, 21 Nov 2003 13:50:53 -0600 (CST) Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2003 11:51:17 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hALJonrX005841; Fri, 21 Nov 2003 11:50:49 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.225]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 11:55:56 -0800 From: "Joseph Salowey" To: "'John Vollbrecht'" , , , Cc: Subject: RE: [eap] Proposed resolution of Issue 198: Other EAP Peer SM Issues Message-ID: <00eb01c3b068$c3417480$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <179276.1069425387@dhcp60-10.merit.edu> X-OriginalArrivalTime: 21 Nov 2003 19:55:56.0965 (UTC) FILETIME=[7A7E2D50:01C3B069] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 11:50:48 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > > Ashwin Palekar thought that there actually are other > differences, and > > the current SM (with the EapTunnelled flag) doesn't > correctly describe > > the behavior of existing tunneled methods (and Yoshihiro seemed to > > agree with him). > > > > I think they're right... there are some tricky issues > relating to e.g. > > interrupting a method that hasn't yet finished and dealing with > > methods that have protected result indications. > > > > I agree that some tricky tunnelling issues may exist when > tunnelling, but > in principal a method that runs on outside a tunnell should > run inside. If > we are saying that one does something different inside a > tunnel then it > seems that tunnelled EAP and EAP are quite different, and > then we should > wait to get tunnelled EAP sorted out before doing methods. > [Joe] I don't think the problem is methods behaving differently inside and outside the tunnel, but rather in how the tunnels behave themselves. > If there are reasons for not including this, I would at least > like to know > some specifics. I would think we could have something now that is > restrictive and expand later in a draft for tunnelled EAP to support > expanded issues like interrupted methods and handling > protected results. > [Joe] There are several issues to consider: how inner authenticaiton is bound to the tunneling layer, how the peer and server maintain synchronicity of state, and there are probably others. I think that having something now that is restrictive is not good. I think it would be very worthwile to explore these issues outside of the SM and 2284bis. > > > 2284bis does _not_ specify how to handle these issues, so I > think the > > state machine document should not specify them either. > > > > I agree. The tunnelled attribute limits what can be done > untunnelled. It > doesn't add anything. > > What do you think? > > -- John > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 15:16:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00648 for ; Fri, 21 Nov 2003 15:16:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6236580129; Fri, 21 Nov 2003 14:17:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89AE4580126; Fri, 21 Nov 2003 14:17:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38798580126 for ; Fri, 21 Nov 2003 14:17:00 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id E35BC580018 for ; Fri, 21 Nov 2003 14:16:58 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hALKGw4u016287; Fri, 21 Nov 2003 15:16:58 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 193: Peer SM review In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 15:16:58 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sorry I am just getting around to commenting. Comments inline. > > "pass EAP messages to a Backend Server where the real Authentication > Method resides" > > As is made clear later, the pass-through authenticator does *not* forward > all EAP messages to the backend authentication server, only EAP-Responses. > Rephrase to: > > "pass EAP-Response messages to a Backend Server where the Authentication > Method resides" ok. > Third paragraph: > > The implication is the EAP method demultiplexing depends on the lower > layer. This is not the case because all EAP implementations on all media > must support demultiplexing (whether they support an authenticator or > peer listener is another issue). > > Suggest replacing the paragraph with: > > "As noted in RFC 2284bis, Section 2.3, the EAP layer demultiplexes > incoming EAP packets. Packets with Code=2 (Response) are delivered to the > Authenticator state machine, while packets with Code=1 (Request), 3 > (Success) or 4 (Failure) are delivered to the Peer state machine." ok. > Page 9, Figure 3. > > The notation used later (Figure 6) is more clear than the use of the "|" > operator as in Figure 3. I'd recommend adopting the Figure 6 notation > everywhere. sure, it doesn't matter to me. The notation is clearly stated, but it's fine if the second way is more readable. > It would appear to me that methodState is a variable that needs to be > exported from the peer to the lower layer. This is so that lower layer > state machines such as 802.1X can know whether their own state machines > should be affected or not. already discussed, I agree with Yoshihiro. > > The INITIALIZE state does not initialize all variables. Non-initialized > variables > include: > > eapKeyData = NONE > eapKeyAvailable = FALSE > eapSuccess = FALSE > eapFail = FALSE > methodState = NONE > selectedMethod = NONE > decision = FAIL > > The initialization values seem important since transitions can be based on > them before they are initialized. Re-initializing variables in the > INITIALIZE state is a bit different from giving the variables initial > values before they are ever used. agreed. > > Not sure what "decision = FAIL | COND_SUCC" means in the INITIALIZE state. > I assume this means that this variable can be assigned one of two values, > at the implementation's descretion. I think we want this variable > initialized to FAIL. The problem here is that while the default value is to NOT accept a canned success, there are protocols wehre canned success is used. For example, figure 8-10 of 802.1X-REV contains a txCannedSuccess() function. If we don not handle this on the EAP side, they will have to explicitly check for it themselves. Perhaps we should note that the preferred vale is FAIL, but that COND_SUCC is also possible for those willing to accept canned succes. > There is a transition from the IDLE state to the SUCCESS and FAILURE > states. This occurs without appearing to require receipt of a packet. I > think that this can't be the case; something has to be received at some > point for the peer to leave idleWhile OR it is a situation where the peer > is testing whether the authenticator is EAP-capable (e.g. > a wired LAN application). perhaps this should be a separate issue. It seems that if a canned success is allowed, a canned alternative success also should be,but this reduces to a no-EAP-message protocol. Sounds funny. > The transition to FAILURE state occurs when an alternative indication of > Rejection occurs (e.g. Disassociate); when the idleWhile timer runs out > and the decision is not an unconditional success; when an alternative > indication of success is available but the decision is FAIL. > > There is also a transition from the IDLE state to the SUCCESS state. > This can occur when the idleWhile timer runs out and the decision is > an unconditional success; or when an alternative indication of success > is available and the decision is not FAILURE. > > It seems that the INITIALIZE state will need to have the correct default > values or these transitions may not occur correctly. yes. agree the initailizations should be explicit. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 21 18:09:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10917 for ; Fri, 21 Nov 2003 18:08:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A60B8580126; Fri, 21 Nov 2003 17:09:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67E03580018; Fri, 21 Nov 2003 17:09:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD387580018 for ; Fri, 21 Nov 2003 17:08:40 -0600 (CST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 1D950580017 for ; Fri, 21 Nov 2003 17:08:39 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hALN8ZrX019126; Fri, 21 Nov 2003 15:08:35 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.225]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Nov 2003 15:13:43 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Issue 200: Endpoint verification Message-ID: <00fc01c3b084$637c2d80$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 21 Nov 2003 23:13:43.0228 (UTC) FILETIME=[1B5637C0:01C3B085] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 21 Nov 2003 15:08:33 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm a little worried about the usage of EAP server and AAA server terminology. I don't think that these two entities are the same thing. An EAP-Server is typically embedded within the AAA server, but I don't think that this has to be the case. In particular the EAP-Server knows how to execute EAP mechanisms, but it knows little or nothing about the underlying application using EAP. The underlying application is the domain of the AAA server. Also if discrepancies exist in the data provided to the AAA may it be appropriate to take action beyond logging? Suggested revision below: > > 7.15 Endpoint Verification > > It is possible for a compromised or poorly implemented EAP > authenticator to communicate inconsistent information to > the EAP peer and server. This may enable an authenticator > to impersonate another authenticator or communicate > incorrect information via out-of-band mechanisms such as via > a AAA or lower layer protocol. > > Where EAP is used in passthrough mode, the EAP peer typically > does not verify the identity of the authenticator, it only > verifies that the authenticator is trusted by the EAP server. > This lack of endpoint verification creates a potential > security vulnerability. > > While [RFC3579] Section 4.3.7 describes how an EAP > authenticator providing incorrect information to a AAA server > (such as a forged NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address > attributes) can be detected, it is possible for the AP to > provide the correct information to the AAA server while > communicating incorrect information to the EAP peer via a > lower layer protocol. > > For example, it is possible for an authenticator to utilize > another authenticator's Calling-Station-Id in communicating > with the EAP peer, or for the authenticator to provide > incorrect information on the peer's Calling-Station-Id to the > AAA server. > > In order to address this vulnerability, EAP methods may > support a protected exchange of endpoint identifiers, > including (but not limited to): Called-Station-Id > [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], > NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and > NAS-IPv6-Address [RFC3162]. > > Using such an exchange, the EAP server could match the > Called-Station-Id and Calling-Station-Id provided by the EAP > peer against that provided by the authenticator via the AAA > protocol. Similarly, if the peer is provided with the > authenticator's NAS-Identifier, NAS-IP-Address or > NAS-IPv6-Address via the lower layer protocol, it could > provide this information to the EAP server via the EAP > method, allowing the EAP server to match it against the > equivalent information provided by the authenticator via the > AAA protocol. Where discrepancies exist, these SHOULD be logged. > [Joe] replace "allowing the EAP server to match it against the equivalent information provided by the authenticator via the AAA protocol." With "allowing the EAP server to provide this information to the AAA server to match it against the equivalent information provided by the authenticator via the AAA protocol." > Add to non-normative references: > > [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, > "Remote Authentication Dial In User Service (RADIUS)", > RFC 2865, June 2000. > > [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", > RFC 3162, August 2001. > > [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. > Roese, "IEEE 802.1X Remote Authentication Dial In User > Service (RADIUS) Usage Guidelines", RFC 3580, > September 2003. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Nov 22 12:48:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17339 for ; Sat, 22 Nov 2003 12:48:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BF50D580128; Sat, 22 Nov 2003 11:49:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1595A580018; Sat, 22 Nov 2003 11:49:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E86E3580126 for ; Sat, 22 Nov 2003 11:48:36 -0600 (CST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 1FD9B580014 for ; Sat, 22 Nov 2003 11:48:35 -0600 (CST) Received: from [10.0.1.2] (pm663-39.dialip.mich.net [207.75.182.241]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id hAMHmQCw008402; Sat, 22 Nov 2003 12:48:28 -0500 From: John Vollbrecht To: Joseph Salowey , "'Bernard Aboba'" , eap@frascone.com Subject: RE: [eap] Issue 200: Endpoint verification Message-ID: <1205958.1069505305@[10.0.1.2]> In-Reply-To: <00fc01c3b084$637c2d80$0200000a@amer.cisco.com> References: <00fc01c3b084$637c2d80$0200000a@amer.cisco.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 22 Nov 2003 12:48:25 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit --On Friday, November 21, 2003 3:08 PM -0800 Joseph Salowey wrote: > I'm a little worried about the usage of EAP server and AAA server > terminology. I don't think that these two entities are the same thing. > An EAP-Server is typically embedded within the AAA server, but I don't > think that this has to be the case. In particular the EAP-Server knows > how to execute EAP mechanisms, but it knows little or nothing about the > underlying application using EAP. The underlying application is the > domain of the AAA server. > > Also if discrepancies exist in the data provided to the AAA may it be > appropriate to take action beyond logging? > > Suggested revision below: > > > > > 7.15 Endpoint Verification > > > > It is possible for a compromised or poorly implemented EAP > > authenticator to communicate inconsistent information to > > the EAP peer and server. This may enable an authenticator > > to impersonate another authenticator or communicate > > incorrect information via out-of-band mechanisms such as via > > a AAA or lower layer protocol. > > > > Where EAP is used in passthrough mode, the EAP peer typically > > does not verify the identity of the authenticator, it only > > verifies that the authenticator is trusted by the EAP server. > > This lack of endpoint verification creates a potential > > security vulnerability. > > > > While [RFC3579] Section 4.3.7 describes how an EAP > > authenticator providing incorrect information to a AAA server > > (such as a forged NAS-Identifier, NAS-IP-Address or NAS-IPv6-Address > > attributes) can be detected, it is possible for the AP to > > provide the correct information to the AAA server while > > communicating incorrect information to the EAP peer via a > > lower layer protocol. > > This is certainly true. I am not sure what the consequences are. Nothing in the spec says what except the EAP packet and perhaps the Identity gets passed to the EAP method. > > For example, it is possible for an authenticator to utilize > > another authenticator's Calling-Station-Id in communicating > > with the EAP peer, or for the authenticator to provide > > incorrect information on the peer's Calling-Station-Id to the > > AAA server. > > In this case the AP is lying accross the interface to either EAP directly or to AAA and to EAP indirectly. In the latter case it has a fraudulent RADIUS packet sent from a trusted AP to the RADIUS server. > > In order to address this vulnerability, EAP methods may > > support a protected exchange of endpoint identifiers, > > including (but not limited to): Called-Station-Id > > [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], > > NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and > > NAS-IPv6-Address [RFC3162]. > > This may be needed to create a binding with this info to a key in methods that create keys. If this information is not included in EAP exchange but passed by the AP to the EAP method (directly or indirectly via AAA protocol) and then included in the key binding, then perhaps this attribute passing capability should be included in the spec. Including it in methods seems reasonable suggestion. > > Using such an exchange, the EAP server could match the > > Called-Station-Id and Calling-Station-Id provided by the EAP > > peer against that provided by the authenticator via the AAA > > protocol. Similarly, if the peer is provided with the > > authenticator's NAS-Identifier, NAS-IP-Address or > > NAS-IPv6-Address via the lower layer protocol, it could > > provide this information to the EAP server via the EAP > > method, allowing the EAP server to match it against the > > equivalent information provided by the authenticator via the > > AAA protocol. Where discrepancies exist, these SHOULD be logged. > > > [Joe] replace > > "allowing the EAP server to match it against the > equivalent information provided by the authenticator via the > AAA protocol." > > With > > "allowing the EAP server to provide this information to the AAA > server to match it against the equivalent information provided > by the authenticator via the AAA protocol." > > I think this is a good statement, except that it doesn't seem to matter whether the information is provided directly by the AP or indirectly by the AAA protocol. So - the AP could lie to EAP, or the RADIUS Server could lie to EAP. I think both cases should be included. Also, I am not sure that the EAP Server per se would do the checking, but the EAP method could. Perhaps the EAP Server and method are the same in this instance? The terminology is a bit unclear to me. Since the Client and AP can use the key to verify that the Client and EAP Server/method created the key, one check is made when the AP and Client initiate communication with the key. The check could be made somewhere else as well, but I am not clear exacly where it is useful - perhaps someone could explain. -- John _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 23 11:24:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24340 for ; Sun, 23 Nov 2003 11:23:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5AC3580128; Sun, 23 Nov 2003 10:24:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70F9D580018; Sun, 23 Nov 2003 10:24:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7498C580018 for ; Sun, 23 Nov 2003 10:23:50 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5CEAD580014 for ; Sun, 23 Nov 2003 10:23:48 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hANGhXq16619 for ; Sun, 23 Nov 2003 08:43:33 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed Resolution to Issue 200: Endpoint Verification Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 23 Nov 2003 08:43:32 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 200 is enclosed below. The proposed resolution is as follows: Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following security claim: Endpoint verification: No Add the following definition to section 7.2.1: Endpoint verification The verification within an EAP method of endpoint identifiers communicated out of band (such as via a AAA or lower layer protocol). Add to Section 7.1: [10] An attacker acting as an authenticator may provide inconsistent information to the EAP peer and server. This includes impersonating another authenticator, or communicating incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol). Add Section 7.15: 7.15 Endpoint Verification It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol). Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This lack of endpoint verification creates a potential security vulnerability. [RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol. For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865] [RFC3580] to the AAA server via the AAA protocol. In order to address this vulnerability, EAP methods may support a protected exchange of endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such an exchange, the EAP peer and server can match parameters provided by the authenticator (such as endpoint identifiers) via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies exist, these SHOULD be logged; additional actions MAY also be taken, such as denying access. Add to non-normative references: [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", RFC 3162, August 2001. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. ------------------------------------------------------------------------ Issue 200: Endpoint verification Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: Nov 17, 2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-November/001845.html Document: RFC2284bis-06 Comment type: T Priority: S Section: 5, 7 Rationale/Explanation of issue: The Security Claims section doesn't include a claim for a solution to the "Lying NAS" problem, and this attack is not included in the threat model either. [Joe Salowey] I'm a little worried about the usage of EAP server and AAA server terminology. I don't think that these two entities are the same thing. An EAP-Server is typically embedded within the AAA server, but I don't think that this has to be the case. In particular the EAP-Server knows how to execute EAP mechanisms, but it knows little or nothing about the underlying application using EAP. The underlying application is the domain of the AAA server. Also if discrepancies exist in the data provided to the AAA may it be appropriate to take action beyond logging? Replace: "allowing the EAP server to match it against the equivalent information provided by the authenticator via the AAA protocol." With "allowing the EAP server to provide this information to the AAA server to match it against the equivalent information provided by the authenticator via the AAA protocol." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 24 08:34:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07339 for ; Mon, 24 Nov 2003 08:33:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8ADCC580014; Mon, 24 Nov 2003 07:34:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4DE83580126; Mon, 24 Nov 2003 07:34:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F344580126 for ; Mon, 24 Nov 2003 07:33:04 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 953BC580014 for ; Mon, 24 Nov 2003 07:33:02 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAODX1A07304 for ; Mon, 24 Nov 2003 15:33:01 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Nov 2003 15:32:53 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 15:32:53 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 15:32:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2D08426B7EAC7745B0AC1B0BD037944F0A56ED@trebe003.europe.nokia.com> Thread-Topic: Proposed resolutions to Greg's comments Thread-Index: AcOpFrrMgKSL0T2MTuSTaGkkWrYYQAJaiNJg From: To: X-OriginalArrivalTime: 24 Nov 2003 13:32:53.0158 (UTC) FILETIME=[7650CC60:01C3B28F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolutions to Greg's comments on EAP SIM and EAP AKA Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:32:49 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi everyone,=20 I just forwarded Greg Rose's comments on EAP SIM to this mailing list. I'm not sure the file will=20 be posted because it is quite big. If not, I'll make it available at some www page. Most of Greg's comments on EAP SIM are easy to resolve just=20 by incorporating them in the document. Most of them are relevant to EAP AKA too, so we'll update it as well. Please see below for discussion on the ones that need=20 more attention. The changes are clarifications and corrections on=20 the specification language. There won't be any=20 technical changes to the protocol. Regards, Henry -- The usage of owlan.org in the NAI realm portion:=20 The 3gppnetwork.org realm should be used instead of owlan.org,=20 once the the 3GPP spec is stable. I wonder if it already is.=20 The owlan.org thing was introduced before the 3GPP standardization.=20 It could still be mentioned to inform people that it is=20 used by some implementations. I don't think there are DNS servers at owlan.org, so this realm can only be used for manually configured AAA routing. Re-authentication: It is included because it is recommended in 802.11i. There are good reasons to believe that EAP=20 authentication will be performed frequently. It could be OK to use=20 the full authentication procedure instead. The re-authentication procedure is optional, and the operator can=20 take into use only once there is evidence that it is needed. What NAI realm to use with pseudonym usernames and=20 re-authentication usernames: We should probably discuss this=20 some more in the document. We assume that all servers are able to map pseudonyms to the permanent identity. So the peer=20 can use the same realm name with pseudonyms as it uses with the permanent identity, and it does not matter if the server is different. For example, if the 3GPP pseudonym mechanism is used, then the servers share a pseudonym encryption key which they can use to decode each other's pseudonyms. (There is also a mechanism to request for the permanent identity in case the server fails to map the pseudonym to the permanent identity.) We have included a realm in the re-authentication identities assigned=20 by the server. This should allow the re-authentication requests to be routed to the same server that performed=20 the full authentication. Encrypting the NONCE_S: it would not be necessary. It is encrypted=20 just because it _can_ be, and the encryption doesn't cost anything.=20 All parameters in this message are encrypted. Use of CTR mode instead of CBC: Yes, it would be a lot more convenient.=20 We have been avoiding any incompatible changes unless they are critical. So we think we shouldn't change this for the first versions=20 of the protocol, because the CBC mode doesn't have any critical=20 problems. But if there are other reasons to break compatibility in=20 some later version, we should definitely consider replacing=20 the CBC mode too. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 24 14:29:07 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23176 for ; Mon, 24 Nov 2003 14:29:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0785580126; Mon, 24 Nov 2003 13:29:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12B56580027; Mon, 24 Nov 2003 13:29:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7F53D580027 for ; Mon, 24 Nov 2003 13:28:34 -0600 (CST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id AC055580023 for ; Mon, 24 Nov 2003 13:28:32 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAOJSMiN019012; Mon, 24 Nov 2003 11:28:29 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.96.225]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 24 Nov 2003 11:33:32 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed Resolution to Issue 200: Endpoint Verification Message-ID: <000901c3b2c1$1f53e550$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 24 Nov 2003 19:33:32.0357 (UTC) FILETIME=[D8488750:01C3B2C1] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 24 Nov 2003 11:28:21 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I still find this section to be problematic, comments inlien below. > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Sunday, November 23, 2003 8:44 AM > To: eap@frascone.com > Subject: [eap] Proposed Resolution to Issue 200: Endpoint Verification > > > The text of Issue 200 is enclosed below. The proposed > resolution is as > follows: > > Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the > following security claim: > > Endpoint verification: No > Add the following definition to section 7.2.1: > > Endpoint verification > The verification within an EAP method of endpoint > identifiers communicated out of band (such as via > a AAA or lower layer protocol). [Joe]Having this verification within an EAP-Method is problemaitc. It requires the EAP-Method to have a lot of specific details about the environment in which it is used. EAP-methods should be independent of the environemnt. I would rather see "Channel Binding The communiction of integrity protected data of underlying channel proterties such as endpoint identifiers that can be compared outside the EAP method to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol)." > > Add to Section 7.1: > > [10] An attacker acting as an authenticator may provide > inconsistent information to the EAP peer and server. This > includes impersonating another authenticator, or > communicating incorrect information via out-of-band > mechanisms (such as via a AAA or lower layer protocol). > > Add Section 7.15: > > 7.15 Endpoint Verification [Joe] Replace with "Channel Binding" > > It is possible for a compromised or poorly implemented EAP > authenticator to communicate incorrect information to the EAP > peer and/or server. This may enable an authenticator to > impersonate another authenticator or communicate incorrect > information via out-of-band mechanisms (such as via a AAA or > lower layer protocol). > > Where EAP is used in pass-through mode, the EAP peer > typically does not verify the identity of the pass-through > authenticator, it only verifies that the pass-through > authenticator is trusted by the EAP server. This lack of > endpoint verification creates a potential security vulnerability. > > [RFC3579] Section 4.3.7 describes how an EAP pass-through > authenticator acting as a AAA client can be detected if it > attempts to impersonate another authenticator (such by > sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address > [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the > AAA protocol). However, it is possible for a pass-through > authenticator acting as a AAA client to provide correct > information to the AAA server while communicating misleading > information to the EAP peer via a lower layer protocol. > > For example, it is possible for a compromised authenticator > to utilize another authenticator's Called-Station-Id in > communicating with the EAP peer via a lower layer protocol, > or for a pass-through authenticator acting as a AAA client to > provide an incorrect peer Calling-Station-Id [RFC2865] > [RFC3580] to the AAA server via the AAA protocol. > > In order to address this vulnerability, EAP methods may > support a protected exchange of endpoint identifiers, > including (but not limited to): Called-Station-Id > [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], > NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and > NAS-IPv6-Address [RFC3162]. > > Using such an exchange, the EAP peer and server can match > parameters provided by the authenticator (such as endpoint > identifiers) via out-of-band mechanisms against those > exchanged within the EAP method. Where discrepancies exist, > these SHOULD be logged; additional actions MAY also be taken, > such as denying access. > > Add to non-normative references: > > [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, > "Remote Authentication Dial In User Service (RADIUS)", RFC > 2865, June 2000. > > [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and > IP6", RFC 3162, August 2001. > > [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. > Roese, "IEEE 802.1X Remote Authentication Dial In User > Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. > > -------------------------------------------------------------- > ---------- > Issue 200: Endpoint verification > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 17, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-November/00 1845.html Document: RFC2284bis-06 Comment type: T Priority: S Section: 5, 7 Rationale/Explanation of issue: The Security Claims section doesn't include a claim for a solution to the "Lying NAS" problem, and this attack is not included in the threat model either. [Joe Salowey] I'm a little worried about the usage of EAP server and AAA server terminology. I don't think that these two entities are the same thing. An EAP-Server is typically embedded within the AAA server, but I don't think that this has to be the case. In particular the EAP-Server knows how to execute EAP mechanisms, but it knows little or nothing about the underlying application using EAP. The underlying application is the domain of the AAA server. Also if discrepancies exist in the data provided to the AAA may it be appropriate to take action beyond logging? Replace: "allowing the EAP server to match it against the equivalent information provided by the authenticator via the AAA protocol." With "allowing the EAP server to provide this information to the AAA server to match it against the equivalent information provided by the authenticator via the AAA protocol." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Nov 24 16:08:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29920 for ; Mon, 24 Nov 2003 16:07:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D27458012F; Mon, 24 Nov 2003 15:08:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E900C580128; Mon, 24 Nov 2003 15:08:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3F3158012D for ; Mon, 24 Nov 2003 15:07:09 -0600 (CST) Received: from struggle.mr.itd.umich.edu (struggle.mr.itd.umich.edu [141.211.14.79]) by mail.frascone.com (Postfix) with ESMTP id 14883580126 for ; Mon, 24 Nov 2003 15:07:05 -0600 (CST) Received: from dhcp60-10.merit.edu (dhcp60-10.merit.edu [198.108.60.210]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id hAOL73un004369; Mon, 24 Nov 2003 16:07:04 -0500 From: John Vollbrecht To: Bernard Aboba , eap@frascone.com Subject: Re: [eap] Proposed Resolution to Issue 200: Endpoint Verification Message-ID: <352335.1069690019@dhcp60-10.merit.edu> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 24 Nov 2003 16:06:59 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit nice - I like it. John --On Sunday, November 23, 2003 8:43 AM -0800 Bernard Aboba wrote: > The text of Issue 200 is enclosed below. The proposed resolution is as > follows: > > Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following > security claim: > > Endpoint verification: No > Add the following definition to section 7.2.1: > > Endpoint verification > The verification within an EAP method of endpoint > identifiers communicated out of band (such as via > a AAA or lower layer protocol). > > Add to Section 7.1: > > [10] An attacker acting as an authenticator may provide > inconsistent information to the EAP peer > and server. This includes impersonating another > authenticator, or communicating incorrect information > via out-of-band mechanisms (such as via > a AAA or lower layer protocol). > > Add Section 7.15: > > 7.15 Endpoint Verification > > It is possible for a compromised or poorly implemented EAP > authenticator to communicate incorrect information to the EAP > peer and/or server. This may enable an authenticator > to impersonate another authenticator or communicate > incorrect information via out-of-band mechanisms (such as via a > AAA or lower layer protocol). > > Where EAP is used in pass-through mode, the EAP peer typically > does not verify the identity of the pass-through authenticator, it > only verifies that the pass-through authenticator is trusted by the EAP > server. This lack of endpoint verification creates a potential > security vulnerability. > > [RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator > acting as a AAA client can be detected if it attempts to impersonate > another authenticator (such by sending incorrect NAS-Identifier [RFC2865], > NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes > via the AAA protocol). However, it is possible for a pass-through > authenticator acting as a AAA client to provide correct information to > the AAA server while communicating misleading information to the EAP peer > via a lower layer protocol. > > For example, it is possible for a compromised authenticator to utilize > another authenticator's Called-Station-Id in communicating with the EAP > peer via a lower layer protocol, or for a pass-through authenticator > acting as a AAA client to provide an incorrect peer Calling-Station-Id > [RFC2865] [RFC3580] to the AAA server via the AAA protocol. > > In order to address this vulnerability, EAP methods may support > a protected exchange of endpoint identifiers, including > (but not limited to): Called-Station-Id [RFC2865][RFC3580], > Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier, [RFC2865], > NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. > > Using such an exchange, the EAP peer and server can match parameters > provided by the authenticator (such as endpoint identifiers) via > out-of-band mechanisms against those exchanged within the EAP method. > Where discrepancies exist, these SHOULD be logged; additional actions MAY > also be taken, such as denying access. > > Add to non-normative references: > > [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, > "Remote Authentication Dial In User Service (RADIUS)", > RFC 2865, June 2000. > > [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", > RFC 3162, August 2001. > > [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. > Roese, "IEEE 802.1X Remote Authentication Dial In User > Service (RADIUS) Usage Guidelines", RFC 3580, > September 2003. > > ------------------------------------------------------------------------ > Issue 200: Endpoint verification > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 17, 2003 > Reference: > http://mail.frascone.com/pipermail/public/eap/2003-November/001845.html > Document: RFC2284bis-06 > Comment type: T > Priority: S > Section: 5, 7 > Rationale/Explanation of issue: > > The Security Claims section doesn't include a claim for > a solution to the "Lying NAS" problem, and this attack > is not included in the threat model either. > > [Joe Salowey] I'm a little worried about the usage of EAP server and AAA > server terminology. I don't think that these two entities are the same > thing. > > An EAP-Server is typically embedded within the AAA server, but I don't > think that this has to be the case. In particular the EAP-Server knows > how to execute EAP mechanisms, but it knows little or nothing about the > underlying application using EAP. The underlying application is the > domain of the AAA server. > > Also if discrepancies exist in the data provided to the AAA may it be > appropriate to take action beyond logging? > Replace: > > "allowing the EAP server to match it against the > equivalent information provided by the authenticator via the > AAA protocol." > > With > > "allowing the EAP server to provide this information to the AAA > server to match it against the equivalent information provided > by the authenticator via the AAA protocol." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 02:38:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06916 for ; Tue, 25 Nov 2003 02:38:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33282580016; Tue, 25 Nov 2003 01:38:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9506D580027; Tue, 25 Nov 2003 01:38:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1DDB1580027 for ; Tue, 25 Nov 2003 01:37:05 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 18857580016 for ; Tue, 25 Nov 2003 01:37:03 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAP7uYH24254; Mon, 24 Nov 2003 23:56:35 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Proposed Resolution to Issue 200: Endpoint Verification In-Reply-To: <000901c3b2c1$1f53e550$0200000a@amer.cisco.com> Message-ID: References: <000901c3b2c1$1f53e550$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 24 Nov 2003 23:56:34 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) OK. How does this look? Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the following security claim: Channel Binding: No Add the following definition to section 7.2.1: Channel binding The communication within an EAP method of integrity-protected channel properties such as endpoint identifiers which can be compared to values communicated via out of band mechanisms (such as via a AAA or lower layer protocol). Add to Section 7.1: [10] An attacker acting as an authenticator may provide incorrect information to the EAP peer and/or server via out-of-band mechanisms (such as via a AAA or lower layer protocol). This includes impersonating another authenticator, or providing inconsistent information to the peer and EAP server. Add Section 7.15: 7.15 Channel binding It is possible for a compromised or poorly implemented EAP authenticator to communicate incorrect information to the EAP peer and/or server. This may enable an authenticator to impersonate another authenticator or communicate incorrect information via out-of-band mechanisms (such as via a AAA or lower layer protocol). Where EAP is used in pass-through mode, the EAP peer typically does not verify the identity of the pass-through authenticator, it only verifies that the pass-through authenticator is trusted by the EAP server. This creates a potential security vulnerability. [RFC3579] Section 4.3.7 describes how an EAP pass-through authenticator acting as a AAA client can be detected if it attempts to impersonate another authenticator (such by sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the AAA protocol). However, it is possible for a pass-through authenticator acting as a AAA client to provide correct information to the AAA server while communicating misleading information to the EAP peer via a lower layer protocol. For example, it is possible for a compromised authenticator to utilize another authenticator's Called-Station-Id or NAS-Identifier in communicating with the EAP peer via a lower layer protocol, or for a pass-through authenticator acting as a AAA client to provide an incorrect peer Calling-Station-Id [RFC2865] [RFC3580] to the AAA server via the AAA protocol. In order to address this vulnerability, EAP methods may support a protected exchange of channel properties such as endpoint identifiers, including (but not limited to): Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-Identifier, [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address [RFC3162]. Using such a protected exchange, it is possible to match the channel properties provided by the authenticator via out-of-band mechanisms against those exchanged within the EAP method. Where discrepancies are found, these SHOULD be logged; additional actions MAY also be taken, such as denying access. Add to non-normative references: [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6", RFC 3162, August 2001. [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 03:11:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07879 for ; Tue, 25 Nov 2003 03:11:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DEB7580016; Tue, 25 Nov 2003 02:12:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6113B580027; Tue, 25 Nov 2003 02:12:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8A20580027 for ; Tue, 25 Nov 2003 02:11:37 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1CF47580016 for ; Tue, 25 Nov 2003 02:11:36 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAP8VBA26315 for ; Tue, 25 Nov 2003 00:31:11 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 204: Peer-to-peer operation Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 00:31:10 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 204: Peer-to-peer operation Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: 11/24/2003 Reference: http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf (See disposition of comment 15) Document: SM-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current EAP SMs do not fully support peer-to-peer operation. The current EAP Peer SM does not provide a mechanism for the EAP method to signal to EAP and the lower layer that mutual authentication has been achieved. In addition, the EAP authenticator SM does not provide a mechanism for the EAP layer to indicate to the lower layer that a protected result indication has been received from the peer, indicating that the peer has authenticated the authenticator. Similarly, the EAP Peer SM does not provide a mechanism for the EAP layer to indicate to the lower layer that a protected result indication has been received from the authenticator, indicating that the Authenticator has authenticated the peer. As a result of these missing indications, it is not possible for EAP to provide for mutual opening of the 802.1X controlled ports for use in peer-to-peer operation, even where a method providing for protected result indications is in use. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 05:33:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11500 for ; Tue, 25 Nov 2003 05:33:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5E43580016; Tue, 25 Nov 2003 04:34:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B8126580027; Tue, 25 Nov 2003 04:34:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8AAE580027 for ; Tue, 25 Nov 2003 04:33:38 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 1234F580016 for ; Tue, 25 Nov 2003 04:33:37 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPAXZA14098 for ; Tue, 25 Nov 2003 12:33:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 25 Nov 2003 12:33:35 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 12:33:35 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 12:33:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3B33F.9435E8C0" Message-ID: <2D08426B7EAC7745B0AC1B0BD037944F0A5708@trebe003.europe.nokia.com> X-MS-Has-Attach: yes Thread-Topic: EAP-SIM and EAP-AKA Review? Thread-Index: AcOoy4UAMXgNOnKUS3eSmn4D625DfwANzsOQAl83gqAAL+bjoA== From: To: X-OriginalArrivalTime: 25 Nov 2003 10:33:35.0019 (UTC) FILETIME=[9460CFB0:01C3B33F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Greg Rose's review on EAP SIM Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 12:33:34 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B33F.9435E8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The PDF file with Greg Rose's review is available at the following URL: http://www.cs.tut.fi/~haverinh/draft-haverinen-pppext-eap.pdf Please see anothre posting to this mailing list for=20 how we plan to incorporate the proposed changes. -----Original Message----- From: Haverinen Henry (NES/Jyvaskyla)=20 Sent: 24 November, 2003 14:06 To: eap@frascone.com Subject: FW: EAP-SIM review Please find below some comments on EAP SIM from Greg Rose. Most comments also apply to EAP AKA. -----Original Message----- From: ext Greg Rose [mailto:ggr@qualcomm.com] Sent: 12 November, 2003 05:16 To: Haverinen Henry (NES/Jyvaskyla) Cc: ggr@qualcomm.com; Niemi Valtteri (NRC/Helsinki) Subject: RE: EAP-SIM and EAP-AKA Review? I've reviewed the EAP-SIM one. Unfortunately I'm running out of time at = the=20 moment and probably won't be able to get to EAP-AKA, although I wouldn't = be=20 surprised if some of the comments are common to both. Anyway, see = attached=20 PDF document with yellow highlights. Tell me if you have any trouble = with it. regards, Greg. At 01:51 AM 11/4/2003, henry.haverinen@nokia.com wrote: >Greg, > >We have revised the EAP SIM and EAP AKA documents, and the latest >versions are available at the following URLs. We'd still >very much appreciate your comments on the drafts, especially >on EAP AKA that has received less review. > >Best regards, >Henry > >http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.tx= t >http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt > ------_=_NextPart_001_01C3B33F.9435E8C0 Content-Type: text/plain; name="ATT78840.txt" Content-Description: ATT78840.txt Content-Disposition: attachment; filename="ATT78840.txt" Content-Transfer-Encoding: base64 DQpHcmVnIFJvc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJTlRFUk5F VDogZ2dyQHF1YWxjb21tLmNvbQ0KUXVhbGNvbW0gQXVzdHJhbGlhICAgICAgICAgIFZPSUNFOiAg KzYxLTItOTgxNyA0MTg4ICAgRkFYOiArNjEtMi05ODE3IDUxOTkNCkxldmVsIDMsIDIzMCBWaWN0 b3JpYSBSb2FkLCAgICAgICAgICAgICAgICBodHRwOi8vcGVvcGxlLnF1YWxjb21tLmNvbS9nZ3Iv DQpHbGFkZXN2aWxsZSBOU1cgMjExMSAgICAyMzJCIEVDOEYgNDRDNiBDODUzIEQ2OEYgIEUxMDcg RTZCRiBDRDJGIDEwODEgQTM3Qw0K ------_=_NextPart_001_01C3B33F.9435E8C0-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 09:01:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17751 for ; Tue, 25 Nov 2003 09:00:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC9BA580016; Tue, 25 Nov 2003 08:01:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D7049580128; Tue, 25 Nov 2003 08:01:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA7BF580128 for ; Tue, 25 Nov 2003 08:00:47 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id A93CC580016 for ; Tue, 25 Nov 2003 08:00:45 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPE0iA25233 for ; Tue, 25 Nov 2003 16:00:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 16:00:43 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 16:00:42 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] Issue 204: Peer-to-peer operation Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612232C@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 204: Peer-to-peer operation Thread-Index: AcOzK+VZMW/bAZFMRYyn3YCzQNS2uQALOX4g From: To: , X-OriginalArrivalTime: 25 Nov 2003 14:00:42.0347 (UTC) FILETIME=[83A493B0:01C3B35C] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 16:00:42 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, > the current EAP SMs do not fully support peer-to-peer > operation. > > The current EAP Peer SM does not provide a mechanism for the > EAP method to signal to EAP and the lower layer that mutual > authentication has been achieved. > > In addition, the EAP authenticator SM does not provide a > mechanism for the EAP layer to indicate to the lower layer > that a protected result indication has been received from the > peer, indicating that the peer has authenticated the > authenticator. > > Similarly, the EAP Peer SM does not provide a mechanism for > the EAP layer to indicate to the lower layer that a protected > result indication has been received from the authenticator, > indicating that the Authenticator has authenticated the peer. > > As a result of these missing indications, it is not possible > for EAP to provide for mutual opening of the 802.1X controlled > ports for use in peer-to-peer operation, even where a method > providing for protected result indications is in use. Hmm, I'm not sure if I understand this... Is this issue about the=20 case when there are two independent EAP conversations (i.e. both=20 parties act as peers and authenticators), or ordinary mutual=20 authentication with only a single EAP conversation? The latter case should be rather simple, since setting the controlled port to "authorized" when eapSuccess is set=20 seems to be exactly the right thing to do (and the lower layer doesn't really need to know anything else). In the former case, both parties have both peer and authenticator state machines, and this is something that .1X doesn't handle well (for instance, we have two separate variables both named eapSuccess :-). Is this what you mean? Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 09:04:46 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17855 for ; Tue, 25 Nov 2003 09:04:44 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 308625801C0; Tue, 25 Nov 2003 08:04:54 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8948A5801BD; Tue, 25 Nov 2003 08:04:30 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CCDB580136 for ; Tue, 25 Nov 2003 08:03:01 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id C440B580134 for ; Tue, 25 Nov 2003 08:02:51 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAPE2l4u018188; Tue, 25 Nov 2003 09:02:47 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:02:47 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current > EAP SMs do not fully support peer-to-peer operation. I am not completely convinced of this. It seems to me what you are asking for here is for EAP to provide two signals indicating the success of authentication in each direction. This is not how I read the model of 2284bis. I would argue that the use of a method providing mutual authentication still requires EAP to provide only one answer to the conversation. It is possible to require mutual authentication before Success and even to guarantee that answer with protection, but I do not see a reason for the lower layer to get an explicit "mutual authentication" signal. If mutual authentication is required and it was not obtained then success (the signal, not the packet) will never follow for a properly configured peer. > The current EAP Peer SM does not provide a mechanism for the EAP method to > signal to EAP and the lower layer that mutual authentication has been > achieved. I disagree. If you require mutual authentication then EAP Success is this indication. > In addition, the EAP authenticator SM does not provide a mechanism for the > EAP layer to indicate to the lower layer that a protected result > indication has been received from the peer, indicating that the peer has > authenticated the authenticator. hmm, this one is slightly more interesting, but I have no idea how the backend would ever alert the passthrough of this. Still, I think it is possible to say that if mutual authentication is required and not achieved then the decision will be fail. > Similarly, the EAP Peer SM does not provide a mechanism for the EAP layer > to indicate to the lower layer that a protected result indication has been > received from the authenticator, indicating that the Authenticator has > authenticated the peer. I disagree with this too. 2284bis states that the only thing which can follow a protected success/failure is an unprotected version of the same. The EAP Success indication is therefore sufficient to indicated succes. If a protected indication is required the peer policy should reflect this and the SUCCESS state will not be reached until it comes. I disagree that peer-to-peer is not supported. I would agree that the specific interface is not provided for two signals, but I would like to understand better why those signals are needed. Also, a suggestion for where these signals would go and who sets them might help me understand this issue better. Thanks, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 09:06:18 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17916 for ; Tue, 25 Nov 2003 09:06:15 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE89E5801AD; Tue, 25 Nov 2003 08:06:24 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B55435801A5; Tue, 25 Nov 2003 08:06:13 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85D545801A8 for ; Tue, 25 Nov 2003 08:05:18 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 246425801B8 for ; Tue, 25 Nov 2003 08:04:47 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAPENfM14993; Tue, 25 Nov 2003 06:23:41 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: eap@frascone.com Subject: RE: [eap] Issue 204: Peer-to-peer operation In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612232C@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A612232C@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 06:23:40 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Hmm, I'm not sure if I understand this... Is this issue about the > case when there are two independent EAP conversations (i.e. both > parties act as peers and authenticators), or ordinary mutual > authentication with only a single EAP conversation? I assume it is the latter. > The latter case should be rather simple, since setting the > controlled port to "authorized" when eapSuccess is set > seems to be exactly the right thing to do (and the lower > layer doesn't really need to know anything else). The claim in IEEE 802.1XD7.1's comment resolution is that the lower layer does indeed to know more. > In the former case, both parties have both peer and > authenticator state machines, and this is something that .1X > doesn't handle well (for instance, we have two separate > variables both named eapSuccess :-). Is this what you mean? It wasn't what I meant, but it might be what the comment is referring to :) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 09:58:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19987 for ; Tue, 25 Nov 2003 09:58:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A92958012F; Tue, 25 Nov 2003 08:58:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34C56580027; Tue, 25 Nov 2003 08:58:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10F0958012C for ; Tue, 25 Nov 2003 08:57:06 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 80E98580027 for ; Tue, 25 Nov 2003 08:57:00 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAPFGVF18058; Tue, 25 Nov 2003 07:16:31 -0800 From: Bernard Aboba To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 07:16:30 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, 25 Nov 2003, Nick Petroni wrote: > > As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15, the current > > EAP SMs do not fully support peer-to-peer operation. > > I am not completely convinced of this. It seems to me what you are asking > for here is for EAP to provide two signals indicating the success of > authentication in each direction. This is not how I read the model of > 2284bis. I would argue that the use of a method providing mutual > authentication still requires EAP to provide only one answer to > the conversation. It is possible to require mutual authentication before > Success and even to guarantee that answer with protection, but I do not > see a reason for the lower layer to get an explicit "mutual > authentication" signal. If mutual authentication is required and it was > not obtained then success (the signal, not the packet) will never follow > for a properly configured peer. That makes sense to me, because the peer would not accept the access offered by the authenticator otherwise. However, the response to IEEE 802.1X D7.1 comment 15 suggests that something further is needed. I'm not clear what this is, but I'm suggesting that we need to be clear on why this is not required (and note this explicitly in the SM document). > > The current EAP Peer SM does not provide a mechanism for the EAP method to > > signal to EAP and the lower layer that mutual authentication has been > > achieved. > I disagree. If you require mutual authentication then EAP Success is this > indication. The resolution of IEEE 802.1X D7.l comment 15 states explicitly that this indication is insufficient for peer-to-peer operation, potentially because of the issue with protected result indications below. > > In addition, the EAP authenticator SM does not provide a mechanism for the > > EAP layer to indicate to the lower layer that a protected result > > indication has been received from the peer, indicating that the peer has > > authenticated the authenticator. > hmm, this one is slightly more interesting, but I have no idea how the > backend would ever alert the passthrough of this. Still, I think it is > possible to say that if mutual authentication is required and not > achieved then the decision will be fail. I think the issue is the following: a. The authenticator figures out whether it wants to offer access to the peer or not. In the case of pass-through this is communicated in the Access-Accept. b. The authenticator communicates it desire to offer access to the peer. This occurs via a protected result indication. c. The peer figures out whether it wants to accept that access. This is communicated to the authenticator via a protected result indication and communicated to the peer lower layer via eapSuccess. c. This creates a situation where the peer has full knowledge of each side's decision (peer knows the authenticator is offering access, and that it wants to use the access), but the authenticator may not (authenticator knows that it wants to offer access, but in the case of pass-through operation it may not know if the peer has accepted it). To fix this, the authenticator SM could have a variable that says that the peer has provided a protected result indication to it, indicating that it will accept the offered access. In terms of AAA, this could result in a new attribute indicating "peer-to-peer auth achieved" or something of that nature, so that another EAP authentication need not be rerun in the opposite direction. > I disagree that peer-to-peer is not supported. I would agree that the > specific interface is not provided for two signals, but I would like to > understand better why those signals are needed. Also, a suggestion for > where these signals would go and who sets them might help me understand > this issue better. Have a look at the IEEE 802.1X D7.1 resolutions to comment 15. They're available here: http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf Username: p8021 password: go_wildcats _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 10:22:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22242 for ; Tue, 25 Nov 2003 10:22:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6699580027; Tue, 25 Nov 2003 09:22:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1B4E580128; Tue, 25 Nov 2003 09:22:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 547F0580128 for ; Tue, 25 Nov 2003 09:21:25 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 416F9580027 for ; Tue, 25 Nov 2003 09:21:18 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAPFLF4u020580; Tue, 25 Nov 2003 10:21:15 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 10:21:15 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Preface: I am not a AAA expert so correct me where I am wrong. comments inline. > I think the issue is the following: > > a. The authenticator figures out whether it wants to offer access to the > peer or not. In the case of pass-through this is communicated in the > Access-Accept. This does not come until the conversation is over, no? That is, all protected messages will be finished before the Access-Accept, right? > b. The authenticator communicates it desire to offer access to the peer. > This occurs via a protected result indication. yes, but this would be in an access-challenge, right? Protected success cannot be the last message in the protocol since a response is required from the peer even if it's just "ACK". > c. The peer figures out whether it wants to accept that access. This is > communicated to the authenticator via a protected result indication > and communicated to the peer lower layer via eapSuccess. these do not happen in the same step. the result will come as the final EAP response, which will be communicated as an Access-request. The peer will then wait for an unprotected success or timeout and go to SUCCESS. > c. This creates a situation where the peer has full knowledge of each > side's decision (peer knows the authenticator is offering access, and that > it wants to use the access), but the authenticator may not (authenticator > knows that it wants to offer access, but in the case of pass-through > operation it may not know if the peer has accepted it). not in the case you describe above where a protected response is given. this will make it back before the Accept-success is ever sent (at least according to my understanding of RADIUS/EAP interraction). > To fix this, the authenticator SM could have a variable that says that > the peer has provided a protected result indication to it, indicating that > it will accept the offered access. In terms of AAA, this > could result in a new attribute indicating "peer-to-peer auth achieved" or > something of that nature, so that another EAP authentication need not be > rerun in the opposite direction. I am not a AAA expert so I do not completely understand what you mean by this, but it seems plausible that such an indication could be set in the current system. > Have a look at the IEEE 802.1X D7.1 resolutions to comment 15. They're > available here: I have read it and did so before my last post, but I find the discussion vague and unclear. Perhaps someone who participated in that comment resolution can elighten me? I will re-read it in case I am just slow this morning ;). thanks, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 10:29:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22680 for ; Tue, 25 Nov 2003 10:29:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB11C580135; Tue, 25 Nov 2003 09:29:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E737E58012C; Tue, 25 Nov 2003 09:29:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85013580027 for ; Tue, 25 Nov 2003 09:28:33 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id CA9FE580135 for ; Tue, 25 Nov 2003 09:28:27 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAPFlvu19884; Tue, 25 Nov 2003 07:47:57 -0800 From: Bernard Aboba To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 07:47:57 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > > a. The authenticator figures out whether it wants to offer access to the > > peer or not. In the case of pass-through this is communicated in the > > Access-Accept. > This does not come until the conversation is over, no? That is, all > protected messages will be finished before the Access-Accept, right? Right. The Access-Accept lets the pass-through know that it is to offer access. > > b. The authenticator communicates it desire to offer access to the peer. > > This occurs via a protected result indication. > yes, but this would be in an access-challenge, right? Protected success > cannot be the last message in the protocol since a response is required > from the peer even if it's just "ACK". Yes. So the peer knows that it will be offered access by the authenticator. I say "will be" because the pass-through authenticator does not know this yet, because it hasn't gotten the Access-Accept. And until it gets the Access-Accept it can't actually provide the access. > > c. The peer figures out whether it wants to accept that access. This is > > communicated to the authenticator via a protected result indication > > and communicated to the peer lower layer via eapSuccess. > these do not happen in the same step. the result will come as the final > EAP response, which will be communicated as an Access-request. The peer > will then wait for an unprotected success or timeout and go to SUCCESS. Yes. The peer communicates to the backend authentication that it will accept the access, but the pass-through authenticator does not know this. I think the point of this is that as a result, it might have to rerun an EAP authentication in the other direction in order to be sure that it has been granted access to the peer. > > c. This creates a situation where the peer has full knowledge of each > > side's decision (peer knows the authenticator is offering access, and that > > it wants to use the access), but the authenticator may not (authenticator > > knows that it wants to offer access, but in the case of pass-through > > operation it may not know if the peer has accepted it). > not in the case you describe above where a protected response is given. > this will make it back before the Accept-success is ever sent (at least > according to my understanding of RADIUS/EAP interraction). This is true in non-passthrough operation. But in pass-through, the pass-through authenticator doesn't know that the peer is going to offer access, because it didn't snoop on the result indication sent by the peer. So the backend authenticator knows, but the authenticator doesn't. > > To fix this, the authenticator SM could have a variable that says that > > the peer has provided a protected result indication to it, indicating that > > it will accept the offered access. In terms of AAA, this > > could result in a new attribute indicating "peer-to-peer auth achieved" or > > something of that nature, so that another EAP authentication need not be > > rerun in the opposite direction. > I am not a AAA expert so I do not completely understand what you mean by > this, but it seems plausible that such an indication could be set in the > current system. The goal is to bring the pass-through authenticator and backend authenticator to the same level of knowledge and make it unnecessary to rerun EAP in the other direction. > > Have a look at the IEEE 802.1X D7.1 resolutions to comment 15. They're > > available here: > > I have read it and did so before my last post, but I find the discussion > vague and unclear. Perhaps someone who participated in that comment > resolution can elighten me? I will re-read it in case I am just slow this > morning ;). Yes, I also found it vague (I wasn't at the IEEE 802 meeting, since it conflicted with IETF). Perhaps someone who was there can enlighten us both :) _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 13:07:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29933 for ; Tue, 25 Nov 2003 13:07:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37E86580016; Tue, 25 Nov 2003 12:07:12 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3589C580027; Tue, 25 Nov 2003 12:07:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8D48580027 for ; Tue, 25 Nov 2003 12:06:36 -0600 (CST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 848CB580016 for ; Tue, 25 Nov 2003 12:06:34 -0600 (CST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 25 Nov 2003 10:08:07 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAPI6Tw5025257; Tue, 25 Nov 2003 10:06:31 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.66.250]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 Nov 2003 10:11:39 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Proposed Resolution to Issue 200: Endpoint Verification Message-ID: <003001c3b37e$d927a0d0$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 25 Nov 2003 18:11:39.0371 (UTC) FILETIME=[92541BB0:01C3B37F] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 10:06:27 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This is better. Thanks, Joe > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, November 24, 2003 11:57 PM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Proposed Resolution to Issue 200: Endpoint > Verification > > > OK. How does this look? > > Add to sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 the > following security claim: > > Channel Binding: No > > Add the following definition to section 7.2.1: > > Channel binding > The communication within an EAP method of integrity-protected > channel properties such as endpoint identifiers which can be > compared to values communicated via out of band mechanisms > (such as via a AAA or lower layer protocol). > > Add to Section 7.1: > > [10] An attacker acting as an authenticator may provide > incorrect information to the EAP peer and/or server via > out-of-band mechanisms (such as via a AAA or lower layer > protocol). This includes impersonating another > authenticator, or providing inconsistent information to the > peer and EAP server. > > Add Section 7.15: > > 7.15 Channel binding > > It is possible for a compromised or poorly implemented EAP > authenticator to communicate incorrect information to the EAP > peer and/or server. This may enable an authenticator to > impersonate another authenticator or communicate incorrect > information via out-of-band mechanisms (such as via a AAA or > lower layer protocol). > > Where EAP is used in pass-through mode, the EAP peer > typically does not verify the identity of the pass-through > authenticator, it only verifies that the pass-through > authenticator is trusted by the EAP server. This creates a > potential security vulnerability. > > [RFC3579] Section 4.3.7 describes how an EAP pass-through > authenticator acting as a AAA client can be detected if it > attempts to impersonate another authenticator (such by > sending incorrect NAS-Identifier [RFC2865], NAS-IP-Address > [RFC2865] or NAS-IPv6-Address [RFC3162] attributes via the > AAA protocol). However, it is possible for a pass-through > authenticator acting as a AAA client to provide correct > information to the AAA server while communicating misleading > information to the EAP peer via a lower layer protocol. > > For example, it is possible for a compromised authenticator > to utilize another authenticator's Called-Station-Id or > NAS-Identifier in communicating with the EAP peer via a lower > layer protocol, or for a pass-through authenticator acting as > a AAA client to provide an incorrect peer Calling-Station-Id > [RFC2865] [RFC3580] to the AAA server via the AAA protocol. > > In order to address this vulnerability, EAP methods may > support a protected exchange of channel properties such as > endpoint identifiers, including (but not limited to): > Called-Station-Id [RFC2865][RFC3580], Calling-Station-Id > [RFC2865][RFC3580], NAS-Identifier, [RFC2865], NAS-IP-Address > [RFC2865], and NAS-IPv6-Address [RFC3162]. > > Using such a protected exchange, it is possible to match the > channel properties provided by the authenticator via > out-of-band mechanisms against those exchanged within the EAP > method. Where discrepancies are found, these SHOULD be > logged; additional actions MAY also be taken, such as denying access. > > Add to non-normative references: > > [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, > "Remote Authentication Dial In User Service (RADIUS)", RFC > 2865, June 2000. > > [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and > IP6", RFC 3162, August 2001. > > [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. > Roese, "IEEE 802.1X Remote Authentication Dial In User > Service (RADIUS) Usage Guidelines", RFC 3580, September 2003. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 15:38:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08519 for ; Tue, 25 Nov 2003 15:38:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50443580133; Tue, 25 Nov 2003 14:39:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1B7AA580027; Tue, 25 Nov 2003 14:39:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 40F70580027 for ; Tue, 25 Nov 2003 14:38:15 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id B8070580016 for ; Tue, 25 Nov 2003 14:38:13 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAPKcD4u000979; Tue, 25 Nov 2003 15:38:13 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 15:38:13 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Yes. So the peer knows that it will be offered access by the > authenticator. I say "will be" because the pass-through authenticator > does not know this yet, because it hasn't gotten the Access-Accept. And > until it gets the Access-Accept it can't actually provide the access. yes, but until it gets the Access-Accept it won't send the EAP Success either so the peer won't try to have access. In this case all is still well. Do we agree there is no problem on the peer side? If so, let's turn to the authenticator... > Yes. The peer communicates to the backend authentication that it will > accept the access, but the pass-through authenticator does not know this. > I think the point of this is that as a result, it might have to rerun an > EAP authentication in the other direction in order to be sure that it has > been granted access to the peer. It seems to me what you are saying is that even after recieving and Accept-Accept, the passthrough does not know it is allowed to have access even though it is allowed. There are two possible solutions I see- 1. make Access-Accept mean that BOTH things are ok and that mutual auth is known to have succeeded or 2. make Access-Accept strictly mean the Peer is to be given access, and make some other AAA signal/message provide the other information. If mutual auth is required, the server can tie the auth directly to the EAP aaaEapSuccess signal. That is, both must be authenticated for aaaEapSuccess to be true. This only works for case 1 above, as the AAA layer can't separate these two if it is only given binary input. I believe THIS is the missing variable you describe? I am really having trouble with the model for why the passthrough needs this information. when using a peer and a passthrough authenticator, it's tough for me to see the true peer-to-peer relationship we are describing in any real-world scenario. That being said, this does not mean we shouldn't handle the situation. My understanding of all passthrough implemenations is that if there was to be mutual authentication, but the peer failed to authenticate the authenticator the peer will just go away (or try again) anyway. Additionally, I understand the argument that we want passthrough and standalone to have the same semantics, but I think even in the peer and standalone statemachines it is policy that is tying together the two authentication decisions into a single signal. The method should be set to only succeed in the case of mutual authentication if mutual auth is required. > Yes, I also found it vague (I wasn't at the IEEE 802 meeting, since it > conflicted with IETF). Perhaps someone who was there can enlighten us > both :) I look forward to it :). My current position is that I don't see why you need two answers. If you know you are using a method with mutual authentication, then you should be able to tie the outcome of that method to a two-way relationship. comments welcome. nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 18:48:16 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17951 for ; Tue, 25 Nov 2003 18:33:34 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C00EE580016; Tue, 25 Nov 2003 17:33:19 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84F44580027; Tue, 25 Nov 2003 17:33:15 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A349580126 for ; Mon, 24 Nov 2003 06:05:54 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 8A41D580014 for ; Mon, 24 Nov 2003 06:05:49 -0600 (CST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOC5l625078 for ; Mon, 24 Nov 2003 14:05:47 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 24 Nov 2003 14:05:46 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 14:05:45 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 14:05:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3B283.49DE1476" Message-ID: <2D08426B7EAC7745B0AC1B0BD037944F0A56EA@trebe003.europe.nokia.com> X-MS-Has-Attach: yes Thread-Topic: EAP-SIM and EAP-AKA Review? Thread-Index: AcOoy4UAMXgNOnKUS3eSmn4D625DfwANzsOQAl83gqA= From: To: X-OriginalArrivalTime: 24 Nov 2003 12:05:44.0863 (UTC) FILETIME=[4A024AF0:01C3B283] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] FW: EAP-SIM review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:05:44 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B283.49DE1476 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find below some comments on EAP SIM from Greg Rose. Most comments also apply to EAP AKA. -----Original Message----- From: ext Greg Rose [mailto:ggr@qualcomm.com] Sent: 12 November, 2003 05:16 To: Haverinen Henry (NES/Jyvaskyla) Cc: ggr@qualcomm.com; Niemi Valtteri (NRC/Helsinki) Subject: RE: EAP-SIM and EAP-AKA Review? I've reviewed the EAP-SIM one. Unfortunately I'm running out of time at = the=20 moment and probably won't be able to get to EAP-AKA, although I wouldn't = be=20 surprised if some of the comments are common to both. Anyway, see = attached=20 PDF document with yellow highlights. Tell me if you have any trouble = with it. regards, Greg. At 01:51 AM 11/4/2003, henry.haverinen@nokia.com wrote: >Greg, > >We have revised the EAP SIM and EAP AKA documents, and the latest >versions are available at the following URLs. We'd still >very much appreciate your comments on the drafts, especially >on EAP AKA that has received less review. > >Best regards, >Henry > >http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.tx= t >http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-11.txt > ------_=_NextPart_001_01C3B283.49DE1476 Content-Type: application/pdf; name="draft-haverinen-pppext-eap.pdf" Content-Description: draft-haverinen-pppext-eap.pdf Content-Disposition: attachment; filename="draft-haverinen-pppext-eap.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNJeLjz9MNCjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5NSAwIFIg DS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3 OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMiAw IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAv VFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFj ZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMyAwIG9iag08PCAvTGVuZ3RoIDE4MzYg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0l22TmkgQx9/zJcJLvQrIzPCYd0ZJ 4mXVjZLcpVKpLVZHlwuCAdzd+/bXg6wMPs54iVu1BRTDr/vfPd09nV5uq7NcReVfPkuUzvspUpe5 gnTDQKrjYdVGhu46rqo5HlyYrppRZaG8DZROEGBYFSwUV/c811IN+KsuLaJ7DnJUhxi6RwysBivF KF9gEM2Ar8Pngxk8DJ6Ub61XbQ07RDePXCB9dzlIiiydb2ZFlCa6zI+wT7iGjuGz34M/gaohHRFC 1KB/no5rekCzVS6FrX7mHj344zyT1MzxI80eI/okzbQlmSbHXNMslJYYfq40k4vtF5rlwNzdj+gy LSJhO+TZXGQHc5oUUfHv7sEwTMIlXcFTEbYnzeYiPKFad1M8MANm4qpjq2KiRkZj27mY0abOxdrv 3namg2GtOmi+qAy5nOvEuHpfmbrFWZFlaba764U5ldlnBEnrb9fsj7QO+3uaSKY+2a8sl9ic10Oa 55Blu/t3abYKi91tmMx317dZWqSzNK4Vey5okkf3UQxpu2+TJW0TumSVsB7ybG4fSrl5yHYk2faB 19Ll/Qomauw+bUJ/bmhesF3YmRZhdlnqHRMJM/E+M1/D/qbiUOJKM8lpP3sPYRzTZEl/NdM846cQ lHjSTOu0n1Dbw8u13TSkmfYZP4WgB0zx/mHrzjmV4wjIWlnRT6p8gi7SN2zdPa03371Ox/gKvb0z HgtBTSTJ5DTuFkUW3W8K2epkyvZFh69NQXgf110gXVxnzhV+c7WqG9wNuz05r4GJpf0mDebgy2v+ 1h/1Jnf9btA92prhhdtuvz8YvT9qi+x84PA1DL79xZ9MB+PR3c1gGoj6L9uDHb6GAXPq3/i9wO+/ wEWYsucNh69hwByNRz3/bijq45VMp8G89SfD7sgfQcT7dxP/0+9hug1md/RVnFYxZWcMh69XwHz3 +eam+zn4IAE+YIr3B6giRnM79UHiQfBV2OFTdJH+AHTUoE+6o744uaTLniWB2SxaI/9vyK6p/7k/ Hn0dCjFlz5DAJIfMiV/F+Xcxm8WpN/48CvyJhLbW/olRgGkdY94F4/HddNi9ufktzGPFafqb/XT2 mMHg3aDXDcQKMGNe0e+bxal3M2DV0J9MxhMQuu9fZsr2Wg446I7qltqDeSqa06wco8QGHWk2VxWn dLbJ4Ex5Ld8ypdlcWRrM2XTO0dnBl87Oj62n2eK12eOnq+Gm2IRxHf/GoeHorBNk0TqmRT0LP6/T fJNRAetEarfHz2EfaS1Pn2bR44Wpfk+jIzMQ3DjMipnSevWqHfzDnmmGbhgGYg+/tT6EjwBK6HHn p2GcPnFG8SpEGc3f7B5gpxZ1nUVxPU1iwzBLczDMP6rBFGlY1fgxE73tSw0zv92Gy3oyx9/bGhzJ XsyxKn81AqdEXnlji6j8bh0VYJAUNEu4APezcFGU33N184y97GP2EVPhsFTrNxieyLUSAO0M7xO+ 7RC4XZWs9ov4bI2tH4OOZ0V6T7OG6luNyIFIJkAlRTqbwFx/7Eflhg6zOmXg6BTOfghVN0t20PT4 Ib6X0bLEhHG+ezahm5xeBl/H5volS6Jlo7byu2hC13F4rPC9Pvo6lOVFVLkCnwTbZIdhjx/6R3SZ wqcaBU48KAdsmcLLNb53YV5wgszSJAENhELDrNgfT2UKLH8wmP1I0qeYzpeUD0++iQsulvNqj57S 58AagUbIHQ+GYaJFiQbVQFtF83lMZcKyYyNxNteF39Ok7PfJsnYfci9d1emyWUEhOW+D7BDNe384 hcRhtBKbfq5io+Y2jWPIO34GgO24phln0CRaPtTpMILNMzteQ+RtwUdTcQV7va5Ze6WgyKL7zels vMYGTpEdID0f8v/NPOO5ENPeP1z4gYJU9pfPEsUiuudg1fGwahlwjdgYQHSCXDWjykJ5GyidIDDh 7WChQEZ4ngtN1FCrS9NzdIs4ruq4SMcGrApWilG+wb5etkKEyz55G7L+CPCfgI9UZbsUVjqubrtY xTZ0clut4X+pCcMfQi0D2hex9qEMsqwYn06shOOhRczmym2/ttl6dkU8NXhSWlTFarpQbatpdaUX lFCrUmxrs1HbfCAuMuG41pDXeJH3lJ3wLnJsTwUxHGTVVpZThVEaiFAHGR2YVgizUCOObprcfIPM UpCHojjjACJYtyEGTQeOmmTD+IQ9m7Noq/j6vOIOALBrHziyzYk3nc7T05Me0WKhp9mvMRSZBuwz WLlv6YXcQKYN6+zGOn03x3UiNu22zRYMvNqcXYQL+Ffkne1NW2MbrHzUhgaLW9pD2DZ1t/XYRq3t OUF72X2Vg9iDDmOhykPmoGeJOMjWYWR4h6FYXwgGQQ5kvXOQVtjbOkmfmfGsQ2pt9p+GeyYTYumu bb0EBVICElvAZALami6RTR5iYTgh4oPk2R4otDxaaVAgi+eXFP9vAOfwyaIKZW5kc3RyZWFtDWVu ZG9iag00IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxOTUgMCBSIA0vUmVzb3VyY2Vz IDUgMCBSIA0vQ29udGVudHMgNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vQW5ub3RzIDIyMiAwIFIgDT4+IA1lbmRv YmoNNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5 IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29s b3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNNiAwIG9iag08PCAvTGVuZ3Ro IDI1OTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0V1tzo0YWftefCG+RtkaI iwQib55LTWZTM5kdqzYP9lQKoZbda6AJ3Vj2v89pQPRpaMlinLWrXID78p3vfOe2eMcDK+GWW//y JJ8sPl671h2fuLbjuFYYeVbgOvY6XFvzMIKH5doqyWQ/ebuZLDYbD3Zt9pO1HUXrleXAb/u48u0o dEMr9B078h3P2mQTp14gL5k7cDocv0ng4+YwuZn+NJt7oW8vDQ9fWJnFgj6S7ss3siclyRPC7ct+ AkfuXTu2B8d+3/wbbp27tuv7vrV5f/72T/n+tfcHbu/2zb/O3/lhRwUr+c/dhzjfdc/vWC5Kuq30 FfJrnIghbJbrWPyRWK7ynDypN7t73BCurvsvSSSeC72xfBWGtwrDV06qHZt/A35YpgRTZVtSdq8f SU7KGOCZsIRei8VVWABYKJWRTKY/yZ/Z5n/yMxLtzdS1EdWiZLsqkVy3H1eazLwglDJzmhPlaZr8 tHPPsLC5p7x72bGkykiuPMALktA9JRyJRgnqSZCc022qNHxViXvYT5MY4QZGSyZYwtLuw+30w9XX 2Tyww+ntrGfeS367ga3fu7eMJPdxTrlyFEhUoTXjwcrnhHP8vwfyrPigvImKdoHu0bMoK07zu+4N UCjlXH/unq+rLU/gBiSsTzsJWCgQn0EGiOLb6fWnz7cz26AwJYW+sM4AxXBO0IUUso05UdxhSrsn 8EeakvyONP6dl4QXLOdk6DIU9h0/l6rgyl9crV/0c3rHSiruM448ESt5l1VusgV7C8hWliHxb9WS O8ji6M7G7JHmuN56vqUImZ58cj353E6/XX1530UOXMrPOcLEs24ZENEP8RFaZ0WTCudtukiGDnjT fTrc0+ReUR0/EG4kXlpoDFhlICdJSRRnbeSOAP4bVWcBfrOyT6kBcU7zohJvjGiLOosTk398r40Q zfH9aIF4//bhenSWNDMWLLXLUoZyFE58vyUmM1klwE6zmtAOfBBKHSCEO5qDJMd6ieZQZ3bIOYKZ wrDCmSk2VizorsrnQpxK9+wRxRh2e0xLDU25jxOi/L1t/FiJkT6iWGSIqaJfLpHL0DLNYFz1dqSk j1R3LX6FDg5WxCmiSB2UM9H6R29r237jrEE7WkLLlj5rEJVefpXdrZHgOpIT5Im9SVjIdiiaMtsr E5AmegdXsPTZmJQv79cRHqOnUPOYkhhF754iajNIMcj5XS+t/LBllXJ1W5lHRMqp+q0eb3C5d3zb c77bPVZ+uJPA6SCNkwcTe1klKiy8FxsOlbsOJH7IoVkzmfVaqsw5rRkpmhBHIZjQ4h4lCpxBbkGu qCxrzQbus2WAouBF/xqG30uWQIuK0zjJWXWnCqyWF2Kh6MyJOLDyQd18AKNI71RkJs4Rqf4vYAA5 rCQ/1AGV5K8K0sfJdIG8DQPAAiqxSsCcQOZGstJ6h64N0jCezaIj2L9r5kCcXvtoekVXr5T8VGeE MSYs29LcXAET6BZgXqgEGRkBAw+fqBJ4Ju27wJhzk5TiGZJyXhn7H9XjjkDd64S//P7l3Yc/P29e qgOt2hXZSE6s3OG6r1HbjH/E9F/Vbl6qlTrs63xj7hXR4UUJIspxW1ikMYoylFL7rpCBRLhQa/cl miTkwZS1DctxzaUxSp7k5AaRZM6XA2ecGJiA14RoCTA2zwCNkn5GZV+fLXvwL29UzqvEPsltnHKG 2JB96Qnk/Yg9k5IGrdYlHQnWDRO4HmVQI2Oc7Q4wgBnCr113oiIiS3bGJGyKmhGxAJ3TI0Un99HI NvtOdm54h4DuUuuXtAFGs1M1Gq9uCl7dGPVVxAuS0D1FLmL1UIJqBq+KgpUq/nEZPxKBTMfSK2SS GfTSYxqKasuhv8ZpFjwFtAjc2J+6nsdZL9ILZQaKc2jZTpU+bcZp79Hxw0sog0Q6w+iNX2OowRCA SCsoYK5BOAfUtilPPRXQg/Bfug9e2D1eAbGpguw5zrKG44V2YDkyYDVU2o+EGDWLNJg3X7Hm/e/G tDb3A7gBJQZdhWY5fpJjKuSz7vD3ZbwX9Xlre3kGrzwsMEAFESv+kJivtJipL3BhrujfcNNd4c2a jeHsSL7cE9imS39PBAMdaqw3HPkDkpZwKcr/iCQtq46O3oKTasfy54wvBMkgKuPyuRcYEMslqomf kOBxwRjGPaqPgxRw7KPnr5r9IFkkZFeV5P8y5nGSVFqSPtOXbCuaomqJMFY5lJJUaz7xmJoR2XVQ ng3bjjFZrQ8VmClIKbQ0fBo9bsd3LKky4BpPcMqa616RikzHi3vKf2hMOt6N1JYVKanhlFhYChtM OOVoG+PdI+UnJg5Yt6/SBn76PNIALqrdM+LhjJjkaAMBVtaK5uO4vqS/3xHgLKONITkZacjhnmh9 11lTDGLDbPNqv6eJNjbhio+PJvkjhcFNOvyHBISIqecEbRohdYqC5lQhP9Gag4UlGXQZ9WNvwDWV 9QdUfIe9+Jgh9uUEZJxftyUl+zf9pSaoiK8cpXKSc0XGgcQPmhKavD4iO2FqX8p9yAzOcLMVcySv vkltw60WbIkQCPSRyVdOVgahH+kYGHpx3leOKmI4O6nSuEQSpTivnhsNLxmsMGcg8bq+QxU3hi3L U9wSo3SJo3eQZlFuzpmK+K7g6yeVLEMoLxETkLj4+PXbtZLM5zg3hsjZnLUnsYDG4VTp+BPbVBLM RMEGDh9XqU+lFowXpZnHOK2IMWTxBoxXlBSqpkDKQn2aecDiY+3oo7o0/b2Y2PA6cESrml6wC5aw 1Jg0sBZkzjhycHEFMSPBoXuiGVURbQynY703tx3bYblsK7cYaQAOzorjcDYalpA0lRlHBS0RB1Y+ IPFIay8pJuQJ6qs4Z9+YOOmaBhR7tW6I0VSmtStHI+z2VlRx0VzwYTNxLfnLk3yy8u0o9Kww8qyV A8+unEp923fXVkkm+8nbzWSx2Sxh9WY/cV07itYw0zlW+7iMQnvlh2srXLu258CuTTZx6hXy9Hr+ cL367q9xe/lfcD21Js1W2Bmu7WDtWV4Ag2Vgqcv/sHJ5/fDSlRPBzlX/UnnJXXvHf07sdFewc6nv bIakQO6XT35kbQ6TKbF8i+2tYKWjbvmCwrNqGWswOwrzgFx3abuhRq9zpPcUTljrhkFkARmhu1Io 61HOqQG67sJ1Fh4Algjnfmgvl3AC1MKG9WVNyL0QZwxwfc8OwAe6AUZIQWAHXhQgRA3jxXnGQ7jA WwcDQxpN/LJYHA4HmxKxt1n5zwB1l469kjv7SF/QhrsMYF+g7bNbxm+mCyqHsVkdY/OdfIj38Efw RfMym8sgrz/NoC3xpvP7eLa019PHmTslJc1JPq9jURnoRRHY5rYWSgOj1SUGyn2e60RDVxQvOMN3 Q1B9OJCVFzVGkicJXuaN+Uz+JXEPsu+v7HWwOjoFJAHCvgCyD9wu1/5Y8fgrz14tvYF4/HrznNNs 7nq2eDpK/O8BADvVlVwKZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN L1BhcmVudCAxOTUgMCBSIA0vUmVzb3VyY2VzIDggMCBSIA0vQ29udGVudHMgOSAwIFIgDS9NZWRp YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw IA0+PiANZW5kb2JqDTggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8 PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAg UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTkgMCBvYmoN PDwgL0xlbmd0aCAxODI2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFfbcuM2 En3XTyzLT9JWRBG8M2+KrXUcj2zHoiuVsucBoqARMhSpgJTt2a/fBikRzYtsOSuPq6YgkECfPn36 wtF55mpRppHiL4uS3uhyRrRvWY/ohkE0LzA1lxi67/na0AtgYfuaYL1l75ewNwpDE06Fy56vB4Hv aAb87ZaOpQce8TTPMvTAMkwtXPeM4gVpZGjA7XB9GMFm+NJ77P9rMDQ9S7c7FuGKVWtLLKr1JUuY oDlPk2rrjoocNrMV36g9kf7Forz6/dS3Lu/ungbVxopm1TrbsIgvOVNWaHG7b+gmIPoa/gaAh0Qn lmVp4cXbwFmyokmE7hpv8xVLch7VUdNEvXLNflTryWsEF3xjCPr4eoyQUxGteA7ObYV6aZmKap2v BkNX9/r7p87Oh/DfbyN/SPgz0EjjameaznmsjIQsZlG6Xm+TnTOKwtmPLGdrhPlhGs6eBnpnPOUz Rc/1eMc1ORLnmkmGeKbM8SSKtwum4Ky3+Rb5QWsh+KnaF2wTU0X9RqSS144ofQDdggn+XA91uqyW cQqhVaHKWJbhN7+zH5nibDK+a9JUrB8bD762lJwhBxpKfg8/vnvN8lWqZJqvqMoormzMaYb0jtxp BvqgayokLyserbqMUIUqLYX/AacyFuFskYFOozRWZtdIBnP14hY7xhPQOEWOLrE7o9nVVN3H1bMH eIDjoS6wLjurjOl671aZhOUvqfiOsC0FzXKxrZcFitfPlMd0HjO9oehabTNkeYYH4V+SVFSyH/sm ymYm1hlCtYvBG4ePLPXfUSUEBxfKyNn0YRae/VT/Xf26ua09u5/8/nB1P7nAe7Nfx1++tDZqN5R1 c//KsXUTLrp9+NKwJXcOozu/nU4nNxd1gNPxn+gnFsrZ7V14dXsz/nKGAt6q91WyHAt8kUbbNdTF TrnkaVdC8CRnYiNYjpulChLU4EjweS1pVNm6/8959cMkJPjaVOJJJJTXtIlppPO5YM+80brOUHdI BQ7InEbfGT6P2khJeVXrjqU8YwJ6LDaCK2H76Qz6b5LHKikueBZRsajpBhIf9ZRZo6fshosPVMun /nR2/TQ4JMbJaw6soBgfB2B39aS8u1vIqN5jcX4A+ydLGKL1jmprNfx4/R7wvNhYCvb3ti4DaEwZ 4g0PgnGcvvDk2wfzodRz9nNDz8f2hjd8G4/V5LJvvO2sqd8N8fakTblV/JP7lu7Cl0ST1fGB2U7u p4L/9/DUPY6idAsnEVcYH4rwUJr+/4nYnqPN0/pdXXwOe4J1z92Xs+nBAQJG+5rmarMe0PLMFzXF dX9itIg63h/a7U8u+CZmeYYErioNPoMVj3zOtvMyn8U+bc2jgtpY1LK65pV6urun5tWvFAo6T1i3 AmcUchVVx2oxed1wwapshHbpKRltBEeTq2kYduGP6e15bbFe/ZNggw7yH+8o+uK0v5bRbQXXPYqx 2s1XstqC2FQDE3SZF/f5uv0GXnlZl05wv4TJupbvSj+FAWLpZtPCY2XCHJQHvQFOSbdTnLdRnoKE aqyXHFktkmww+kGS3iwanWnxDN+pVSKcoozi2tDKuYgqy6iT0ljGFoA9M9SaIhrHrHtoajmQlSTq LRJPUW+xUjq+r1o9++M1q5iEMg7fVO/F627XWJqzw2k8xcE7gRTidE5jlWQ/YLpbd9bfaTrnyPco Xa+3yc717PNdDUudnjALat8R202M5yqxRqqeK73jbpOvBOvut4fSgMZb1FfvxzcXqshcl9kRDYx2 Kf7nfRb3n/vJ7FNS72o6u/rk3CsbS8EmEmtDkbOq+ytoCxmGJcfVHKbpznG/VhTT9+aH47HzEoPS kJpSss+phdPxKWfPKXzh4YHh0CyaLt4dEP+RNzfjpromYY9o8i+Lkp5j6YFnal5gao4BayJNWrpF fE2w3rL3S9gbhaENb4fLHiF6EPjgpKHtlnbg6Y7l+ZrnE9004FS47hnFG/L2AiQxC+B3VCIH43+D ea71yqNw0vN11zc10wVSXU0Z/0NLpPm2UccI4KTTNCqNfNvZ+P3ASeLASbt+smTSleflygq08KXX Z5qtpUvNdeqod3xBVJwdYyVmQ2FukUtsnXg1eo09vYdwwrvEcwMNyPCIo1AW8TYKgISMiDGC4cqS CIeWp9s20h+xC0JWef6GA8QydRdiUHegE5IL054ZuAhRyfjmbcY9MGD6bsuRUhM/j0YvLy86Z/lS T8VpgBLb0B15son0HW0Q24Vzbu2cXmXYiMsaOig+BocLuaBL+C/PRuWPwVBWu2JrADlr9ocrOrB1 v/88IP3ys2a4z76dg2YQgG9k56F0MHCOcVCeM4kRtEOxeScYFvFA9V5LVmZQOsleJXg5hgwH8n9G G5Aty9F919kHBSQBwj4CsgXc2r71UfFYjqk7ttkST1l5hxlfD4mp5697if9vAHmXxIsKZW5kc3Ry ZWFtDWVuZG9iag0xMCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk1IDAgUiANL1Jl c291cmNlcyAxMSAwIFIgDS9Db250ZW50cyAxMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzky IF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vQW5ub3RzIDI0NyAwIFIg DT4+IA1lbmRvYmoNMTEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8 PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAg UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTEyIDAgb2Jq DTw8IC9MZW5ndGggMTc4NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX25Kb RhB95yfMW6SUNWK447d17DibqrU3XlJ5sP0wi4YVMQIZkGT9fXoAMc1Nl/XGZUtVqgEx06e7T59u 5r/lthrkKi2/eZAo8zd3VH3IFUo0jaqOp6s21YjruOrM8WBhumrGlVB56Stz39dhlx8qLvE811I1 +NZLyyCeQx3VMTTiGZqu+itFKx8QRjTVD8TPTpk8m/r/wnJGCTUMQ/VfKRrRHbEK4M/yI54wiA17 4d+ZBsAAGfz9YfKWF7s0+/xsOoMtxJxcBQHP8+byesGTIgojntW3LDD3yf9TmYnjsMnKmjDk/9o2 0RzWX9zybMUSMNExWOw75uDMtoULXPSXvDl+3TMYtQ2akzRslkVrJ8+ey11JEG8WUfLQ3GFJs3x7 dd2sM87ilbhyAfFY7M73ZZ1mRZQmCEez5Mk2ytJkBe7I/O2WPJM+sD6s6hS5YZPzBWmuRkMH3tCu N7rtXOhNL/YtIBsWx/KvewbIZJKSwSRd39xdS/R/j+wIN3E85sTlKWEbQABuBKyVmTSJ96TD4v+r aMDRLGEr3jH3VEWzaR9v9liISma8wFDxcJmjJEVP9otqOrOJM0m6cvAN6Wozv/YkJ90wP3HKcr5Z pMleGr5c5z7Url1ND4eLDSZxh2SiZ+97yRyKap27bkAF4sHUHRyMageTlqMWMQccvVj0TmveKdWo DkVFX/mZ9hwViB/HUawd5pjMSpq0ev/jKfkjqcgof38KFTlPPFrmhgTlD7blWQRiiqpPUvOOxemO 7/uZff11HWU8f9Hc0B053q2zKJYx1DXNLJHqzsHNXhCaj4DoDcTiwy17kFm1PlXR7oXCPhaLYUW9 TgrgDJe5fZWxsCjPcw9yMIhXHDaUttdXtzJ+1zcyLK0eXhqgBtG7Fj40JvRam5yWRtmDXHkXFOk9 VlWIehUjoxckE4yeCJKGVeDcan/PZyNzykgj0s7h7SUtKRtF8B0ncHqyCX3XCfzxzSjjFYNmP9/4 Ok7FH6gBnWbr0Ub0NG8WQxTf93ndb0HHzD8qZ1grsT6cmEUu8PVuc58HWQQ6OaZM5uQmXWxiFGyc XIwQVRPSBLZexyiZT5OiImOLSBzZeleF7lvSZKhy8xXL5B8ByxYS7SLKC4jBpkBFfy+PfXN383TI U3hTY0WaXTi0tM4wZC7ewaiyjfiuQ5Ne7Z7LuN+jhw3STSrjt0x3g/lNuwhG2gjMAHPMltG5vuGJ Lp05inmdpQFfAOxhiqKzU8nyYr+GO5g9QbpabRLxGEdtJCqWQ17XEw3ixCmUoIJbVGXFkqHZWRqM UwFgsPnIJnbPgs8czaQjmtkxucnbmjY4MJ5y4+rqCge+SIM0Ho47flLGVojlkN/4VUJwbbDTYz6F JVMPuqt/K/H91tFZLtHg4fU9/7LhOU5cvhkWDQwVRuldmn0echsOryeK+uj5QX67+tBS/qOuvJMB O1JkzwehimHvFwkPFHUNCeMoGaI3ogLhUCAtWvNOXbQ601HcYlBAtqu3EFapPGpG91GM+s8Z/evj 5Prm7vrjVNaUfJhdWMUFX0HLZ5k8vTdGf5ysc75ZpMl+hWxG4fgOeDncsgAdiSoEjblhyINCpo1V xMmn2qU1nK95EIURIi4ycwdGsIjAq1GXio/vLmkcpzusQke4B6UBRVHxb95L6lpIYDFOYkThgEfb irEXJHqg6iU03OL2a9QuXcQCaHYo/2GWrgbBYkMdwWZI4nPQ+7x7wAX+BGlWFXNrsG17WcU6H5Zz /GgVfAwHNTOG5oeRWcCvg3ZBk8ejA4vztLlYsu3Qex4IQys1QPcYveB9i0Y27QHBf+0rVBXfPEgU yyCeo6uOp6uWBmsqBjuDGNRVM66Eyktfmfu+CU/7oUIp8TwXJkVNrZem5xDLcFzVcSnRNdjlrxSt fEKcXhYb1csCvGWiAsH4FzAfqUq1FXY6LrFdXdVtmExtVRr/R02E+b5RS/Ngp9U1Kow81Db+GtlJ LdhptndWimCL/WJleKq/UyZctdQ0VG2rjbqOF7QJq45YhVmTmHvBpSahTiu82iG8YzjhWerYngrB cKglUZa6pZUAKZ1Tba4DYIFwZjjENNEQT80yIMuiOOIANXRiQw7aDgxCsm1i656NEFURXx+PuAMG dNfuOVJx4sV8vtvtSMSLkKTZ0wClpkYssbOL9AQ3qGnDPru1jzSdYh6JFj8tB6TZQixYCD9FPq8u pjNRYOWtKQwR+mS2ZFOTuJPtlE54FiU8mR2qr3ZQ9zzwjdYeCgc96xwHxT6dal4/FesTyTCoA6x3 erTSvcpJ/lWAF0I9m4pfzjqQDcMirm0dkgKUAGKfAdmA2JqucSl5DEsnlqn3yFO9vs7yaDWjOim+ Hij+3wB79rz7CmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDE5NSAwIFIgDS9SZXNvdXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vTWVkaWFC b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCAN L0Fubm90cyAyNjQgMCBSIA0+PiANZW5kb2JqDTE0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0 ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4g DWVuZG9iag0xNSAwIG9iag08PCAvTGVuZ3RoIDIxOTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSIm0V11zo8gVfdefCG+xUlaLBgFiU3nwapSNU2N7YlGbh/HWVAu1JGIELA0j69/n AhJ9+ZKEdnY85QLc3ffcc8/96PFMmIorFJr/CDcYjH9ZUGUjBpSoKlUsW1NMqpKpNVVGlg0Pk6kS 88F68LMzGDuOBruc9WBKbHtqKCr8HB8NndgWtRRLV4mtq5ri7AZqviAzMlLhdDjeceGjsx98vfvL cKRZOpm0PMwfvoxe+e8pF8l48fhUfo+Y+86T8tUT5WO4Lh+TLS+fF+kyOUTynarl49vdImFx8jYk 2Kzc2TCbG5uqRAOcvzn/BjdGlFBd1xXn03l3eOCySKQ+Szg6M2Y7nvBY+uAF5SNLkthbpgkX9/iU cMVXrcvLJwe8lVs+82CTbO9rwJ2/nYf7K/NTCXQdxjuWSJKcLe+KR7FUogpWrUFJBW+Lm/RZfop5 T+wi4q639tppWnA38UL5bpy8MuTpaqZQeHX+l70h1Z41i0mpiXecy6yLMjcMEuYFopUo3xNJG1Ng 4ZQWQA29kprvoDXsvUijKIwTRNXy0AoDp4XgMZzTRi7e8eB8+3X+unh8ef72+XHh1IAWiaOZ1sXE KSWB5YeyvkbmjkkHmC9CBNP10xVvniuPAu2Wz3ERPS/Y3JzymA2RLoUL9jBvKx4kXnKQqcoklF4a nhCNNIXwx1UccY4JEVEYrJBKJbfn5b73km2XqIYjk1h3o+vU+5pDELwzpSSV+63nbuuxb88wEOrz y/Ns/u3JaYijgHdaa1yZZcmWncluWahjqI7hrnwN0h3WxwmUdMrdhoLLsHekahY1pKlKAb7NH2Bo Mf88nznzT6ecbqbRld5jpPVqJAnoU+25D+lwuYJltLR3sAYMvgkTj1VSDBecOEzaLPbAXOjxWFsu 0lJpAV0NtUFD/ZRmme7RN1zmu9nsgg9EzeidH7AzMADw2GN++eGtpWSZeOq6VL3KB+DYykpv9rf8 W6WRVIrcvxhQ4AUoYTB3C+aHe35oujr/iDyodT+VHzRLJkIUe77MLU1VJzlezSImzLiAoIKv8i8D axeLKjC/fmEbGUbztyJFaxk60k2wgBpPBz2Vkx8DCEOAeuOnmK2T/LwpmZzBmx1mtkDtmo0fUlAU 9DI3F0hugOpEq1v4WprQhsVGa3giP9tjkjajL24SLnFFA9YLjvQGSdAI+5J0ruytk0r/c7n3vStn MTXNNnV/cU9tpgqXedWsaAEK01CtC+NS4v6ykGGCQh35xztMY97BAzm+VaDQdrguRxvcfnksV8jj /iGj2KrzS+4gwG2H6rKi/DNGnRXDPbHQOyYrqCbfO2YIWQB7dIFTmfwRA6DZ3toaIcfj8RJdwXK9 8SImq55BQQ03b/duRSpMwqzWifLzDL4htbzButnbUGJrv19gZUOR24fx+99ljz4OOnFPV/ChxwgU YJFclmCMo65CW/uLcWsM5BFojGI9pZV4O467a+PKhUpj5UJzyzUh4B8SabUQ5leCi4m2qF0ohUhR nqHRC40clZQ+RPIFN6ZjQPpMk+myctpsy3yfBxssT0rx6PJ45bD7+vD8Sa48HSvqWG8K944LgacI 1p5obrhCaxqDO4z5Tw8zCT5EG3F8bhgfS3dJ/Y8oM2+7sL5I//IWHcl4dMilflttxvjIZ3uLyC4S 0mRahLsHGV1FrCNozN+EsZdsZTfDSjkN5rztfumG0eEMGX+OwNobUYW0bG/5kg3p0Odw0rBGyegB tWREkoRVDXFnfnuGFhNedR/K83YxwZq/yuNWMmeCUHoBnd7d3t808VS46pSh4MGq3alC7Gggnfke RK7AMprHMRqpIua+80tXzWuBd0iEf0AxwLkGM9DOCzIFk1oi/dCGtfACl7cylBVmFMINSAAxLgPK 2qlnaHRhrhvuIhbgsW0PudtqF+VUD3lfU9qLQn7fGkjRyUPmFeLh+eV5Nv/25MhEZX7au/BDRyy6 jGijtA60U99oBmBLn7edldeRAzqqWUVOCSFF8fh0U1LWyyGCt465kPF+q5QBqaCYRz47oCG3mmsd 0LMsR6REoRA8+49D5N02w199T2y/+VXbelUgt7V1VG6hO0tBbbn7jgbCNLmmSef1DxXIzpwEcRwr 43W0VSvraY6QkI4TIb4PYXO1ias5klWkkE9hBTzRM7xn8nzxOl/UmBJycZ70cvFb4+ppkgmehp2O TBPliN+j1l01Gpy6cFsyumEMTb29o51tmUcRLFLXhQyrNch7hPQaN7xglZfrigg6HOko73smQYgC 1Dr1/yTa8f0UZqUQOeL6KeozUIwq89I7P2AnYeqBBcxH+y81wmJZ0hWkIizhUK0X7MqocHUmILLD soRVjzxOGdUa9kce5s6AKtmPcIOBoRPb0hTL1hRDhWdqglGd6HSqxHywHvzsDMaOM4HVznpAKbHt qaLCz/FxYlvE0K2pYk0p0VTY5ewGar4iOz0vtVTLoX9hR+O/g3lPGRRbYac1JeZUUzSTaJapSOP/ VYLMfNOoodqw06gbzYxsjjb+07GTGrBzUt1Z9AMz25896bbi7Ad3XDGVcK2YRhX1kS+Ii3FkrMCs SswNcumEUKtCr3qitwsnrKWWaStAhkUNiTLvWmoOkNIxVccaAM4QjnSLTCZwwmkgpZOckG2SnHGA 6hoxIQZVB1ohmSYxNdtEiArGo/OMW2BAm5oNRwpN/DQe7/d74vFkTcL4xwClE5UY2c460gvaoBMT 9pmVfaScE8ZeAKVkCJcqnoxW2QNbw69EjIuX4SirbvmnIWStdjfasuGETO++D+kd1KCAB6M8qaWD mm2Db/ToYeagbVzjYLZPo6rdDEV0IRg6tUD1VkNWml04yT8y8NnoNBpmvzmrQdZ1g0xN4xQUkAQI +wrIOnA7mep9xaMbGjEmWkM8er55JLzdiGok+ThJ/P8DALI1AlsKZW5kc3RyZWFtDWVuZG9iag0x NiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk1IDAgUiANL1Jlc291cmNlcyAxNyAw IFIgDS9Db250ZW50cyAxOCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94 IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vQW5ub3RzIDI1NyAwIFIgDT4+IA1lbmRvYmoN MTcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAw IFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9y U3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IC9MZW5ndGgg MTY5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexXbW/bNhD+rj9RfbTXiiap F0rFMCBNvC5Dm2SxsH1wi0KV6VirI7kSHTdAfvyOkqx3+a3D0KGVEYeSRd5zzz13PI7OE0v1E5Wk n8QPldHrCVHvEoUgjInKHKpaBCOb2arGHBgYthpzZa68cpWR61KY5c4VGzmObaoYPvnQ1JHDCFOZ jpGjY6q69wpOX5BGsOr68mujDJ4N3b9hqBFEdF1X3Yv8kfvTEYNsPrVYOf/oJTGiTL7tw6PtMw0D C0ADPJwOfvMeeByEPHw21OBVZAy8cFaMJ94y2vDH4r4YjL+sgpgnL4sHlBXDs1UcLF+Uv2BsDN+7 vyuUIQuoAuQ1VLVLQnSyl2owpzfeHS+WZO+HmoXYFo4JA2lA0y2wUGEIZyaapNRWvgwFj0MuisUv Ym8u0vVsZOzAKxezOqCOz25K/i7flrSsxYKHIvA9EURhaoDoiDYtTAsTdJh7O9ySL+dYqMvotS+i jzyusZ5xpLdIMsDofpKaPsvHesvy4IbzWP5Ed3J10JUuY28ZqblX4S6Ke2Kv57HPE6aD0actkSdf xQoSg52briXlscbG+Wtn+f+bLFVMRDH40aJbu+Wf1zwRo8uZ5EM8StKglPXLqMSR82QiQy5dKyRl AIxO/p9+1k69smg9VUpICqMpwv8sWiDtton0F3Mr4SrhkM3AebKKwoTXSaftajY9CGwNFtsSQuwj Q/KVEfnlGw9Jz9WTL3Jj35kvUIlHE+HFIk8Ye0/sWmlDkN1Im4MxZ7Xe6Qjj4N3gzP3w5/h2cnl9 9eHN5cR9N9yb0XvY1KgDQv6R3send10jO/fmQ2FV0rvemhwBcpqp5Or66nz84a1b7vHwcDJ+Mz53 xxdbDYF80nzA7e24F3yPikxk1xvQ7PpRkXIe8gbO7hNVWXfOF95yycM7nurKPCQw3SKC7sg+pgL1 Y8w1dXt2dVHT09uz81xCB5ag3Txq9LuuRDXX2oeoYvD8CAeftxvEQwLU3M+2CzTVVC9H7YZ/mnb8 BfJ4HSbFzetJedrxlndRHIjFffIik9Nu2e+LQbe6SDsb9uOX5915wJOG7Evk4awYz+DdB55kHlg7 E+JED5y6PA/0IeFJAofIAucn/piBZMck7YmQcR3y/1Dkhzi//9pxGMz3zK/qRBq7xgmnjZ5NhJzY h2RbRrZDpAV8Xw99Moktjf1oPr4xE93HMF1HVtcxbDrQJmvfh6LVLgtPQzxoUr9dp5P+762JwJnT 0t0jWopfg7t1zItbUoygzsjyUtzP18tlufetxYKHIvA9Ud1eVnHk81m+no0R+Vp0AKIYV8F4yyQq boLQX65nlY3aK0YJX3mxJ0r/Yp5FTtvnQdntbhaBv8jvzFpe9OOeRRU4YSSK8b33qQSzTspxNC+G AKzsOfTRmd3RLJXz4s551RYrCOexl4h47Yt1nLnPUcOh5nbU79ot7+MuKFF99BJedkeNBqTRNXW+ t0NtqCEu3Nim+qFfdnO8qjaqCy+pBCsIBfxVICaiqiZgNorv6yzMKxHZp7bDxFRtNDdeKEqAokyC qpbiZoheVP0O95MQhDM5s6JhsahG97Gd3zs9WCdBeNeVnivuQ4/t9yMvIc3kQ/FYwZgI7lXE0xdc CFAIc4+E3LJXCWvpwCrh61kUPt635qHiibs4ofy0k+rg0sMTPw4+VjQblOtPuF+zZyC9WQl212qj 9OsaqO2Rc2WBsasQVX4SP1RMHTmMqsyhqolhTCzIXR3pcD6LuTJXXrnKyHUNeNudK4Qgx5GtI1bz oeEwZOrMVplNoGGHWe69gtM35OopUEJT2zdebvwzmA9UJZsKM5mNLJuqFA5pzFJL43+poTTfNmpi B2aaTaPSyF1u44+emdCMm7pRn5mxacn5cqQ7qrtRBlxlajRXLbOOOucLypuZM5ZhxiXmFrnEQITV 6MVbevtwwruEWY4KZDBilijTmOMUICEjgkcUAEuEms6QUW38iZESshBihwNEp8iCGNQd6IRkWcii jlVBlDG+2s04AwPUtlqOZJp4ORptNhsUcDFHUfzvACUGRqac2US6RxvEsGCeVZuHiiwbwb7D4yG0 DlxoMznw5vAlklF2MwS36CB9NITNjw60hTeEc9bgYUgGsKlCvdPSXCwdpI4DvpHcQ+mgYx7ioJxH CXbaoVjtCYZOGKietWRFncxJ/kWClxVZG8pv7jUg67qJbMvcBgUkAcI+ALIO3Bq2fqx4dJMi06At 8WSHCS0J7jVCkfiylfg/AwD2Fvk5CmVuZHN0cmVhbQ1lbmRvYmoNMTkgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDE5NSAwIFIgDS9SZXNvdXJjZXMgMjAgMCBSIA0vQ29udGVudHMgMjEg MCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0g DS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yMCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg L0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRv YmoNMjEgMCBvYmoNPDwgL0xlbmd0aCAyMzg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJrFddc5vIEn3Xn1gqLyvdshBfApGnVRxvor2x4xuR3Qc7lcJoZHGDGHYAK/73twckTQ8M svBeq8qF0Mz06e7Tp3sml7mrRblmVp88SgeTD0tTe8wHpm4Ypub5luaahj7zZtrY8+HBmWmMDNaD d8FgEgQW7ArWg5nu+7OpZsBn/zi1dd8zPc2zDd23DUsLtgOjWsCNjA04HY4PIngZ7AZ3Q0c39V9G Y8uzdWf4J2F5TNPj9xvySIs4LMS76fCX0bfgD9g9NnXTtm0teM+PigbwQ/DfQfAvbONueDyq/XA1 v50sF9fH73EaJeWK5McXTw00aQuNM8zp8TEUOwv0Nkno7vhtXRYlI/zrzNDNvS+A+STQFXkiCc22 JC1yhFZY25Djc8ZoQSOaiJgG6NdzPIqFjYywNWVbshqNXd0bNlLwEmx05rpMEhGREgCnRRzJdsN0 JTAUx8cyRxkpdiiwRcHih7Ig+cXx3Tz4/ufVl+Xi8833T4tlUMO+aOM2dHhh16xR0uZjCKGKU6KG twwhp+RZQamfWcxI/vb4wvIEtozFiYBqGYZTwbE83YXq4DTGqKQ/DtGvF0kw727DR5Hd2Tdlnsa2 CxZ4uViu1ygXqYzUFbRIC8JSIjLynoXrojp5pjsnkPPDXAVoqDsRSVR/c4kXlQHT1q2mhbujCWtU b/RGhzTwPa6uMvo5KugDYVL862jZrXA5YLRTXXrLzG4TRxtlreaEAcuQUuzCZ1zgDTlCFQ8hrMGP v5C/S5IXXMgmyyJkxYWCsedWLJTP8urT1WVw9f5QRxdn+JER5MV5sM/D84XkGU1zIrzrKS56W2lf 1ysawtLtLY5Ls8Hs1Vcszssso6wgQlkenpsnAXrrzPTVfBLKv1i/iH9FEfaUFk3HRFw7e0ixCdG2 vCfmeJslhHe2k0Fo0wzLcdVi0f6u1gj7f0XBJ1HJ4kLYymgSR88Xr+p1nHQvg77+ikKfE+RCgzbj GoTE/8skhjCNrxij4sQsjH4gacaz0V7sT8K+Hy5JJHVhMHs/Us0xJ4RrFxdqYSAS1ogiPr0pU4n9 iDJSTzoJf0/FN0rKC8bmZVyED0n3GBS3VHd10TO1+3113g7H9WDPKQ1ujzwXKKhpEcZpnD52ZCqB BKPa2LveORmdLlZ1IDhhT0h1zVH1QNpdHjRNnpHhFVf0hhz1GKHPEC0p/SqXGxqqJF0OozoLk6Zd YSCsI89Iz9CHUUSyisV9mbn8+Pnrp/eCMBtKc6LcdjJINAK5zHuGfR2zvFDF8pTZJM6PbMEz+6sa 98nbT7l9QIHidoW7L/fOsEO/O2quTnzzHvviJUrC0a0MjKAwd3MY4/yBbjAruO08yfcxuElGZFWy GndfvrY7i6O79yO1UqNbVlFwtRBJ2dJVvI7RkEKg2aDfaUpUsYI1+WF8OpesqgvleSXWzQSpT1ZB Fr+CY2vCoKfjjOyFvMcEtQVdZHGYiNC+I1FYohr/93eYirERJEdMgefiHGewz4dgoGCfP4NEYRKV CRb3dmCA+tfzS1FQYQKXHuHwR5JGRI1aytOKFEBKPKzXAtfCfc7w0cB0qurqBikuapcbGFlJ+ohq VmpBlDHAqQw1nxr7qvDJXn1irFS3bPmG1RPKQVRQAyJsG6eQ/ryf5ju6hcRkxRGhWf46TMPH6l7R +1DzeMjvlEFxCV59ICk0d0nUcGq+5uGjUoxuMQf3UPeSdvbdtLadoIj+o7a4UKvaA3mMU2mYRG4A dTpIoC69uViDqIUeJV7WbeZoYtpbRxr6VOYlFBkaIfO8JLnaNirPFpMaN6yOGxGXGf3VUtI5EbOq UlcCtnTVkmr5AFzkYreJI7F4f1FoRaBH8UJPYb8iodpbVMvEuioesVrVnFGA1S0pz0jE239TVXu0 xzuI0jcdvf9HdfNheS3AlQ95BBMDYWrwdXwk9FL6MH8WKehgWhUTKvJr+hAnpKfDyyOsbnm8Hy6u l4v7kYgSdsywdcP+pk4r36fqWhHdZnCvEK6ifIc9PSg2jOBp4DEuFCGpvl7SMi3YM/q+IsjL68vL +9GFDKQ2sRN1LCnSS5ZrmWo3lZMO3RCwx350ory5RKnALUUATqlAsqW4f27Q+Gwa54VN5kiP1Cz2 nI7kNngj36TApeXiRpr2xVoqze8Ql1Wu7h9dVBNByWFgTx9flRJEzzNDO5VDi8ZPYJkye5BXoZ1p DA0G96M6ks9K1/fV2CMxNOOjCVXP58eHDUmy8xDMS4F9zei2o6sULw2G5+J/goGXIiFNCdIS1HQf hD1GIP3kCa1bS6WMKCOkWt2k9/MF6glS8z5/quIqjqaF+Xwu+hyjBY1o0mygKAG8wXb0ehzoppzM o4jkec+AHypZKtubudQUvvwuSGA5Mxf1hL8g1Ri38t4jKpXRcIvHSpI+xYymW/m2WVfy0dOz5XX+ upZ0jHkabhGNlfrLSJhsBdScZCHUW1drf/Pbm57puD8C+a0yhcUT998W3IwySYqPU4d61s1fq/zc v1h9a6gAv3h7A1MeLyf+Sjl2fQxhfo9Tor5dLcOE7shzG9jVzyyGOfmtYKonKiNjcSKyZhmGU4Gz PN3VjKrkMSrpj0P060USzLtbfM3zvynbz1UwMDX+yaN0MLV137M0z7e0KcxWvumCuNi6bc40Rgbr wbtgMAkCB1YH64Fp6r4/A7uGtn90fE+f2t5M82ambhmwK9gOjGoFP70CZ1qVC7chRw3G/wbzsTao t8JOb6a7M0uzXHDX1YTxv7SUm28bnRo+7Jw2jXIjj3sb/+nYaU5hpyPvrCPo8v38yfa1YDcYEm2m 0bXmTmXU+3iB/k73EasxGwJzK7imo5ueFF7jEN4unLDW9Fxfg2B45lSgrPJsVABNc2IaE6CNzRGO bU93HEQJ06kCsimKEw6YtqW7kAPZASUk19Vdy3cRojri2emIe2DAmrktR2pOvJ1MdrudHpNirVP2 /wFqOoY+5TubSF/ghum4sM+V9unHyprEvH+OePMvxiv+EK7hX5FP6i+jMZer6tUIurM1HG/CkaPP hk8jc1hLx/hQfXsHLd8H38y9h9xBf3qOg3yfZRp+OxXZC8mwTQ9Y77VoZfm1k+QnB88HkPGI/ydh A7JtT/WZOz0kBSgBxD4Dsg2xdWZ2X/LYU0ufOlaLPLUmjvN4OzYtvfh5oPj/BgBQBIYtCmVuZHN0 cmVhbQ1lbmRvYmoNMjIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5NSAwIFIgDS9S ZXNvdXJjZXMgMjMgMCBSIA0vQ29udGVudHMgMjQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANL0Fubm90cyAzMjYgMCBS IA0+PiANZW5kb2JqDTIzIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg PDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAw IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0yNCAwIG9i ag08PCAvTGVuZ3RoIDIzNTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0V11z 27gVfdefCGdfKnUsiOCnmKc6Tdp4Z9J119zZ6ST7AFGQxYYiGZC07P76XogUcUmCspim9owNUQRw 7rnnfq3+WnhGVBj09FtE6Wz19wdqPBYzSkyTGn5gGR41ydpfG0s/gIWzNgSf7WbvwtkqDC3YFe5m axIEa9cw4bdZujYJfOobvm2SwDYtIzzMzNML8hLTCCP55zibv1mE/4blkhJq27YRvm8ehX+eLU3A ACDg3c/zu7TkIuXlm8XS8m3izN8LtisXf4Q/w+0OnAs7TQJf2fL9+Zv2Rx7m1d93Dvxwe9+e9XD3 qV3fVuWep2UcsTLO0tMF1CZW/4bP7RXWot7oN//fnPZ4RHfpL1GZbbi4aW+zTHOx9Ig/t5tHbrN/ aTtwKaLFrO1quNGT1B47XIT7uGg/FDySxqnPOY/iXczVG8BBu845F+2HeCvJKV/aB7tMHJhyS1Xw rXpZXQF0r4Bm0j64q+1OF+a8ZzpYddGUEpuyzaLqAJButNBBM4dx6Jm40kbBd1wgcrL+ZWuT0AZ9 rWXL86XTLtpx3GcJH7+0KEWcPqKbEMuIgA7hCFl93u5Fy4s0V7ki1DgbLLI6FjUyvGjRwIYDU+s4 jZJqq25iiF6WKDflmZDiVPB++q2A0GcH/tMkh1hXyqm5T6li9x1R0PVOTf1YPIHHUAaICSca9PRK 9FXDDQoIdG2alaP8Y0jjHuhC6SahboLuU3Iv4icWqc8PVS4PHgb7hUMvGN4klL55yvYsl0awZNxp eQ/hlzlLs/TlAO98Wag47OA+ubpOXRpTLiKOmBLZpiMHbQDv4xFnRQlnouTPClIOaY6lYN24rSzd 4sME3yDx1vZk01PxgX3VYyyqTRGJGGrdnwrssnbNn6M9Sx+Rv6q0FCzibIOSIqKDsydebEWWg7HF WZrXxvg7HjHgeSSwXyUv5U8o+BvgKoQFfM0SnKxjddgxq5LtRLh7nuRKxxsI8aexdAeUfR3NMmMp /lWDO/WlYklSK+T8wrXy2DCsbZRjMdC7Tw93isvjPo722vqxq4QUrp6kTtGXnIA31KGbgftre3jP nutrd4FTbpvvhRb4WEuUdcyJslTGtCKeqeWRJwnqnLR5rLYo6rtoQvEurvAbP0AuZOKlZ3sZ43jA fVXBq63MqcWYi5mYWvL4twrsTbCAUURsKvW44DkTrFSe2olMlTmsmXBg2KdsE6NM9NAmtIlo71qC UJ0JQfOoxHS6h4aQoXSQHyIQRJUwxTNMRsdMfC2USu6hSiDJF3xqX/TQGxICQhWPyMUwTFQCyxGU XIAsxGmAUlYL/sjEtpMlRwpyLeWzKdd1Cr/1+6DwJUeUDycRjYKHnv2+1iSU9VXrz3IvOPrUgYj6 znNTdxV+XWMKxrzt4PoRZn2ZU6TZ+0EVaVErEf4N6YQ/s0Oe8JuJ8UOpZTuu568DM1j7nvuXw0uW S3FlgkQomg/x415hQf2VmjMgacRbxNtIGWxqnUZ/lwMdlzeUTLHdWot0Gfhyg3JmmvR93B3ZmkKG vN2pBtf73cJ+P2f07/H76YFd+GzvpcG3C66sfbCf2mJf4/YB/nMaItNd2ZpywYdTRtFRbqclw4vO tJEzf+VLVgFOsD9inWz//wlm1w5c23cd9sOiWPBaKmN2XIfreglEUFRvBva8FsKvofzhbsb9/i4W BWqVjmh6GCtA8bBpwWUsS5OR9hbZtKuSZKI8Rtjpza7tOmHIriwdwYcOGnGD8vrv8FRz1bXpJ8vl cSwZ6EpFeN3htJ+LKoe+E5UgRXiadRL+9kbLQZqljU3D5DF1qJk6GF72u8aj+nm09crUiWVELvw5 2rP0ketAFzmP5KSmHcj6Ha9DbDJU8JQm9D2PMoHR/c+BjfJSkaGbePoUiyw9AB+FXimdPhHPpylH dKBJaluD59rTBsrYNG3TwpwPbb0sO8FznnYmA1RpWN7/EsOo+owf4xLNloqrUsARNzqvZ2KLiKnt n5CzYgAXYZZkSCdcOgKPk7e3t0rwWVV25qAU5qlDV8QIINtu4853yEfTe4x/3N6hyGPJQQXll05Y VgVDMYSKAxs/S/kUklrHHH1eO4+KAwGeHLCZmn+3bbgR1OQMonLbj8oOPnCOzmqsuiKC5kX/UlxM 9Mc2iyopFuWGj9mRP3GBxKoAFfusShRZG1wISszing3HhUsEfH/PDeH7hGtGhygunlBw7QRq9QSA eEzj/+BIGOvyhgPPR55Gbft5LdcsKYG/x70Wayc/frr9F758EpWxroXQ9lTlvua8r/Pu+EbgK7su Fq8McR8ZsB2nXN86PbAElPUypOXDcx4LXrxtH1i+ylvQsSRKipZpOieIlk88wxzgwz8S65o49Vsd nJ/vcWqh5h81DT0WlraHLe3WS33hvEtL8A9XYnwv2K48ndYi0eKVh3kapB9u7xV/d58ULZ3W43QB tYnVv+Fze4W1qDf6izP5co9HdJf+EpXZBicAYL1myB5Q5MClE0m6FMs4BuI0SqotkisSNvCy/JUX OeRvvrpreoEbrexwDGA6e7mhibgp00IU8Vy5WuWOc+Oy1ds1iOF4ZNY78ELWwCvaKdSvDCvyh3BG DflbROnMtUngW4YfWIZrwppKjdvEpmtD8Nlu9i6crcLQgbfD3YxSEgRrUIhpNEsn8AlMnGvDX1Ni mbArPMzM0xvy9JOfqXUSwT2TzofLv8H1sTGrt8JOf028tWVYHsjUM9TlvxupvH54qWsGsNPtXyov eWzu+OfITurCTqe7sxajJ/fLlR0Y4XE250ZgZDvDc7uoG75A4W7DWI3ZVJgH5FKHUL9Dr3mmdwwn vEt9LzCADJ+6CuUpZMwTQEpX1FxBKNoS4dL2iYNzG3VOhOzL8oIB1LaIBz7oGqCF5EFusAIPIaoZ zy8z7sMF1tobGFJr4u1qdTweSczLHcnEjwFKHZO4cmcf6SvaoI4H+7zOPtImqVUsU/lCTiflcisX bAd/ymJVf1gsZYCdHi0g/1nz5Z4tHLKePy3ovC6Cy3P0NQZaQQC20cZCaWDgXmOg3GdRMxi6In/F GTb1QfX+QFZWUBvJnyV4mfGWC/mXsx5k23bJ2nPPTgFJgLCvgGwDt87anioe27WI61gD8dTVclnE hyW1SPl8lvh/BwD5GpdpCmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9QYWdl IA0vUGFyZW50IDE5NSAwIFIgDS9SZXNvdXJjZXMgMjYgMCBSIA0vQ29udGVudHMgMjcgMCBSIA0v TWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3Rh dGUgMCANL0Fubm90cyAzMzAgMCBSIA0+PiANZW5kb2JqDTI2IDAgb2JqDTw8IA0vUHJvY1NldCBb IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4 dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+ PiANPj4gDWVuZG9iag0yNyAwIG9iag08PCAvTGVuZ3RoIDI1NzYgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSIm0V12To7gVffefGKpftp0aYz5sMPvmnZnMOEn3dGKmtlI98yCDbCsL yEG43U7tj49kMLoCYePeZLpqSmAknXvuuV/jD8wzImbYpz8WZYPx56VtbNjANi3LNvzAMTzbMmf+ zBj5AV9MZkaOB+vBL+FgHIYO3xWuBzMzCGZTw+J/1XLqmoFv+4bvWmbgWo4RpgPr9IG4ZGTx0/nx YcRfhofB8/274cjxXXOiWXyaP9VrhvMXnNePD9+WYf3w+FWuYxzRHBW4foGyY72mxRacscPggcQ4 K0hBMKtfFVtUyGNyeeSeDUee6d/juHo15Zh/hH/hJo1s03Zd1wg/XjaNZPXyBeWE7hm0erxcPMib iyInq32BmVm/+5olR4ATN804Aqw1SuVWfktpxKiEHv7pMuB/YLajGcPjRfOGFMn1CrccEZ9QzyzT vq9vsoT/+WP4L/EENPF8/zhfgDtRktZPTzQvCM0alF8+7YJBIWBNUcLD/J+AsCjZx0BM9SpXsO0U bArRRdc9Z1e9l6cz8GVe0eYo2nI8/6q24I2QzjXNU1SYWga4TGSUrG+3VyLPqAyaFGUxKmh+NLXG VIHyNv8trqMEqEQYvNcypG6BzgdijraUYWnuSh98lHtNmAtyD4i9ooy3tn4vmgkBSTsjmq3JZp+j VQLUhXKU4gJKTC/DZoZRZZnuEpxyaSLhYamWRQk/G1q3mlBsgSMixLDeESoKkIaPOxKhBCS8s/Ug sx1Isb0aAKqrS5kDUV63Qx67pWnb7yA/V2+Y1o85PlUzjV/ZDkdkTaIOyBkCt/JwfpOimt7noZEz mBWgt2j2IrIUCPUU/QZqJJHBjhEDYUGBCRHdZOQ/GBAJCitn9U1mQMeWqXQNi7fk9PNS2sr2Kxbx aoqBr5b7aNt0Tay9RnVGu+6pRe4iek76ep/oMr8EviVZofsCcAsluSY5A9/v+W+clAip3sPFlsa6 o2AFiPc5qcJ9c6NbGhdkeEML0kglv25xn/oIszepgUCGdgzvY5odU2hFfo6SG9xBMlZgJGGDEqji 4xU0w8At5/t6pDSGExwVTPthO8zfFBPNssxIShKUg9SJtKFbQuuBrHnBAXpS9VJ1yA1O6GbXbPCg 9EKgfVDaijc0EpkMB02NuZCLgVbRC+Kc87rcQxKwKMQ4Jy9YQ1/f8nSpVOQ01aJ5+PBBAgfNysOj fF/5XFrYERyLh+VCxvhcyf8pbyjiStPNoemaXQekLSt6vjRMdBovAF8Wr3raDVJ2N7tdhosDzX8z aS7PPZBEJn3QX1Z1Xz+qPX/M0VoGhfv56al+CJf10nFNx538aLba16DOk0IEWcHJTI59WmRFWR3D H10ViGTAnJXSvfGihMWVJeM3gL1Ls+hODxJKNiYbUmgFK3wu99+ZadR53oe+5zUj6BZ7THpIUCY0 cidj589ghMCvSDTkEiPpjj5dOrK5JqaePwusYOZ70/dNsOeD3jacAM5hx77NMe4iL6HZRmFc3wqU 4X1D8r0hOoWKOCnC+ZwejQuA/W8bTsMengFdf5HD5APk1eBOTDl0D5q8TIYVft0lJIJFvcj3UcEr mGSb0Rv12Vm5YNxnVF4KcoAymyqJmyeclGcH7S0JzjZglOuoNe36VLWrFzuFvm1An5YUGt3fUt4v 8cPzqzbBYDrIAyncWU1/daSpJldN0EWTr0WmngTYtMChQerZLZGNTudD+8xrbEc0z2Enqqihb1bq oRmV3x7pCG7mRmvrdM+SSbIo2ccYpsvKkzfaqQ58KtmAA55+HiXxX3AWgYygNPDnnhcmo/lcdnJV RyORr0tB3pBQKG/yUUFzaD2SsLcItHROW0A/Mb1AK2T18/LL129/+yilmTAZRKub55Ic7xAcBNYg DtuOVtM1dHtD3J1h8hMzAYrrhYj3CynS+h5y9NQar75V49X/o+plNBvtGN7HNDuC+bFzxOty3aq7 JdA19je4VZ1XFjCOQXqIEOuc5K7a8vBtGeos6fDQWvXjXakP+07jH5O/cCuHvHv3+xCKxTUskfoV r6l9L4/6XF9+oy3KUVSAdH/3+x3wAC97QOCglaeZlkt6LnfAMSO3d1HmQR13hLya/dq4Ozhu+Ujp WxtdqzwM1PDv9/Plh8VC2zD3r70vKNnLM61X1/4+fA+UkCT0oJ+fml2/5L1X1yl9czKjfmo0oTwt lxYWDROvhRXXBCNMPy3BpimligQBLnsKBBeRFCWqV1jTFSqp8ucVrwq4rG83lCjuCwvQFcMfgu9D +ZO8iO04zjXRtwXPn5cP8gzXtNwfZjtVqRm3XshA53GuS8dfeMXkjgNVHEJeIiGjY9vIT687kmP2 syy2vtTFLieJ1KJjWZMTSsc3vTK1KKjgP4FwZk40Cej5CW2kv237hzZ+Rq4HI6iDFDWzZTzqef2v z/6Yo3VxOq1GosUrDvM0SD/NnyR/C+m6+V50hwWJTtnudIHtmk7zhuf6CqfKyr6SnT1Td+nXqKAr nCuslwy5LYom/NIrJCljz1vKNySBZ8yXHv2/OsWhGGaTO/tOFzdyZNgSUEfBCFXkR4hpDB2C2B/M wd3lBCm+ljmLT29URlestsqNXzO8oQU5HSDdyptfWRD7ZiQlO8LmE7+idJcoXhvP/zrXV4QmfRfc usvpjjLt1htg4xeQlYi+HDeF0q7jB6AXWD+4pK6m0b7Knycih3BXveDkKJ0FWCeC55RLQhUEJC3a UsiZ1PblRvE2HcgziJ6WFYLTKdVPp/1bX+12hhM+x0Ae2s3WDWad2ZDEwxpfNsXQKbH2O67ZCDMG xQRsofur8xGL+HCq/6jMM/VxfVuhmEZ7oZk/NmWAWOhSIRwzHr+GgBO8w4CvqqXLjg1DPoUD2xB/ LMoGU9cMfMfwA8eY8nYlsEVJdk3Xnhk5HqwHv4SDcRhO+NfhemDbZhDMeEGzjGo5CWxz6s5mhj+z Tcfiu8J0YJ2+EKefQtJ2TmH6hESc8sv/za8nxqDcGhi+PzO9mWM4Hq+qniEv/9XIxPXtSwXQqes1 LxWXbKo7/t61M+A7p+rOMm94Yr9YcUjhYXCPDdsy6NrwpirsijBedKYVZSVoS4JusWtPTNtX+LXO /HYCdfkWLzA4G749lTBP6c06IbTtsW2NeevgCoQj1zcnsBezJydGtkVxwQDbdUzPnTUM0ELyeC/j BB5AVFK+u0y5zy9wZl7LkFIUP4/Hh8PBJLhYmzT/3wC1J5Y5FTubSK+Iw554fJ+n7DPrgjImovUc ikpfjGKxQGv+X8HG5cNwJHLg6dWQtyTO/YjPVBNzdv8ytO/Lpn10Dr/KQCcIuG12ZaEwMJj2MVDs c2wraLtid8UZru1z2fstWTlBaSR+FeBFjR0Nxf8YNSC77tScedOzU7gkuLB7QHY5t5OZe6t43Klj TidOSzxldz9iJB3Zjlm8niX+3wEAJah4+gplbmRzdHJlYW0NZW5kb2JqDTI4IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAxOTcgMCBSIA0vUmVzb3VyY2VzIDI5IDAgUiANL0NvbnRlbnRz IDMwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiAN ZW5kb2JqDTMwIDAgb2JqDTw8IC9MZW5ndGggMjIyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIibxXa5OjthL9zp+4VD6Nb60xD5tHvnkfSSbJZiczpFKp3VRKBmErFwRBMN65v/4K g1EDwoaZ3TuumpIxUp8+3X26tXrDbDVgqnH6sIAqq+8fDHXPFEPTdUN1PFO1DV1zHVddOh5frF01 x0qkvPaVle+bfJcfKa7mee5G1fmnWW4szXMMR3UsXfMs3VT9RNFPL1RGljo/nR/vB/yhf1Q+3vxr sTQdS1tLFjFGIaH79ntwQDkKCpyz9lGRiuUBt+uS4ZyiBGvVE1fXDH7on/6P3ObS0AzLslT/bQUg UPgP/t+K/2+I7OPN95jiHBXQ+B3DZZjSp0QYRzRs1/d4iUoOgRYk4BtT2v5yG1YPC4LFxt2TFPUD zh9x3oPMoV0AeoG9FvCAFbkH+agHZOgBygXsfU0WDofILwIcYeHd9q5dsxMjWvvdv/he+zXL07AM ANxsGheLpa05Z4CbiW7M4o1QYE88TbIYJ/zl0/4axTLEGabVCe1rCaIUsgFz2rSdKqcvIv1A46mU t18pxqG03HZiO9rFWPZKgjKpufFoSAPQKdqLDo6oQYZzTh1ksonM06v2SZrLTslxkO4p+S/wFfzW BGok+tOy54xERPUe71EexpgJ2tNIaGBKWZGXQcdUgotDGr6aR3aNHvfIvob3/W8PPgQTpXlyjf99 jpIECYJZhgMSESy0J4L0S3RceJPmHc9rZk6i09bTVFd+2d7KleVqRYsqQjFLX8QNBzFTNhs2p4oi KN4DKqQYWLljQU528GWQckCo0qxSehCsAPxY1hnFXpRSmLIS9JZRzBMVfVZWsWfpPz9NmAH6Pqsv 8PdEUp0bqnAEMFJS8k85GGyePSXcwob0BOLKsNATApRTYKaYt1iG8id5tIaq20bolTyM3B9zOunP GmUk+wC3DGeoSzydO9ScO0anJ0Z5KvIUo+AgCoqjBKV8KyW6IzIhZiTvdlzIOhSAh9v3wJM6uc8k Tc1ueN72p22HSJEJHUZ3+EVsCMgwuGJJRtpG7d+hrz7Tx6Pe5AME+3ggAGXdbWXvpVHURPMZd45p RVprQ3ytNqHcFYj9R6brEyfAMRXN0pgEUMPA0aQORsF6wbiWbShMCCV8wOk0GcBwrz2wMooqEEBk mhru6C2VOtBqgURM/083q8tytOP1MBNac/MJpTg6nerr3b56Y1CSpfVIMEPe53b3OQwzOIgB5QSF 1Ew1z5B9QRABA1S7aqa9DjKp4lMp0VDQxykSBQmL+FmzzZjx63yLrPkOwCD88oJoAEaLIz/kcnXO TJ0DegQVhMHpIc7JI7x0wD4ETd++f7iVX6Z6mR6kZdwpL2GLVK2g0aUZeRRjFBK6FxYOXMyCAk7m I2o2v2S+xPV1aOPTDdb22kSIXQJ3eA+cO5JC9Fw0ytA31jczM6Tl9NNC4Pwd5mGCsgzaQIC1yVdD 0LXE/s5QPBgSpkwpZzuTEvThhw+//fxWCAKNBT78GfFmi6XHjN2QxElgjLg4eDVzzxXxnEwqzGCy p2kux59jFCeTwB9wLxLXsucMSQM/vegG9hoHCEpHp2IwCGaCBA8RIrEs0xhUP5B215sFg0MUOJGI Vth2pRntY3mP+XWVFSvePlZvDiiOMd0D/YcjfJWRGbgohCWWIUpQHJU0qEIqL4Kma80I6uWySRCh BQLSBKYGLkdMfEtBPaVA2Sbw3/I8VcZQGJJOWheplI0kBQD5nALjPI5LMhN303u44NCdqtqrl07P OqLWKYcfeJrmXHwApaCwH1CcHvHT0OV3nzOSY/Zt+8B02uU2ywm4Fpm6vj4BNx3NVvXT3Qvig38V Vldb1291cH68Q3vBpGH+KZ2ilpY9fseT68Et5f2HYhGJtzmKitNpLRIp3uowW4J0bFLbdoT1ZMCw NLNv4WNrwlzUG50FVDdbkxn9EBTpDucd1muGrAFFa250Jkl+jihLSFHAXtxevuRjzf1oL7mthRve WEcq5q5R3UvpP1Xd/fHmXDTusQnl+DVnODKZmE47AnoYkOwA06BkMGLwhK3/17tf3tz/9Xbrb4Gc FjnZlUXjjdbLnS/C/WgrEjqJGYPV/n77B/A1iMsQdFbhO6ZB/pQV9b1iRsuZ0BJ4qFedO5zc6KRU GExSpN/Mp4+gMKCPKAZdOiIYdL3hnDUhB8Rc1R+MoAuD0XnKnMk7xCMKBAWszKrRcKS0xphEYOZM s+onJB3FSDXLJPyAwZAyJ0tgxXUycnz4vcyv1FsUH9GTKH/JODpjMOnccTqRE7H9QCcw/ekmJCwo GQN5DlTnAQed19ea9WnxaibBFy5PFwWgXVF8/KplOceBvsiNN8NG7K5OeVOlthPPAJMMzMRyFZhw NxhtPTAyIT5x/oKwD6MWogINIzJWWfBKKnyddfkirFdj73zFUKsPC6iysTTPMVXHM9WNztdGNW5a mmW4ao6VSHntKyvfX/O3/UgxDM3zXD6s6WqzXHuGtrFcV3VcQzN1vstPFP30RnX6KcSGeQr7Hari zo3/w80TVam3eqrjuJrtmqpp84nRVoXx31VamR8arYBuLLtvtDKyb2z8OrbT4zs33Z11HtrV/mrF IflH5QbzPWoaqfamC7shjLeFTUNZDVoXoAfsGmvNcDr86md+R4FafIvtqZwNx9gImKdy0U8IDWNl 6Cs+FlsVwqXlaGt4zzDWJ0YORXHBAcMyNdtyew5IIdl8Tjc9GyCqKc8uU+5wA6ZrDxypk+Lb1ep4 PGoEF5GW5l8GqLHWtU21s4/0SnIYa5vvszv7tFagVqS6Vi0qUS6WYbVAEf9XsFX9ZbGsKuz0aMGH BvNmeUCLtebePC6Mm/pCujyXX+Og6XncN6PxsHLQ20xxsNpnGro3DEV2JRiW4fC0dwZpZXq1k/hz Bb6SuuWi+o9RD7JlbTTX3pyDwlOCJ/YEyBbndu1ac5PH2pjaZm0Okqe+uS4ZSZaGqRWfzyn+vwEA rL5DawplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAx OTcgMCBSIA0vUmVzb3VyY2VzIDMyIDAgUiANL0NvbnRlbnRzIDMzIDAgUiANL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1l bmRvYmoNMzIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQy IDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiAN L0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTMzIDAgb2JqDTw8IC9M ZW5ndGggMjI3MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibxXa3ObSBb9rj+x VL6MtTVq8RKP+bSaRDvR1tjxWLhmUpmpVBu1LLZEo9BIcvbXbzcg+kKDBE527SoX4H7cx7nnnjt9 yxwtZJqR/7KQjqa/rAztmY0MpOuG5vqm5hg68lxPm7g+f7A9LSWjzejnYDQNApPvCjYjD/m+N9N0 /ls+zizku4aruZaOfEs3tSAe6fkCcclE56fz44OQfwxOo083fxtPTNdCdstDRMPdYU3WP1Zfsi2p nveEpNVLjL9WzwdGWjckTxmOKFnLExg5rBP6NYZbU4pjsIc2j/J0ZHIT/wr+xT2YGMiwLEsL3l32 hJKXrHrZHHa76gUf+Lk0i0KcRQlF1fflRi6pnlIynjjIvZnUd8mArcXHTIYiYuXjrDQ5+PsrQq7E QI3/7fxj9czwUa6KpN+YytAn/KS0t1/9bGcZzsDFdJOkcX6OdAaz6nEdsfDAGIBDJC9ckbBmgI0s eQg/tzUgtSRXLvWzvQsGavp0UTv8Nfi3eAP1dPF8AKfOHK4TIsNDE+hLSCKQUwxcPg2ppqgdSYv5 fS1YRV2Zjnu1rh7IlwNh2XS1vJ2+3eLdjtBneW5MGMPPpAd9QPhC+sDS4GTXQRyvIoSW0LCMYFAg XQnjmKYcKb0oq5V2uL1Gz4rqQmUALFLu3yepWM3aXPk+hV7SXATgilMYADLJolg1kUkknLZRuO2B i8dVUL3cfQhUR/jZSDX/QpE+CkheS/O9UktPX9sXltbWk/o6jvi9i+mTvUgS3jUTIE3ap9ERh/Kd HfYCBmofypMBUC4v/GZ4fkOZ1zZcp7GSD6UbuAADG+sthH3RhT0GUeqq+ZQco+TAlFC1BEFmQDAj DQGVsdbDoXOAya7aXRT5NdPv5st21uhXZXGyjjbtwO9MU5EKMjAPSkpBq5oHn+8WfwSf71eLx3cf 7j7eSpfeJydyJGlPgYGfkmNnNyrtTgcaDiFNCbgsS6QlJExSqI26AND0nCXgO6HHKE1ozMEmnQS0 hPd7QtcRLRx5bvjRv6cDdcWRX5z53M/0U5RJUpcqhWVp/QgMmIkfz0unaCWAe/q3csF1OyLCglMZ jfl8LsGVHDJoAJCm6H9C3gcGr5OBGCbRgPgBuQctlICmC4cUvItVtwbRSaNf9KD2MKEijfScSmW1 UuFdIu6arZdRB69884830r4tTnGYAYvhOCSjxxlTjSSMkcKnA0xnZNcYbLp5u8OK6CrB1YeX3tju pYseSJdyXDYlyf9BMH2gIEiTwWqEA6kLqpdV8ll+ne94dZMD3epVQuSK9pBIkFwIJ8bKz9fIPSUa 1YcYAxRI69dkx51Ph7n/lIDaBhK1PvH1aWsd1kMWUED0/bXTqzqcOuL1AIviTHfCOsTXgP5xlmgP i/lj8P7z8p0sP/ISkn3WOLqgZAwL8FRvoA2PSwml9qgB7Jvysog4/mRWF0dwZ1QbvsB0ktvZzidv 0iTJ3oAbLhNHwy3AG9wLVyBBsGArDb7HvHYiStqRu8I7roS/qj4vXvbcZfZT9cF0ZdL41LiTfpm6 bufmmC5yNF2gsmYV/BEWesguVtXs/HQP24hh/VVEpOHxxHIg+uv0394HlpQ3b0okkt6leJPlp1WW tNorDnNaLF3M72X8lrcyLLXc5RcYFjKbN3yqrjDHxUZ3fA6+2OOgtks/hFnyBAcWHvUiQpYSIptf OjBIF9AfH5iMHU3kM6DonLMiqPeeDqB05WMHxRcjCCASdZYA/zzrttfROXdhC3i4mDFQI4h6dwBr ceOhRmZ11tskjg80B0DH5HMPW4AifcDoBzetSHocKH5+IZSkeAfc/ybB1NnFlJYAx1qQ4LCKTPuk C91llbu1bCvreB0OkiEPhO0TyshUiXtMmBCxsGsDuVz+t9VFPr1kuN4AQKD4rEjLyWtAu2mqxMuD oLoa1A4c7vpJUxmD5Vke9FWpw/VyLULteGp1pk8UTtsoLFzefoMfDSwCVOCnnVwGkBzj/TWAd7td EwsKqgZgqCPL+zQJCVkDLy5NhR245qNieozAOACE5KoxplqotY1fM3/ZMcd0ogoCve/0VVdC7VlX ZHefFsNlcfJMo/+Q9tMVjEMz8HNKgF81DQibSkc9twKovanVBQmuaRCrRYF0B5Yr9S2mgCFBmXCs b5I0htIAYo6wMI2e2jFnIws1cjCxevbl79LLQgxE847JYgaNLUsxZXGUwb62SZO4NfO161RyGFDf DV6qY4M3xikUpmUDYyDILCMYqK0N3FsCS2mXoDU0kXWdUgEkxFjUPhU12ZaGu8MaVvnFWfTLgbCa 8MIZ13ZciJ6D23co/VOMpfO7j3wc5YPpb9JW/vmfj7/+Wo6q4n9tfYqvul883M7vFndBuezP8QVS HZB2nh2el9xRkeHpKsNp1szzdX6rw74ZZbhyLjzgfiyDj0M70Dn49ZYspVwpnbqUAUl/YEq2f7wQ xgZ8CysXwcjQxC8L6WhmId81Ndc3tZnOnw0xS1rIMjwtJaPN6OdgNA0Cm68ONiPDQL7vcR7UtfLR 9g00szxPcz0DmTrfFcQjPV8hTs/5xzBzTrrHgpT45V/49ZE2Krb6mut6yPFMzXQ4+zqavPx3jYrr 1UuFoTPLaV4qLnku7/ita6fPd87qOwuSdMR+8cRNCk6jG6Jxu5ON5szqZpcB44w7K0NWGK1Lo5Xo GjYy3Fp89XN8Ow21+BbH13g0XGMmzcy5XM8tNIypoU/5zGsJCyeWi2wb9CjDziOyzbILDhiWiRzL azjQapLjIMf0HWBREfL95ZC7/ALTcxRHClD8NJ2eTicUkWyDkvT7GGrYOpqJnU1Lr4DDsB2+z6nt Q1X3nEY0I+nYvqEkm6zFA97wPxmbFi/jieCB/NOY92PzZrLFYxt5N8excUPSiGvbybn8SgdN3+e+ GaWHwkF/1sdBsc80dF9Nxf5KMizD5bB3FViZfuEkeRHGi64wGYu/BDdMtqwZ8pzZOSkcEhzYPUy2 eGxtzxoKHmtmopltKuDJNdrNhEXxxDBR9nKG+H8HAJt6E/AKZW5kc3RyZWFtDWVuZG9iag0zNCAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk3IDAgUiANL1Jlc291cmNlcyAzNSAwIFIg DS9Db250ZW50cyAzNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTM1IDAgb2JqDTw8IA0vUHJvY1Nl dCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiAN L0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAg UiA+PiANPj4gDWVuZG9iag0zNiAwIG9iag08PCAvTGVuZ3RoIDIzMjYgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSImsV12TmzoSffefWB7HWzHmwwb7vjl3vJvZyk1yM6S2UsmtlAYL mw2WHITH4/vrt/kwaoHwwCSZqhRghE6fPn26Nf1deEYoDLv4EyEbTf99bxtbMbJNy7INf+kYnm2Z C39hTPwlXMwWRkpH0eh1MJoGgQOrgmi0MJfLxdyw4K+6nLvm0rd9w3ctc+lajhHsR1bxQr7JxIKv w+eDEB4Gp9GXm3+MJ47vmjPNxUcqDpwJOr2/+2N6n5E0q3/aUyHIlpr1g2BH6+tV8G317vO3u9tv H9d/1k9JlqXxwzGT78VC/lhfbSmj6Xjimf4NSaqnc8D0V/AfgDyxTdt1XSO4vQ493lCWxdm5fpDS H0cqspht24Be1Y9Ouzjc1XcZiknQ9JGm9e1RUAk+juSlpGjD0SuMlyFljYiCf16PQxxoGEfnDoDf Y7apb7hEQVg3ETioA0UhiR0/JhtEWHZM0XeKy4Vl2j2Rgwjubtfvgrvgs14l1xjNVDX969Pbt6tP wZvnJZXxCqbTE2ali/qexrB32sFWuicM6Owml8uVUtEHQY8bzs771jqFmFIgQ/XRn8QP649/rN5B RvqyqOVHJ59CFfWa/tCReONM9ODZbGxR+oHj+bkfWLmpwQ/B/1SfQJZ3FQ/WZiuxEQdMCBDrYvmi +X62pzgM2csbgtyFvUgZ+NPr1YdJbeZ3zdgOJPxOZWxfb+hTSA845eSK5Dc05CnJYs4aAQ4oQsbl BiRJ+Iluvo47e0sPikPOMhIzXX9R1DUA4yXwV7pvdlb4dWdIq6KfkCOkCxaEDSJbPlFjRWqHu74a f/+Q04KboKLA44MIgUlkKK04HmMJH2SVjwb1fTUUIOnKS3Cm6JjIX8rAo7H1M7puuF+j40pN7cgj Ki127oxAaYit2IneBh/oNmbsUqbbgfGgtt0oWQUZ1OSOsK18gfeIO4Xa3LL4b6rd4rnRoIwnHRgP JBrZOsMBtT3IbK8Pdkg1e3JGSTwcKKqNSFZihMigT2R/SNBMV0U1oNSv2+UOefMDxYiEOKLYH+QS wfdKZlHFZDuORrjG7EHYcOSKahAveEhlGZgg3cQEWWYRZYyEhNYKHmUnksqXE3KmKW5RXRpKX9S7 lHrd800cxYjYqxoW0AqQvXUgA54q5+3Ks3bEuAq6bKNS0atE8FeIwg4JFFRKvLl294CkaAT6QghJ uLta0WVo+kj6HJ4aHEYp32u3i+IUTYY4qI5+RtDEt5EzJrYsXnQoTa9k9DSwGJ7TRmdcVypUzY9E LS/zJprPzIMHjA7OLsYvmsPvi4eAlX7+fLaUlGau9fjvFM+FafxYhIImJtR61b4n0OxGRCng2ov6 2sYpTuSEkVJxTLQTe0TiBOHv4P3IEhhnntVHxwGsOBK9zLPraRZtLmulWR8YcMspQ37oIlyb9gGo S3Fo+zdNKTRk1IFfRmWIYntA8qCpwoByOmF8qEdoW2FZ4v07IWpcyLKv9S3ZgGQxm/CTW1a0tqTf QFcE0qneT+9Jfm46t0NcPx1iKIbf6geOL63gkMaJTJRjWbMCjuObnmHljUJBhf/lCBfmrHxLwfnl A0Fzqj37SzsDTFwPNyRkZUrLxY+qV5XN7vIEMnR8vU1JlBU71Oi0MeSf9TTosSJxWa4Umyg2sF3T ae7wpd7CGZcL/fElIfkaz9Rt+j7MOBy7lEyUrLkt2mawqZ44EMzgZtA955bzTGuOfq5s79+8//T2 Vko0OZGz0jmaH/yJ8XaQVepMT0ZHH5Wzxa+0SjiF0fhxwKlINjRkJ48kiTdme+uXzQAfEkpQKmAC w3npOOg26c/ne60XXVvUkAtnyYXPvio4pDzs6ier4Nvd7fpdcBd8bqtEi7V17lHCv8CrKkKIgViz XcqP2522cMoCkxt3TMTtcNEkVscmO/EbykLUfDu0vC7tpYbTd8ZqpA9BwZhDPkk4OKVe9BgHmr54 qphN632k+/6nMuX7WgFweAEFpBsIVqtVcziQcX+FkT+UGUYle+BCxA9JNc02iO5/HMO7gxiezo1k iK9j6Rh4BA45BM6OqLKlwmBGQ1GjH3BylAI/xdlOk5K+lcDTeBszItG1zhvXzmNXTLIsIxTYlqSb y8A5wKbRfHzaUUUUwx2mx2GpaYw4BylhYh+XwrmE1rdCCWsouiJs2Pnx9x2PQ6ojp5WAiOuZ6kzb r2hgd1EnkYpqUSJERlLsSMcDOu6VTRqfd4mSqmpa/0h/HKnImirsm5s9yBKG4+s+1w7iQFMgea9v eRFPYPLHyEVGD+KXjQp3+gaiAFTOPTB05YMXYjqlE6KMzzgnuGpYHqb6RmXVAwq5o+OpZkawhaPS wwNqC/bQvFV1nDWtqH/7wp/uZrFlpbFeu41aNNF+rZb0MrGsE/H87NEpHSJfEfS44ey8x4lJGdmj yeGRxAl5SHpWU0nCZd++BatksP3ZFsqfzEQ/b75WrHI7tQuEMO4L/WGuW7KaV6E8GWAeGHA/sn+S lnt1NH0PYBtlohfHawqDCcMGyruby/op3BG2bQ6k62BkG/mfCNlo7ppL3zH8pWPMLbi2PSgs13Tt hZHSUTR6HYymQTCDt4NoZNvmcrkwLPirLmdL25y7i4XhL2zTsWBVsB9ZxRv514uYbafg4QPJiYDN f8D2sTEqly4N31+Y3sIxHM90fM+Qm//XYPn27U1zoHPXa26ab7Kt9viza+USVs7VlWVivHx9fgWQ gtPohgISg0eGN1dhV4SB+cwrykrQlgTdYteembav8Gtd+O0E6sISb2kAG749lzAL/VgFQtue2tbU AcQ5wonrm7MZfAH8sKR9VjCyy7IrAdiuY3ruohGAFpLnmZ6z9BCikvLDdcp92MBZeK1ASlH8Np2e Ticzpllk8vTXALVnljnPVzaRPiMOe+bBOk9ZZ9YVOy1OW2M4O9JssskvSAT/ZWJa3own+fmieDSG 1uTcTHZkPDMXN49j+4amMGOwyaX8qgCd5RJis6sI8wCX8z4B5usc21q2U3F4Jhmu7YPs/ZasnGUZ JH3KwedWMRnn/1PSgOy6c3PhzS9JAUmAsHtAdoHb2cIdKh537pjzmdMSj1ssnoh4P7EdM3u6SPz/ AwAuWziKCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50 IDE5NyAwIFIgDS9SZXNvdXJjZXMgMzggMCBSIA0vQ29udGVudHMgMzkgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag0zOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9U VDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+ IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMzkgMCBvYmoNPDwg L0xlbmd0aCAxOTM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3Fdtc5tGEP7O nwjTT1YnnDjeyTc1URt3bMe1cTuZpOPB6GTRSkAAWXF/fZcXwYLuMHLT9MWa8ZwQd7v77LPP7k1f Z5YcZDItP1kQSdMfrql8n0mUqCqVbVeTLaoSx3ZkxXZhYThyyqSl9J0nTT1Pg13eUnKI6zqmrMKn Xpo6cW1qy7auEldXNdnbSGr5QmFElb2g+LeTTl5MvN9gqVBCdV2XvTeSooJpsA2vfICfFc3WicFZ nC6bZb5izXo+u2zWGUsfWNp8XflZs47ivFmnLGDhA1s0D/zosVmHCxblYd4++HiSsHTjR/C4/9JE sYh98viyfm6Cs796P0ret8ORJBnbLuLocSM2GqfIW8XfQsTwQuDnYRwd7Po4aR4t03jDhSlhCJgd nFZ8cVRCR/qcsWgRRvfcs5dhmuU4IdPr03Pk/6cty/KXvNjCv5TTKo9VEppsjk2CH2FzyhXLkjjK 2PS0n4rED35nbXh325zrcxBHOexsvVvEXPL5ScL8Np68feuO1TnR2hDgi12USVkbL174k30Uxe86 lFe/gB78dbhAWRcw97FNx3Fs9BH6FfJK5Yyi46Iehn6Yzi8xvhEX7B4pzm+uvT7feInGgSGcKznS LPtJz8eV1zbDlRJH7Wsxn+8blq/iRYaYsI53pFehHdEsFbUSU2DJWAn1xBAW9Z1xnauqo8S0qOvp de6nOXI9y/z79u1dmK/6xxwhMzPv9nJ+dT67mF94t6dvbq/mPwlNodIJQZyATei3lc8v017YOx+X bOuvNlbKcd47DgXr7YJxXRAXJdrO3TkrMAFkTr33Lb3zPA1BlGoZPFIFBYTsKKIw6QQRK2xRDLEG IvILglrGa2B7XTFHQB/4Gcteoed7yeyURk9AlScFdKBGFjHjDxTZNkniFA8YtTQKlA53wIN2k4YP fvBIeonsyuvfFyNnNhL72qmysDNgxfdR+AeCC7XttoV0Wg9K/RG95MAnUX/uxRnyM+nfrbkCs/ET fi0PNs9S+JpTUE0e3dbFmiEgSt3NEFGeNXQPMCXMsi17TsvoDVR/vWN8f3N2Nrvx3vYbxl4a/+aW UdX6UJIhx7xO/daHc8MIzTh+1BbetQ+yyB4PI55/TsIUS59mt2iAfKzbAUpTVaN0R7OJVdGq4xX+ Kzx0iMEh34dL3Hap+Ss3YkW3xBLFH1VOYWROI8SFN6m/zMvTGk+4/haHWRxP8cUB30FmHR0uDVCd aH0LHxoTWl2RdqcyLcIz+i7I4zuWdlCvENIPIDLA6JEgfYHpo1Xc5Xa9bh8Pz+HNg48DMici//DU kaIQRMKGbrXPGIeenLmBKp37y1M+HzMOffm5qDfxiC4vIrn/V05BWOyEesuffwYzVfuBgBfMWBzJ /n/MVQ3yR2M3VhK+7pTVi+epUh0bBLKMZtLB21l3MOnS5X81U80u3v9D41Snuz2rvQx1wgE6/De6 zEsUywj9HNDrg5T50Z7j3OYyPIqkbMnSFAlc/pjgZpZyfe3fYo5vmTEc155dtsgWomwbrLgUUscr YuvCbsX4FBmL+AoG/j7aHRhazwV4CSyhlD3FMOxP00+4tiBnG1TDiOG40/TaWieho9XyMo0DoDce dpC5Yem7e+R6f1nPxl9CsW8S1EbKkBM+LtFInw9qua97zZfzm2vvSPWGDlakTpDT/lCZ5SzJ9uUn HIXGInUqlMEBNAYUqq/ehyWD8lKefyRYjZJ3csEv805i0lKpF0gdcM9tdV+o6GO7WXFujMYt1I+w agrcrCHkd1g46np+Nn/tzd/c/jy/uj59d4G7y7OaL5x58e7i9fz23DsEGUnzHQv8bcZXHvY5WPnR PdJ73pS7v8uibI/vV4IZcW+5XxDd29TXK42D9AG8l/Or89kFMKA/oPG4ekQp7KWmAiLs9NWa7UKy i2nenVP6FX38bDo8n/enA97wFo8P6/mz2+t1CF4p8zRF5oam9CBGsHyzjUR3pKRqlceiVlr+hqBf vr7O88j8/c3Z2e3sxntbk5k/3obLXrxzT6Jy8cmCSDJ14tqabLuabKqwphZUq0506sgpk5bSd540 9TwD3vaWEqXEdR1ZhU+9NFxKTN1xZNuhRFNhl7eR1PKN4vQSEqqVMF36BU5g/BOYD2Wp2urKtu0Q y9FkzSKabcmt8V/kqDB/aLRw1NStvtHCyH1t4yfRThd2mt2dVd6sYn+xApe8nXTCZGrI8VK2zK7b NWCgaGYNWeW02jp9gC41CLU7+Kp7fIWO6rDFcmVAw6Zm62ZJL7X0kNIpVacaeFx4qOg2MQw4AUS2 gt0oEVnl+UAAVNeIpTu9ALguWRaxNNdCHlWQJ8OQ22BAc6yDQCpSvJpOd7sdCVm+JHH6ZRylhkrM Ymff0yfIQQ0L9lmdfaQp6GkY5SydwJDFcmVRLPwl/MuzafVlohT3iPLRBPqddqKs/IlBnJOHCT1h aQiyq+zLrw5Qc12IjdYRFgG65pgAi30aVd3DVCRPJEOnNtDePqCV5lZBss+F84VUKJPiP/N7Luu6 SRzL3CcFKAHEHuGyDtgajn4seXRTI6ahHZBHLzcrWbhRqEbyz3uK/zkA7gxtiAplbmRzdHJlYW0N ZW5kb2JqDTQwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxOTcgMCBSIA0vUmVzb3Vy Y2VzIDQxIDAgUiANL0NvbnRlbnRzIDQyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNDEgMCBvYmoN PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RUNCAy MTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg L0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTQyIDAgb2JqDTw8IC9MZW5ndGggMjM3NyAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibxX23LbOBJ9108syy9rbUUULxIpzZuTeDee ysUTM7WVykxNwRRkYUORGgCS7P36bZAS0SRBibRdG1dclEwApxunT58evxOBFQvLzX9EnA7G/7pz rQcxcG3Hca1w7lmB69izcGaNwjk8TGYWp4Pl4G00GEeRB6ui5WBmz+ezqeXAz+Fx6tvz0A2t0Hfs ue94VrQeOPkL6pCRA7vD9lEMX0b7wY/Lvw1HXujbE8ODXNHyeUMpLz+siCifiX5F0O0iS5/W+m87 whJyn9A3eM/0/AF3H758+/i+/Mip2GTpQn2eObYHCP+IfoUARq7t+r5vRe9PB7JnclV+uL66HX3N NxR0fHfzaXwnCZcac3FO/szSONkuqDADboTLFjSVTD6h9QfI7gFy9I/TQK+iP2/eX3+ObqLvdvnl zfJ8whYZQplmEl3Vjna6qz2+GCZR7mPKdnQ4Cuzw8njGtGM8csU0rDUVgjz05sKnb3dR+YHCTaK/ IWIYL7pAPeoGth8pWoDzNUmBBec4Ub3tAmb0vWd2s+6JqDL+XcIA1SE515yjjTYk/kmleZ84K8Pu CvFim6r618nK9Ek8i4ERtZPti/KLCCX2tpURn7/o560wcZ3TCg0K2fCC8KxskK1iqGQxkSxLO10p JgMqZr2llJzdbyW1a8pQETNH6TP8IfqPSjDS7JNwW3SiuP2/tlRIA7MbEgeorz5/B+R/fr3+Tddq pQJOCxKS6HP0wI1kTVgq4T9doJsbtdyBkERSFMQyg8KrvIEBt6Dsqsp7kkrUAzSFMd8aWPvq3KGE 9UH/RzEzd7iycHoXQld5MPa760SgJnGGbA0anepxDcDaoBSR9m5vr3Kxo+Lwl19ZV9ydrUvXS3p2 7EXkt5rUoB2hEkGlf0YB/ACGhoNKmCv9jiTZnj41Q75+3DAA80v5hRfqADecJToYz3EmORwvtAPw zUqQMSr8TyGc2ZPirQrOH7fgdco93eAPI8NGftAu/MVDpV9VjrhJJeUp6tbvOVnKfN8SkxG52jYw YAYu6kzefNIJqtR/foDr2179hB/lEd6wWBgOj9eg1gS26dAvsczuKa/kv8iV30jWBA49k64eDfNV poCuju9lUwCq7OeZg6sUVd3tGN8ufYxXJEVkXZOnevC68VIoP5LUN6ulj2dbKHqtFgcr18MZCMp3 SEcqkITYmnyeoDG2wEbfY+wraNrZE/MYdTSxPW4R+QSYobKHlP3XPDQ0CNOqpuA3MC3NCzjdsWxb MXQHNhVV1XfKqFrWYkudmHUmJMLBacV4tlKj/BgTHcY9rURat8gdykY7V+MBWZo8tZ12Lq9LxlGk 2o61UqxrftF5WWW43Wd80eLLy29bR6Ge0dVqBw2EcsWKSPmiZ2DGArRxQP/89vHj1bfow8ujaphE JDXdB75G7XSanRY4pNvrr5+uPkO5HWIyaaBx5jsNDKtABj2nZsT1Y0wE6lR7bFCRzIEgUbZDL6Ii 2ab0cUNjieIqJUDvVXBCDJ2+nlnA3mzJzJS8g3NxYBN7arv9euCVlCT+iSJ7gJkSVe5NXW1vOduR +KnXISfii6pVVZ1J77MdbWQCGYu97hmbTAh26DqH1vTUZkEQOSpylxOFPmu02W4Q7pwuG53DTJfb GcozDRk93tOYQP3qvNSJuegv/XUU5d8WGTX39BTOEoKA99dkyDh7YClBTF/ybG1M+44k7Iizq6sB sw6q/lO7ECgqUw0S4A1iCsk53WKHJCepWDPjPrpNdcPXrnUbBQD5JDzGkbTTRTRVpLBIPfJXpz2y c6kJDl0uMxQEsmRLhtvdVhqPkHx7wqZljaZzbExcW5eb40vHwuvejVprvJXRe5Iag4W2RpFnZ1Kg jdvmlzcYSMM1NPpr7zYmKPaBONii66LZ7F3CANOBydecI3tyipd4T4pWddXAOEODz8U2JViOUXo3 PFNKUsN0oROIp0kMimxVaiWLq+0cD2R9igOuMtcuNHi9Vld7SwSgTJIqKzgKBT3jNrZgyyW8h/i1 yRIWV7reipjLr7Wx0fUmKdiQGfr2yUAqBOH0gfCF6UpPtrUrTYpYcZTviJLrCzNwAuPqugi3l9K1 JOXQQkxttY2fa3BAkiCF3Ai6XWTp01qv5dn9VsjkqeJXOQX5LBJNe481Wh11e8fpMmdrRYRhXQm4 orIpWdM3xiRVtuS5lCzEs3xQhS8twlSTJJT5mqqdU62XOR7kKmr+qjU19xQC2HWpxRe4nX5U3ZhR NwjQaMctaVfx/l30zG57V9T18fvlVSIVCRWZa8LYg/DYypE4Prj10mz3tw2nLBgeFCmvaELMeLxd C0lS6GU6mCUiNn0kILzIETUM0PNcQeNu90gE8ERQU4UkSx80ArZG3eghs38fYilDlE/pkhlnGYnH lbxNFZfRt8ewlnpCp4JlkDAcdhjo6vOrcTTQ++BpM1VJPXI2Z/+XtGcoGFamOj4S6nTxxnApFwm7 h7EzaeuGSWWOVYzfNNPwSqMf9l3HLmBW9mr6zxd/1OD7OZy9eKcloQOXlMbqt0DONQWaFVoV87pM 94hHZGuqak6fnGQCfTJ4DHwdzDzBdOwLa9M7TQ16ucybjfN1NHAt9SPidDD17XnoWeHcs6YOPLsB KJ9v++7M4nSwHLyNBuMomsDb0XLguvZ8PrMc+Dk8TuauPfVnMyucubbnwKpoPXDyN9TuuUF3vfzs W3I4/C84nlmDYuncCsOZHcw8ywtsLwwsffi/rVQd3zxUAZ36Qf1QdcjD4Yzf2lbOYeW0urKYIgK1 Xj0BpGg/uKSWO7WypRVMq7APCYPuMD2krADtaNCN7LoT2w0r+XWO+W0F6sOSYG5BNkIAUsLMhx0n R+i6Y9cZe4BYIRz5oT2ZwA7QsIq0T/KMrKQ8EYDre3bgz2oBGCEFgR148wAhKlK+OZ3yEA7wZkEj kIIUv4zH+/3eZlQubTDrrwLUnTj2VK2sIz1DDncSwLqgss4ux8sxTCGUD3PBGS3UA1nCLynGxYfh SFVu/tUQvIN3OVqR4cSeXe6G7iXlDAp1lBejDtCbzyE29xChCnA+7RKgWue5zrx5FZszl+G7IdA+ bNDKmxdB0kcFXrWv0VD9pqQG2fen9iyYHi8FKAHE7gDZh9xOZn5f8vhTz55OvAZ5/HzxSLD1yPVs +Xik+P8GAFCMpy8KZW5kc3RyZWFtDWVuZG9iag00MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q YXJlbnQgMTk3IDAgUiANL1Jlc291cmNlcyA0NCAwIFIgDS9Db250ZW50cyA0NSAwIFIgDS9NZWRp YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw IA0+PiANZW5kb2JqDTQ0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg PDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAw IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag00NSAwIG9i ag08PCAvTGVuZ3RoIDE4MTkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV9tu 20YQfedPmG8Vi3LF5Z15cxKndRG7jsUgCKwgWNMri4W0VEjKsvv1nSUl7vIiiXLs1kFrAcaK4s6c mTlzG77JXDXKVFx8sogpw19HWL3NFIwMA6teYKouNpDv+aruBXCwfTWlykR5HSrDMDThVjhRfBQE vqMa8FkfHQsFHvZUzzJQYBmmGs4Vo3iBK9ENkA7iwwgehivlanCRJhHNspjdHmm66VnIHiST6ngc fj19e3Ienoafq2fXD9Uxn9LqPKLpHU35V99AeHCkfQl/ByU6RtiyLDV8yzVGCvwQ/qmEP8tQrgaV lPbh05SyToVZpbD4mtKIxnc0qx4Qce3k+ELXdBd5g0uaLRKW0eHo9Gw4ykmaVy/NwQ3kVshfxfm0 Q7GzNg1M2Im7y3XjQcwkwCUUoSPZYedPwrD4hrI8zh8kSd+WNMvXMQT3mz0xkjxP4+tlTsfaL318 fPZxFAqaLGhKcvEuEQgnyWyWrDLUYAPAeRwHTid90C0zeiO7/+Lk8uz4HEIAgfh6efJBmEiYeDHu lt0VvpuElizaWOrUaG66Hqf5TktYIggXJSwnEiFIdbojs1ggBD/PCYOYtxhQC1qvLMkouxFxgrxo MKaWsDsteUfi2TKlnT6VAax1FGd6H00Jk3IsB9NiBiwquXJAsCHdk1sW/1UmfJ3z8MXjFnCmdVLt NwKiYia5TEY/IkBe+tA2+eR+EUPWvqoemJ7gyyKNZyIepmHYBRzTQy4UX17+ZFTyH0foI7t8q4bz 6kIuSNj7UtKvwT7dcreX2e5cO2XgeUYFo96mZJIX0ioknXi5MLcDqRxlKK3CLUvOzDyOSB4nrFCA LWQ2NVxVKkytvOhpG+fzOy7qUvpHlCfXNK15vfSQ1XKRDUoPdNIO8svE3J6e3fVG6lDXs87qzwtD zJb0oPSu19md6Be851OpDtRa3WQ5mwmItfh1zQC8osjTAzChjIHeD8xl2byKhvxmSmYzCgUCNeJX 7xy1cvu8PeTdx/fvjz+Gv/VtIV1tY13ns1ryggTNaGZy/+rbt0OIbi1sFH1mkdHlTcIe5tvv5VOS 93FcVFpXDV19x6Q5WXSlwD/RC7emwQET1JMly840kNj7PePnhojPywSpwK2nnUMm0i0l8RloImcE 6292ZwveZ9ZeF+00vpp1urBHMwLr2+Sxs+CjzOH7lEzY+iJV6yYdc/i/vBYcn39+qoVATqjCIHKg I/8v4/+lMt65LrbmmnX7fzFJ0L+THDCC1umQUn2L03eO0jvsJbcppQKeJHGZyZFL6UHDah3lE3K1 DmYfA/u3nRZPawy93Or38WBEo9oTG1lj7ccs3Qta73pSx2Wybw7cW7JFwjK6rwEmbPYg29DKpfEg hihx/z8VL8eacM/18pFDWym3zzgmSW33nWT/1rN3XX3CZlHMPHvq9tZgHjB7N/bGF7PPPnfdf+wG u78DCLyraRxN+xgvkbr/XlGfGuCLx40pgnF0RLSNFfx3SzVaEetD1h4lq2HJTUK7E3RFJE2SXRD3 bbVEt3rH6Hvb3eOyLalKVt+EI+yh5W7J/EKZXF1JnqcxVEaavfCG1i8HWZu3O7E+ejuoFlFJeaMW lBV7/0JS70slLzZ6+483z9HD+mxTXRtOLfMPGIVffjO7OLk8Oz4HGvbqZj9o0tSa8POkz4EErbKt epIIWdGMZFk8qbOmjD9rhKd/Tz6Ea/1YtnUY6l1zbWQiq5J2RrOM3AqUIw6CReLByT2ZL2ZSgRoP TtkkgdTM4zs61p6q3odTKZpZY1dqsY0lTGcbEKICNYzJmsbQpjHViNK7uMxmyyxPSS6ETpNVd92T t6QWxyNpVbqmkqXz+ZLxAUHKUYnDbUaVHN1bQsrDSahglX+yiCmOhQLPVL3AVB0DztgFYlvIwr6a UmWivA6VYRja8HY4UTBGQeDDgGao66MdYORYvq96PkamAbfCuWIUb3DpReCxWYC4IGvl30B9rCrl 1UD1PB+5vqmaLoyFriqUf1IZV99WyoE6lttUypXcrnV82HYzgJtO/WbJTpff5yeAFK6UAVXBFclE dZ067LXDIPmdtctK0IYA3fIuthH2av41Nv7dCtSCK26ggjc87AiYRRIZBUKMh9gYmoCYI9QtD9m2 NDxju/DINM93GIAtE7mW3zCgE5LrItcMXAlR6fLFbpd7oMD03ZYhJSleDYer1QrFNJ+gJH0aoNg2 kMNvNpHuIQe2Xbjn1u6hqmwNY5ZDokHZobl+ww9kAv/ybFh+0XTe9opHGrQGc6BPiWYjf3Cn4QFN Yxhi9CIrhYFmEIBteG0hNzBw+hjI75nYCNqhWOwJhoU9oL3XopUZlEbSew6eV0Jd4/8paUC2LAf5 rrMJClACiN0DsgW+tX3rUPJYjokc22yRp1geB3oWz3Vsovx+Q/G/BwCsy4SmCmVuZHN0cmVhbQ1l bmRvYmoNNDYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5NyAwIFIgDS9SZXNvdXJj ZXMgNDcgMCBSIA0vQ29udGVudHMgNDggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0v Q3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag00NyAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIx NCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv Q3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNNDggMCBvYmoNPDwgL0xlbmd0aCAxNzg5IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1Fdtb9pIEP7uPxF/hGu9eP3u6nRS2tArpzRJ g3tVlVbRAgv4ZGxqm5BI+fE3axvv+o1ALpV6RkLrl5155pmXnRm8Syx5msg4+yXTUBr8OcbyIpEw UlUs264mW1hFju3Iiu3CwnDkmEpz6a0nDTxPg13eXHKQ6zqmrMKvWJo6cm1sy7auIldXNdlbSWr2 AVOiyt6U/W2l3knf+weWCkZY13XZOyseeb9JKtJs9mgKj3bPFBVwATB4eNP7QO5o7Ic0POkr8Cky eiSclesxCaItfSjvy8Xwfu3HNHlTPtDscnm6jv3gNX+jqkb/u/eXpNnIAvAAr4JKvBhCBxn5VxWc N1dkQUuZ2PneVyxk7wCZsGAqFN0SaVBzFYXdvVYCRmFK45CmpeyzmMzTTFqJpBUvE2a1IB2eXnH+ Rh85LZt0ScPUn5LUj8JMAdaRVtdwU6rQ+vlGu78jn+2xUJvSy2kaTWhcYT1nSG9QZIBSRpJm2TWS 2mOoouj9Jgg6TKopYtFX4b8ipxlS5cJb+kl5MyUJd/s8ivlaBELagBg9QY4fBJskjUlKeXT7/EvY ziX7i02c3TrgFm7NXtATCpmCytuRKLpmDnfSqXc7OhteeCPvK/8iClPih3wL9QFc3Ip0TeMVgdxN jwTrzxhZKc9rgVfCpSd0M4vCh1VjHxJ8xdEkZCXc0B8bGk5pmy9IkETlzSYRPZLHbNhX65n9lEmV OBE5Smh8J9AH6pLW78AX7z+fn59+9j6AU26vh5/a4gSSO4eoHAbrmtGQpAMoBINxSuIUNe2qZkmz 1rAXxq5QCEnUu6I0Zi+1vXXqgCsTYreUFSHBo7ij4uqoWnNbKtnJyeOuhj3vKrczDE4lJI5S8So/ iAww0WqzV9l7vRL8m9m+EyRW02eb/1gp8yC6rc6Pq9E8i4RoDiN+iC3hWBdO9If8uDGagZKjLFzL YRa+dUXP/hyDNpNkGvsTwahGdSJ3xA/IJMhR0sd6CGaiXyQED4L8ZSl0SwlLaj9ciBWCZXtOuNbs eEpIXZzbxfH8TNZ/Yoj/ehleY1ksjuAHpVF9WaHb65T9uOySFfMYJ3WjvOl9YwfP6cXX4syp9AZ/ D6/Ho8uL2/PR2PvWz6W4+zrGbiYVHSOn2t1xeB2N7OPv+2Ol68qZeqxH0v/nlHgpFdlLu+3kzoMz WUdhQmvRuXckOAgWj1IV6v1TUdoJsojNXYNaicyLy4t3w9uP3us8KM1jMqqTRkXTqjHa7rcCsNNk FYCNh+fDd97wbJc7kDZZyh9PaQdGSEBHPO8PyaP/kkZ//EJ51CvNfPZsN5p3DDJdLbqf8vVBI1+j eQhndZUwKeEDx4q2CY2kKTQsm5TDb8xsfIi6I4E/E+wUBrYjRjGQkodDKevQuah7iBNYIWmrV6BK dY1R4jQ3CYTJiw92K7Jue8x9cOi02k3aa1Fq2GrDITHTmFXXcTSldJa0TjxPwSWcmk2yIVz71k+X T/I8rvOcbMTusratmEXFPufdkgQBDRf0SNgrmiRkQZHwpnU+rWT6NVU6OM13q5XRiMtRxRp2aO3w BNunJOE32y7n14K2UljE7yot2L7K0SxWWxKmz4sTIScgwudRzFM07qRVyDs/CDZJGpOUcpgTGkRb 1KxxVRe+7EKtHocN9+4RwE+v3klrfH2AMTb2Q8G9olPGBKylD01qh/drP6bJm/KBZnNfr2M/4IVD U1Ujn5jsZhNTO0AZQgdaquYRf3NFFjxAsPu9NSIUvXp2tzulIngUpjQOKS99ZzGZp5m0Ekkr3q5m pFJrRh85LZV4y9u6va2oVjQJdqWRtFqHnMtpGk1oXGE9Z0ivUTT0JCyzXzINJVNHrq3JtqvJpgpr zOjTkY4dOabSXHrrSQPPM+Brby5hjFyXNYWqXCwNFyNTdxzZdjDSVNjlrSQ1+4JJzxBCZ8h4uyKM L1D+A9T7spRvdWXbdpDlaLJmAQOWzJV/kUOmvqmUATV1q66UKVkUOj517XRhp1ndmdNosf1sBZC8 rdSjMrblaC5bZhV2QRiEmFlQloNWOegGu9hAIEzkV93x2wlUhy2WKwMbNjY5zMzbaoYQ4wFWB+Bm nSFUdBsZYt5gI2NkmaZ7DMC6hizdqRnQCsmCuNNcS0CUU77eT7kNCjTHahiSB8WbwWC73SKfpnMU xS8DFBsqMtnOOtInggMbFuyzKvtQmV8Dn5WJvtGDSqHM2ILM4S9NBvlNX2HdVvaoDwVI6ylL0jeg tb/r415eYJVd+hUGaq4LtuHCQmagax5iINunYdVtumL9hDN0DFOoajfCSnNzI+k9A8+ONaXP/imp QdZ1EzmWuXMKhAQE9gGQdeDWcPRjg0c3NWQaWiN48kqsJP5KwRpK73ch/u8A9lVuGQplbmRzdHJl YW0NZW5kb2JqDTQ5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxOTcgMCBSIA0vUmVz b3VyY2VzIDUwIDAgUiANL0NvbnRlbnRzIDUxIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNTAgMCBv YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RU NCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2Ug PDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTUxIDAgb2JqDTw8IC9MZW5ndGggMTU3MiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicxXbW/bNhD+rj8xfbSXiRZJvRbDgHRJ Nw9rm8bCiiItAlqhE22O5EpynAz58TuKskS92FbWtJsMGNQLec8999zxOPk5c/Qw03Hxy8JYm/wy w/p1pmFkmlh3faI72ESe6+mG68PA8vSUawvtZaBNgoDArGChecj3PVs34VcObYp8F7u6S03kU5Po wa1mFh8II6YehOJvo42+Gwd/wtDACFNK9eCkfBR8r5mIuOJRCI/kJV5YiMAq8J1hAkTAKN6fcZ6K lwRZ8mV37rCrWMTtGLgYHa/zGx7nUcjyJB0bDnIBpwFGkA2DT8FvmkEpclRHagwXCojHsZhkPQ1W z3SBwStNA1lPNXFUTCQWuOj0+WvsvY5K362t79uFnsX92scSo9MDcMbTO55WOK4SnlU3cZJX4xt2 x6sbFj8Ua2KrKxSJsgxtDbOMra+69nUcWs+zMI3milPRlZBc/lDjv2PRks2XEiV/bEuwWFoAJRCL rx+D95ASFbYsZ2kexdfVg9Pjs8ls+loSTrYL9EDaxbkLqf4FrP+fJT6I+eEZLjnGW1GrpRGiYJzz z2ue5SIak5kIkyhze0NyCJdbszI0RLsxXow+jo6Dy+M3Hy6nJ5fnp+9+qLiHx3+cns+mb99c/j6d BR/HchV/uwnsgd7LowH7kdPcbapLkNKn8scf9ytl1yV5emzr6JvsEU4Ron+9O+xffLg8i5du344t ZZmtkjjjLV3SAcHdD6tWp4kO63MnyFKX05PTN8E0+FAFMkzinEWxWutYNUq5RGCwumOIkrhT0z+O q0edMt4qfL3NzE61folYf/pv1NorqFHlptnY0iQPnbaxQYLiRXvwNlZC1QpSXXeiRTWED9Ry1FED y3PYtdc5b+sj61HHHVtGV+LOMxFuJM9uxB2Ye/qD+KoXd9Zslth1ypV2SVlxnamqrrQ8DOguMnO1 TdgDa5UmIedXNbBNlN/0TjyUZMPwZmJbjEPeS1+UZWuFI9V6e0s9P4BmxcK/eF7zwbbL2kOBrngY LSKuoKtXn/GwYc1CFLWXUAwp+QN3jax5xZbLauZLAF17n1TDV2vlo+M+h4cZ2+NuoHAdsqy+2QwU 0s7DQMrD5DqO/ua9qzyPqjpJqZpYcQXmOuuPqFJlFNHs1iZTeIDaU38HQn1SAnf6xOrNLc8yds0V BPVwuVxnecpyxZk5XyabpgqbBa9Txcvq3lPYK/l8pcE3t9/YzvtS41c4sqZRrGhdDf6MAbf8oRu9 0/tVlPLsRfWAuLWkVmm0rMVETNOSpyO3ewhobeQCodfbtV+cqZIg5qdt79XsZmizhxge+YaxaZzz NOa1JE9StsgLCxW6JzVKkBw1p9PXO2qaPG/sbUlJ2cC4jYbSQX1G34Z5MudpIxKSNdqhzWp1gY1a 2q+m2mMLed2m+wyqj3hJ9hI24CoWcXv8U8hLpF/pQb++ZVP5VBNHMksscNHp83d/U33U7qa3Cz2L +80DDCzdJ7jZwJ3xBmqOUm4epO6trlAkyjLTa5hlbP2Dp60vdmg9z0JouBWnum3wHYuWbL6UKHn7 fHUaaFgXvyyMNZsi3yW66xPdNmGMRbWiiGJPT7m20F4G2iQILPg6WGgYI98XiWXq5dDyMbKp5+mu hxExYVZwq5nFF2L1AjomMvuYSBsw/hnMR7omp/q663rI8YhOHCDZ0Wvj7/VYmO8aFUBt6rSNCiPX pY13u2b6MNNuzpT8OmK+GAGkYKONuA5vk4Xu2E3YJWEQZrukTII2a9AddkFI2G3wa2753QmUwhTH 14ENF9s1zEIGZoEQ4wk2J1BBqUBoUBdZ6jaFrYKRmzzf4wCmBDnUaznQC8mBkk58R0EkKV/tp9wF A8RzOo5IUbyYTDabDYp4vkBJ+jxAsWUiW8xsIz0gDmw5MM9pzENV4k0isQOPoWzw3LgSA7aAvzyb yJsxuEVGxaMxFAEyMm7YGLah0d0Yj2Q/Y2zTr3SQ+D74hksPhYO+PcRBMY9g0++GYnUgGBS7IHu3 IyviSyf5vQAvWlVjLP45a0Gm1EaeY2+DApIAYQ+ATIFby6NPFQ+1CbIt0hGP3LONLLo1MEH5/Vbi /wwAF23OggplbmRzdHJlYW0NZW5kb2JqDTUyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVu dCAxOTcgMCBSIA0vUmVzb3VyY2VzIDUzIDAgUiANL0NvbnRlbnRzIDU0IDAgUiANL01lZGlhQm94 IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+ IA1lbmRvYmoNNTMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv VFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+ PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTU0IDAgb2JqDTw8 IC9MZW5ndGggMTYxMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexXbW/bNhD+ rj9RfZSWiiap92IYkDbe6iFN01pdUaRFoDpyos2RXEmu2yE/fke9v1CynHpbsE4BEooRec8dn7t7 OHkWG+IiFkn6Ey8CYfLLnIjXsUAQxkQ0bSoaBCPLtETFtGGgWWLkCUvhqSNMHIfCKmcpWMi2LV3E 8JMPdRXZJjFFU8XIVjEVnVsBpx8wIxhRU1VFZwFzzla4kB6Vz50M/0Jabab7lN/IH5xfBaohA/Z1 TgQFA2hADfteSG9vvOCRrGRfxokbJX5wXU5Mj88n89mLdANCiw0qXCUkWTGQKdVgpUsU1URUVAgi Kvv+ZG8XjgroGBsmB70y+ByVfuRwio1qiDi+jMQ2KvIQFiu37vwwaCKLMUFax012Cspr79PGixN2 GpM5OybZ+X34SHbhMquojD2ifowX0nvp2Lk8Pnt3OTu5fD199biMPUz/Nn09n708uzydzZ33craL DczYBZ0bRwVyxagjrq1iQeGx/O7HYab0PVmc7to8Mv4dBuHULAUC3yOV7mdsiBTpZ2ZxjF3Cxusw iL0WY9URxz4MsOItRruZ2wsyZ+zsZHrmzJx35REvwiBx/aBeBd1yFHkZAsXdJFA4E3/hJn5YFVD/ ik0mX9/L5VRBHr2A3SqJVRzG8PhbaPzTQ+HxjkrIex5yIxjVZ+de9NmLShxXoReXL0GY1Bi2CK8D /0+vBrk2sDAi1cydjKU2vVL7/5xfzo23KztK9VAeHQ8TTzq0juhvcECa5RnLMk5D1rja1KN2qD2i IA08D5nko8I8MsfTD2zeaRxM6bRhVU2DjlSkvSDzxvHzm9PT4zfO85F6J7U77ECP2iHAylrf/27U zj26xKFM/DeVzdZPbjiaZrlZrWp1G3XETIPaZy/Pnk0vXziP7yFw+MeZ+2F1gw3m5tPT6TNnelKk FGRTWg32j3RPesE9xNr3MvEt2fWQRJhUugkvOJOg+VvD4bwi1yVxUmv751506wbAlXKmaKrlBKlp l9z4gD2+9EkHdbmx9K83UfX60VuF24q8q9UmTiI3qemsOuiFG1cvW1Ar3K8g3ctx3FRwS9df1bYO iwRu5EL7xtbv2K275iJYx97mKgy+3nbSspoIFqvNlXdVm+hzJs/zsoJ1Dop/9+uHvXYXf3hJLQyc AvPZXfkVuHWHLYVDaBdJDjvAza5aTZWVoL2ucVXjEfe5CwzxgxqZ3KDyfO4CQb2v3SBOv6z9yIuf lBPUrEruOvJXVbGlGGuZnjC7gqhVHxhCCxpJt4JdnLvXFS8o+cAlr6I2SxP/LBobz4LEi4IaIU4i d5mku5VI9rrw1hMQ2m0VFs4NY7AB07wGmo32aXD13ctFEn70okbUswipnRBprWbHD1LX5+y+wVEY 554XsX/SwXiNeNJNeNeIWuzCqOfk1UNdIgeeA6q+af7Zcf73vMgR7k1KKu8Y9dsfwX38Gbqa/q/K 95LMjYDvf6frwColc1vH7S+ZZ1kbjTkdrGzC+WXuAFq/FKBtrf89CdB9TRxlaa3x0/pCGvb/qO14 sdFB3G+SDLbmndx8WEP2qcGCdFYP6fJM6NQpa8Q18ltdOu8IVK4I5Mk+1Gg+cJOUcbsTTR2BiOwn XgSCriLbpKJpU1HHMCaMuSpSiSVGnrAUnjrCxHE0+NpZCoQg22YBw2I+1GyCdNWyRNMiUMBhlXMr 4PQLtnvqFdws0ybsstwD45/AvC8K2VJbNE0LGRYVqQFHYIiV8bdiwMx3jTKgumq0jTIj17mNV30r bVipN1dmoTfYejYCSM5WkDyR2GK4FA29CTsPGDBAz0OWgcYV6E50iYaI2YgvLuLbC1SFJYYtQjRM olcwU4bgFCEhE4InoKNUhpB1UK0uTImWRuQmSQYcICo0DNVqOcCFZICwo7ZRQ5SFfD0cchMMUMvo OJKR4slkst1uke8lSxRGhwFKNIx0trKNdAc5iGbAOqOxDpU5OfGZDpc1CaS4csUG7hJ+JfEke5HB LSqlUzLUByopN66sQWX+LBMpu8EoRfrlDlLbBt9I7iFz0NbHOMjWUYLt7lGsdxyGSpjMMju0onbm pPeFgWfXRUVmvz23BVlVdWQZenEoQAkg9gjIKsRWs9R9yaPqFOka7ZAnk+5K7N8qoHiSLwXF/xoA DBzViQplbmRzdHJlYW0NZW5kb2JqDTU1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAx OTcgMCBSIA0vUmVzb3VyY2VzIDU2IDAgUiANL0NvbnRlbnRzIDU3IDAgUiANL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1l bmRvYmoNNTYgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQy IDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiAN L0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTU3IDAgb2JqDTw8IC9M ZW5ndGggMTY0MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIieRX227bRhB950+E j1QdrvbCaxAEcG2iVWHLjkU0COxAoKWVzEKmFJKy4sIf31mS4p2yFKeBi1KAsLzszpkzZ2Zn+yeR IU8imSS/aBJI/d9GRJ5HEkEYE9m0qWwQjCzTklXThoFmySGXZtKvrtR3XQqz3JlkIdu2dBnDLxvq DNkmMWWTYWQzTGX3XsLJB8IIRtRkTHYn8MzdSNfKm/x66sErpJWeNK+j3hf3D4lqANEwYUn3VFIx 3ABgWPJaUXdeR296amYjWUfdLqQSRJiAdVoCeCi2HVc+vacayMqsu790mEjemshq+Kc4x5fqFf+6 5lHcHw3O+6PYC+Oe+5dEKDLSz9vx7wHLzEnBSCszciDIa+VGOXbHl87V+fHQGbrjwen4yvn4Nuce Xv7pXI0GF8Px2WDk3vTSmNLtWjs8aOVRBaEZZcClWYIbowXi0/vdSum6UqKe6joyXpmCfpwJnHhG IUe6lJAJgXapNVotg4jX5Mq23/8kuXaCzNQ6OAWlDtzPeWA3fnyX36x4eO8FPIjzJ/4U7vz4saLq 4cXwxBmfu28Tawy3e9ihYQHu+5NOmB85Z86J65xuswsSK6kMhxPdgZHYYPnAPHtJmn14RXmm5G7C TcXFEsb6YDDLh/Edz8cRDx94mN+GfLKcB/7fPGr9eh/xwfdBfbKFEanUiW6c3losEPsTL/aXQQkn 7DTBpAQlXE44nxY4vWK4jtbeoj19yt5ATcjHo5wHwEr3xOpH0doP5l2LV7bHkztvseDBvPjinkeR N+eosm6VKZzkU2uos7W7zF82IjXIIpU/oAfZ20GDW7I78+frsLi95YvlpuBrsVhHcejFHfKaeFFx s2nRUSNsNfnOPH9RWnq5Lc7JA71jG+l27N5btadBxNfTZfB4X3gWTBbrKZ+WHrTObCvvXhyH/u06 5iXgxct89OAt/OkOh4pi3e1Qd/6i2poNMfxLg0owyo/yuv4iI0VdVtor5u8e6McPSlLzgiKKIw/k yx+bRDrfVn7Io3dFMplFjFehvyjqIcVYS7tKs9kX17YGgdCCFqK5eV1feqXSQemXViWorLortUSw QnjFxCCIeRjwQhunoTeLk3VzTK3IuzbcSn0dnBcEVUp8YmB3E0azjdCstFAGajN6MYmXtzys8J9y xRpkadU+p0PwTZ/FC62ty7zkPBQv6U6+9riSRdoOlSXulmGHBhj675wBjtLU0MBFo83f3b3ZUb0p 2y70Q9yvduywdJveRtUdaLos7W3BskimOyg0pRrzmMpeawolRZmFttZuq8x+vjF/qUPr22gCG1LJ Kb/eOngPsNF6t4sUJX+qSzBZ+ufF4FO5VYjEwa7cFkEZEh1YSjht1uAcUhfnex2Huq/XLPG9mN8/ w1OOScsO1uiHRyJM6aFwR0iew2UWrOwbom6M18qNaNCOh5+hSRtfOR+LTQQeZyfZ8dlg5MJxNlnF 3rVr7eJRZTjLkLz1ya/O8+v7lxxgX9H59SeYeJZO5SkVZLRaBhGvKZIh6xBFtmHJhQkasaoN7TPI INA3reeEyjm2OBe0HEaycl2R7/BieOKMz923CSxGOlzsUKtZdaI1gsmnZltbBOZHzplz4jqn2zSC DEpy/zt47sCYJOOBRL8koT78jzLKcSUii180CSSdIduksmlTWccwJsJvhhix5JBLM+lXV+q7rgZf uzNRaG1bSA3L2VCzCdKZZcmmRRDFMMu9l3DyhVg9CRDoImmnPRE5MP4VzPuylE61ZdO0kGFRmRpA siEXxj/JgTDfNCqA6syoGxVG5pmNj10zbZipV2emKjLEfDECSO5GUrhMsbycyYZehZ0RBtrQM8pS 0LgA3WAXOkNiVvjFW347gTKYYtgysGESvYCZiB0nCAnpE9yHExETCEVaa+VtkGgJI3dxvMMBwmDD ZlbNgVZIBhzRqG2UEKWUr3ZTboIBahkNR1JRvOv3N5sN8nk8Q8vwxwAlGka6mFlH+ow4iGbAPKMy D+Xlpe8HMZwH4RzAY3UqBt4M/uKon970wC2qJI96UDmoot55PQ2S7qFHFB76AQ/UbfplDlLbBt9I 5qFw0Nb3cVDMowTbzVCsngkGI1DSsdmQFbVTJ/k3AR4joqg98c+9GmTGdGQZ+jYoIAkQ9h6QGXCr WexQ8TCdIl2jDfEkpVhRI/9ehY4z/raV+D8DANZTLt8KZW5kc3RyZWFtDWVuZG9iag01OCAwIG9i ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk4IDAgUiANL1Jlc291cmNlcyA1OSAwIFIgDS9D b250ZW50cyA2MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAw IDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTU5IDAgb2JqDTw8IA0vUHJvY1NldCBb IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4 dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+ PiANPj4gDWVuZG9iag02MCAwIG9iag08PCAvTGVuZ3RoIDE3MTggL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSInkV2tv2zYU/a4/UX2U14oWqXdRDEgbb/WQuGnMrijSIpBtOtbgSK4k Jw2QH79LSRb1tJU1HbJVBgxa5uOcy3NfwzexJc9jGaefeB5Iw9+nWL6KJYw0Dcu2S2QLa8ixHVm1 XRgYjhwxaSm9ptKQUgKr6FJykOs6pqzBJx+aOnJtbMu2riFX14hMryUtncAP0RCxdV2mc3hHb6UL 5Vnx3A/gL2SU3jSe54Mv9A+JwCzNsmFHeiypGsAFvLDjhaLuf54/G6j5GelG6m4nFSOsc1jHJYAP xFZMyTAaLfCmLLphUQFi6fnruPiVhMXw2tuI1yuWboh15GRbNhEOVAvZSglkxk63YUmJ2uMTOovZ dhEGd9cFXD8ohkf0cnw8mtAx/ZQxMJDRwaCLgAMrHoFAkg/CgpGmeFV2bWq68db+oqCzYdG1F7Ag EVwX8MtP7nL0u9f3sHv+wyyE9jgae8r63/cIKYGpnPx0+kuvIzLtWIg0+CqjozP1nH3dsjgZTsen w2niRcmA/iVhgqwuZ+nEZRdWcXK/IWCanrLrRnmhfOaucDY6Pz2agDuAU1yej96/KPvJn6Pz6fjd 5PJkPKWfB0JJfOQAhR2y9IDWyyoB4gawWmDcvzogj44ns819XTvWk1bNjzgi/dPuFmK8CYOY1ZSo 7+bvV+IeWEKXWo9w2Aky1+EuJBfXeesnqx5B7kUWekgvOq1mVYnbJ5znBJwWAgB/8m7yZnR5Sivu Mx2djN7Q0fHOjz4PMnd0u1NmL7w2qoi8j499j4v9+oR8TClowo8KRbqKGCuAgvKF4Iu35+E2WCSR v4lriRA207Jw1bZ1iX59MBZ1BVREQrxhFItj517MXpTnRWKmVxonPShEnIJYUeJiKDO2DKPszliN oFZLHN2MyjTiamG48sRZ4Szx/IAJKJ6whDefs03izdas4a6oeENXflyxkJgb1/KLVvPObvD+er2N k8hLSsBmbB3eovrczpv/QYPKBZRftaXMNhG+9eAqwOIlM5eEMPWAJLtrWmT0beNHLH5ZvCC2CFGb yF8LYRJNM/Kqs1mm1ByZI3RQW+19ceZdibsk+pdKGVpUnno1hrRfQWXjcZCwKGDCFY4jb5mkuznN Cr5HUAQHE/YbnwqzbMEHQK1zL/HDYNfl7MkvJA9WdiXZWajt0HfzJJyxqGL1zEJ6w0RGrapqN1Ib Z/6X2XI9yhljEf+T7LVYjyfdpK3WL1kv4xVGLcSc/0yVlvc2BlD8B71Ns7XJN3oU+tXqCrZuU9y0 GsQXIRNxNwiFO60gwJRiy10mfKMplAxl7ta1AknV3Ye2KA8ntJ3F88iflUjt0ovAf+P5a8hAeTa8 r0sw3frfu4OPq1LcjnlC94OreqbPDL6vReyyuV0NFP8nifeyfH8Pz2yM20Jj1ix93bI4qfVK+67k EC7RJfXoMQ5h5L3SOJivt4uSD0OjcTT5BA3U5fnofaX/yNuOy5PxlOa9h9Bnk0t7t6E/uNd49T3N xhPqNR7Wx+b6iTdhELOagPZWDw+UkdajWe0EyQUEwhgfjyZ0TD+JfsVPVqLFYKpXKYEaYXYnJnsP q3b49ZrmZ+pdn1BYztPzE6k8sn7xYKHdnf2c78l+vajQFSv5R4ak5iVF+i5uq828bbm7lix/AAFl nHsudzJeffeKRh0GJ26PELTn+VnKjXSC23Ybj1Zq1GGJNEF6loSdIPNU8duHk5OjD/Rt3/qCHEx1 HWUGrnrxT1NojKiEZf6J54Fk6si1iWy7RDY1GGMOSkc6duSISUvpNZWGlBowmy55iei63JU1OR8a Lkam7jiy7WAIK7CKXktaOoPvnloPk1SCZx43Kxz+FY73ZSlb6sq27SDLITKxwAKWLA7/KAf8+Oah HKipW/VD+SFX+Rnvu1a6sNKsrsyu2OLr+Qgg0VtJYTLBcriULbMKOzcYXJyZmywDrQnQDetCT4vt in21nX07geqwxHJlsIaNTQEzVaKWIsR4iLUhAcQcIY/rRrmAx0ZqkVWS7CGAdfB/3akRaIVkWcgi rlVClJl8s9/kNhxAHKtBJBPFy+Hw9vYW+SxZojB6HKDY0JDJV9aRHhAHNixYZ1XWocL3h36QsGgA dQRL1AUfeEv4SuJh9mMAtIiSvhqAWxNFXXkDSHzKzQArLPIDFqg798sJEtcFbjhnyAm6Zh+CfB3B mtu8is2By9AxT/52Q1bEzUiybxy8hrCiDvg382qQdd1EjmXuLgUkAcLuAVkH2xqO/lDx6CZBpkEa 4knjpKLG/rUKCSz5tpP43wMAss4gbgplbmRzdHJlYW0NZW5kb2JqDTYxIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAxOTggMCBSIA0vUmVzb3VyY2VzIDYyIDAgUiANL0NvbnRlbnRzIDYz IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBd IA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNjIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4 dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5k b2JqDTYzIDAgb2JqDTw8IC9MZW5ndGggMjI3MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIidRXa3PjthX9zj8RfpQaCyJBio9MpzNeW926Gz9iMel0NhkPLEEyuxSpEJRlZ/zjc0lR xCUJypLX22mlGS/EJYBzD86952J4Jhx9KnSz+IpprA0/Tkx9ITSTGIapuz7VHdMgnuvpA9eHge3p Kdfm2odAGwYBhVnBXPOI73sj3YBvORxZxHdNV3ctg/iWQfVgqRnFC/kmBqGuZenBFJ4FG633XfXp B//RHHgrONcGBkAADPBW72V8ejO45WKVxIIPJxeXw0nG0ix/27SIt50gV/2MVuz4vPThZWL3vusP HOLCP78F/9QGpg+LDUxiWvlC568j+9x7+bV3GtxdnI+vgovg37Dcdt1NmD1UP1g1Wgm+niXx87J6 Es54nIXZ80n1BJa7ur46G99dBicFLMvsCLEWhLcLwnLrQWA25Iz8VZfQNtew/WT84/gsGJ/f/TK+ nVxcX/3aL5imb+C5AyMQTY8levCmz/Z8//ZS0VsicPD26pAq6G/7KCMP/nLsFt8X8yi8ZTiugpdX 4v++GfhupfcIvy4naivgTXj6yNMKxJyFkah+ZUk1XLKVfPzAiwX35XaZtxJkQ/wUQuwS/1cFdNNO 4Rjn7q4UbCOwid0RQVcAHsx4LXsPCCArB0kVkdFj9ehUanpkUTiT5YqnSxZDgWqVq13ZLB+/wOrl j1EltPfR2P+y/vd93pj+O+ErKvPWBH9fc5E1PJAS5+DarHY+OjrANA5B+blXGOLN+Pby9AoyAfLh 7nb8U83eSlu5+/FiEoC3FOdLu1O9w+acYw3kr1/jIP+/BvJuW3T3DHvbsze0DR0aNQ4ojZ0gS2Hu 79S6C96+/sxQR9jZntHXM60Mw/vW/Vlne3Z0H/w1ydXVnpUm/t/LLqMddR4wZEQtWIS2OTidZ6jd gU6mGkdMSFmpM0Z2Q1wItuAnyoXm6yjKf3gGMWsp242KrWEB0PGUZWEi2xWRu0k8lUuv0mTK+Ux2 aEwO12LNIlL9vJgrwUFg1Vj2fgCVHgg15dNkEYd/cKFcvztDJeZYdjAhCuU+ksugzrOMWc21gBC2 Gq1OdXRgIKEQ644gmk5+9sCiiMcL+UYpAFJbtn7gRlEOdvqUOdJTa/YfDM4iBOaUPE1YlGz4czuK 8dMqTLn4oXpAXan1VRpGkjdqGHbZWbb7kUaa5gg9ouqvP98wxAO1f6u1mlV3Wbf/Ohc9JQEXMWRm zKVwzlM2z4rVvHaXfkDJq0n94lLSUku2RqukqmW0LEVuzcQcotr0epol9zytsb5lyGpRZNedBpFk 4PKKH5Wv1ra0iSV1eMsHp+pi0iHM1lJmNeMjj3nKonZe7VlhT8JdoMKWLKWGePwYpkm8BMziBOfg a+VxyWRC3NdK0DxJl3x2ZBGep0W5zaJnSecHPmVrgepSVylF+trV/33Qi6I2W6eoorAvfCsU0SZ8 L26ML1FX/Y+TSyXUU2t46kms0SJJod1aomOoFesML55yYFlukZOXVyIpfAlqG1favoTWCmORcFYt xyxFhsExCdkRZmm4ingm0CkmSyUHHWlxBs/Sw518YDWaw6NNvX30yATjRHIMfiD1veFIVGIdZjW7 hJNoyRjpo3RI0mZ/bwDB7pDVWYmFFMbTaD1Dp8+ksLFKwOCeVjwW4SNWzhbfoIOww8C2ac0emCRh lnA1y3neHZNKh6RPM3tQe1Wr7HsD6kQccz5DPzbvnQvYTMqTUXTfb5H+lMlxV8EuZSJj4BvUsKfJ Op7lceLGDa3akb2HNrd13KT5wldbILhzBzWoBiSr/H+YTHfUDIdLOOElzm6c+vdJ9qCkQpG2Rxij qO4JLUtYcZ5Kmq5lPJxNH5Tb1+OXlYWHuadIEuJ9mXjEkRaXjxClEu4aWCQkt3OGSuw9m35BYFqi 2ifzsIZX7jaTe5X5fEQcG4YOHSkCl6y0KS+s4G8v3HsmUA4n6qz8wp/ljBlceR5fn7OCSyefhfHi W+R2gK+TDPWln+5gilL1n+54PE3VITE5DNuyOSLrOvhmac2uJCikCfDCjE8l9i7XXoHIsV/gGFkG ZfZ+nXFxorzhvQofrYXPEixyEeLqdslEhhL/E0qYmn8dlHliHzeI/MNteFFcgjIZAEPwcCfaiGPC hcDQIC7UVUucYsWn4TxUm98EThEvYhOHoEhqB2J03CWPyHJUv1ulRN0h5/W/KTukpwULY5GhRVcR Q7myCZFfbV38iARZQxu5iBFxpjO4R3eUKfQKcCIniNiiSVUyXeuOgruz65+vgvFtOxuaZnfM/bJb wBJjp4XvMeHOAwljsD4WhX+0LrBH1M2SRlWdAZNW19HmnEcWrZV+jjr0iDMkFez/XVnddosjwpqH aU2Znc6JkkKs70XjctVxeRGqdDm0dDbZu/x5EkiBSF4WKWe1k8GdMLaM+FnFfcNhH8NkLdpxvcWs hGTv76g95U8sb19P9hxgKfVpguTdQfEJQpFDHAeaqedfMY21kUV8l+quT/WRAWPTgepoEcv09JRr c+1DoA2DwIa3g7lmmsT3Pd2Abzm0fZOMLM/TXc8k1IBZwVIzijfy1Yt6atKixt6wvMjC5r/D9qGu baf6uut6xPGoTh1CXUeXm/9Lj/Pt25vmQEeW09w032RR7vFT10wfZo7qM7dF38nn5yOAFGy0Htcp 1ZO57ozqsEvCwEFGJWVb0IYE3WLXtInp1vg1dvx2ArVgiuPrwIZrjiTMwpuMAqFpDk1jSAFxjnBg ucS2YQUwtS3tdsHIQ5btCcC0KHEsrxGAEpLjEIf6DkK0pXy1n3IXNqCe0wpkK4ofhsPNZkNCns1J kr4PUNM2yCif2UT6ijhM24F5Tm0eqbqBYZiXmj7cSHg2mOUDNoc/mRhuf/QHeUktHvWhv6C9wQPr 28TrPfbNHnTvMY8Hu/QrA6S+D7GZZYR5gP7okADzedQ0/PZRrF45DMt0QfZuS1bU3wbJn3LwuVMP +vlfzhqQLWtEPGe0OxSQBAj7AMgWcGt71rHisUaUjGzaEo9VTB6IcDkwKcmedhL/cwA25GO/CmVu ZHN0cmVhbQ1lbmRvYmoNNjQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OCAwIFIg DS9SZXNvdXJjZXMgNjUgMCBSIA0vQ29udGVudHMgNjYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag02 NSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAg UiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JT cGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNNjYgMCBvYmoNPDwgL0xlbmd0aCAy NDAwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFfbcts4En3XTyzfxtqKKF4k Upw3xfFsNFnbGYup2VQy5YIoyMKGBBkAtOz9+gFFSWiSoEw6WavKBUoEuvv06T6N8SX3jIgb9v7D IzoY/2tpGw98YJuWZRt+4BiebZkzf2aM/EAuJjOD4cFm8DYcjMPQkbvCzWBmBsFsaljyc1hOXTPw bd/wXcsMXMsxwmRg7V8ojIwsebo8Pozkl+Fu8OXiH8OR47vmRLOI0pwKzE7PjyjO8emJ8NNS7NLT OlXvPzCM4H4sIvP0EG7VUfPw/vL20014dXf6CgnByCoXdXszy3Skh3+Fv8sARrZpu65rhO/OB4Jp xJ4zgddH89PDEeE/CxiigXwM/1s8AXzOngi955g9gigJjeJ8jRU6iDYdadtMUxqpk78WyNzc3lxe 3S+/DoEFhXzpB0BFBnHWc4ZHKJfbqCAREiSl4JfvOeaiNUXX88tz6Wk4tV9nGLNfjpmzO/vIs5Ry LdciFEd5jCCGKUTwAJdyRlEzY+kjWatTkTp0i+IY0wc8PpgejjzTvzi+Ou3odwuwPNriBOtxrbuL Yq4cjlJ6gJnr4oE4U7zTlofj+S+WxzXisEyXmHPo/gf8XK+bSum9roLepmLbyhhQO2vtS7WyWb6/ /fTvd6fHLXoEWVaR5FkGNsUkIeL0tAGNS1VVV8bSPFmBo9ON8jRf8aKwqDLVKEHQK+I43QFqr7D0 S8fYTR7HPX1sYSfFeK2l1wrmhEk/EtVAZf5whHKuc832yuoZrQC8dS0BFd3Ne2lLwUJoO5hvtISR awlk8U58+i5BTyTJkw5JZPgQ0muQ5rqgpTTKrqAi2skNWsfPi3B5jDrWevpN/plNTXhdkS6UTylb Ay8ATSAJOiajU4lfzT+2qiQuketBfuAwF7CkoMlNWpQfoQ9VtPmvba1StkYVYSFKvJ3x1cQhWjLq GHtXian2/KczTUWxbl18KZ5V7X64l6++AY/FXALK4vm0xkQeqX5a9e2Le6yBUqujJJvII/gJPSBQ 1RuWqrq8/qDXzhoroN8VGT3SRUuEMg0/kAXZGxNEYX8/Aq7rJHCnrBxm1gCtqLasYL/Q2KJy96Vb 0d1KEb+XkscIBU0E1tUSFbLy3Azk6ikjDBLc8U/LecZIrFjiWNZk76Ljm568TtT9g3+FrzNzUr5V 8fPLR/SgEHCmf2nxH7le+4Sh72KLotgoVll4x9BG7E87eaL1tzjM03gK+89yca1gqVTZ3oDtmk7d wpeTCWdYbvSHUO88U2f0NhKp1KAK6iVCbgOiiTTaE6SJKT09nX3X2jIWVQb/1OtSe6OS83mE1zlo zgn6BsQNKg2csHCGGBLQwg+odaU66yVNMFet6CPH+Tqlzwm86um1rNIjelzWGp0EMRjmvgEqi3CE Pc6H5yJMaQxEYaEQRT8ZykYYYBCKU6CZbfjJut6l7JsSjxTQgqZQBaP0gZL/6dt69ysREfrJ5cxQ EoGLxgYB9Fco+gYw75IivSr80H1rodegMwFxeV1KmYAza+t0Byb96/ln9TWN4nzdGLb6DBDfSJah VazOmIf3N1f/Ce/vruafwvf3C3XtQ0IwsspBJyD6mboYd54zAUpnjYQiPegtEp5eBXBXXPW4GEvB GF9uJQswBXKXYM6h/H29WOKoUime6X4dwmkHVEozvCilApHSwdM1AzbrqhqhigC5GvmheNehTzfK GTaeMwPqAUkN1WsioTQO8v4s8JUrRYWCD7Q67usQfaNjzG5Loi0ob6A+kO6flqFWoY7l3aPdt+Bd gVGQBGubdusFa4coKOLWm9sPNHptH5Cncz3sklmlsa780mPRdVhv49vVI5iWSQcgtwhQ5yVeN6J5 09PtVjcgu9eER4jpRbNHAUPdhaxAPbt1dhyJVOr0naHDpYlQLjBa9y1NUHbaO9VrCrBS46tKFLL1 JXj9/9BrZR7TR8JSmmBYx7stZrVEHbKOYgV/IeCVzIOxCeM1UMAWqTwyrwcJ6oR/NSvlMIfJY8PH Hq60zwqVlJY6qjxZpWKrgba4EVCU4FZ0YRnVMqKdR18sp/J8BSRoQBnWV9bNfKFqQZITCZ3CVge/ ZfskG23TFDaEYwY6S1omb3UZI9X7WYWiiIEuAG4nbA1DVLK1RY+NibLM9nwODtowxAXLIwEvlCzN y0yI+qzx4iCar3gx3FE40bRRmeEYwfGSlWOhVoVhBByy6xBOn2F5n0eV799A98VPKMli3FaUrRk5 N84rjtcrQWwRSCrvSRqe4YhsSPQSXDDh9djfyyEfawcT0AN5vpFmCEwqMMVFdXLEPcMo2kp1Av6e EwZoAefmM31R35mbwTfQ76PcRynT2upxVS2uHUrwKtLbVfrCLpMPHFNeqS8twNbvfFbnS8gd5llK OR4v6qYyFH3Digkp04417LBfS8Z9in9R3JXaNr/5LDVNqtsfr5IXzfWn09DZDn23Sfh8Arp6L+Nf vLu6CRfh52ZECmn9XK9yfMrZcnE9XgrY+sqk6eUTgNPV4crIcXOr1km6JptnrZ8vjhwt8Z1PRVeP m5OcxLYfV87Edn5SrbTGLEaR2kiOza1rI94ROM9ROd1hdt4Ns4nU68b43pdMmXH9LbPr/bI2UVSV IUHPtX59FQ5so/jwiA6mrhn4juEHjjG15Nr2ZO9zTdeeGQwPNoO34WAchhP5drgZ2LYZBDPDkp/D chLY5tSdzQx/ZpuOJXeFycDav1GcvsfMdvY4fkQFkNL4d2meGINya2D4/sz0Zo7heKbje4Yy/qdB C/NNo4WjU9erGy2MPBxs/NG2M5A7p9WdZWK9Yn+xki6Fu8EFNhzXSDeGN626fQBM6sP0AFnptKWc bqBrT0zbr+BrHfFtddSVW7zAkGj49lS5ueeftffQtse2NXakx4WHI9c3JxN5wlF27ckeka0QZwKw Xcf03FktAK1Lnmd6TuABj0rIs/OQ+9KAM/MagZSk+HU83u12JsFiY6bs5zhqTyxzWuyse/oCOeyJ J/d5lX3mqeLHRI52bDi5oFiM1sUCbeQ/wcflw3BUdKf9V0M5PTgXoy0aTszZxePQvsCMUExHx/I7 BOgEgYzNPkRYBBhMuwRY7HNsK2imInshGa7tS9r7DVo5QRmknF2l80WrGA2L/xjVXHbdqTnzpsek SEpIYndw2ZXYTmZuX/K4U8ecTpwGedz95hEnych2TPF0pPjfAwBcg2ZxCmVuZHN0cmVhbQ1lbmRv YmoNNjcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OCAwIFIgDS9SZXNvdXJjZXMg NjggMCBSIA0vQ29udGVudHMgNjkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3Jv cEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANL0Fubm90cyAzMTMgMCBSIA0+PiANZW5k b2JqDTY4IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAy MDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9D b2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag02OSAwIG9iag08PCAvTGVu Z3RoIDIxMzggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0V1tzo0YTfdefCG8r paIRN3HJm+JVvnUq9jo2zqU2KRdGI5svEigMWOv8+vQIxPTAIIGzsapc3Gb69Onu0z2zC+ZoEdOM w49FyWj2vztDe2Ijg+i6obm+qTmGTjzX06auDxe2p2V0tB59F4xmQWDCqmA98ojve3NNh191ObeI 7xqu5lo68S3d1ILtSD98wI1Mddgdtg8ieBjsR5/GX02mpmsRW3GxD5O8vsnT+nIdbjb1zWMY/Vnf pIn4qEAfhUX+TJM8jsI8TpNvxEdpVl/Tz+F2t6FiYxqFBRP3sAO/9nRiAsQ/gh/Ag6lBDMuytOD9 aU8YzV6oMLVKKatvklQ4mdEofUriv1tWq7eTqUPc8VR2p34fr/jD/FXQcdbkvHIl+PptocAEZbQB jNSvLhPkUCyARCGj3yh9bTDG8jDLmSIWRk8HTqRD/XiXpRFdFRnKAcFlzFgRJ09iD7FuubipAnNL /yooy2d3l1ezOw55IM07SGaaC94CTFb5UgDY7MNX1sVQOMhzxnEnkXA8Lh1aT/TxQBdigbAzzeMk 2hQrdZIvgofF9W8Pl+8fbpc/Cdx5nsWPRU5RTq37JM4+ZKUrA93AcMNHJAso+Xm1YlsYxo7S7J3w vlWa6yzdvqnIsfSYjntWeo6We5VZFRiBm8bwtdpDCNT39z/+uLgPPjSjlUorlPz3106wc7O8vVpc L6+DzrRAHqiVBmoUUXyoUiLZkrVE5x0KboP/87sTF9ANXO4E//r4DDW5T+MPIRAcJ1TgCpNVfX0X btI9fW17vfy8izPKvq0fmK5gZJfFGxFPU9ftA27TJQ70WSBUQoX/OEKP2OVXEs5PN+GToNF0/lCG bWo5OHAdNEkbXyY5zRIkXO+zcJ0fdquRKPHyzRwFUhxKEFpBi1QwBwOGRcymhU+1CXNSLnQnuLQc ojL6McrTR5pJrJcMWS2KbDB6hiSpfiVDNrGIVVu5bfbU+s1No1kpC0s2Ldk5UXEBqvJ1uoEMxY1v HT/hFhlvNgXLszCnrfbcS8/qpksajpxT6GUSZa+7nIpiqtUAtUGEFIQwxZ/vQdvqm3dfvyNKAriQ 43EHaTpqt7WX/bD3HeAkNROY8MDBdmnC6OyyubQ5SizYQH5XMYsKxjC/j9DuRAWgCSjc8BoHZ14E SJhOVE0zSrfbIuGenxlyvyyTCMGp/iciuk67G7tq19NHhXNuLHhrgwZ3GfzWt7mdTIfmAGqPt5Qx UHjlbNk3JTYACXnPp3cVddKoV8vD6pwbDWF5pCA8ONvQBrnKbJpsXt806+1SxmI84+2fqRpiI12q QUItfF2JwqjkyYkZ8fFt7pRDHJbsAfP1kFz7smcd1ezV3SZPbNzvYMCH96ck/ruzbU1LP/sKDM7P 8CmjtFlc/SdeZKZgOI5ZcxqQhvpeKcuzT+2xiGy/+OH4d48pjUNrhwzzWul36r26vwsqbTUG1YO6 29DWEAH1cfHx/jpY3raLQ9AtzQ6hkDAY2cXzKC2SSi8HtIKXcFNQ9WlNifb64/XF8uHuRCnnz2GO QCV5GCdMgT6DHC5PpQPgJsX2EfeE55ShTHx8VTpSJqXaSXBpeX1x+/B+ESyU1dX4+PLngfmgGBML PObgzl8xLpXaCSxXi4secRjA7oloVQ1dvFEXYJSi1E+xFEgF2BDjoPXuTa3oaoHGmQ0Txd+sSTRL qpN8+WsADWtxH3yA1vUfc4yJSehnUTst/W21AyJtLyfl2w5j3dJa2Yw7jjtpcpyk83hLFasE1o6O iSYYuYlVDfn08SGl6okQGi/F54QQcb0fQLUoyLjdHo5V3YhC/x5MQeC7aoVm2zABEC1IgvtM4d6O 0WKVJq/bE+vUPfyYhAOSuoO8HJcgZAE+ha2LzaZjPflS2Rx0DcggTPE6loYx1LQwGairin4pvEIn OKkZ/z6GoSzMpZjiE2xSFssxFr2n2Iy+xGnBNiKIUjM5oPt90qGsmAFJH0/T0eg0pc+DFC+DKuyS ewwKCzgLX9RDVEMjK9XpOzivs3Q7kPTzM5G6XeDOLoHmCqmUwxCVRPRMoz9bWjuAdlZEETRtqDP1 5CMxD8m7S/GsLo2cXUcyvobR40z+r6SibPtIZc8dKzvH5k4X3jRTsHDbVwyGTmr/icw1DmCKyh4w QkqnzP6CkT+XVNMG1/3beW/VlcZ8HCoJEGrZklzG6gaIU1w6dQ5t6ydzvWsgYijflBrQq7prYfxX VfkcMtkiXSH6uhK+kYNwQlupIyaIvivdQcB6tcMDkWLrVGmFC92R7HlXrZ29WAYjQ+M/FiWjuUV8 19Rc39TmOlwbDuSERSzD0zI6Wo++C0azILDh62A9Mgzi+56mw6+6tH2DzC3P01zPIKYOq4LtSD98 wXc/1L1hHvDdhJXxv8B8rI3Kpb7muh5xPFMzHWK6jiaM/6Il3HzbKAc6t5ymUW7kqbLxU9dKH1bO 5ZWlODl8Pb8CSMF+NKaaaWvpWnPmMuyKMKibeUVZCVoXoFvsGjYxXIlf/chvJ1ALlji+Bmy4xlzA PGiofkBoGDNDn5mAmCOcWi6xbdgBSrmk3T4w8pznJxwwLJM4ltdwQAnJcYhj+g5CVFK+O025CwZM z2k5UibFt7PZfr8nMc3XJM2+DFDD1smcr2wiPZMchu3AOkdaR+quNYu5jk/4AJRPV/wiXMO/nM3K m8mUDzSHRxNQVXM8fQ4nNvHGLxNjDE0GDj7TQ8EKB03fB9+MykPuoD/v4yBfZxq63w7F7kwwLMOF tHdbaWX6pZMw2wF43sinE/6fhg3IljUnnjM/BgVSAhK7B2QLuLU9a2jyWHOTzG2zlTzWYfGUxdup YZL88zHF/xkA2fx+4wplbmRzdHJlYW0NZW5kb2JqDTcwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN L1BhcmVudCAxOTggMCBSIA0vUmVzb3VyY2VzIDcxIDAgUiANL0NvbnRlbnRzIDcyIDAgUiANL01l ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl IDAgDT4+IA1lbmRvYmoNNzEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u dCA8PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1 IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTcyIDAg b2JqDTw8IC9MZW5ndGggMTg3MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexX W2/bNhR+15+I3mq3FU1S92IY4CbGmqG5LFZ3QVoEikw7GhzJkeQ6KfLjR0qyRFqUZaddkaGTgYS6 kOc737kPDlNLDVIV5b80iJTBL2OkzlIFAQiRartYtRAEju2omu3SheGoCVGmyltPGXgepru8qeIA 13VMFdJfuTR14NrIVm0dAleHWPVuFZh/wIRA1QvYn5XSO+h7f9OlhgDSdV31jspH3sudFhBgm20L 6CPuKGzZ7CgNUi2oGvT1Ze+d/5kkYUSig75GNwGj50eTaj325/GKPFT31WJ0vwgTkr6pHmC7Wg4X STh/Xb+B0Oh/8n5VsA0sqipFIODjL4bVAUbxlYDz8tyfEU7ap75mAXsNyKQLJkLTLZ40WIjYpEc4 +DjKSBKRrDr7KPGnWX5ahUSKlx1mSZCOhuc1f8cnNS3L7IZEWRj4WRhHuQCkA7wp4bISgfvFRru/ Jp/tsYBM6FmQxdckEVgvGNIbFBlUaDdJTZ3ZC2MNmJPeOyckYS/xVr52uPJDbIl6HHdx0mJ5HYi2 lzB6cPC45vJpV7WdYXBK0ZSsJ4gYlZ8Ny//n6xiB0GpS0NMuyN2SpNngeMKIyB4YVzQHtfhPDaJk xwaYnStkFIF3mVc9/qQ96Sos9MiljRzEM7NP/tKWOTQNYcp3uoijlIiE42YKu+wGK8Cy13QgFzg8 I/uBvOx9pLkrmC8nJK1zd7VKiOYLCad6E5b6fOwXHqc3o7ahklwBWsUsvrDs4lFf41A/P3ePar1e FVRj4MiC+7LXpf+rTcXXR30D9UVXq91BADgmCe0TOO8K4lkUfuFcj/paw8WETG30HvuwkbZzed9L C7618WcJ4eBzAbJMw2hW3U39tOgGkNEeKKWikqzbHeHdKiXlghS6GcCSlwgx4FkIul2R3UCsF4c/ GfRz9vSt136BXqZlp612FLWatn+Di81EnNcRd721q47IM2/eSnfaqBUkqx1D7+r497pfpLej08OL q6OhN6yfvqSPD88+nHqji9eFYeEO1aKVTg07Yu/ZYj+x+xaAM0SnZ6eHo6uxCPN09Kd3dTEafvDe XR0fCYqdDA/Xxa4DvBy1jsUc9cN0TsLY+H2ECRQzdnUJu6+exGqZmlxgVKmp0w84D5CnRbHuyMaj y3w+qixKy2g4DbnKUzhoXZe4GsXX1GlC0puIpFzJmlb1oEUbmZlaA1NWqXbRjgcZxMsoIwmoHgiq nwz/qtYpHeSIVNGIrLg+ozCdVlX1babbqi6XOZ9uyY6WujZWnHD63GdNhdhJoFnP9zMhZzzpcPcf iJ9WJfe4/o2pr7V071wBv6Z0b5369q3c1bNVmN3UAejf1jH32Z8vSVHhdSjXrqU02rsU9PZuqarO lNkq5LqI3dMTNIT3rd57xocQJs9mSv2K6v2cu/inzKs7FN1ixjPbamnbhOd+g/lumyKS6pp/brUW ffFqww3/H/E6Rrxdr1G5Y1j+Py/SqM5VdZGe8TII+D6uWjz2YW+Tm/U5Um5+mEGEGqnuaOiNoKIB 6PcV0EbRrnvRJA7IZMm1nSv6WXVzWERX3dTVFvLiuFqPb/35nN05EKAaHizsIcPXNHS1OJ5KW+AF 3zVPYi5vRXHdS/rUjRaZ9IBgQ5e8vnODQ7WkPU/ZkF6QuyVJs3XjwwdHO36R6br7CGtYYTRhrzkd tgFNH6LgJomj8Itou0USX8/JbXV/XaB+qCPGbKl67eDDKJgvJ2E0kyIjUZA8LDJST2N1R3XlnZ1d jU+G799zh0k5FbtJyaC7B731VOVxOFOx0iW5yEnNttD0yc09zvyE86N4g9EuJwijMAuphWvYnLsm NFzqsWg5n7cox1u6iFJeXS4W+eV8vkyzxM8KnSpT7Q5cavlpPJ/HK94vpuFMADRq+IafZUl4veTd 3OcSDZ0PY/5zwSgvXr4oFABN/GJa2bIQigJ7NvIUpLJfGkSKqQPXxqrtYtWEdI1YHteBjhw1IcpU eespA88z6NfeVEEIuC7r1aFaLg0XAVN3HNV2EMCQ7vJuFZh/wU7Psx1tspnwc78UfkfFh6pSbHVV 23aA5WAVWxSopdbC/1AjJr4plAE1dWtTKBMyK2X81rbTpTtNcWeRki22n60oJG+l9IiKTTWeqpYp wi4Jo3FqlpQVoGENusEuMgCyBX7hmt9WoDrdYrkqZcNGZg0zrxwwR4jQAMEBpogZQjZwGXyfiIyc kZss26IA0jGwdGdDASkkizaW2LU4RAXli+2U21QAdqyGIoVTvBkMVqsVCEk2BXHybYAiAwKT7dxE 2uEcyLDoPkvYB6paPQjzDptmLpJpE7bwp/RPlg6Kmz5VC/fyR32axXFPu/H7Bu1TPvdRjw4ZEYm0 PHZrBbHrUt1QqSFT0DV3UZDtwwi6TVMsOoyhI5u6vd1wK+wWSpJ7Bp61L1qf/SX+BmRdN4FjmWuj UJegjr0DZJ1yazj6vs6jmxiYBm44T5HOtDS81RAG2f3axf8ZAFIksGMKZW5kc3RyZWFtDWVuZG9i ag03MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk4IDAgUiANL1Jlc291cmNlcyA3 NCAwIFIgDS9Db250ZW50cyA3NSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc0IDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAg UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYg MjEwIDAgUiA+PiANPj4gDWVuZG9iag03NSAwIG9iag08PCAvTGVuZ3RoIDIxODIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV2tv4zYW/a4/EX2r3Y5oUW8NFgu4ibvjRcZOY6Xt Ih0YjEwn2rElV5LzAObHLynJIilRtuPMDrro2oBNPUiee+65Dw7OM0cNMxUW3yyMlcE/ZlC9zxQI dB2qrm+oDtSB53qq5vpkYHlqipWl8mOgDILAILOCpeIB3/dsVSffamibwHehq7qmDnxTN9RgrejF C3QTTSerk+WDkNwMnpTb3gf0iNMoxvFZXzNcE1g9FC/q8Qytkif8Ul/Xg9HzJkpx9r6+Ybj1cLhJ o9U79kTXrf6n4J+K4QKH4AguFB2QRyZF0TsTPv3g38Qmq3yLA3vbu71C95it6X3qaw5wd4BsMqBb aKajahBAk65+QW2kW9BVg+/ZQFh4HOc4jXFer32RomVerFYjkeKlizkSpKPhFeNv/JHRss0fcJxH IcqjJC42gCYwmjvc1lsY/XKi29+RT+c4QLbpNMyTO5wKrJcMmS2KLLLpYZLaNtMH1g4wt3vvCuOU PjT28nXEp1jElZjHcZekHZ43Qel7w3G7GD07+7Lj8rRPPZ1i8KqtdZ7NEzYbVa8Nq/+rXbToutMm o6dd4z+2OMsH4wWlJH+hrJFU0aEkBqLiyQUGXZfDfISov/xNO+lT+uoLl0AKEGKUfjNPEVlLtyge ujJpk2AmfGebJM6wSLjRTma3h8EKsNwdHdAH3kERdYK87f1Osli42i5wxrJ4PUqxhoTUUz+JKnt+ 75eKM9vx2zJJbgApNs5rFfUWQf39z66onbe8LkmVIUzqw+C66Z9CXv5u6iF5yR1S1NqDaakTJJXU MJiPf2EFhVyOJufX84thMGR3vye3z6c3k2B0/a4UkX6EiDrp1AxPLE4d/hPLswCcIppMJ+ej+UyE ORn9FsyvR8Ob4MN8fCEY9nF4vouBA+DlqE1a+f6KCVXnK26vNtiUGPzDSYb+UHrFB1ZdCw+6hnNK o9BVE8SUKmtpbitVsFTJMusjWkWsQ77bss6RBHE9DpMtbSxlC8QJm7IkTfQDqC+/lOZ6+9rC18rw f8Ah/zV9vrHgd6bno7PcW9Lz3oL/2uw8D6bT+ezj8PKyytPOfgs6FGa+sazw9UKegeEB6R/v/FZb 9f+uhCOgOn/KnPTKzFAlhqbtxeInmS9GALQlEGc4feSyKxlHy4hrfxvpm8/SC5zjMM+O6laqoG1l MltMtF/BoOABMYgbzNn2gJhZUdnmL3g7WwFOH3o6gD2urOi7C7t2j32ac76hcKq+4lu3MyfUplH1 fFj9X5XqMoBXV0m+yAj9/yxHaV70/Pr+nr+lQpKM31BPS4iwja4oLr+Mrmfj6WR+OZ4FJDOX8A6m 5o6qAcWm/i/THpM8/HV7sCMjyNxrbpelu8iWNRyTJF2jFWtbtyt2IbZH7J1ktUqeMiDorEs6ld8Y iWX+Kq2xZPL5U1H6bRRELvQiQndXguEc4uZgzLzCn1GW0f02ZZfoLnnE7zreTDP+nJNi9myNswzd c7UXcWtm0TpaIVbM8qS5PqlUhuw0udegO5RFYX2VNlt0dgpDGWanq1/JK1LzhHpb9Qfci+jgEa9l BMvH3UaQg+SWrbbvgMicErEnVS+QSbF19QWlg/I8jUhLhHdnEqEzKJvHbtgR4/DwYYmRHzxwFtYI GOsJzuLvcq53OQZLmMQ54gCh+IWtiHIkbQB5DjlInJyK4swlslTKcSb2oJy0ozjKI8RZt9yWVNdZ 81iyu9gUIpqzggpeHsKCxj/ezAKG9j5OuJAVJU4UHnPBkCxP0kybtu+EXn0y+i2YX4+GN8GH+fii LRPQ1sVpmXAac24OcbTJOdP2Ro+c1ex15xAUL07ir7WukJQY3GZgyJNDhtZc1udPF9LXSZSXoLXj wPLNbSshMD2i8DPOOUUz+kn+O4ptknzXUUziLHtl2uDX7ICHn8MHFN9j3nUcjnghp5ZwVY9/QtGK r697LEYnpofwAYefuejsKG/Fxmwzvj5vw5DUb9LPHcd4iuJsHeWytBnjJ46G0qCrEyRTnIc6sXNe EBqUIxrSTZqEeMF7JNoJ5/UdyAanpC6sMYPDBdI226IVc/SMlGp5fm3Qi1YpRgtWwj7HpIGWT9ze ZSHJjfvbD9an9s6kmfIDopklxrGU4BkiDTx+aRs/et5EpC95X98wXJaMNmnEicnQdas8AbjAaZ4B Gq0yRegBS9LU314hLhQN/5M0i2qmeM4TKoS8VIxpBxdzArtI0TIvVquRSPF2HVz5BEDUzGgRNNk4 asnOE0Z1HHDrYwGd4wDZptMwT4gUBNZLhswWRY3D1DEk7QmDaEGNyl+kHarQZUymXMdRtq58ARtO /kUqP+kBfn7H3/7p5vKy6groM5bpUqkCRoECVfrNwlixTeC7hur6hmrrZAypOkxgQk9NsbJUfgyU QRBY5O1gqUAIfN8j3OpqNbR8CGzT81TXg8DQyaxgrejFG3T1giFoFPRdIUob2fwPsn2kKuVUX3Vd DzieoRoOcbCjss1/VWO6fXtTCtQ2neamdJP7ao+fu2b6ZKYtzizd6ND5dEQgBU9KDxNAarJUHVuE XRFGxGFXlJWgdQa6xS60AHQFfvUdv51ATTLF8VXChgttBrNQm14ghHAA9QFRsUkRaqYLLD4tQKtg 5CHP9xgATQM4ptcwQArJIWFl+A6HqKR8s59yl2xgeE7LkFIU7weDp6cnEOF8CYhcvwpQaOnApjOb SA+IA1oOmecI80Ad34OIZsE+LeG5tqADtCQ/eTYoL/oarS/FrT5JHUZPe0B9C3i9xz7slfVD24Vf ZaDh+8Q2WFlIDfTtYwyk8wyo+21XbA44w4Qukb3bkpXhl0biZwqe9ohan/5i1IBsmjbwHHvnFCIJ IuwjIJuEW8szXyse0zaAbRkt8ZSFRsuitQYNkD/vJP6fAQB+b+lJCmVuZHN0cmVhbQ1lbmRvYmoN NzYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OCAwIFIgDS9SZXNvdXJjZXMgNzcg MCBSIA0vQ29udGVudHMgNzggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJv eCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag03NyAwIG9iag08PCANL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIx MCAwIFIgPj4gDT4+IA1lbmRvYmoNNzggMCBvYmoNPDwgL0xlbmd0aCAyMjQ3IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvFdrj5tIFv3On1i+bXsVyjzMa751ks5ORkqmJ81otOpE URmX2+xicHjY7fz6vWWw6wKFDe7eTUsRhqq6577OPTV9lztqmKvG4S8PE2X6zwdDfcoVg+i6obq+ qTqGTjzXUzXXh4eZp2ZMWSpvA2UaBCbsCpaKR3zfs1Ud/upH2yK+a7iqa+nEt3RTDdaKfljAjWg6 nA7HByG8DHbK483fJprpWmQmebgNvt/fffl0+/nuc/D94/vvX+7+OH2LktNjsWKn57vbe+0L+1Gy vJg+fPw0fShoVhD+2dOJAUd/C34Dy5pBDMuy1OA9hxEq8CH4txL8A+N7vJmRGcEn8xNPvz+nRbSM QlpEaZLXb+3aABx05tgzHgc9rmBjb04r8g0L4TVbyKLyCPu/ibUhFZ/mwkiZo91F2goUID8LN0yT LdufftLT0yLKNzHd03ksTK1ZntMn8XuZpeu+HAoXWbZlWQthZ8eGseyYZHMg9rcspOA9Pi/vgM2F bxlayp6LksadxSLaUSE+0r0s8CuaicAvU+TiaqI5xL05LrUbRWs6Li/as57xaMgitsnAw6TAHosE 9PQTRCj7e46PWLIsQzUT0+SpBOdFo0ANw6o0Y29aGWm03VkP2r0GKFAmUHFsaEYL1ruvXXJ5OS/2 GyYLTpHRJF9XeRvRAXEa0jj62Sj0BDUrapUF8iFK8oJREcV02dcJVTFow9DI6ELkjob/YcUxT69N VX0d++n2X8LrPC/FJkRInOoqRzF3n/Gim0F7YMKktNFxqNFC2IV8le4klShNebv6esiLtxgKyqIK xAvdEuD/fAhOP4AANmnSJvwxBLyLilVPBkdWKkeSs0uJFpTKtkx8jOT90vB8ES1wflAQwvQpiSq4 P9s0OybQvY3+P2myXmuovySlaTjaHI2jpFzP+6p+neZiYR5BkLg9NDHmo/kRQQKijLHYQIY/0Cgu 0YDFgL/efMDvv07k2D9INx8VkkCxWzGwjMctkzbc8HErzUu03sTY7LLyUI69kcQtjUuMFzdccdlh zI2VY+lElzs3ZBL/ZFmKUnEOqU4IsUzXcb9ORBlmDZ5DA0+EqkzyMgyBK5elkFQhhZHfidYIeQdd zqKNCAaasBdou+FjS6Sicga9gLhdlu/K3RGYaQkJToquzu9XvShgCY70cL6iMtJYioYcgT9KFvXp InO3ywKhPGRlGyVPfXOnHiKXx4OQzCOYOx8i0t5IsbVlDR6roKrlvCYcajPcMMhNyYZ2vXyavFJ/ vISeRFWnidj49cAr9R3oWJtDc8z5xwMecmzbchAPLVLUm1gM8L4V97O67Md1XqMUPv8unsMVp4ir 5FxUCLh5ga84ML/QlGmoGugs5CWQKlJq0pQSFPQAcxtUeo5Tjq8nlT+rsbppk6VFGqbx5ZRUM1sk hSZ7Kfpm115fkZVDxUh/mtVLUK1J9ANq18bovaZxc5CviG6GarZOHq9VlpWMe/El5X5F8z7Bd4/f Y8H38Zyyo+LjbhWh4t80TPXEAKiaD5uRE489V00+IqxoTs+b4gj5Kcd4L40Xyk0PvXIRVyXsyGyv d9tB7qQJotKWbyJLDT0gycD03YpXGA5qlpZJhX8xEn+EBEMZC/JpKi3hwXlkX2qu0Hq2c5yLru2h YDMG54pjRTl8aOLqUTE9wuU2+P7p9h3qkiKL5iWaKDC/KreCkXhRiqMkjMsFkzgPy1JEyBBKEHc/ 4N5Q9Gs7iqIoJNQwUL3KkXS9u05FvXJzwvSQJ25kv4nHRr/N2bLu/WzsyB7enNK8X9dwQL6GbISe RSoadGRr1k23Gtx1HXj1JD8L75W6VK4yB3YhA1nEsqvG9qCeRcEacI3rUZ5DEZ3Tp1im//80Zy0i VyMduUwg/awhNGcvpZ0eQNG4vFD5Nynf/UohplHC5CT8QON0x/aS0njeRBnLfzm9MF1R0pssikW1 m7o+O6A0XeKo+kEWY1T4H0fokVm1qoHz8Z4i7rH0b9KK1iwHN2dPUBoHf0xAlyQo2O8zkCqH005I pHj5YY4EKXSBiF8lLKuwNOjmYMCwiNm28HgyYU6qje7kGHy+xyEyo7+HRTpnWSPqVYSsTohmYFQe pAbxvuDa8pCuL+ruAd1FM7Gck3WaRT9b7M5iWmCRiWoXgh2yq3gPE0SZlzD49ghhkkcLlmGjAvGG ZhcvXVnFjdE8iqNiL1uNRn1dTCNuJmsGgUJXil+hgbe4MgDLXhrizhQZ4Bi6PdVDKaRl3rgW1bNn rAjByMIyy6B1YszNAg23IRiZ7gVqxJuQty3yu1ghgRYlyzRbNysLbcXJA9+um6VoItPTU5yGNIaa nscMOyByhesZw5AhRg5t0sN1olG4gByE2ennSRy+YHDxYIhCu21UbaMqYN0W5Shab2K2BoRNB9ZU oF3AWF4gsmB4P8pNzq68IDavU23ADeF2/gJxFyiGyv/yMFFsi/iuqbq+qdo6PBt8HFnEMjw1Y8pS eRso0yCYwepgqRgG8X0PyFxX68eZbxDb8jzV9Qxi6rArWCv6YQU//UC/hnmwfU9r4z/AfKQq1VZf dV2POJ6pmg5MFEcVxv9SE26+a5QDtS2nbZQbeapt/NG304eddnNnNSMcvp8/AaRgp9ww1XTVdKk6 dhN2HTAYMXYdsgq0LkB3omvMiOE24qsf49sL1IItjq9CNFzDFjAPo0w/IDSMqaFPYWxaHKFmuWSG dYgxO0RkVRRnHDAskziW13JACsmBOW76DkJUhXxzPuQuGDA9p+NIVRS/TKe73Y5ErFiSNHsdoMZM Jzbf2UZ6oTiMmQP7nMY+chIP04jLrgnv7EJb8Ae6hP+KfFr9mGh84h1eTUCAmDfaik5mxLvZToyb SrBqh2YUDpq+D74ZtYfcQd8e4iDfZxq6303F5kIyLMOFsnc7ZWX6lZPsmYPnF0dtwv9ntAXZsmzi OfYxKVASUNgDIFsQ25lnjS0eyzaJPTM7xVMpWy2P1pphkuL5WOL/HQBTQ/hjCmVuZHN0cmVhbQ1l bmRvYmoNNzkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OCAwIFIgDS9SZXNvdXJj ZXMgODAgMCBSIA0vQ29udGVudHMgODEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0v Q3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04MCAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIx NCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv Q3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNODEgMCBvYmoNPDwgL0xlbmd0aCAyMTUxIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvFdZc6PGFn7XnxjKL1e6NbRYxDZvHtvJOBUv sZjkYZKaQqixO4OAYbHs++tzGjAcoNHieK5V5Wok+vR3tu98PT/LTMnPJLX8ZH40mf+8VKX7bKIS RVEly9EkU1WIbdmSbDmwWNhSSifB5KM7mbuuBrvcYGITx7ENSYFPvTR04liqJVm6Qhxd0SR3M1HK F/ghsgLWwbzrw5fudvJluiAGeTeTNUsni+lFmsZp83TmZTSrn4zpu9lf7i+wS1aJquu65J5zE/4E fnD/nrj/xba/TBsjw4X7wLLmIaN+zuKofU6ozwJG2zfyB9qs44SmXuf9OBC+mFDa+uFFa+FLGU0f 0WssmskmsaY9j8Gzne7QTsx8HjOCfEXHFava29a5FQ3jbfOU0u8FS6kQ7MXp7Xx5ebXTQ1sh6oGo e77nMfoFhcuLRvxMPP8bzZvHPzm+KnzyHc0S8JFyuPOzkNEol7uFhZawDYE7BPlPHguLlP45Q4k7 LBmf4i0Fp9+3GzdJSDeAz+tmZfnp5vOv583j9Y2LUhQ+16HWDgRcJKhecUr9OE2hIEbApzSJ05xF 96hYHrxHhuM4Xvzve/VQ9a1mWrxvd8L1CrAV5cz38hjFCh077CEyNHPZ+oXaPYmzjK3Cdn+A7Hb9 x10bw5FpL+wdJtrp0YZmmXePKSVGMW2WYZwhzChlqRdlLBdFAqP32vO8kPksLpDbHmTSZ4kX5T0Q R9SRl+d0k/QN1JUUZcWmdSWlWVykPnJ59dwsoxinJitwiXVT8BI4QXo/QkqOxH80P2Nu6PFVr0Oh L6goEdR/8CKWbYQxCylityI5lkCBNNozgVdaWyxAru0O7T5KXBY+ZLFNI2olnEagEcoeKeLtIKcV Hb/YReMMUmbxtinn9Lt33gzTrw5KARqqM8xztqFxkaPspSxek55lWT9QG3DJoTbGbnEp3PQGPEb9 KrFx2SbgnkZgPHy/J087B+2a5sDY2f78Iv7whGk6onEGiMrZ2/qxSyZ0RxwmCJhK69aRLav6WWSw nuuHgd0//Sv4RJSitN4s6tcfAmo0iGPEc/V52YoBzp6jaq1Z14Ll1QO5J7XG2BLNbZxp+sQ5EDFN TtMNi4C8erQ+wPavRP7Hdt6saeAV4Ui9drqryEZ0v1+mbKTV/Hjdvqm0x5wUkYelxtEDN0njDvlW iTjB6h7x8Q5Q6C1wsU0fE+vCIA7hVoDHcilkPwzhd3PT43V5P6+PJWJkzAjCWQcmzfb3Ab/d0AzV ASOU7NqFKrI7W3ZmrT5G5AsIM1BsmyYDo9Pl7SJJIz8uIug5PJxHAZUiL2WrIu/Txa7hejTabRqj 4uocWeXiOUGNiKp6XSQhJxg63Ny+3xFjK4qFUeSHxZr276pHJHekYwRltjPFHfIdC19XFy2IJojk BtiY35Oed0QTFyBMjLqvsf/c9ttlt4hAZ8T3EfsfqqsojuTsG0uSTg//X6pNiAcVVRHRpwRUFfq1 r2KWxYrX5CvL4F86dnpAHdydXre3ERi4YUjxzE1pQr1czPyn7teX3T+uJlj0CJfSNT706vQM9deb Z71/YuK169Uz5otuLG5Pz88vr38+NG8jnQwY21/rXR14n4CkUhYhcsK6aunBAKbPKD4vFfaUsLQe xeUXmtWCT1KGbheaoixK7JpFzCpAHXz4j2O1yUIQxi+3+Jaoq39VurfHbrJujqdOrN0u+VCKkK48 T+HSWFprkAjxcmOmAGnn2op697SjS8sDVP2liXplVf5pdW1ZnRoziejQGz+PVzTtRL2KkD4I0c6O +gGjfx1TsYzaekjLYhnV05u8Gy7urk6vL67dr5fnX+8ufjuCzg5V6ksK8g2P9KGQPWS2g8qHdmpb KEA2dovb3nleViWwORWN8EO1wRLGCb4EWUS1PwzNvS5gp204MphbLGBiYu+DWBC1rdPtA4pdnXgc FBwyqIPfL+6WlzfXX3+9rK6f6Bpw+EWymfYYBvMfmqeQZbn4AtYfyECeGfiGIlEkSZziEbd6FlrK aPpIqww3bWtMBffO3bkOhMaH4mu0CWstKhDltW/oAE94m2CbJKQboLaO00J+3le6oxyCh5LHG2f/ 7ZHv/w9KDPWLlOVtMpIYJPzze7x33FCv1vb5cfW5Ks/6ZAS+V0zyHc0SqB/Kq2p+FjIIYxU5+aJD B4nnf0NDasvyB6FNTCKHRp1TW/NwUkTDGq5L4YQMLb+OO/44ru07slLQvqN1c3Ai6qAfFjBB0t4g Xf1EMEhEEDCfm+/Nu30Ao2KzQlGIW5ZoNHl20oZvhEXGrYhlPqIE1Hcb/msqpIMLd6JK/JP50cTQ iWNpkuVokqHAWuVSTie6akspnQSTj+5k7roLeNsNJqpKHMcGFaJI9XLhqMTQbVuybJVoCuxyNxOl fINbLwtT1cpivfV4tcLh3+F4Jk2qrY5kWTYxbU3STNA+ptQe/ocU8eOHh3Kghm72D+WH3Ndn/Da2 04GdRndn1T0m389XAMndTqZU0mwpDiTT6MKuAwaTwqhDVoFWWtCD6KowfK1OfJWX+I4C1WGL6UgQ DUs1WphlkyslQlWdq8ocJKfOEcq6RRZYw6uLMiIPeb7DAVXXiKnbPQeEkEzQwJpjIkRVyJPdIbfg AM02B45URfFhPt9ut4TRPCBx+jZA1YVCDL6zj3RPcagLE/aZnX2kodU541eWGfQnzeU1X3gB/Muz efUwk/mgKr+agY7QpvKDN1sQe/o4U6fVZU9+ab/aQc1xwDe19pA76BiHOMj3aariDFOR7EmGrlpQ 9tagrDSncpI+cfCc8eQZ/0+9HmRdN4htGi9JgZKAwj4Asg6xXdj6scWjGxoxFtqgeKpboZyxjaxq JH96KfF/BgAsCpgtCmVuZHN0cmVhbQ1lbmRvYmoNODIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDE5OCAwIFIgDS9SZXNvdXJjZXMgODMgMCBSIA0vQ29udGVudHMgODQgMCBSIA0vTWVk aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg MCANPj4gDWVuZG9iag04MyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250 IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUg MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNODQgMCBv YmoNPDwgL0xlbmd0aCAxOTk0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7Ffb cuPGEX3HTyzKLxFTwRD3y77JWsXZVK13I2ErD7YrNQQH4sQgQOMiSvn6NEAS0wMMQNIr5ylilQog 0ejTt9NnlneVryeVbnWfKsm15Q+Plv5UaRYxTUsPIlv3LZOEQagbQQQXbqiXTEu172NtGcc2WMWp FpIoCj3dhM/x0nNIFFiBHjgmiRzT1uOtZnYPtE4ME94Or48T+DLeaz/dvFsYduAQV3FRb2je3+w3 tO5veNVfluy3hpds3X+xeu0vd4yVfxKPZkVCM/FjkfHklbT3oUkscPtL/HdAZVjEchxHjz+0EBMN foj/rcV/xthnYX9MUQRMAiNAsoyzZ1bhWGul2cPtjx/6m2RDs4zlT8iQ50nWrFH8XOTsNv7XyRxC tI8hQiiz+GkpvOeFQJWWrNr0d4w8ERROQptKmHFlqRK6o6tMPFWkqIpbtl2xkudP/XdVsWVXQt+V 7JkXTZWJHgBYaymZ1V/Ol+fT18dY4GD5Wmlyf/tlYfgkuDEuQ/fAql2RV2z5+PHT8g4aIK+N+7Is hN8dTX5lInd7Xm+UnplklRRr8dN3XYxzxUTdfg5xV/LvCPpBzIjtB4MZkWZHmhaXeMTu3/LIymeU 7M87VtKaF6e+9QS4bx5ARCBQrTbxqKwSijWrWVJXKks522i+KOrfhPFn1GnI2xX5Lo8dom7RAWKp SXlVNUxpBUj6679SnjWoIwb9RseNfg1vNGCT1zzBxYTsvQBrAWWJN7Nyy3Nas0o0VjxsbswaFaK7 PbiYTM5hGvsUeRcC73KnrPxc7o7EqwSTFllW7IHM3o8bQO5pSG/QDkzX0u/eGQs8aA5szeEozTQE olrM2xLn1gUqflmp4Q/2Js7CqUMHcRnO9N58yxBZnhRNDh2EytVfbWmWFuUWTSGt65KvmhoNFEU5 yo/0DdNbPOX8P8gSfjRUoc02UvUr38krTgEAUYnAsm52WTs4CsvZDpKpeCLRVMq4S2xFzrcw+7Qu ylc1gGF/bWFm8K7GQYnx4fkzzbiiHGKcaTVgGaPFd2nCR+LnraasyRU9gYJscvayg32hZvzDlmtW 9esO88VZen6Qh8v+I4ZrWBPQiJ9u7wYJ/KM93n3++mN8/zDg6TmvIznhXETSbyUpbjG1lkA0SGFy aV+oVzfGOKC0Vl5WU0ZHgjqzt3tSv3TjTQrfyfU6sdx3ZZGwNYaWAlQRTnG+6Q9q8BAoGcQh0du8 5hsJPVwIzFxUVK5IkkbEnqL5Zi90u0M8ztVnupmyrgs2Wsdops2LOa4novPV4+u2RPWrctlcH8Ll euIKlVisajpBhT88CvaERQH5R3ocV0cSCM2qSmCrINwTT45b+ArYYxXLt6jARVOrxewgpbj7aFYV 6Ll8razJSHZKZSyFPOirNUl2grmBuFUE+DcKWHmOKACfCB4paFr2Os7N/cuOgy58339hB4I4dyXP RD/apul24OyA+IddIaHCfy3CkLiKjfLTF4oq4di/HNhjtE786X2i3gAfW2mZI2b9UNK07t7WI1Hi bV/mK5BKRIfEwa3Ui50DyzkJs8GG7f7s45oNpHXrE5XTz0ldwDxIWT9kyBmlaKC2VEmSSPjShYlU YHeeOyeDgOUYf56RU6eDB1LyYvzWvEqaqkLmyM0j6DR+0vrKBXMJDbeawybo+2/SEzMUkaDUDVlh JAQoouVcjGZLTucyjlvzxG4jDpMPHrMhSZvo09fHWBYJVaUK5LqEQglctYZoEuThm9XeZ5GxtMmy iQ2iVnoz1SxypBqHpT0qPTkScJnW6G3Xq7vjGC3vNqBZGV5gZdHka/XSmi5lxeElNQqjnTxaoiMe 6sL720NQX4zLcA9jP6hccS+vPrRIyxkeWTFQDhdop01/Er204asD3LZDEBbRIgjETIPgDQs9UU9V 8dgfl0E7HSQnSn9I7KzYRoMjceTvGKGSGVOD0zLBsOqTE7Ni6kTJI1JfTVynEXkY4vzfjMp1SEfp +v+QvMmQTBcfDYsc9+/bLR/VxzApzcf6oC0wOt3293Ay4+kQ88+QpUT6xiXuzwvkmdZXFpLn665e 6ER2WOHSGlRLjekhycUJKCuAolDJoW92lxX6PtYsvf1USa55DokCWw8iW/dMuLbaQ4BDHCvUS6al 2vextoxjF56OU82ySBSFIKFN/XjpRhbxnDDUg9AitglW8VYzuyfat3dVtuyu8l9oW3pw/hu457p2 MI30IAiJH9q67YOO93Xh/J963rofO22Beo4/dNo6eTr6+MeUZQSWnmx5aEW/tW+vAFK8126Ybkd6 keq+J8M+Jgwo3jum7ADaFKBH2bVcYgVSfs1TfieBOmDiRzpkI7A8AbObGLNDaFlLy1zCYcVpERpO QFx8+rPcLiObup4JwHJs4jvhIAAlJB9OT3bkI0SHlO/mUx6AAzv0R4EcmuL9crnf7wlndUqK8m2A Wq5JvNZyiPRMc1iuD3a+ZEd6jlry9rC7gBlktbFuL2gK/+pqebhZQFj2TffVAgSAfWNs6MIl4c3z woIzHc9ZbpzG7xigHUUQm3WMsA0w8i4JsLWzLTMal2J3phiOFUDbB6O2glbvgmQvLfiW5YxF+5/R AWTH8Ujoe6eiQEtAY18A2YHcuqFzbfM4nk081x41j9MZGxXfGpZN6pdTi/93AMx1TCMKZW5kc3Ry ZWFtDWVuZG9iag04NSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk4IDAgUiANL1Jl c291cmNlcyA4NiAwIFIgDS9Db250ZW50cyA4NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzky IF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTg2IDAg b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9U VDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNl IDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag04NyAwIG9iag08PCAvTGVuZ3RoIDI2OTUg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV22TmsgW/u6fuFQ+6VZAXhR0q/aD yZjEO5mXG7m5uzWmUojtyAYbQ4POVOXH34MgfRobRrKJVSmaobuf85znvPXfMlvxmWIcf8ynnf77 uaE8so6h6bqhOGNTsQ1dGzkjRXXG8DAYKTHprDtv3E7fdU3Y5a47I208Hg0VHX7F49DSxo7hKI6l a2NLNxV329GPH2SXqDqcDse7Prx0D52H7r96qulY2kDyME99nzBWrnee/40k5ZLsCS0Xwbp8TDak fGYk3pO4XHop/JEmge8lQcQ3Hzx+CcsvXadh+Jy9HOmaCZC+uP8GxKqhGZZlKe5VM3I/2u5CkpCV VrwaFke4v2V2+x1Yun9nK0TIQ3eg2Vp5xjV5Lp/fE0pijPmy8xoQupsA2Ux8gQ+2I36wDgj/YhMd yudv5Dmgj+Vy6yUkDryQu4Jve8xxFzwAlYYUd06saTsZsZdacMfxTif3XDSzm/I5c2KN71/z9+XT jccSJBbsgEX35nrRk5m4AuP3ZMXvjKPtT+sGSzelcHQoUP1+flNjTvl674Up8tuie+1jx7FF77X0 ttu727fTrzcuP7+n2prTpSfLkOIaTYjgVM5hTEKy9ygPWj+iCXniaxR56ygMowNrlkoLid9cl49/ cHl8mBiL7myVUZc8/6C/Xfs/zkjgbz6TmGF6PwYs4X+dg3V+gpxffL7o5eT9qmCdUanP1lG8TUOu X28Z7Yncva9+vOIu2Hix52OlAxtRglQDTgJZEXqU1skf5oUCOHFbezrGtSMIRlDdyZIYy/8QJJso Rdqh/FMwZxtkgPPvW+ClOEmU3DCeiGf8xkBuxRnwUxI4+3Lifp1dTW/dmfsXNyMBM5dpQupE0wi/ 9qoQshnOkOonwnYRZaQPKbI/T7yY/zmvrFw6UcyfUWWVoS9qpxiwzYRH/OKUkZVcsZdzCrblzHEL zzSYG8h96pb7L+X5JXEiaQTUD9MVSgseUwPGzWzSMQiQPqJg8eiqci5X+KWECwEXMRYswwaeV8SP Yh75FbqO7hNLTpZDLwp2WuIuN5zYFzqARmMqBY6nKt5siXgrBZAzG6NaywimWYqeeVu+iOIVbisF e6VhfHkP8Glye4XlEIZEUASCB/EofF1mEs7EWV1vclDxcW6AW7HgJZUdHVOuFkKYV1LgebNxAl6+ WaL4+Dtl8qMoOJ+IABY9rILckrahLiv61eCWE2iqy2dkBEt3uyjGDcK+cjRNt0t4dZbkWkQ38Pl5 +mk+u7v9+nE2d1Hi/ic6rtksURiOtbwhKlhv2zlWaa8ptlWOqz1YlWKhbgBZ8+nH6Vt3enViTdJv NsK8Jckhir9xpWI0Ip/IArHQCYpuwTqT077x2KalFeuUijMfNMaqIUN+GgalCfIBthXF1/iCWqY1 8g84BE2HUK3PGpBLFRJHMBQBFbt2Wdyj1dvLNXnKC67Qg8idcEparwumL+0vG7MJLu9n00Sjkpta PUmHl1GXO6ptWFYZfi0FL/QYMdkHUcougLSSezJ4pFFcFHSRalg4WRHNpijpGPXBA9oCSqicYw9G TPJ8buX0aRfEhP3O04zDk8YuDkJutqnrgyMc09FsRc8KuoAK/8sQjrRB/pWA8+Hee+QGW9YXadug WjbujND4KDQU8olyRmGQoYQzfhV76+R4bolJijw7zJZgBj9yJlEUTdIsapLAPzaGxwsMSzOrNzyU V5i9fKPTO7kh22Nrskvv/CSCGinwn3NlnZE1gEsRLYgu4EZOUoPycYq9gRBDmf0aaQjlyrWQgJKI a7B8umckXUWngQW0iWI67wbK5btqjl507z+9W/RaBvBhE/ibcvVIKORj3AEysvOyN9zu2KMsAIfi AMamM4TInV6zEhIwEHH8uxg6TbCgHFguTZl1OsunODRJodJ5IGEoe8+Zr7hwTpiQXbFLF92b+XWN VWFAv7UstqH3jC5mxE9jPHHhBIVr1RPMNXiMbGXAtN6CCKI1lqablwzZpTEMkLgNueP3x0T1hEQg FFVuPu4/M/Vw+/475yPBsqauF4a0YF+U4ZnAzkSFRw+uHkoOHOj8Wu486ddT/HmdjdA2BvufbJxr +4IoDh4DipqvGzlujPY4RXGfnBokaWOF74qLuVfF825Rtpr7C0EzWsV2vT6fX5rG67JJTL6nWc3n 5hx4whaEiYMnSPj76MC5OIWGXPSikT8Ve99QeF9/9ZBIUZ2pi5pDkGykwGAgupm85ThPk8bLXR6h fvy8+0XmZIe9/lUGTW/ffvp6NXEn52bJ56dTSmpRokQPYI5yY7Cd7aaVdYoLmaAb6X0sXTJQchF+ tPVMVc3aKLmfH1VtF1uGIi5Rx4wnmoU6qaWH6Ylqck5j+1R0OvgCYZY9lpCS+Ev5up2hBP6OrITh dkYhVWzFO+/jyM8qNSo/MAfRlRevcB/1bnY/R/X6Pl2GyOstlGmMbNUsVw/QMX6Rq3537ETVi0jE CZDJ6awpDi0KdV5pOJIIJMmXBiILRgC+LAaEcj1ENEZrkQl0xiR8hPqYbLjpxqLHmZqwlugvIeMC MxfQkKC/OoNFjyfGwwbNtRIDZE7K8ow0Q7co0bJ2OldGqBaF7ydlJS+Xr7YRp/H7q4onhJ6gETi0 y1uZO6CP3pULS7NkvEXbIEnISh476+po9v7FvC60A9h1eR5iFe+8GCyQqZM49RN02z7g7plnUwa/ 8YPHeL085R+ZgxtlPNntYCQJnqrcHU0oY+1SE4SpoIDE6Z7x8so2URpyQEsheAhuT7xEenqDu5DH 9yTm5YkF2yDM48aL2xrG+5f5h4lqyGcLDHALFQKH/c5brXDFQChXwXpNYqjXnKr7kHgMt+JrFGo5 mBaJTEyUuPcVWpMVSbwgRN3CO/QlqHNPaACdEJFHeHN6KOIjp79McJfSX9sb+lEcwyTIWY+AzGpv haj2g6QmDiglPAjeiB2TSPU/7JgMW1eXAYf85/X0L04TagP//Dz5yJUsDnHVtpO7hKFOu3z6A9/O bbvj9hPP5wyfVIHsnrodQ8l+zKedoaWNHVNxxqYy1OHZsCF/Q+IwRkpMOuvOG7fTd90BfO2uO4ah jccjRYdf8TgYG9rQGo0UZ2Ropg673G1HP36RnX4k0jCPBN97Gbtw+Xe4PlA6+dax4jgjzR6ZimmD M2yFX/4/hWbXn1+aAR1advXS7JLH4o7/1O0cw86huDP3tp3tz54AknvodIli6Uq0VuyhCLsgDGrc sKAsB61z0GfsGgPNcAR+9RO/tUAt2GKPFWDDMYYc5lGU+hGhYfQNvQ/dlpUhVC1HGwzgBCi7Oe2D IyObJGkwwLBMzbZGFQOkkGxbs82xjRDllO+aKXfgAnNknxmSi+L3fv9wOGgBSdZaFP8aoMZA14bZ zirSF8RhDGzYZwv7tDIN9AMKDUsPsiFJ1FX24K3hv4T180VPzaaA46sedEBmV914vYE26u57Rhem KUqoegq/wkBzPAbbjMLCzMDx8BIDs32moY/PXbF7wRmW4YDsnTNZmePcSPKUgc9ShdrL/ideBbJl DbWRPTw5BSQBwr4AsgXcDkZWW/FYQ1MbDswz8eQpW4U2QDVMLXk6Sfz/AwAW363tCmVuZHN0cmVh bQ1lbmRvYmoNODggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OSAwIFIgDS9SZXNv dXJjZXMgODkgMCBSIA0vQ29udGVudHMgOTAgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04OSAwIG9i ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0 IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8 PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNOTAgMCBvYmoNPDwgL0xlbmd0aCAyNTkxIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFdrc9rIEv3On4i+BW5ZQg+QIFX3g2Oz u1xfJ75G+6o45RrEYGYtJFYjGTuVH39bDzQ9YsDCm7ji0sia6dPdp/v09C+4qwVcs4ofHkSd/s8z S3vgHcswTUvzxrbmWqYx8kaa7o3hYTDSEtpZdj76nb7v27DLX3ZGxng8Gmom/FSPQ8cYe5aneY5p jB3T1vx1xyw+yI3oJpwOx/sBvPS3nS/ddz3d9hxjoHggWbqiUcoCkrI4Oqvfw9v6+ZrwlCb18oq+ 1M+M148ZpwtxLFeexCKWMhLWa06DhKZoSRc93TW8rv6u99X/D+DXLcNyHEfzL4/78YhA/XE1+dOo Vz6yH29yLxEAAJ0gdJtMgHkiYUaFG3fdP2aTyeX9X3c9tEFAT+mmXjiGJSKR0NKl6s2wW7rm/+u4 QxzFJY3rx280iY3m1+hM04AXTp777rv8X8//K3+NOHHUKg5WQnkWpix6EH7Zpj5nAldCokW8rpdR tp7TRITs+d48QwtLLAzDwH9ZV0mXoobAtYlXEEfAYRrBf0TDSDxvSJKyPP3o7yxCoeUZS8k8rNKl c/YNfRmssuiRKw9WE79tnoG4HOFRls0yDsN4izMRJwuafBAleU+jQBD5rmvZo3oFGeN3vTP0MUE0 P/jtCKjUxWVou96rZdhoFTPKOURc2Truuu5A2H1JqQRy8gy5XKDAvuHkPQ/aNJIKCa6xH1NanwXY hOpt+i4na7HYcJot4oqbysKrlw80oglJY/EmIML4fHdmW4ZK/Eb1UpkREIkARLdvSRyuKnzEtJQN 9q0IViO1r8H/jQYQCq4WhFxx5I4vqch7ldAFJAyyUO4z4q9lrfIPFUoL8aekTkWbJpuK947hgogD RSVSyUj+LUL5y7l1150uch6lL9+DOIsg0t8/ff50MbmffRcZuCo1C8HRc0uoJGRsbSk9PdSukjUE SERnHj9RNcV34OsXsI5Tqp4edkraKJ4ThYJVJgWgLUtXMWqJJBJ4IKBrBqKCm2+UhWKCCFYkIQF8 xsWBywQVZ+WBzIWjCM/9++nl5JM/9f8UmNI0YfMMVVu8VAZpcn5TRemW8k0ccdqfTa/7sxTkD2lh 8EhTAThOxDPbndu2P4DFY7a2qDggt+q2EkevZVnFnx3C9vrEmnzjEFaUWlXm9p3cY20ZT3WLqcqy wYH2gnSsItDZig4mOQOkuvj86yd/cnuEU1JODgwjk/MyPzd6O3pI1LhtKt+pIWw2YwXiEyotouk2 Th4l8UdFATOWAFS11VZ5sdyKw9KBzRMOZuvQPK9qz7+QJwoUpiKSWEVnBMQIKazI4vOGwYAvRkjb E1TZJCwU9Wab5qCAY3s7edoTr92/HOHIGChE7MsNeRDOOoOvyluR7hyRJbU+TXNqROi2dJmQZVqc ViNR4s0PU8ktlLqI3/RahEUibmHAcgy7aeFLbcLulRu9HtYnV6nxn2FIgRlOinoZIWcvRAMwemKQ jtQA5i00iSZJ39okhAr9nVGe7qq/XV2+oUdcX6naA8bUGETx4AmFzp7UciTk+/Tb0CahAV1I+oJH B9lLtVv/aOxnzctoe9VJMhGCfD5SRhTP6K9N0oLZuD/J4x3PQmnQcmxz10eZqO9GFFp2+iJWghjP 9+YZWlhiYRgG/statwTyBGtSBHmjkXwPQK5tYAhieWKlainvTydIlDuQRSRYZdEjV1qUCpOoiwCn zB2oVOpN97W2s+JhKDKIyTOEdoHceR2VIVlrXL0a/f/EFokLcskSLrjo2NLsIGJ+YDq/nok2FRCB f36gvR7I4g1hyZbxw72tTGydqrbpueve7C6LpbOomUwnk0m9GJm2YVnM2D//bTfJ31dULSS355fT XxVqJOLCNzRgS6bWpC+3P10ISR0ORl+VxSzFvC5Ruy2poSPBjIvuPI/0BfexNTSJhJFQusOo/f0h 9DoBexAnSTGgN/2vztOvb24m+u3k4jcduvirPZzTAB91EL9ko+pChaVTJXY2+XSZIxPVP8WBRaNA QDhFN94oFH3MHbwe5gMpRaXTSERZRm+68jWpiVvbjyuzal7AXmEXWATqhRzcH5/OlPtWhItpYZlF gTTCKa5uRYhIc1SRunYxUxNpjHYUQ/SaPcvDVsM4Yl0Qr+dwa0LEhWsU8pY3BAbSz1Gur4L3HPXJ KpR0ceBS0zrz8xdlTH+eiWvIodk4iWHWzBBzDs5ZR6fIcv6/9pWevNZNdvNNaV8EE7IS0mOxlYZf 7ENyOEUJJTyORFawWOWVL535JneCDJpjlCrTcJQgGDYR+9cx6u246bCUi2LiIoTpVjwj79YxOl+S gkr31yc6ivFGMMjvqaHEckWGwzh6QCSSMvpRcDrjuD7FdhiSKxHYEvH1sfptq25yleMyyBMmgr5V c45wDiWF6wilE/iIGptIA5rrYF7J76wodSQiD6jv1S61TVVISRLhwKmJgEbp85v+bHqcuCIO6J61 jbNwEb0XL1Y03IgFEy2kHLhOmDoKJw4JT5ywBxahQsdllzdepdaTxaK4baE6YlEgTt1iZQvCbLHH ihPwt2uhjfjsORqQMMhCIqPGH2woOhUpJ5mjbro3rrYfnqCfsiVWHETuBoXqZ0ylTc7tVOBC5Elo QNkTGqWWCQqYfA2ELpc8Nstvz6E28rmEWVYMH1gAo1hgIwjlJiSoVcH9B6jJseagXhCizjyjcmsa G3vz3vEpbSisXkNFQlOo1z/FyRplArtxk8RpHMSiNibPKY04m7OQpS8nArBaQvjHt7vztrc1INpX UQqYdk2qzekD2rhlqUg7JtdFvEBD/3SRD05gPSnVpu57bZvvf2n0kK7OlKnxXzb4GkfDBZaXFQsQ MZHCLOMwjLcoHmgExAFY03QVL5pxDJRzzcTvWFr+w4OoM3SMsWdr3tjWhiY8Wy6Uk2M41khLaGfZ +eh3+r4/gK/9ZceyjPF4BKO1qVWPg7FlDJ3RSPNGlmGbsMtfd8zii/z0ggKWXdDihuS8AON/g3mm dcqtY83zRoY7sjXbhYHe1YTx37UoN79vNAc6dNym0dzIQ2Xjf4d2jmHnUN5Z8tTN9+dPAMnfdrpU cywtXmruUIZdBQxazrAKWQnaFKD3omsNDMuT4mvu4nsQqANb3LEG0fCsoYBZlJNZILSsvmX2bUCc I9QdzxgM0LXHGhQRWaXpEQcsxzZcZ9RwQAnJdQ3XHrsIURnyzfGQe2DAHrl7jpSk+NDvb7dbg9F0 acTJjwFqDUxjmO9sIn2FHNbAhX2utM+oG1gfbi/QGQpF0hf5A1nCr5T3y0VPzyWpeNUDQbK7+or0 Bsao+9SzuqCkEY30XflVDtrjMfhmVR7mDo6HbRzM99mWOd5PxeaVZDiWB7T39mhlj0sn6XMOPtcI vZf/pqQB2XGGxsgd7pIClABit4DsQGwHI+dU8jhD2xgO7D3yOMVmnbO1btlG+ryj+P8HAC1nJ/8K ZW5kc3RyZWFtDWVuZG9iag05MSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk5IDAg UiANL1Jlc291cmNlcyA5MiAwIFIgDS9Db250ZW50cyA5MyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq DTkyIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkg MCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xv clNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag05MyAwIG9iag08PCAvTGVuZ3Ro IDE5MzkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV0tz2zYQvvNPhEerCSEC 4DM35zGtO800jdnm4MmBIiGJDQUqJGXZnf74AnwBJEFKjp2ZtFNrxgOQxO63u98+sHxdOHpU6LD6 FRHVlj9eQ31TaBCYJtRdH+kONIHnerrh+mxheXpOtLX2KtCWQYDYqWCtecD3PVs32a9Z2hj4LnR1 F5vAxybSg51mVh9wJYbJpDPxQcQeBkft5uLZwkAuBpZiEdzvifEmLEMgHm1Jt36dxWKzTkgad7uE dstSOvH28n233pIwJrk4UXTLgpTidNYtodCV5UORngkgA/4p+JnZZUAAMcZ68Gbevpx8OZCiLF50 T0Iaq1SjOdXV+gMp9hktSKF21aEIN2KXrZXe+YXQTbkdYmGWocay4Id5e65iQsuERSLvh6V4RFzC XHwWpoXwSbEnEdelDPoNk/hJuOJqYTjAvaALswVrn2kSk7O8vnr3Qgmb83OKgKfp5IGeOolBDJTJ M4Rtgz/5Tsqa+QDQ84FXidU9WZFNQgXmY9IjwlDqVLDKbViObZmFHDHWJiwHVOQU8KCRRaXkx+vD qpx2vpxFQgaqSTCQlJOC5LcSiypRbWjsXk4jxz2Z03LWDVHehinLdykp1eQdOllOgZisE6o+dk2i MsnE3huVAimVzy9SrOLsQnV8zk1huaj1j8yRSTa72GZHYdmKpNkRjItTP2keuWCSXe4eLlGZhz+F tyRnwaBKQ69DhpHcKyrK3T5hpHspeOl2y8t9nqQiZZFpWpVtyAUOa6AsVD1U8h9H6AGr/qqH8+a9 XPux/anOgwHDDezIlJBc2eO+/Kj5tKfsipYkp1J+vcnDdVlp6NApbeBiHQV6mVcyWS4PjEqs20Qh J32lAGKAhhpuOhVoUR90F21A+BkHqJT+GpXZiuS9SNRewyO3WUyp2nFqNjWIzBbG+A9Ov0LTr3Bn VxNeUX17+jrpnazupNUu7HbhtIvOa1678NvFf0My95onvHbRchIpc+q5MftrOs2Jr4znUnWoyMSV yVwakOZvOfo1fUfYqqm4B3ycDEJOJcRWmCjNclJmDkT18LR5zCX6iqxqxksuDY+r2U2f0kyyU7G4 zTIs++XfGxw+eJ0dnGfTJaodLbgsa6rqKcIzHZ0PzRxUS/Tm4zMOD3C+4wA1MWkq8URnO3fGlgc8 1sdFp5sYjLpZW3STZLcjcRKWJBXzwTpL2cCQ0M0DRqUXg1n7/KFuduouyzxZHUppUm3n+tFcRmjE yo1yHOV2C5Pr5Bf7P/goPJ7gzphE1RfcdbI5SLiqCbE3PRZKv24IZTNcNFCh9AodOwgoJ6nRIKrI om/b/b1R9/+//09IriMofN7r/3XNwMoR8Ukq2LiGDQrpfHto4LptuX5Ypxk3mq/r2YNpwlKguanz HQAwqFgGsqYM/u4i0OsiT9pSLtuC0iueg7JiTt8yHuC0KxrzKxNRl8N9mLMb1SENc/FaIFF3CXU9 DkcmtYKkgn/K1zN23HI+CSPknpSyxqZuSdck4pfFbu+N6DgE1HPzueGsk2bAq5mu8MigpX11vTEk KWYiInlmd0jLZJ8S5UCwzg7500Vudc8MUZNmF94lu8PuDMtU3VjYJayAJrLEUKDUPBf+860aQE1o lB7iiYDNpju3LZ6ikrDgyUnbDWSTnO2Vtge4JpgvMDEbjYXtRZFFfDIWLjgmkgPUjJZjKr1nl9c0 7pzVvbAfH+0wPYb3xTDasTKEiRgnd6GY91dSZTxmguPCMbtMHmjv5fSXMrcmnorVT5Cr5RQvB3Sv PC3gxaQk+S6hkonyqN6fsWfEjm9UT9g8+uDBKXJ8VVJdjq9S9LBbkXzAbymesqfykG7EzpS+ybPD RvgJIlfZCaMwTSVNNKPNWHTefav4nOz34SpVdHWpjH7cEqkYi+XwyronRHCb3xsPlLFEyuZvgVNy mUS53sgjw4ozOVKZOJGTKNvQ5C/pRjsp5N3v1zX8YMCpk3YQKRVk8cyVxgdS7DNaEO7T5es0IbRs nPQ2z6WqsQ+jz0QAP26TSCqfVVpOTBItzLeBBnX+KyKq2Rj4LtJdH+m2ydaQZwUGGHp6TrS19irQ lkFgsa+DtQYh8H0+/Zt6s7R8CGzsebrrQYBMdirYaWb1BZde5RFEVW69D3lyMeVfmPpE1+qjvu66 HnA8pCOHJbijC+UfdcrVj5VyoDZ2hkq5kk2j47epkz47afdP1snu8PN8xSAFR+2C6Bjp2Vp37D7s xmGsctiNy2rQpgA98i60AHR7/jVb/04CxeyI4+vMGy60BcyqJpkVQgiX0FwihpgjNLALLEsqhtCq PLItyxkDIEbAwd7AACUkxwEO8h0JUe3y/bzLXaYAec7IkJoUL5fL4/EIElKuQZY/DVBomcDmJ4dI T5ADWg475/TOga4LLBNezhasbJDSiPkiXLN/ZbGsNwuDt67q0YL1FXRhbMOFBbyL2wW8IDlrltRo 068xEPk+sw02FnIDffscA/k5BE1/HIr9iWBg6DLauyNaIb82ktxx8HyaMhb8PwkHkDG2gefYbVAY JRixz4CMmW8tDz+UPNhGwLbQiDz1GGAUyc6ACJR3LcX/GQBqTQ1uCmVuZHN0cmVhbQ1lbmRvYmoN OTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OSAwIFIgDS9SZXNvdXJjZXMgOTUg MCBSIA0vQ29udGVudHMgOTYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJv eCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag05NSAwIG9iag08PCANL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIx MCAwIFIgPj4gDT4+IA1lbmRvYmoNOTYgMCBvYmoNPDwgL0xlbmd0aCAyMjYzIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFfbcqNIEn3XTwyP1kYLcRG3eXNP9257Y9zuGeOYh56O iTIqSbWNgKkqLGu/fhOQqARKF7xtIhyAqMrMk5nnZM1/Eb6RCMOuL5Fkk/m/Hm1jLSa2aVm2EUSO 4duWGQahMQsiuFmEBqeT1eR9PJnHsQOr4tUkNKMo9AwLrsOt55pRYAdG4Fpm5FqOEW8nVv1BZWRm we6wfZzAy3g3+Xrz03TmBK650NyQUm5oJllCJMuz9jV9TTYkW1OzfXO3UmvUdx9vv8wf7+7bZ0H5 C+VqmyzJy0xSLtTi9i7Ls+nMN4Ob2U/Tb/G/wdmZbdqu6xrxh/NOi++sKMhzStWuUnL2XEr1Rm6I RA/0lIvLnArkklrDaZKvM/Zf+g5vk/X3DC3TuWkCiP9xwe2uZUGzpdC6CKi29/8kLC25+q0gyXeq vNxtWLJRm1C+ZRmRdLAvuGlf6eaVJeGp7ayq1uAx/k/1hOrvrJ3bY86UszsmN2wAcZOOynb7lKtq tJ0QLeB5uVZ4OJ6nwkIgJiRN6XJQT0050mGA5/Fq41Dd8geuFDIwdK5wmYKjbR/ka6eu2aB0UTk2 /eT4wcV+aktdmWFaI2yd5eCMijPGGaJC6hKEs0iGOSeZsrqlQpB1v6+uJ4YlkQrs+6fHWCEvWZq2 T8+on3iegNVTQf1Ks7VUBbViNF1eHSSCsCmtS60DMQdVmNUrbTt9IsAgLMPFheB7JGm+o/shLh9f Cwbp+Vk1RqDasOAsVRznWNaids4JTB8UBSDveIX/Kg9Dc9F81fHz6xeCutX1v2njn7k+Tm0XCz2f 3FXtkCEC/MDJSta7tZ5o/a028zWeYq7FSnbbYcHagO2aTt/C19aEM20WBtMj+NUa39QZfUhk/kx5 B/UGIXcA0QKMjgTpTIeUAnNJ3mGmK4v5haQlKm1VioISngB/r1W75Fy7aUZfj2x1tSod/TivPx3S uxaUpywFClBtDa7yHRNoZihowqD3l++04eR8iXT9eupjuI3fTHr9GQyR6IC/MwEUDpEkJJPI9rLn h3Zfti1SuoWeaOeCMbPPJi8Rc+JBiwhRbhFOSqUplwRh1IUZFS+i8/LI5N3S+mETSoIAQmZBqUkh yhRGLxVkb5qpy+rs1HCn+XgExjsASOgrtNuzJ1UMBaeZqPcFvYRD2yi9NI1o9CTPulm/ANt1c6hn OgrnLzyXeZKreeDjq6TQGs8sZXI/at8RfXmqdCrbS4TY874H5x5TakZ3F3Ik+oe2MW16ekBFExvv 9psqOf3UWOQCsEV7otZtotfWbFFnqZHFNlfXDuVV7+WlcueZU/Id45ijDugyG8LvE4xTL1inSbY/ nwmhpfFrhnCyXOqluXcynP1O/y5h1K5qa/4oCUdDN8cfNsjB56KAoKjm++YsKXrQXq88u5Oc/owH BEnXXPVVk1iayN7IzSlMC7RDX0iBD6Kmiqoz3X9uYn2Ie6FcqpJzbXjiHJqUnFMknlAe4iCHfTY9 EMAPk6POofJaahDa7uzJMcIBsnjqtNkntGXewE77FXQJdlwpoiyKHNVkf3pZcbJuWxN1Jigu1Wud gIOs0OWjO4HuRlIjbTQCWklfgwjDlG0ZRlHkekCxQ1vyyrblVv3GSSZWSPnKDOXvz5v7+OnP6alT 5dlATiBSQvXztFNQ1WlSOZCSPXpC/I7TSV8TSpe4tW+TBOYSvC3itq9QU9/evSkMjXPKpW0pEM3x /IUtkaR1ZlyVzfhJh5FtOZZK8h4LIeLbNeiLxEohjnPPtfWFpUVTawi0fh8+fnp4+vWDIsOHuJeO U1JybegjprcaIBO9/0FHtPc0IaWgJzE40IjCq8/LGV3nktUs8g693PUXnGOONx3Piv6wiedAkgrt MWY4R6OpsBS4m8i5aNRv5faZcrMXxXkp8lUe7/vy+39KWbxB/CFgGMC+HoMXffyxQAgEh161sfzW L+6k3sSYIxaWYNL3CZH5XpfVmtNBGrA2IA4hSUILiefp3YYlG/W7bhQ/SPBI8iRpRZ9a2AZRjXJH BcthTGV8jI1RZIkQ7BwQ+6k4ZDppXywpHC9T0Zk9FY3TjHKSntwNRtQtEnA2tn6GfY1Qeez1gWfa 4w65vlpw/qig3+5NxHyn/F2VqUKOlJCWTLKEdGLCnbxiHKl0h837ScNidQiql4TjZ4dTz1iWHiCl r48Dp/TOUTyH4QmaodD51KGnFWp3uRs7IhQlL3KB9XU0+six5vR30WU0ePAe8nLzNvYpKGpYtL+g mX5WuY3/+vzw+ZePf92r0aalH91OnfMA5S8H6etjRpZLVk8Eb5pACZKwMX29MB39yUVTVUg7UHmd 0JdO3tDAIJvwNmPz1CCnLd78GVg060z1KJBOgmH0hkqUe3QkUMAtmUhKcULBh8A1gbTwXR/IS4fW NUCLS+Ce0zM44OgruoFJo3svJGVLhNehkfjIwIbY6oj9YzyxjeoSSTbxXDMKHCOIHMOz4N72gSRd 07VDg9PJavI+nszjeAFfx6uJbZtRFBoWXIfbRWSbnhuGRhDapmPBqng7seovqt1r2bCd2vYXcjD+ N5hnxqRZGhlBEJp+6BiObzqBbyjjfxhZZX5otHLUc/2+0crI+mDjt1MrI1jpdVc22uZX66s7cCne TW6oATqRrwzf67p9AAyExDtA1jhtKacH6NoL0w46+FpHfE866sISPzIAjcD2lJu1BFu1h7Y9t625 Ax5XHs7cwFwsYIejWtuLGpGNlGcCsF3H9N2wF4DWJd83fSfykUcN5MV5yAMw4IT+IJCmKH6ez3e7 ncmoXJk5/zGO2gvL9KqVfU8vFIe98GGd31lntkPPnGWS8ml1rpKzZXVDVvBPinnzMJ1Vyl2/msKY 4dzMNmS6MMObl6kNncwyms3qZlQBOlEEsdmHCKsAI++aAKt1jm1Fw1QUF5Lh2gGUfTAoKydqgqSv lfOWad/MptV/Snouu65nhr53TAqUBBT2FS67gO0idMcWj+s5prdwBsXj1otngm1ntmPK12OJ/28A 6tFPHgplbmRzdHJlYW0NZW5kb2JqDTk3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAx OTkgMCBSIA0vUmVzb3VyY2VzIDk4IDAgUiANL0NvbnRlbnRzIDk5IDAgUiANL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1l bmRvYmoNOTggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQy IDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiAN L0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTk5IDAgb2JqDTw8IC9M ZW5ndGggMTgzMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexXa1PjNhT97j9R fyvpYMWy/NxvKaTddCCwxLudHXaHMUYGtcHO+kHYf1/JdiLJj8RhaacvMsPID0nnHp177vX4JLPV MFNh+cvCWBn/vIDqfaZAoOtQdTxDtaEOXMdVNcejA9NVU6xEyo++MvZ9g87yI8UFnudaqk5/9dBC wHOgozpIBx7SDdV/VPTyBbaJptPV6fJ+SG/6a+X66LuRZjgImB0D/wFvxxlOn3C6vTx/v/C3F8Fy HXzNtpckDpfFHZ+aC8tM/JsP06vF7GJ+czYTl8jzlNwWOQbslqsDg8L47P9CUWoQQISQ6p8yyKFC H/i/Kf4PfEDfdtgL7NnmnhDo9dHbgGInMY75fvHddrwIlskaf23HP31ekRRnb7Y3DIcHskrJ8pg/ 0XWzxGs4wKZcM7AiKvGPIXSBWb0l4by+DO45V8j5PNJs4GwAWTUlGrL3kVKxZthOa4tZnOM0xvl2 l9M0iPJy3S2mTuRsWbsD83RyyZmcnXOCCnrucU7CICdJXG4AETCaO1xvtzBG1URntDkGNscGXZte hHlyi1OJ/4or1CLLpJvu15C0/AtzYvKxNweSWBhHnakRJUuqQxLf80XuGIE5V2aKvxQ4y+t3aJbA OkoawE7U2/QSxExT8XJ6dT6ZT+f+zez05mr67lh8+NP7s7PJe/9t61mdOwdsT1ebzD/WCwGRy0y0 iRTjDsT8VsofPxZ5ESyXnBr8TAnPyBPmOLOEr12JY8u2NRD4LtebX/i9x/2YpGJgATeeAULgoQMJ kUy4rOOh8p11b9mI8yHgrKc4xJRWbpeB8ChbJbFwhFGaPHauv8JispJ8J6OC++87H5JlBe5AFuM1 d/HJpXZVJc6YGtR4kQcpB7AKwt8FNyRRF0qRD0xoYJyqVYqfSFJklRQPyIkSusBqPBDwI84ysUqs KZ6kyIWFeFKIBnIANNlm+tIxSSUMfeW+6TH7S74s7v5S9u+RudTk/LWC33V03LMbh36Y9TcKyS5N 7U8/Od/2Z1Jl/NowsIdlXR9te+P938z/btp+SSvVJdqBx/APEHFH7rcM+5sF7D+QrBfd4GaLoj2f nEi96+wDvxTqFH0ynZ9c3ZxO/MnuqtMMwgYGEE+EirBKlxbNm9ZSqlutelZ7/Uu+Olj6CSKL77Jh wBhx/dme82aZZ95TsCR34uqvJMRea6ly5tX0JRhk/dFSKSIWE29X9n4vc1uF3x9XrUyhR+rq9od+ fIhw9nwKNurpsbhG3LmgpCIp1ZrpRWdVcR8In6XhKe37Zv7HHgtpSbuQDED4PKrXEpcSnOMORyQW zFPQ+QKHOangJ/GBAZhizn+z00l+Nb+Yn0xvzv02Mfvt7xY3j0qIvFvMjaM4oCZLJUJsFrSgYNrK SRjkJOGEt4RKpLJH/UqwAcGa01pkjXU7DmCf6FrcSkzuZI+HESyXXIfSB18YZEKCfzqKiupVwa8k 69/dTEjBfhqB5ityNamrxqtIcDE9m57409ObD9Orxexi/udL8QDZ7fSOAeKstPTNEh3qFLKQeyU8 G6yv40EntTmXA7rXXSfGtbxHm1Lb1tEP84dF1p1etLRmL7XlGN8nOSlBcZqE5jpb4ZBEZEc9ELRg Aijn3H+trUXNtpb3NicPVKU43mK3vp2X3q8juY8Va9c+VPTsoxyL+cc+caW+6MX23Op/O7prfiJh EucBicWtO0t91Ym2ANXmvs8Xm25w3Fy4g5OsCEMqQ5be3PWS2yZaqf8tbrOQJnaVpNu1hibpxmN7 C9prdVJXk/np0NLVYX5dnxqAvoIqbJ3g3gZUubThjDuZXwTLZI2/toFPn1eEVpc32xuGwwNZpWTJ T9LQdbOEYzjAVvWy5ouoxD+G0AVm9ZaE8/pS9B3kfu5s4zVk9/cW1WDqK1BlvyyMFQsBzzFUxzNU S6djyKYjgKCrpliJlB99Zez7Jn3bjxQIgee5FJuu1kPTg8BCrqs6LgSGTmf5j4pevsFWLwOARgni Mqg3/0K3J6pSTfVUx3GB7RqqYVNObJVv/qsas+3bmzKgFrKbm7JN7us93vXN9OhMS55ZsWyz+WxE Iflr5QiryFSTSLUtGXZNGKXYqimrQOscdItdSOuSI/Grb/jtBYroFNtTKRsOtDjMUgx6iRDCMdTH VFyIIdSQA0xRN9AsGXnI8x0BQGQAG7mNADoh2TawDc8WEFWUr3ZT7tANDNduBVKJ4s14vF6vAcF5 BJL0dYBCUwcWm9lEukcc0LTpPFuaB7bpNyYx9eARa1hy7Y4Ngoj+y7NxdTHSWJUub41oAhpH2kMw MoF79DSCR5XBaGWG8gANz6OxwTpCFqBnDQmQzTOg7rWPYrXnMBB0qOydlqwMrwoSPzPwzD+1EfuP gwZkhCzg2tbmUKgkqLAHQEaUW9NFh4oHWQawTKMlnso5tYw8atAA+fNG4n8MAJq6T3cKZW5kc3Ry ZWFtDWVuZG9iag0xMDAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OSAwIFIgDS9S ZXNvdXJjZXMgMTAxIDAgUiANL0NvbnRlbnRzIDEwMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEw MSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAg UiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JT cGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTAyIDAgb2JqDTw8IC9MZW5ndGgg MTkyMCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX23LjNhJ9508M3yKllhDB O/OmWNpEW2vPxOZkN+VJTcEUZHOHIhkSssZV+/EBSIoASFAXj7dqY1fZvAF9uvv06cbsqvL0uNJh /VvFmTb76Q7qj5UGgWlC3Q8t3YMmCPxAN/yQXjiBXmJto/0YabMosuiqaKMFIAwDVzfpb3vp2iD0 oa/7tglC27T0aKuZ9QfMiGHS3en2UUwfRnvtfrLKCC4zTN5NDcu3gTNZlGhDpr9H/6CbO3RZtNBM QF/ZbNHkXfczjf6jec17Ydf7yXL+odvrbnXdXc935AlnJIkRSfKsNgBtYPUt3HcmrGmz0G//v6vX eEBl9H1M8gdc/q2zZpnm1PCAP7HbR2673rAdatSAANrM4ILFgfnF3Im+5xfS9t22w4voCXMXo8/X 86vuFhFSJg87wj+4/ngXdTcP/HmSxelujdege/L3vOyuaUQbX4zGBYruKKRb/McOV2RGoz+7ekJp irNHzENDBMQi3DhfC4gq/hyl8S5FBK+7R/kzLpX7bfI0zfdJAzd77MX+FPA1IugH1ft2sZAqs06h 5fkDKhzZX6RmgeIvmPy3u795f3O1/Hwd9SCbElV6ddBSRWbQa4gzBKZKRImLEle0hoRMIP66KnCc bBLhZZLxSsQxK7vu3gWQk23VNxdQT8/MWZNxwejDi5IZ0DMeXoRS6MXbmTyjdCcQqcy3yn0KjMvv uNO05MSdKHB4JvCuOkEv5W+VUUNZh2N5vp7/1peD7h5ncflStGl/jYuVkC5euMma6THh+SrK5BnF /B5la+XCON9ud1mt5F2Ny1nK8FfuWokvki8kNYoBWoG2mWBbEqxqRO4oW1a/Kt2jb5Y3V7efF/No fmEFKKKMyqG2dw8+DYrRB/anKZB2lrP87XwsUpRQ4RCykm/GQiQFQlWbCU65O3GeVUlFKtXGGaV/ x9pDPCXpPjOyQOkU334sEceqinr6Yb5YrG5+ElKD+vonNYCjaC/S317KV+pkVLgUO221K4q8FEI9 VsFNvV3YfcVy2KNMMENyRelzlIibr/BunWcvW9XSvoorpWVURDa7NH2dW5KcSLqQjZiVWCWJ7xjP +txq97tARVgjW/6bUvJu+XHx/ua366G5b6bL2wjxG/CkA3JC6y9M9RGy/d/n/XY5/xj9/Hm1GM/7 eQOKBxxOlGYMqQqq0Vg5h7zp0CNVNR1U19X5QCS1LNsvVZnlLKJdKbl0JBqdy/pBlrrU4ODR9oO/ 9CFRlYz/+SnxglS1Z0lhwlSeD7+ZwcdOhdn3d7fLu1OWRs6Ff8GTYA/KqxpuDzY79Y1MxtstXieU MulLL+mnj5NkzxVBGh9KzD865O4COa4nXYHVecZaWMZ4zWuDdqdcCv0DpTrviQl5UjeYnMhtrmHX IPoXwBXYOcAuhnpXqckgTQ9oi4WYroXiFbglrojzslHqtVilt/ObRc+N80f++KBElQpuM+B8x99R MT2YU/RMQWwk2X6dTvyTkoCHhOKoaC6Vxx7pNFqUOcnjPBXUlJ9JtuiLlCT1bidOZ6gp024sO7dQ 6WarX4ehU0ZecmmLqwo9KrtzfyAaTlGfJtWXpCjQQ4o/TS+k+6kDoaievWFY6qo0JzH1QdE8zx2W jsJs4yMWDSKjIaL5FRKvSAN+FibW5KzRf53wgFPZuTDMybZI8Za2lxGMecFkDKVjeZGbvFxtRy6k Nqoqzp8R9THJsPoscodY53gZurP8WiRUp/jkYPm8BooySbmyW6bp1LgtH3i6WYtFr7l3PwxhAJzm Kwnn/QexOuzwd2UfNWzvnBlTrVMr2vvLTGizixJtSL1vh0mJnG3mKTCLpUO5zwMkndBqA9AGVt/C fWfCmjYL/ekhDWyNB1RG38ckfxAPZzT+TazsQbAcanRUw8eOQm7/KMQn/1usOH0eY+5rxrleWcpn IiIrVw9dK0hDjEoJFmQhIb3YnSr3PcqIgIqLudiQyn64eNLEIlThcCZPSJxdY5w8i9OTOMAIulVi 6UCzjDSos98qzjTXBqFv6X5o6a5JryErJRvYMNBLrG20HyNtFkUO/TraaBCCMAwo/Uy9vXRCCFw7 CHQ/gMAy6apoq5n1F2z3OtPQqrP/AbH0U+N/UPOJrjVLQ933A+AFlm55tAY8nRv/l54x80OjDKhr e32jzMhja+OXsZUhXenKKxs6emw9u6KQor02wbrt6vlG91wZdhswWj9uG7IGtMlBD6ILHQB9Kb7m Ib6jQG26xAt1Gg0fuhxmXTVmjRDCGTRntNBthtCwfeCIGgqdOiJPhBxxANoW8Oyg54ASkkeVxwo9 AVET8uJ4yH1qwAq8gSMNKX6Yzfb7PUgw2YC8fBug0DGBy1b2kZ4gB3SozIWetA50OjVLWKOY0ikA E2PNLtCG/iHVrLmZGmwsqB9NqbpaE+MJTR0QTJ6ncNI0W+NQfq2DVhhS32DrIXMwdM9xkK2zoBkO U1GcSIYNfUp7f0ArK2ycxF8ZeCbdxpT9xagH2bZdEHjuISmUEpTYZ0C2aWydwL6UPLZrAdexBuRp erFRJVsDWoB8PVD8zwEAiJn3EAplbmRzdHJlYW0NZW5kb2JqDTEwMyAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgMTk5IDAgUiANL1Jlc291cmNlcyAxMDQgMCBSIA0vQ29udGVudHMgMTA1 IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBd IA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTA0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl eHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8 PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVu ZG9iag0xMDUgMCBvYmoNPDwgL0xlbmd0aCAxODA0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z dHJlYW0NCkiJxFdtc5tGEP7OnwjfKnXMiTve/U2RlUQdW3IlkraTZDwYnSwaGRRAkd3pj+8dYO6A ExK221ozHt7udvfZ3WefG4wSU/YTGWa/xA+lwfsFlO8SCQJVhbLlINmEKrAtW1Ysh1zothxjaSW9 daWB6yKyyl1JNnAc25BV8isuDQ04FrRkS1OBo6lIdu8lNfuAGlFUsjvZ3vXJQ3cvfe696SvI0oAu uPB26RqHaeB7aRCF5eNgSR+mj+wBezceXitznGyjMMGDSf3DKOY/7CsmsHrKm/5X9xfijQIB1DRN di/avSq3X0yuBovUi1NQvDN6+V7uzzQ4XyK37p/0jou6deuhe3M1HJW3Vx8Xbnlzi7l4/c1uiZeg fDKNyst7nCTeHS6CS7bYD1aBX75eeqnHNkoae4pAJVloRtgaCB+F72383SZLIXN4gTF37VfyawGU fWirAL4UUXeNeXQnn1hxhUv+zXg6mt9cDN0h+yBN4+B2l+LkGQkp7HIh5AWGTOtogW03XhCm+CFl EJJ6C5KUORKtBMnRe6tos4n2QXhXPglxknJJxaEfP275JyzKs8Jh1OvaEft14K9PBumch300+zh1 x/NDWZnOpqPxzYLhOmFl4i2XAa2bMw6KvOq7VmsHkLgK/6Me2YkpYZud1xA/5icFZPy7ezMfDz+6 H24mF4dgux5eXEym77t1kQlMhnOFRynRzbHSpOPX7lB/ExAD5W2Cw2UiRFXgXkF4B2bG1vO/4ZTL WMcSiQtjzBvGuIxPf3ibYFlz8vuOVFebj4Cz9ppcx3NwWXPPoLJ3wqlZL47TYKxGfibMbWV2RFxb cdPqaaZwPRr9wLFwv2YH0hmYh3HeLAMO+wplkza1KBfSl+SPvkdAJ7KGvKtkiGBUK7u/2ZzO+axm VaEbcWT78vQ3fRChGOMtqWuSD57q2OtCO4g1QX1oGwByLF0314Hk8nRxRm8fhWmFpnL7yBV0Fdqs F3dcEcTRvXCbBMekcH5iUbOp02S49tp+6rFXk4P/s3jhZmPeLR0587Q5ynvVNkhFYqGOuEh3nTBU i31v3NnsZnE1vLxs401u7gtAFLVK2oCzY0scVW2NmgiE/d7mpO8l+Hjrd3C6ThA60MQVxvTK82Hv qnSsFqUzykSIMo7jfPAd0vCNQVGw93O6e4u54VWVPQf8K8Zw6WU9n7jyIssuVyoJ584pyew0CnTA DYPXJsHR5WQ8JYw3n8/mpHEvxm1Fcwrj/QunTKJgzvj7ySd2yyXlWcQ9nQlD2iVcbvZBUR7rZhJa 40jXHFvkuqFbHk1g1zuL6d9plJIaqgjzV62OXeLdsbtoJQ7rHieV74JnCh4d6KDiz3/BE5k4cSfv JqOhO5lNX1r7It8bqSgvKgpYlKcPHpFSQYgZSPxMWnhU1z02Axw/bAOiQ8/LB8hiAW/jYMO6B6mq nnmJLGDm2rumy9kf9dAWKvTP13wB6OpXobxRNPOwKBcX6oRI6TjkxPZF7K3SbLfSE6G/dDPzyFmC tBCDpXKOygxADaC6hc+lCdTPF1p9nvZNIDI689PoFscV1HOEtAZEOjHaEaROPNpS4c8SNssg8XdJ cnKL53ELSLA1jmlUpxul4BafeUIOoV1j4ZUkD47vbfzdJqsFwEVTl8IVWuok3iyA6hioLz+xXnop J3sIdyTEJkPiEINv4yiN/GjDQcHE4b33rTIVxbtVykwwhPO0l+R1at5rh7TmKK/ksmUopRG3pHom ah4GvvSSb8F2691u8Jd+kfJTVTrzsSLOOdxEguTEM1AUbhjdB2L8Gb/dcoeWPFkd4qicsZo6g7RI tMSiNByaqLws4AidS8xfOI66njuclnNHXR4d3HbsSlCmv8QPJUMDjoVky0GyoZJrSIeWBjRoyzGW VtJbVxq4rk6+dlcShMBxbEL5qlxc6g4EhmbbsmVDgFSyyr2X1OwLunvmPkSZ7WuvMP6dmA9kKV/q yJZlA9NGMjLJ3DFlZvw3OaTmm0apo4Zm1o1SI3eFjV8PrXTISqO6MsfYpOvpFXHJ3Us9LJP5Ha1k 06i6XQBGuMsoIMudVpnTDXShDqBVwVd9wvegoxpZYjoyQcOCBnMzKwU18xDCAVQHZLhq1ENFs4DO qxWoZ4is07QlAKghYGp2LQChSyaZ9sgxOY9yyLftkFvEALLNRiB5UZwPBvv9HgQ4XYEofh1Hoa4C g66se3qkOKBuknVmZR0om28QUHHWJ/SAU2VJL7wV+Zcmg/ymr1C2yR71yWRDPWXt9XVg9370YS+X tUrWjCxA5DgkNlhESAN0jFMCpOsQVJ1mKrZHkqFBMolVq1FWyMmDxA/UeUocSp/+x17NZU0zgG0a T0khJUEK+wSXNYKtbmtdi0czEDB01CieXP8qSXCvQATSh6cS/2cAqG+RBgplbmRzdHJlYW0NZW5k b2JqDTEwNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk5IDAgUiANL1Jlc291cmNl cyAxMDcgMCBSIA0vQ29udGVudHMgMTA4IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTA3IDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQg MjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8 IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0xMDggMCBvYmoNPDwgL0xlbmd0aCAyMjYzIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3Fddc5tIFn3Xnwjll5VTI0TzzbwptmZG U5bssXBmXMmUC6OWzUYCBVAU76/f24DobmgQ0jqb1MRVqcamu88599wPhheJKfmJhLKfxA97w1/n SHpKekhWFCRZjiqZSJFty5YGlgML3ZZi3Fv23rm9oeuqsMtd9mzZcWxDUuCnWBqa7FjIkixNkR1N USV33VOyF8glAwVOh+NdH37p7nof+m/OB6qlybpg4T7jcr1NvCf6FC3LZfocJOXDGifce8yfkg32 g2WAF/SPYbmcYz8NIvqsy7pcPrzDvrdNMHvj+cCUrf7+cAMg/+3+DowGSEaapknuZTuzjed/wqkI ZhSuXsoHjyKCDWG0W+HFE17jMBUpMR7d5LgGt/jzFifpcD6ZDmdRCrR9j/D7qQLYfdsOM6D3LCJM QYYR/YMfhanHSOmFFP/aCxdeGsUMozSNg8dtipNMX1uREcWiEFvAo/tv8sRYpbNLRu7DdHRRv02k dBD6q+1C7AffSxi6C5z4cE5n6+RRkI8UexZVbTwoPOtTJF7qHcslZfRhxfG9lb9dcb6ALMG4HpdW 2FX+lqxWmed5oZoWyQsmyFy+dA33lZfiuHz6guMEbmfyp6EybOIojfxoxUhxz/j0E1tpGuoMZ7Px 7OL24XLkjqjZ8rCHiwr7QwLCYZP3ggQRx7Kl2KURsyXzQ/mMQz9+2aSMQT72k0/BZuM9rvDH8yLk akfElSTeZyGjm4AFq/cjriKlwLgCGIj1v6EnBdVSeAQP9siQKZNMbVtgcRg4L8yu3ckvk4uRO7me tdSeupmOwJrgGLz+L6onVPvGOt+hzyTMrxnj/AfH0XGV2aIeGFWjbnQ6obW2c5D5SrPv6IkwLsso XnvCPlnNmwY7n5oUFM3LhvHXdv0ItYq+HuMakU79xT42PIhhRdJdJElj5F61dLtceFaraBeET1Qu DhzU6y/Bgokt7XtP22AhrHq758B/bqtBa4+WlsdjG90y2obCCPHXfgrChbAdFbZLaLP1ms5jfPt5 64VpkL7QIE6Lc6qNpzRU18azwFD0GNPtgpTSqPo1YItKDBMoqfcMhoTRiUQ2+ZlpNShvMfu6VUyp 3VCyNW6eenH6E3Owyh8MBTHZwDSAxW9rrwTj4tlbrXD4hNnD9TYowh3GK8ERTfjkfFN4PoeraatV bu1qpjrlVQAuGYzjOIqZk+0GUJTOLR54W7AX2P60rxY2rT72nba41O6qdYBiDlht1zQBmhLniGJy NoaJ7IzJrgUBwCTU7hkDLqoc29paP2tonQxBUQaloEEVheaILje9m7uVEloQqIxxRBOmZrATs7gA pifp3RX32Rym3W+sdzlQ1zfKdbi1Zlo02a7N9Expo5OyPaSdCxdSGGU7hbc+DDPsuOGglUTRE6kj ztC3YHUyk0O2quNXBq/FgJ18ozVOgzX3TSikceLHT40Gm5hnytvXZwQJXeOS94Iji33DV1l1xmde 8z12cGmdvVP282MR+ds1dAqqEpCjfqt93h4Riw6mzNbLbbplvhvggzCBniWcNtltMEunEdTUg18O 9QVwsEgek5eE3xe/eYAiCDEFzHpn7sEoiF/qjMdfN0GMmSFRtWiv2MTBiqqsKoqewVUt2ZSU7EOE RcX+IwhtWc/f4nB+uGHtoKO/hW4baCZbu5pq9KFvoEmY4jjE1B2XsbdMsxtKdEIO5FhTgB4GF6rp ZEql4oaX7AKkyWr1hg/lFep5vtE63weE7DFl0aXXfhrBNwAXiVw1rSabDpeKhWt0U7e4jWpVhP+c 4L8B+BmfH8r5gZsfj9mJtzql8iMkdTAMcDQmn4JcmU1VGcKKFaZJgUIEpOyjx6vgPkxHF3UQSnaJ UfdUFnFlH+Q3b5BoCX83s/G7+A3iTAFQbAX8ruRdfH9Y7eWD17yZ0SX/kEukmrJOLmJkqouzV8cW qzN53ySOvt/SKE72mrZPgS5M3570m2763JdBKApUphFy+ATrV5QRZzA7dTfp4/zD1cn1sZqMczO6 vJzMfm1Sx/qB3NOcrkrLrfesfDMedrNwRDO9SbP349v55Hr2cDVhZuxygcrqcagovepSXGSITezS JoZs1tgSpqq49bgP8/HV+MIdX+4pi2yiCAY6+ApochT6VrI0C1Dmiarw3YjLkzxNGrrP7Hp2MX6Y CsJ9vABNA8r3k6DVAzfj2+loNp5Bk7l8uB3/0YmjUR9VX9/9HeiC27i5lW8aYsKj2f0xVL9VME8i yhmbcNTEHH+5u7oa3bm/HRXTH5ZolwyeXIKFJ+79PzODqzI4TfPQ7Wh22cTrYMqi/0+s2xtW4esm grPxX1Cz5uO7y+vZ/fTkrD1+rDldCW5EOWrCO6zE7bhI8x9LicZZ7rAu//vMe3F9N3PHt6fPvKcu xQO+eEJtTQSOUZ1HuaBkH9zr64f5dHR19V17dnPc2+d0cSHoEux8cpt/12A3eVoY7LHbQxL5Sfyw Z2iyY6mS5aiSocAaERk0WYMuGOPesvfO7Q1dV4e33WUPIdlxCB1FKpa6g2RDs23JspGsKrDLXfeU 7A1yeqYVFAAg3b/xiIxw+We4PpB6+VZHsixbNm1VUk0QyJTo5X9KIbm+fikBamhm9VJyyVNxxx9N Ox3YafA784CaZD9ZASR31+tjSbOkaCmZBg+7EAysYhSS5aAVCrqmLtJlZHH6Knt9G4FqsMV0JFDD gsGohJn5TskQIjREylAFxAThQLNknZ2wkZ4p8pymLQSQpsqmZlcICCFBWpmqYzKIcsk37ZJbcIFq mzUiuSl+Hg53u50c4HQpR/HrAEW6IhtkZxXpAXMg3YR9JrdPLjN9GIQpjs/1fojTwYIsvCX8lybD /OEcaKn97FfnUEjU/uDZO9ch6b6coz6OgxCHg336FQRVxwFuqGBICDpGF4Jkn4oUpx6KzYFgaAjG V8Wq2Up1cpL4KwGvyAjqJ/kfexXImmbItmnsgwKWAGN3gKyBtrqtHWsezVBlQ1dr5snKaH+QBOsB UuX0697i/x0AlJRQcwplbmRzdHJlYW0NZW5kb2JqDTEwOSAwIG9iag08PCANL1R5cGUgL1BhZ2Ug DS9QYXJlbnQgMTk5IDAgUiANL1Jlc291cmNlcyAxMTAgMCBSIA0vQ29udGVudHMgMTExIDAgUiAN L01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90 YXRlIDAgDT4+IA1lbmRvYmoNMTEwIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN L0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0x MTEgMCBvYmoNPDwgL0xlbmd0aCAyMTU4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CkiJ3Fdrb+O4Ff2uP7H6aHcjWtRbC/SDN/Fs3E4em2h2UWQGASPTsTq25EpyPCn640tKsnglUX7N Al3UBhJKJnnPOffBy9Fl5qhhpuLim4WxMvrlEauvmYKRrmPV9Q3VwTryXE/VXJ8NLE9NqTJXfg6U URAYbFUwVzzk+56t6uxbDW0T+S52VdfUkW/qhhqsFL2YwI3oyHBNUw1C9i7YKoMfqs8w+KdiIY/N Cq4UTWcQGAY262kwDp5v74Lph+nlOJje3f4w1NgOyBrUA334JfibwqGWq4WJJ769Pqzm9w3xoQny 4a0Ygoeh5iCP/eOQNGwjR9UwwibH0+LVJVIPGOXLj9PJbfA8eXi4e3i+vLua9PLmNs7ifaYaZ/Ae 1C4O/tJ8OFaRaV4Ps0WyWc7qxxdaD+Mkp+KHfEHEIpLnafSyyWkGRb6fPNyMb7nO06vnh8mvF/xH T0e4IsIAHvLT+PYf1WJhK57BGR8+ffw4/hRcd6alAvlqk2/Icvlev6DfwuUmi97oheCdAGpcbndQ E7SPBJzEwEYSCwDJHGxOV/VDSGKZ0lHM4M2A2EBqtl5gJivxkEcrioRH50cAqfxhVPT0IqgMx+VB tZeo3N/T3/qcNLm9fHi+GgdjQTHrsL2A0IAuSb7Yjx838FdJcSr+m0+PwT5foPYuICh0nmADadK5 yEBQiZvxJdjo8Po9JAIQCa2da34yvTcZiKx5ktbjyfh+9Di9EWlDs4y8ij3Ihjsmj0KSR0mMWtFz KDkeaciX1c+OCOM1DaN5BJyxXUThoo0j62N7muuakL9f+jey3IgnRgNUz264HuetMIlzEsWCcb4V 5SmlGU3fgA9f3nNaVqzdgmML1jxZLpNtYyuBqh59pe9gyv6oABRmYs7nAeP7eYikAkIpyjA9IapC sgw3SwJPpuSNplLZt4tkKZ5YtNfjNQm/0hzKz9jQuLHtNoJ1aM3JkuWJJ1qlnVZFfFj/MCM5uZCb ggzYuUXXDZkbx3B+UliegDvvcdfeOpMBRXMRvv+maQJcAir9zpdR/NpnWR5BzJVl/LfC//gDrRUA VeXIpDBg4CwomTWiDXjjhb7CFO516iXMlMJR8CQsiVEps2OOunZR/yMQP25e8vd1L2h4+LO2q73F CdktzmmwO4iw6uCYAcf1njc2wvLokdbTrLXlCaDb1R00oienREbjGUwHKG30GicprHsxoFTViQ7j U0orO4RYYRdK9Jxme4uaPNBWRJwz+/reKG5bPKFoQSfUpQWI1HBMJ5IyuiYpOwBARw97JUpAg7Kn cSrw1jSOPZc7vdKZ3eceEzADGLEV8M65XQus/YtkC682rMtAXfc1kfcNGlUcvqrKXz2dhbbLX/E9 pXJcE9YaRDHIL5hPj4T3Qu9dqSbf1hErEj/VLwxXiLJOo6UoToauWwU7w0WOqnN4DVTwwxF6yCpn NXA+3cMGyzK+SE83zXSgDD1iNjaesoxOY1CErlIyz4vdaiRSvHwzR4IUnoUwA8aNprAwgE1ktC08 1SaMYbnQHe7E52scJDN6F+bJC00bqpcKmR2JLGb0sEhtRPoORfeD+38y+n8ya1oMp9eoAtBcvXm9 Vb3Q2g3s3cDZDWrNvN3A3w3+P3ZuiXZsiftR2/8tY+bQrB/Bxp2mshU4/4ERUMy2JQleVVIee2a3 SpQhUe9U7GJK8+AjjV9Bh/ZX0eqUyXNgZ5DdfLovsTF4qHojjtVCXn/+NjEDf2lsJkjA/63vuqku UeOcj5T6Lr+PsFFWSG/ngqfBTbVmXP2/PBan3AnF1s0rw5+G+/fY+BOFU5X01YHy3T1Zo9VaviYp u4ytZK3WNZupPV6PsYYNr3779PBBrDewbn2pn77Sd9DnLkgmSsgbWW6o6DU/g1vDsV23HE6xsQx9 8pIT1pEJPPM0ETRh+2lUZ7zGr2ddcz2mXt67PtuLP083Me9awKULokg2+XojvcRhBxhlF0gh4zWN Q3oh3W7ZLOE9nTeMhSiTNoOHaHXQfR5Kw27GGuS35j2pBxRptHgwukD8/P2ZTQOmNhm83ZVM4qHe ZtM4Y/e7CyCSXfKOUnTPNRDcQNuXMgu1rmUgS/T+pvPYYvD7AtxTzr2HRXG43MzkfIgY9lxgOzHL GBpHBlzKlFxHLECE5p8eg/phnSYhM3IewRfKbqwgiZLkK8xXcJUl8fuJuBOGJO3aBuk8lYdUpdmh /AiTWY+nWOGKZhcnws37ouSA/tFrDCUky+VBBWQxJBHgrPJEYhGiyZqmBHibnJ2fNuoeXnuS0UWm 8DILwulvF/Bxcnv58Hw1DsZS1GzC/fjqanr7S8vmJFCwyr9ZGCu2iXzXUF3fUG2djTHvykxkYk9N qTJXfg6UURBYbHYwVzBGvs97bl2thpaPkW16nup6GBk6WxWsFL2YwXcv2GCjYHhPOEVm/F/MfKQq 5VJfdV3WCnqGajisc3FUYfx3Nebmu0Y5UNt02ka5kdfKxq99K3220m6uLCV3+Ho+YpCCrTKgqump yVx17CbsSjBWTO1KshK0LkB31MUWwm5DX32nby9Qky1xfJWp4WJbwCwiQy8QYjzC+shgiDlCzXSR Ba922CoUWeT5HgLYNJDDiDYJSCE5DnIM3wGISsnX+yV3mQHDczpEyqD4aTTabrcoovkcJekfAxRb OrL5yjbSA8GBLYetcxrrUJ2LoyjOaTq0BjHNtRkfkDn7k2ej8mGo8RpZvBqyo9YYaAsyZDfUwdsQ D1gPE9NY26VfRdDwfcYNVww5Qd8+hiBfxzpov+uK9QFnmNhlYe92wsrwS5L0GwfPS4U25H8paUE2 TRt5jr1zCgsJFthHQDaZtpZnnho8pm0g2zI6wVPeb7QsWrGmHuXfdiH+3wEAqGWRCAplbmRzdHJl YW0NZW5kb2JqDTExMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk5IDAgUiANL1Jl c291cmNlcyAxMTMgMCBSIA0vQ29udGVudHMgMTE0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3 OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTEz IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBS IC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNw YWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0xMTQgMCBvYmoNPDwgL0xlbmd0aCAx OTYyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7Fdtj9tEEP7uP1F/TABvvH43 Eh/SuwOKoC09Ax+uVeVzNokhsdP15tKr+PGM7dg7tjdvpRIVkEjRON7deWbmmdmZyVXh6Umh0+pb JJk2+e6W6otCo8Q0qe6Hlu5RkwR+oBt+CIIT6Jxpc+1ppE2iyIJd0VwLSBgGrm7Cdy+6Ngl96uu+ bZLQNi09WmtmtaBUYupRUv7stNGTcfQ7iAYl1LZtPbrWDBNUg25YcgevDcu3iaMQptHbZ7+2T3E2 w29unl+9ens9jaZygRA8vd8KVrR/JXHWyvesFbcFk2eJXIo8zop1Kto/WJbwx41gY8Mj/qjZ4wLE N9EPWvTFcfxpNs/5OhZpjlGIHWPyWSwlrJvpy8nts5/a5w1jXGl+wfgD46SjMTAJlbgq/9euh6dz HR4hMA/xaiuf5ilbSf35/ECMkjwTcZrJAIid9C5nFW55zP0jjtU8X63yXee1NL4OwIX+p55RqkDx SEUar9IP3ZA8sETkHMF8t025GgeOVp+D3QAcBdYylShdf8JRMZdLCybJioj8gXH5sFsivhUsm6XZ ok8rAG/twdepanl+marH+b3Icuwo5FPOErYpvay2sJfZjTvaf3765TZSJW6aJavtDKlM5yct2Red o5bk2epRdeaxeNdriwE2afEtEAsTzSGujMOGJSlkVdHXdQGN8g3jXSpjd8gyEid/YJosY/kwyxGC LJcv1qyzBdkJOT5Lu1qLC4FDWc23mWBcesv9lLWrJDkqnfnBgB4lYbLM82IYoJOlpK5VfGjYUfyo ysAtNMvX6szpmdZJlOcvpMwZXHIXQ5cHQ/mv7WgvgXMNmfN8LbnH2UOab6UT4Y6T+YHvuoqkqMih 606caX8dMGmoQJhYsdwb9HipPcgrLE6Wp/hzVtxuv3/xy4/X7SOOlUzcRZ6jOz/f8kSuqjmNit0p M2pSZaxAhJZ3xIJlZS35CMZIc1+uWFxgi6V89+rbqwvxUt813yiDsM45xjbsseL7fCv6puFLr/aF rHvb9T3jRV/ZBWALlmx5KlDDstms0qSCVagJUcNW1agur1DlLZb5DneS0C6RYeVF5bNzlSsa8bbI fpwA/vHLg0p1ynL9fQxtapqh9gOn9W1c9nuPQ2/evN9AA1Z83f5h+dI5G56uvpJvTNOpDLd84sHs AUZ1UOFPiTAgTr2qg/PuZbyQkXHsN8p207A97LzuNaW+r56Vl1yGbtJrHs9FdVqLRIm3PMxTID1U PqdbSNhM7ClXKaA2sfoa7loV1rje6I8b55d7PKJS+gLyHBKk4/XaQ/bARQ4oRaQbkLHPvD42s8Ez /NDDr6zDr+zWQEAcdPIZq2sPb49qNzqN4DaC1wit94JGCBvh33Fyz2nnNmNfGse/NXtOrfoSHdwU ty5d/sRxr9a4igSvK2pJOPtAQrTnVGc4TeJ0zP2RZQshb/9vWsmtU0d9dAfhE4kzVGTa6NV+8Cuh OiQ4nL1dzChGBqxEafZZx+vjP0rTm5w+qKOuipayxD1Ttzi/Vi1Ob+OhgJyGaFjuvjzKofQfdsqn 0fHP8qzT5vSv08HV8/fHS5iNtqiRS9lKNjWHZ82b51ev3l5Po+lwZJATDLSLaYHGIHzcLr+05d+X E9kyPgqG29xV2YDh1xJIulmicUWw9+LAKSxL+ONGoGO2Be619164APZ09hBnCTrwplaBE/NWQCcZ c7nm9Wh6c/t6LCcOeJTjQ5opo3LVtfLpKk/+uBDs1TKG8QjZ+3p09fQKAVnns/7UVoubaipBNin9 tod/ZAC7EPCco8mnR9Hzx9kT1Io5ngMlddDE+YFx+bBb1jPCRSNXNsP+wpNFushgRkRJmSHgCauo dN7cCrFUD6FxK81YkfAUzqyLV6vLPdOQAxUDNHc4dOkU+RHVpz9qKqegU+bIsbTXCXTK7v9t/2d9 MnZa53b9HC765h4/0FpWK21Fj6fMglb4c2zKh7rXr/s+u5kGVH3fofaeDieI/7v7Mz9HG1lyREft eUcxAd41PQS6FK5jEVc7gmbDWY39Ewyi29xbENR+c38M7wUfpcb/RHPfoZls6W8ijerlt0gyzbVJ 6Fu6H1q6a4JMPYiDTWwa6Jxpc+1ppE2iyIHV0VyjlIRhmX2mvhedkBLXDgLdDyixTNgVrTWzWlGe XtkPCV3qfxnvlb8D9amu1VtD3fcD4gWWbnmA1dOl8t/0rFQ/VFoCdW2vr7RUstjr+PnQzhB2ut2d dZC8cn8pAaRop42YDkI+1z23C3vvMOCqu3dZDdqUoAfehcSifse/ZuPfg0Bt2OKFOnjDp66EWXHJ rBBSOqHmxALEJULD9omD05c6lUeWQhwxgNoW8eygZ4ASkucRzwo9hKh2+ea4y31QYAXewJCaFF9P JrvdjqRMzEnOPw1Q6pjELXf2kZ4gB3U82Od19pE2eydpJhgfO6OMCWNWCvEcfkQxqR/GRtmAV3+N oZJZI2MZj+GuGj2M6YjxNGOZUWWlNNAKQ7CN7i0sDQzdcwws91nUDIeh2JwIhk19oL0/oJUV1kbC rArgTUJHxrj8ZXEPsm27JPDcJihACSD2GZBt8K0T2JeSx3Yt4jrWgDx1RTOKdG1Qi4j3DcX/GgDR DBhkCmVuZHN0cmVhbQ1lbmRvYmoNMTE1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAx OTkgMCBSIA0vUmVzb3VyY2VzIDExNiAwIFIgDS9Db250ZW50cyAxMTcgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag0xMTYgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv VFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+ PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTExNyAwIG9iag08 PCAvTGVuZ3RoIDIxOTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIncV1tz2zYW ftefCKdPUltCBO/smxt7W+/m4o2Y7kPSyVAUZKOlSJaEbGsnP34B8XZIgiKVuB13pRkNSAHn8p3v XLB8mdtKmCv4+M3DeLb8aYWV23yGkaZhxfF0xcYach1XUR2PL0xXychsO/vRny19X+en/O3MRZ7n WorGv+XSMpDnYEdxDA15hqYr/m6mHTcIJZrih+LnYTZ/sfB/40sVI2wYhuJfzlSNq+a6+ZYP/G9V dwxkShb+HanXG5LR+4DRJK5fJdt6ycBOEofZIW3t/J0c6vXH+b8+iS0fF/UrmtfLPCUh3VKyaf48 inE1pHPDfvX/OfO/PW31ioQt5SayUflgNSKOABXY8KcvQSSNAhoz8sjqN2ES5zRnuQyhmOQMeHV1 cbNcXb+unwPGMrreM5Kj0l38lLZKYhJEt0lG2d2ufpORP/Y0I7k0qhGJb9ndWOz7mLCkXq4Xqo2c OVlo8048CnbqtiPYySPtCJ4e3XvxIlhUfomdBud3l8G7fcRoGhGZcdhu1B8qdHvw5CTm/K4fd8EB xA1EDThD4zDab0gXBRA41YA5dzJUF/6nm4vLy+s3P/UJ0bwZCEyQsxOnHniIaQw1Xb15+e7T5YV/ AbEoQ9PPk6+3G2R3nLAugCDR5ZRiCQuiCTRM+KHszFLRScomCYfgg4ZBKKe5HzQMA5Q9UqZ2ZCr0 w8S+aBTu830QfS+1/tWkfL4JNhsa355yrwgj4GZBpbuzudQT7R9SwP54c2JrxxveQKLNQK6PFrIz +DMBngYYswmE26hvqg7WhyJ6zWTywruE162mhiXAkYBJvMITvZpW6u+DaE/aiI8dmZgxaxImO9JJ mzOi8vX9IAjZHhSdNNi0TwH2n41NkJ3LspxI2+l/SdY8fJxrj5oGZirQ6UV34yyVu5rxeSulJGYy tKBPPCJ5cNs8v36/8s905J7PkNsDkN6n6QjeJXhjsIDUgc6A5DmaQsN6oD0jPbYBjXIZzi0XCMla hbfZRlkPwzpMUll8VixqqvqO5CmfMYkYHZcvIxE2dZrRV1kGSk0ahL8D9ESTk2omrVNhAuadb/Zx sAY5BiKQZknIydLR9k1nK+BNa/w76QYj2Y7GASgW0NxgL4BmIKyFF4/hXRDfkvNZ0Y530airP9qz aznlNbMrH11l8/rPgdARAzrAxrYKouQB3JWa8D2mYjL/oX6hO01VTTMKmryuaebRMN1BdjEtt6yC H2Ghi0zJTP3hBua6af5aMLDju2rYLe9b9xT5heWaXw+yGJDvMgu27CittkRqrxBmSyzl2dHgB25U Fy0yHBVgA+ldDR9qFXp50XBaFw4byZS+DVmyhhnOUS8QMnoQmVzpmSCdyoDWtSW7Hywz/Y2tStOQ HgL4D871fSbN6sHUO6MBTE5Q2KG2SbYLRtvTxKuIlMajDfgueWisXROepKgvoh3YLsO0ilX9Dx7+ Sx/+y6hpyl1yByopVFyrqYXWIsxqYVULu1rU2eBWC69a/H9I7sNXJurUjPxOPf0tKDe26zsguCJU m0Kfay4cNxiSwgSyAJTLITmFmL6Q4jIlBBj9DtLUy7YciTHl7QghNGxM7/NZFhdeZNpF9IljU/RL jGyNZ84kM2UWV7aWcoC5nfh91UcKUFHB/nQdzyglChfrLgoeWkY6yESwR/xy9W51/fbNp1fX9eQ9 WMKnevtFzUpiiLxjjXYhcHVplX/gzMCMWlP7r2lOFUlbGv/WvePJJReJ0WBe4VbC1qrJLXqezKPy 9jiab72MU4Wyk9RpNwETuRLbINsR+lzrKPvM+GQ+1mm4ipDtg6iW/AvJcjhgvqI566iV53OZS+Wb zwutd+PRzcH73jOPUHHAkl73Vvs0TTJGNoMQ4iJOuH9Hgw2yo8yR8mFcmT5FWTnKd9tv+0r6bMOC nqRTlxigXsH4i9Q8W3in1KVxHr6ZRPr21FUc0ap6JhmIBVrmqXrXA77HcQ09K5ZXE4dkOmuPHl84 X4Ep6OSItM9BMGkTx/tOXGNymzAaMP7u+0YyGLVSEtIt7Qnj7UFvDTPDRq9IyKBKE2EEPCInHAqT mAU0bsyBo2PPlf1uzV81pkNSH9vZ+tAfdE+aDtVdXdwsV9evG/Ek4xbIPSn+qx9fvweTbRJHBwBm GO03PZ+gw2CGpuxM6OkujciOxAywJt7IhQcZiETER2o5gSiQlZNwn1HWuJMmEQ0PpzAp0/i8MKx+ fvv+1WX9GMEZRsKIXGY33JdkGxAdcDNJM7IlGYlD0iTDLgHaig0ZKdzYnOlHz74tzXIGbmWNoogE QG0Sj9FezrU1qA0F0za94JxBpxHV/MYnhTvNEpaESTOUbkge8kyXE4zBGrdJwr3gr6zElaAA+6/8 GVbENw/jmWUgz9EVx9MVS+NrLAq0gQzsKhmZbWc/+rOl75t8t78Vjc3zRGfUlHJpehhZhusqjouR rvFT/m6mHXcI6ceKjfWymYkyzpX/wdVTZVYc9RTHcZHt6opu825gK43y/yixUN9XKgy1DLurVCi5 LXX8e+ikx09a7ZNFW7HFebHiJvkPszlRTE1Jtopttc0uAeM9yiohK4zWGqN76GJezJ0WvlqF76Ch Bj9iewpHw8FWY+ax+2lHCzFeYm2pc4uFharhIBOO6tg8InLH2AkHsKEj23A7DkhNsm1k654NLCog T09D7nAFumv3HClI8cNy+fDwgChhW5RkT2MoNjVkiZNdS0fIgU2bn7Nb51A9byxpzHhhFrMAUzdi EWz5D8uXxcNCFRl2fLXgE4w+V++CBZ8j5/cLPCcZjUmsVulXOqh7HvcNlx4KBz1rioPinI41rx+K dCQYBnY47Z0erXSvcJI8CuPFEKAuxC8JOiYbhoVc26qCwinBiT3BZINja7rGueQxLB1Zpt4jTzEz qjndqVhH7LGi+P8GAOimb1UKZW5kc3RyZWFtDWVuZG9iag0xMTggMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDIwMCAwIFIgDS9SZXNvdXJjZXMgMTE5IDAgUiANL0NvbnRlbnRzIDEyMCAw IFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSAN L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExOSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg L0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRv YmoNMTIwIDAgb2JqDTw8IC9MZW5ndGggMjAzOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpIiexXWY/bOBJ+158YPdo7ES3q1gD7kKNnJotcE2tmsEiCgJZpWzsy5ZHkdneQH7+kJIsl ifKRBNheIG2gQdos1ldVXx2cPS08PS50XH2KmGmzX+ZYXxcaRqaJdT+0dA+bKPAD3fBDvnACPafa SnsSabMosrhUtNICFIaBq5v80yxdG4U+9nXfNlFom5YebTWzOiCUGCa/nV8fxfzL6KC9m/wwNSzf Ro5i8X5i3onT76cI/Pgh+heXNTDCtm3r0TNxUazxH6L/aNE/oIaTl0cb2q5vSbqXu1VC02W7y1bt stwkRbshZZkni30p5RZ0nTB54JCUm3ZjTQ0P+RNjcQ8EHsflnqTt9g+aF0nGmr3bmMpNOmnHi6Qo 5Yaydbl5JDFskliCKHY0Trh1BbBIokkrWbXddARkT31SfR+YyLoQvHBHIeGyDN4Vp/tlwtZKGCdd p3SKOnBXYK39I5kYQTZ0OQN/yNI0O9AlMFntfYh4xPe3tZXy8mK/22V5WXOr1XEpc0aQFDTnisY4 RAnYbMitlCMXMMnqRl468+cslyruyHaXUokgqQ1cTc1Jz8S6DlieL+rASWO5hTlVBShj6T3Y0L5z Qega/z+ClzKlDy+kJ2Bfp6KdTviud4EplvTnExqTfUGV4C5L9GF92+4BRReqwG/3aZns0oaPV9IR 4HDGCkSXp2xJJWt2ZKmua6eKe6dGf6J51lUMcoBeW9oYjWlRkPweDf3Q7VjDBdfiCyaIQ8q+9itP vDxhgH2ESavmRJSc+yGmm7tdktPiJ8kYX1J2lyep9LRlmk4F1/KRx5u36LMQFfwTCAPk1Kc6ON+9 IWvpe8f9UFOj5xHD9sb7ubqxP2clzRmVfHyWk1VZ3dYiUeIVl3kKpDeP30j/PX8p3bIXSV4mMSl5 BlcKsI2svoZ3rQprWgv606PzhYyHVEpfx2W2gLWWe732kD1wkcOVqp3UKYLwq+ZoR6WPXFklHkcf 5zcvbp5GN88+/nHzdv789atzZP2S8WqV5VtytruNg1EVI1D2ik12kImwoJz8qElWPGaGInLmMWDD Pzz+kzX+k90ygIc06JSNnsb2/va2VtY5LtzjwjsuWoYFx0V4XPxf31xngPT50W8TmcG2Mp1+NE58 mgH85Jn6A8hcpx7qlqcBdT53Ut1BgQIbYDdC6PNYN/9nu8J1rXGH1bdW2yr9ofGQq6zAc5rSGA4x zSxSiYRjlzeerov1524kDFtoAg55cHGZtHi+onydfOqBH/mUBQZ/WYduezMfo+usTKouIus9AVWs eZz1LxvMiJdMu3Mec6jcQRg+XC4bjjp1+qQ74oyVJAEPEzkSloesibCYqHohvHzoHXhzv12MP1IS thQNe+Shy1v9DLb4/t3lBjQrKLij9bx5xRR4IKwEKOR8yWlzdjDsNW6v07hfvX719Objy+h/2rB7 IL436gfYTr836nOAJp8BlcUhf2zA73Z6tXGjHd2tXwLn2/mx/XZaNMT7lhY0v6VLgbUdN9Q9fLSJ C7nOu+GBxWwwXH3Vn9oLIMcvUFOJWKZizJpA8pwLyGXQDMvtPvgenj++Rs2Do9s3mRm/YK6Shy7o pYM5i09X7TpvisKwo55ELcYyeeEqS3lXBkPo4l4x1OWELbNtbxhrt2vKaE5K9SWqearavJ9gbwjq ilErzdj6/VRawv2xSe+BZTkAAaaS/jhI9hwjK8UACadCehdvCFtT9Rxde6Sh+2AiO4m7572xpwVR TdcFBSd6nOvYK79n9NCu/6L3CVu3Wz7z0Twh6cDEK+gEWajgF8kpAA/GbMnjTzQHY/IOhKCgfK4H eLnPpdvWLMuB2qPgFz2fchrTnYh+f0TvPFi+vkp0EuDl73OZ+/EmywqqDOCgTvTifoL3lIBHEuD9 FVl2cXY8X4E4jSbbUU7GkcXpfgkYU1D+PiPplTAbPbN5SXLJsjzbs2XxCLqVKX3cDczjf8OUVAoU ZHsmQnVtOB66tDgkEh9JU2iewYdAzvGCKuzckfgvWhbqUtWxbf7r699fPFOaJ6vMOsuu7SpFts9j eRdoeXWlZLQAXUzm+7F3DHwpbXmTUlLAKiLX797+/LTdYN81P8g0qP3fJsOlAdhmOSQnz6Ztl/lk ke3LPn5YpZTNEnbcHNgS7/OkvL82J3e7tEnIol+xbiIN6+JTxExzbRT6lu6Hlu6afI3FMGQjGwd6 TrWV9iTSZlHk8NPRSsMYhaEYZU29WTohRq4dBLofYGSZXCraamZ1QtxeVUBsVVXxDRFlkSv/m6tP dK0WDXXfD5AXWLrl8cnL06XyP3Um1A+VCqCu7fWVCiXrRsdvY5Ihl3S7knWZ9oS8WHFI0UGbUN3B erbSPbcLu3EYr/lu47IatClBD7yLHYT9jn/No39HgdpcxAt17g0fuxJm1U3MCiHGM2zOLI5YIDRs HznwHYKdyiObsjxhALYt5NlBzwAlJM9DnhV6AFHt8t1pl/tcgRV4A0NqUvw0mx0OB5TQcoWy/NsA xY6JXCHZR3qGHNjxuJzXkUNt/54ljI9CUzEtlcZSLMiK/yuLWb2ZGiI7q6+mfCKwJsaGTPnDb3I7 xRM+QzHKjGP6NQZaYchtw42FwsDQvcRAIWdhMxyGYncmGDb2Oe39Aa2ssDaS3gnwoqYbU/Gfkh5k 23ZR4LnHoHBKcGJfANnmvnUC+1ry2K6FXMcakKd+nxlFsjWwhcq7I8X/OwDDR3ZoCmVuZHN0cmVh bQ1lbmRvYmoNMTIxIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDAgMCBSIA0vUmVz b3VyY2VzIDEyMiAwIFIgDS9Db250ZW50cyAxMjMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMjIg MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIg L1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTEyMyAwIG9iag08PCAvTGVuZ3RoIDEy OTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV1tT4zYUfvefQI9OWyu62JK9 M31gS9qlw1IWvNPZYXYYkyiJO2BT2xC2w4+v5Jt8CwSWbUNLPJM5tnXO+c6nI33y+KeUgWkKcH6l 08gY/3KCwSI1MEQIA+4RwDCCLneBxT1p2C5IhDE33vrG2PeJ9PLnhgs9z3UAkldpOhR6HHPAKYIe RQT4lwbKB6gkCPhT9bcyzJ2R/4c0LQwxpRT4e4aFZGqZWw45NTnkcGdkEU6hbe76Z0eT4/e7h5ND /2x/7+x48qF858g4n/1fDf+7InYRVt61gtWB+oa/FLU9j5PLIKtv43ltZo1R68HYZpBlSXh+nenR YVqb6TJeRfXdubiIV3mJLoJ4XRkdo+CLMK74QlBGosXwB9h8F9yIJIyETh9Es9o+CSQU8aVPzuT2 KkxE+qZ+QLim4SoJL37QbxCy8xIIh0zOdhdf86ewutAuRrVwnh4FC82dzT6PLAa52Zlsi7JmpWsY awXejzKRREJP7l4SzLM8Wo1kEK8KxgaQTnaPNH/77zUt17JXoiycBlkYR3kCTCHpZjitU5BR4chH FfnKh8GhpL9Ns/hcJC3WC4ZojyJbJn2YpAFEqALS/+H1r8j6V7SuTEJ1daf3M9bx62i1r10ZTmWw yqiZcyvDq4wXHbmYWc15xZupO5MOtsn31j1XEfW+EdXV2A+KloLtZdddLusB3ZV7JoSwtV3e1daB iBbZsr79sbZwsYRk4wwvobt+3+Ue3gAQ81ikIrkRM4XUXhexilLsPHdt+tW6cpssbOtk7Azohd4C 1ivFhlJ5nWr7CTrZUMWZmEth0mIUao06EVO1iWo9gAR20UjxJK0tZT3+m+DiuiH2objQWePoQuvf NI6yIIw0xmwV13ZS9pAW8i+ZSPWWvFqGU93IQaIzpg35yXTAv0RStEH1yNmwngYzqYhmYbQYVPdw EcWJmA25JWIqrhTFD55DOmczt3U22z38tA2nsh6Mb3Aee9XL7Y3839LLgW7WujlC+ublSWepR1s6 L9VK/+qNazONHJjn51PHtu49Qiu3SR3jBo5HlvFP66LX0sWfPx4c7H70322DOA5jebpCkq1TyNZZ 91Urn6CV6CV82PxvVXPzeWn/uvdFnu7T7u+JqvntdHLdBvb6KfmyPyUxamnm/t7k0N/3P/2rYtkB 8dzfkah9CtaP6iVeFvk1xsQ3MFBXOo0Mh0KPE8A9AhwkbazWMoUUuyARxtx46xtj37flaH9uYAw9 T+1VCJSm7WHoUNcF3MWQIOnlXxooH6Gi53OBSV7gUVAm/1OmD4FRuHqAcxcylwDC5MbBgE7+O4hU +n5SBdShrJtUJVmUOT6s8/Skp9P2LBqGKX9lSUj+yjAFsAmI54A5bdglYXJOnJKyAjTSoHvsYhti 3uIXVfyuBUqlC/OAZINjR8PM+xrlCDEeYzQmErFCaFEObbux62M7Z2SZZfcUgCmBjLqdAgYhMQYZ 8VgDUUH51f2Uc5mAuKxXSNEUb8bj1WoFQ5HNYZw8D1BsI+gozy7SB5oD20z6sZYfrHeScRhlchO1 zUhk1kwZwVz+Zem4uBlZSiTyRyO5YolpLYORVGjzZoRNkUj5iax8xesCiefJ2nBZoSrQczYpUPkR jLz+VFw9MBkUc9n2vNdWxCuKFLcKvNqdrJH6F0EHMqUOdJlTTYpsCdnYG0CmklvbpY9tHuoQ6Nik 1zzF8cJKw0sLE5jdVi3+9wCC1W7GCmVuZHN0cmVhbQ1lbmRvYmoNMTI0IDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAyMDAgMCBSIA0vUmVzb3VyY2VzIDEyNSAwIFIgDS9Db250ZW50cyAx MjYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzky IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMjUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRl IDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiAN ZW5kb2JqDTEyNiAwIG9iag08PCAvTGVuZ3RoIDIyNjAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KSInUV9tu40YSfedPDN8iZcMWm3fOm2dtJF5kZpyYi2BhDxZtqilxQ5MKSVn2Ih+/ 3bz0hd2UJWcDTCzAKInsqlNVp+uy+nsTmGljwu7TpKWx+v4WmpvGgMC2oRnGjhlAG0RhZFphTAQv MmtsZMaHxFgliUNOJZkRgTiOfNMmn0H0XRCHMDRD1waxaztm8mjY3QvUiA2c0HXNJCW/JQdj8e7d MvkPkS0IoEsfXBqWTQAQBOSdu8UP6AnXeYnLd0uLnATeApVrJt+iojrgF/adCVfPu7zGzXv2gxMy 8WJX58V3/Ilte8svyT8MJwQBQUkQcJAEn/hHsUbA69+ScN7doA1mOr3wy9IKQDgC8olATVhuIHpq 9yao1uRbLkiKr8sW1yVume7LGmVtp40h0eKlygIN0quLGx6/6488LPt2i8s2T1GbV2VnALrAmVq4 YyacZX8wXI7Bp2cCoDP6OW2rB1xLUe8j5Coh8ojRV4LU88UJwhls9ghJ/YPzj5z5Ry7zkYCOBqgS a1XbzBLTy7R4o+CPQjAKLJrRKMSj8JfW3GebR7+LYJdQxlZXS52/WUc+vdZjb4wfoUb0NAPyVVRI 9LtEaw9ECrbFRfLv68urT8l18q/utqn1o1Mma3JVPT/ictNupRDoLpysRxeri7Tdo4K5er2mF7rl 9XEw9OrdHorX73K2LDeUr+bXn7s/9KePAuHsaAYcN9PHWeXNnZqY+0W1o2UXFffL/hhUi/ud1tCA Ekxy5cREgaY+vYL5vNCA2dD8yRn46pi3YHimDVwdTpiQbPnIsG+4XGVMbIVXhHLDfssbJq5xRgYl PhzlfGa6xSllF59PgAO0KJ5Qse++RTaACzGr815kOS7WeuwCOtS2df6wb7mtB7zJS/7CIW+3fDwY UvTwIhxAcnXLp5eo6KrbOGP4UpceZoWjjhy2ecohNDuc5sS3RpuL3tZrGVMgCjmhrjViFoRgySHN G+0wOR0/jmSoKuicvBZsa+E2+4cmJVnC9bwHc56Wazo5CjYm2eoD1jsCJp68xrDkaEj1Cdrh+hGR vaFVTvIhFPG3G7xfV+XL4xHHa/kcuSHOifhrbCFpulas6G+jgiGriFOtzvWRrdPrf8Y91hUJqAfW oMc3oSRFTlufZqqclvavuaEWGnFjFC2RTcj6GTe7qmzwSmnJO5T+iltOFqk+iWrwc4p3Y+TOiHe7 FYIkU1e4gB//eZuwL58+c3mN06pGgpvHC4+QjzIt9muhrp3NFCFFJxJ3XQn2ykoBI+RKKE3kCucl uTDlhp/dF8WZaNMtqkkxwrVQbT/gFIkd9/zSrtLscd9wvx6EN4U3ijbfFfhNvBZweHIT+U4LsMHl WuDRDq31hVLJlUT0/+K6kq3x90hBO7MQljjFTYPqF00HsPsxSjdChQAKhYiw7+eLT5fabji0eUGX 1CXfMphNqtn8bCaA0tFDLNbb6iAMApg0Z6CSWg6IugbY8yM2nH/kzD9y2X5J+BktlJmeGWTqmTJ2 1BsFfxSCUQhHIRqFeBT+6pqD7j5PtpNuOTl3NbH62vCW1US/mAzJYytU9zJp7QqwkcIUNnuuWT5l Tf64poqafuxnPXE5022xmh2x0wk14EifxvUTXvfoonmlfG3kQC1+ryyX+iZE6mvO1R/7OxIFfqnB Cba6I46ty3T57UiZo5k+gg9os+R4k+XmVKwnx0Vrl8flz8+B1LC+JhZyLNM+fGLHfELFXuif0i4r tU+hJar9Mq3KFuWlMLQc+CRSD+VAHU3OmEayqiCdV1LCJxUmfX/7kcmU7BzQ/QKjlI9KMJgZlIqq 3Nwv9ZPyvCN9WPrk1uOBU4fFBgurBQ+bNM3td8KyR6dFcc4Wd6Z8U1a1AFE6WONh+wESimOjzFs4 Ve4fH4RpVqCRNHaRWb+g8zsWs1TeL9k3aZ0ShnSRXBW3025rjPWZG7e0MwgnGX/CdZ4Jy87cNvh2 z8WJc59leZqTSf9MyCglW6bEDIFO06X1G25wVxV5+qKPXMf4mQ1XXMrWeZbhesDMPH7T8tSVJGH/ u+YErogXHMyBeCssVEgfbLnCpUjQVhY8pwK/hj1XKIRlKj49My3DrMYd+mVYxvrg1xXds6SsnbKr 6BfJkehqstItTvt0/HpmPmbZLldYVGvYcHx3lNrqWyrN1cXNSUytHmh74s2EVPLtjBuZUFGklkFs rW6veX/J9kUxYYI9GYSOXNU9CWTZ5imi5ZgbfCalgdQFzpWPlRDWZofTnNQGUj1e9Pk/FgTSpJt8 3XOAvSMmRpwqdOX/B0TrYCmQV+w8t4g26BfV16vnXU4C/p794ISc3rs6L7grjm17/QQbqiPqZL6j CCPNnHu3uLtBGx4SL/qiLUOWG0gzldT29P3vumxxXQrt+rJGWdtpY0i0eKmyQINU5K/IrQuJHv2i 5R7Z8945w9QaSgtfAHRGP6dtRbqUFPU+Qq4SoskCpgvSVWJAk36atDR8F8ShY4axY/o2kSGNsQtc GJk1NjLjQ2KsksQjbyeZASGIY7oe2uYgejEEvhtFZhhB4NjkVPJo2N0bVHvnBtk4KYgbNBj/jZjP TaM/GpthGIEgckwnIGEKTG78F7Ok5lWjFKjvBlOj1MhmsPHT3MmYnPTlk32sA3qeSgRScjAW2PRc s8rMwJdhDwEjIfaHkPWgbQ5aiS70AAyl+NpjfGeBuuRIEJskGiH0OcyOEnaHEMIVtFeECy5FaLkh 8MTLBb0uItu2PeIAdB0QuNHEAS2kgJDTiQMBUR/y3fGQh8SAEwWKIz0p3q9Wh8MB5LjNQFX/f4BC zwY+PTlF+go5oBeQc4F0DrBLuMppLVmSkRG31poKKCP/2mbVf6Hbp7PoflqSC+gsrC1aeiBaPC3h oq/CVndHuYNOHBPf4OAhdTD2T3GQnnOgHaup2L2SDBeGhPahQisn7p3EzxQ83S6sJf2P0QSy6/og CvwxKYQShNgnQHZJbL3IPZc8ru8A33MU8vTl2mryRws6oH0eKf6/AQBoFubMCmVuZHN0cmVhbQ1l bmRvYmoNMTI3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDAgMCBSIA0vUmVzb3Vy Y2VzIDEyOCAwIFIgDS9Db250ZW50cyAxMjkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMjggMCBv YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RU NCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2Ug PDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTEyOSAwIG9iag08PCAvTGVuZ3RoIDIwNzQg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV2tv20YW/a4/ESKfrG044vvRb07i brxYO67NoC3SIBhRI4stRSpD0oqL/PheiiLnDh8SlabbYhsJMIYWZ+65Z+7rzF5kjhJmir77ZmEy mf37Tlfus4lONE1XXN9QHF0jnuspquvDwvIUzibLyfNgMgsCA3YFy4lHfN+zFQ2++6VtEt/VXcU1 NeKbmqEE64m2e6E0ompwOhwfhPDPYDt5e/ZkqhquSayexe359cuseYpysUzCuFiwBfpHszwP3pf7 muc8bZZz1izDNMmKNT5hKXasxHsZ4w+MN4+chSx6YNlUdYhbA7Vh8S74Dzik6kQ3TVMJXh52jAq4 F+c36i3LNoCHze4ur2YvVjSOWXIvMGxo+CsTzm+jfCVOalYPNI4WmIWr8xfPmueUDxivPFErD4J/ HbkQCWgcsSRXLzhHh0vgMJFhuhAPTyNgf7mMwvKE5r9JsZ4jrtPdjXga0c/GoQtr5rKnfX4/lcOJ coEnSQWKJWfZ6ilpnl+lWwYhIKhEsZaCh8JASDMmzv95H1LggDHSgQOBt0jR0RjuPiLR7T6i36rr 6suFKBfnnR4GHwqW5QfDtTf0Tksy8Xu6ZjLnvfl3DPavUSISJF0eoGmFckQKYumG4yjLUQWh8/SB /Tx99jnXeaCeGI57tJ4kDOFAl1xWuWiB7GJIcjocLpPCKYo4PODg1flPiN99dBWI41NL5jDyqP+u 2n2A5jmP5kWOIqk/GhP2EVWDIo7FEQW8l+RRSPMoTT4rBgEFW29y0uIBtmllT4TH4JfyCfXJt2cu RAHBjl1f/Bi8v7m7ePPy9fVPV10IB846gC1AJCxTvqb5MaqGoPSxHaF8XqVbcWlzFqdb0i2VshPw k1uGyc4H+GjTPfruRx/+yRj+yZw2dDjEk64Tm2sOb45qNlr1wq4XTr1w64VXL/x68f9xcou0sSH3 jXr4W+XYsbe+6ckmOVw+TfHvJgyjUG8kkDiUCfnUnPhf6G35ardNN4lR7WwH45OOCafPRJgXVFST m4wVizR5XA/Y8gZtfepjXTUdXEz/2huQWtfQXfyxTy8J7X7y5Ak5aq3i2+u5sGvcCZrr2r3vEWs4 FFof0ntdhgNHnI521KfXYl3L/kz+/16pX7n4B7ogaKoC9cSIxb0DZL5Cza3b+ebsHvRO8yhJJGM/ Gs0f0QYqF4pxk8WmU07iXTkRo9t2FYXCcrZhYQQuoREQeV7tPdb/l2kMvTtK7rvd+0SsaIgrqcgI ug9ErnwF+IcdEjQFz4UMogfswkjKE7pmnzXMgU7Ie3nZMEkWJtjcsblVGj/liROTwjouiNn7zV3l TnCiP9evA4QujIvFkK6ksaBwk/ITwA0K2QGDJ0RVzvg6SoCpKh4rC3h+D1eUQ24xjsLrOQtpIWm/ U5NASvgT4K6LTHiPNBdFb8R5tIl7FYsl58uQ6kyw+tvQRX+2d/OiLlLIn/Fy9DfGUxkeqkFMhH3C QpZllD+OjB2WhOkC3y5EuojYqgS0/es4MEZsvgm+Uz1xEqdJVgkiiHNkT5JIb2+/e2EYrv+uljL6 WG1ndrXd7cX5m+DV+8tavv6F2q4N5au2qxZ/NwX2Vdsd1XZlKP9vtN3tfqBQzwvUQC4XZS/PH1sA PrWSXDUMADO2Vv2DBVx9c0e12y1T5UlKVPp6/qtEIHGOqDpJWbn1hZnGVy33VcuN0XKcqeOmw4F4 jdolpDWjflGN1+rZ+C76LuIVfWA8StCARxPB8R0tBdpj19OLj5uIs+xbwaMrhpANj2Ix2xqaZu3g GG43U1tJUCL0IC27peHtDb0XLFj+u17xp5oOTml5Yumfvy4T0BYJE3XnJafLfHdag6QXb3lYX1e5 OL8R/F1eCVqk4BjRwOrhwJUbGekz+jrM0znjEusVQ2aHImvfqOpGIUiSCvnJ42o1y+NRnw+W8E5K RGj+LMUHVhcoueUSUP0gj+0jILIFstUj4U6Ana/QUC6pM4Y0XEjFEVi3Vk6fgB9bSHCz7EAWkUAF ewuWhVAbkf+I9jsWSr5aBGmcy1ORsuQh4mmyBkSSkOSsl3AaCxm7SblMeoZe/FBA3Vk862WE1wPc l63WURLGxQLV43mKKrDwotiPJYOO4MoqOV/BbiiwR3LcZwznDWZmdEQvUuRpkuZtGpA3j6dGL+Pr KAH7qEQkRSwabbiiHHov4yj9n7OQ4pw5qRl2BwLUHi+Cia6U3yxMJrZJfNdQXN9QbA3WetlITGLq nsLZZDl5HkxmQWDB28FyouvE98sBVlP2S8vXiW16nuJ6OjE02BWsJ9rujfL0XQnVjV2lvaFlXQXj H8B8pEyqrb7iujDJeoZiONALHEUY/0FJSvNdoyVQ23TaRksj93sb3w/t9GGnLe+s6rxT7i9XACnY Ts6YYllKulQcW4a9Jwz6hb2nrAKtCdAddnWL6K7Er1bzOwjUhC2OrwAbrm4LmLt2pO0Q6vpM12bQ 8MwSoWq6xMIThG7tGFnl+QEHdFADjum1HOiF5EAHNnwHIaoo3xym3AUDhud0HKmC4tvZbLvdkojl S5LyLwNUtzRilzvbSI8Eh245sM+R9pFmAJhF5cA0LftPri7KBV3CnzybVQ9Ttcyw3b+mME0YZ+qK Ti0QKA9T/awaNdU6/fYOGr4Pvul7D0sHfXuMg+U+Q9f87lVsjlyGqbsQ9m4nrAy/chJaK4AvK5s6 Lf9CiZYhm6ZNPMeuLwVCAgJ7BGQTuLU889TgMW2D2JbRCZ5qJlWzaK3qBsk/1iH++wAS+EneCmVu ZHN0cmVhbQ1lbmRvYmoNMTMwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDAgMCBS IA0vUmVzb3VyY2VzIDEzMSAwIFIgDS9Db250ZW50cyAxMzIgMCBSIA0vTWVkaWFCb3ggWyAwIDAg NjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9i ag0xMzEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIw OSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0Nv bG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTEzMiAwIG9iag08PCAvTGVu Z3RoIDE1MDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV1tv2zYUftefGB/t daJ50bXAHto03TqkTZao2ENQBIpNO9ocyZXkuBn643co6kJZspw0KZYWlQCDlMnD71x4vnMmB5mD phmixZtNY2Py2xlFi8ygmBCKXJ8hhxLsuR4yXR8GlodSYcyNl4ExCQIGu4K54WHf92xE4C2HNse+ S13kcoJ9ThgKrg1SLJCHmASkg/hgCh+DjXE++mlsMpdjq2dwvc7yenIp6mGorVjm0WrZ/JXM66HV bL3NRfZLPc2vmvWZiGciraercJb1rkvF2HSwOzLDNXyO82ga5lESa5g/BH+ASibFlHOOglfDqkUz KSS/rT9sovyqnvwr0qSNvlkHp9eTWExFloXpLa4/BRroziEiniazKF7UH96+P1N6BeUnu9Qk+HkY /zxZLpNNr6neB69Nr/knDeNsnqTXbXupL/X0/PT1AWOu/6FQxCOYNjiIDBaYBn/LmRZA5yMXU6tR /UVwcXD8/l1weNpVZkDIgJa6MbcQa4GmK9/BANGa52l0uc41vzTuzK6STWOVSwFG3TaBCirmuDKo ND1awUYwSOClQvCQcalK96G7/2K7/+Lj2jYO9lpRoh9XC69F1RutamBXA6cauNXAqwZ+Nfg+JG8Z 7a7x98wcftXd3bfq2VaWktehHS6fa78XCzh2IF1DVGk4tciWwVcu2CVHiekIOR8diXihJbpf6xEt tvSL1fDVT7Hc7wN6kKzjXKQSpYVZv8D6+dznIZMzbOm36wn5S8F/QB67CZdrLatFYjl7lKQ2TeIs yvKsT1hD2NQpefQyyrtqDiqxBvmLWDRoI3DzQiPvqXJ8W9OG9lOxSgXwfd4SoXFpvknSf1q02+iS QpWAFfR7kQswlN3HUBfB8fHF2dsXR0dPgas6aL6ctdgP1vrBWk+Gtc61IMcYf65l7uEhaj8CEZ1C tklvxEwxkTfMRDuIiH8LNPTwhHVnUtKS0P0oCJK7xgTKMT0NopbB9vHR5iqaNhEUpnpT2eTevDm2 1dWtV1o3JLtQvS0LY42iFnGSalhbG1NoAFeysdpOv3tZyWmx0rvjdweHF2eDXNTK6F+VldpoHquD qjinZZavNGjZapD4Rv3F3O/hjUijWMS9MXEWgpbitmvuw0+rCKL7ef2BuY1hV2m0bMohRohVWIe5 uFN2b3GpROhBSdxNr+cn4aJxi00+9NZIJnfu4IKW4DeylIu1i/QqDed5Ia1G0otX605aAg9fnDT2 e/O2Mcsaoi/Oo2ko75HK/nyob6j4tqZS1bn0ss/xNE8uRdqyurIQ75hINiv7jbQjBf+on56g5G+/ ftLKJ+1e7ZKjxPRcgz3VVr/Y+xVbB6r5U7XWwO0dKrYYJJYv4Liv46+hRmmfxTUS3e22bSm9CWyn 5+xH89z3XCZv3bMHPb2qV7n4qZyh+NOvbqDuZy0g99/Qu+AyGS8vbOn4J2WJB5zx/wbwYWBQJN9s Ghs2x77LkOszZBMYU1nIccyph1JhzI2XgTEJAgtWB3ODUuz78gITVA4tn2Kbex5yPYoZgV3BtUGK FVJ6oShlRXichDIy4PCPcHyEDLXVR67rYcdjiDkQKw5qDv8LxfL47qESqM2d7UPlIYvyjD937fRh p93eqbzhyP1yBJCCjTESyLJRMkeO3YZdGgyC0i5NpkCTBnTHutTC1G3Zl1T23QmUwxbHR2ANl9oN zCJoSIGQ0gklEyg4uURochdbegVPrcIiV3k+oAAFTnS4t6VALyQHKmDmOxoiZfLVsMldOIB5TkcR FRTPJ5PNZoMjkc9xkj4OUGoRbMud20j3BAe1HNjntPbh+ppOoqL8sEbQs5gzOQjn8JNnEzUZg1ps VHwaQ8piI/MqHAPdjW7GdKRaPbO6fqWCzPdBN1pqKBX07bsoKPcxSvyuK1Z7nMGpC2HvdsKK+UpJ 8UmCJ5iOzLH8FeEWZM5t7Dl25RQICQjsO0DmYFvL4/cNHm4zbFusEzyqPzKz6NqkDOefqhD/bwD9 kr5UCmVuZHN0cmVhbQ1lbmRvYmoNMTMzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAy MDAgMCBSIA0vUmVzb3VyY2VzIDEzNCAwIFIgDS9Db250ZW50cyAxMzUgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag0xMzQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv VFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+ PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTEzNSAwIG9iag08 PCAvTGVuZ3RoIDIyNDEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIncV1tv28gV ftefWCIvlboVxSHFW4B98NpOV4VjuzbTokgCg6KG1nQpUsuLFRf+8XuGFDmH5FCWNkERrAQIMyJn zne+c5+dZ5YSZAopv1kQj2Z/vyfKYzYiqqYRxXZ1xSKa6tiOMrVdWMwdJaWjcPSzN5p5ng6nvHDk qK7rmIoG3/3SNFTXJrZiG5rqGpqueJuRVr7AhWiqbhuG4gXwn7cbjX/gn4n3X9hOiUoM/uxiNNUA A4CA1z6Of5hM4Yw6lyy8NW3WT35UiF3IaLRqdknYLHN05Mx7uL65Pr98uG/+8vM8ZcsiFy8FSZz7 LM7EDbukWac0o+kTLSU5oBtA++z9Y+T99TDu5XNOxYVhEkXJjq7QY4FHiPLjVbJptnGxWdK02T7S mKZ+Lr8E61ziFec+jYnVgjWZWqo9zj5N9v+aR6oUAhXr6BkplSL5TGh7eXY7u1+8RxRO/QIQxjkL /JwlsSo172H1q/vBAuRIuEWGqPIFumDtRxGNH+mAIuL/LUXyAZxYR1kisV9GkcSOsw6IiOnuRMf6 lT6z+LHZbsAjUuZHA5Qi55W4pZ9ir8kFQqHd/2gqNsU2idGBeIWR+JVfNTQd61bsMU5SBLElJKUB 3WKXqW+tkolu2TyZaDyNjL9NkulEz/sP9x5ynSTJqNSQ3SzTMf+B0KF+sJaFzgk+0QswcfkXcHfw dbl7dHS9/+Xmw9UFDiCJkz8mibBVlhRpIN6qkvAJMVqFfEwzlHuFu9UZr0uyUOY2on6G9RHrj3fv zpsNsU3ts5T9TVLFwAlssxgu2LR59pdJkXeB4+iQJrdMCimjQZGy/PlELv3tNtqbP+tGC5xFMQK7 VmTYKrEFp2XJ9BbvFudn3uLm+qSbjoyxir+O28hrdw+IrICj2pOtk50wy5JC2VX7RLZVEB3Lx6pb 0SZ78P0PGX6kDz8yJg0bPEdig7bkNbc3dzUn5/XCrBdWvbDrhVMv3Hrx57iZs+bIEv+47i11dQ7t Zzfl/zg9+K2Mcfgd/kXOzBFMuTBUZYT7vALnpePRL83FV9CP5KIK/CQSVymRgPrVfcfLevdy+9KP wuskZ2G3SJwnK1rJmdd39UICPi8T3Sq9d0+DYWEWvkdTfE2OOnrYQMnniNFCFFIYMvZa86ZMVIa+ hY7tpAKwo7zQhyzNRL7FrSwUmwRtl0y89mn8TnrktpkcBlO3RIkK3omlFjeoLIZOd5vSXN7Wr2gW APnoIROi72nQggJ+/mpV+CNOc1Bv4VYCdcSy1kTH61WzW/tPFD2iuC2u+vqetU/gtiKsbK6zAQAs ioosb7Vg7UFz4/OWUxw/wh0y9USc3tBExjbbiG6g6W3T/f7sP9IWdsXCkKbwevPPLkn5BCPg79aI 4y0nOeZNXF20TwrGQf1lnS5+GTCn8ih+k9LfwHmww3A3YAF9g6y6hbkMWSQ+kW4MhcZPLE3iTYu0 NUVBieaVyiYo0/F+dO+iKM6+6eBGNN1qNtNm9SFDbrL2sXsjA+d0s01SP2VoMFvRmOH8EgQDswmm qWWWEzr2vfGEsT+NFxtOGpoLfBYVKf0b9g4EL8yRohgSTH1RBE0FApkU8arK3N8i6xHNIKcwDyEg 9C6W3Vx9DLOYM0QZE5SdwP3/g1jcjMjo/QXye8pi5JK4zN77kIrpcx/65Zctg9z0tvlDt5vl2Rbc WSila9q8hKPbqiXtIMWHI3SkvdvHWx/pa5LP0oTY6QfbbiX3rwUv6TEVnnGRAvPlbU6/Ex23sVoS pJCOBH8oLZ0VYENeqsoUXPW6hqoP97r1LNOMKeUZS5UJvQnyZEnTFusVQ0aPojkIlZPUmWsOp0Rb JY5IGzBWnF8tLq+9h8u7u5u7h/Obi8t+tfr67iZM0o0vjDVQ7A+gkXXIqGJk62QnYqFsRSTNQluP nvGa6bH/IcOP9OFHBp5C7VZ6aclrbm/uak7O64VZL6x60TiYUy/cevHnuJmz5gjWvscxcRjOS8uZ VfWlufgKakC+brY/icJYZRdQWp5dXrCnVVlFIvgcShpqui7TNBH16BwGikqKdiiHcVFW6bJ19jHb NHyPtvia/FTOViJbMRqt5MkKd6m9hBQkMFEw1Kf74uQu2Wu9fMYn2saiyFjHTgt8RpQ3/WESQR6E KUR6/+Hp8pQB8mCbLrFRqziVToczb3nHvI6BljHfFLG/jNBEKVq/bZq0+u2tH/xK8zdvJaZ4pDFN /egYUjqaTTms1x2wVIkcrVJWbGGYwJ0q9HYZNBsIfT40ya4SOtQpl7ei/lD0g5VHo9r4mmJ73eQq YGx75AJSxFo9OBN+BPnxX5d394ub64erxb33FVTrR1INkVmEIQtaIRcXmyXiEwV7069nBwzxF+Ry ScSC5xP1OMgsn2F4v96I2CQp8v6UbSOaoxlz7cdSoGXApsgIQVSsBq1yd3Z98QescemNiMK/WRCP TEN1bV2xXV0xNVgT3uAbqkEcJaWjcPSzN5p53hze9sIRIarrcv01Zb+cu0Q1DcdRbIeouganvM1I K9/gt5ckEb2Uf+vvhf8G4pkyqo66im07quXoim4BVksRwv+txFx8XygHahpWVygX8riX8c+hky6c NNsnK0ta/DxfASRvNxpTZW4pSahYZhv2njCg2NxTVoHWBOgeu2SuErvFr1bzOwjUgCOWqwAbNjEF zNLhtBIhITOizWAQMTjCqWGrc1ziybxkZJ3nBxQghq5ahtNRQAoJ2gxLdy2EqKJ8e5hyGwTojtVT pHKKt7PZbrdTGc1DNUm/DVAy11STn+wifcU5yNyCc1brnNqE+IzxQXYCeYjm0xVf+CH85Nms2kym PEuXf00gAPXxdO1PIBrHTxMClYvFNJ6WISoU1F0XdCN7DbmCrnmMgvycTjS3b4rtK8YwiA1ub/fc SncrJekXDp6nk+mE/1K/A9mA/tKxzNoo4BLg2EdANoDbuWOc6jyGqavmXO85T5XRphnbTImu5l9q F/99AEMtxSkKZW5kc3RyZWFtDWVuZG9iag0xMzYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDIwMCAwIFIgDS9SZXNvdXJjZXMgMTM3IDAgUiANL0NvbnRlbnRzIDEzOCAwIFIgDS9NZWRp YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw IA0+PiANZW5kb2JqDTEzNyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250 IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUg MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTM4IDAg b2JqDTw8IC9MZW5ndGggMTU4NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibRX XXObOBR950+EyZO9U2QkvvtGbdr1TmKnttLdTqbjIVi22bHBCyRu//1KgEHYGJMMjWcyEkg65557 de9lMIx10YtFmP5iLxAGX+ZQXMcCBLIMRcNCog5lYBqmKBkWHaimGBFhJXzCwgBjRHfhlWACyzI1 Uaa/fKgpwDKgIRqKDCxFRiLeCXK6gIHIABmKImKPPsMH4al3c3Oj9OkzoLLhTf8H/ktQgUmX45Eg yZQLJUOXP/VuZ/ZkFN/0pWy1G5FiHIRJMV5FJN7cfizmyaZctyckKibPZOuTVxJzK92kdhsDZhNT BrCXUZQYRwkCqDBrRpxdqRmpKfjfC5Z4G3e7JcGaw/YDb/uyJEvuQTG08eLIIJ0fSJPp14hmHBk5 /McZ7ePjyqIKdxMUcGN7YheTYRjE/pJEbuLTUf5Yy0lUj5RTPkg3zoQpTjsfYM4fEXG3u1IBd1e+ ug0PWzcAYbS+LZ5t3JhzOgm4c2ISvXKir8IyPCb2uAEwzmVGuYUyr3GjIWsSMJV41Cjc1cbd+H4+ Bo1SnnqnAbfiLV4SN479dcDx4Sk49kP5/Neei7uX3TN3maBZK2Ky8UugfRQmoRduwUmIvtskSm4w H98Xc+qW2K25VaWpxWj+8lwxZ+WT7bIMbT7aVuF2Gx78YH26mZOwL+nA6BXXknNWowHxnng+hV5+ vOblN+WXeeJGCWj9B+Uuk9vwmNxagsMuwSdhQvX00iTUBhx1CT4jkvtCL0+QtGIAlU5lp8UsSCQn isKojeXqJfA8L9dVBvlyIfl9gwqR5vLxp/tKIj/gMrwblGlt7tJrTH7VpJGfe5+WgrJlQEZZe/eR v/1QvpFlNZULGUDPvFDjpdJXJlBrfPX0QLNUcaaGfmTp4yQHSIreQu/KweMgIVFAyo5gFLmrJD2t YFLLlx2m1zDl0z+fae1KnKcAUAHoFOGpgEB5j2cce710jw7qQKdeEtLaUlE9U0g5k0iloG8UqWWT kSd5Kc/RXvFi6SZlHeHKmxfu9mHM1dFwVcZhkkT+80tC4tKqw8b3NlxFfiXndbGRbXFoU4WO2xa1 +tPq++1j3cq80nH1ytvdFkksT2VdplEK/mCPRuPJl3bgesfgk+lk6CzucStw4405/KrlzuzenjgT vBiPFjPna6PqnTYNFPzeHraTHHTdNKSy4/Hn8dDG4+nkKninTQMFtyffWwieg3faNNjM09TfY/y9 lewXm4Z3gn9zZnOq+OJuPL8a8VDrGHzu3DlD7IyOLBrBu77nnx/v7uxH/Gcbx8OL9/yd4MPp4wQ7 szYuB9D6PeALPJ0u5vf23V0DOOo6yWTpdd7KctR1khnejVludWaz6YzKMHKawN+aZM4645bX/1sr LdJIQF2HgjMZzhYjG9stwJXOQ8H5h1a8ufM4mk6+318B7zrlp+AzJ88AV8DfmvKL7pebVPux9/TD J1WyoW/0wiBx/YBrHcueNExYL51+NXDrl+XmV3f7QkBuMWrZCX9jm0o8KCP1Az/Taz8IoazAs/47 nTwT7hvy2OyWG/3y5Zx4FVuMPFtzHwCcHQ4WoMh+sRcImgIsA4mGhURNpmPIPvcUoEBTjIiwEj5h YYCxSlfjlQAhsCwWTLKYD1ULAk0xTdEwIU2UdBfeCXK6gp2euhii1O0PLvM7Bf+PwvuikG21RMMw gW4iEek0gnSxBP9bDBj8OSgjqin6KSgDWecYXy/ttOhOrbozi0Od7WcjSgkfhB4RVUMMV6KuVWnn gtHA13LJMtJySfpMXahSh1T0lY/6XiSq0C26JVI1DKiVNNPrIqcMIRxAeUA/SxXGUFIMoKrcRYdq qsgmSRoMoEkF6Ip5YkAtJV0HOrJ0jlEm+b5ZcoMCIFM/MyQLio+DweFwAD5JViCMuiEKVRlobOcp 0yvBAVWd7tMr+0CRoAZ+kJCoT7MHSaQlG7gr+i+JB9mkL7Eblj7q07SIetLG7dMc2Xvtwx6J/IAE 0vH65QYiy6K2wdxCZqCltTGQ7UNQts5dsb/iDAUaNOyNs7BCVmYk+cnIsyQv9dl/4p5QVhQNmLp2 dAoNCRrYLSgrVFvVVN4aPIqGgKais+DJ6owU+zsJIpD8PIb4/wMAQ6ALsQplbmRzdHJlYW0NZW5k b2JqDTEzOSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjAwIDAgUiANL1Jlc291cmNl cyAxNDAgMCBSIA0vQ29udGVudHMgMTQxIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTQwIDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQg MjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8 IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0xNDEgMCBvYmoNPDwgL0xlbmd0aCAyNTE5IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvFdbc9pIFn7nT6wqL2u2gtAFJDRvHpud eDeJGVuTfUhSrkZqoHd0S3cL4v31c4RAfSQaDE5qTZkSkrr7O7fvfGd4IzwjEoa9/Ygo6w1/e7SN pejZpmXZhh84hmdb5sSfGAM/gIvRxOC0t+j9GvaGYejAqnDRm5hBMBkbFnx2l2PXDHzbN3zXMgPX coww7VnbF6pDBhbsDtuHEdwMN73PV3/rDxzfNUeaC7liovkR51GZ0kyauztjeO9r+C/YZmCbtuu6 Rnhb7Rn14EH43174D3zYyXPCFW2ur8OnT9OHx7v7j0/v7x7D5j7JYvzO4/T99Cac3u5fVu9Jydm8 lFQhj/JMEpZVvyeW6exwA76ToNaUC5Znze+sTOdwy2xufOq8YDdXK6IOn1OqXhEFjdiCUWUKUw8f aSTxfr45aq7zBQpKf+CZ/lUTmvGZBnUDOFLrfkrYbt7fTT+GT9OHh/uHp5v72+lhTLohUW4i6lHC AGTzk3Kec7QupmYnkHUCOp5fJeBJwJ9IUqK8sN6q2KlLR5tyLgrumv6U6NoTfXjrwB4YuKuw/2+I r5Okueb0G3hPKv8tUGDWlWuV54RgyyzFcVzwPEVGUrSSs7xUu9Z1hpxKItr1yIupTkUEGaePhJbV WlYyruAVPC8QnP37pAqmShoSRTmPWbasa/PCypS51jNvHuuEikgrcx5qhPEbhTFPWPR8nvWfH/55 o3J95I6+7uvJPhPtQzcP0lIo/80pCt2JehDlAixrlXpMgRNUvgnsFSIvRMkySbehI3OWMPmMAMoN rlqWxbSg8IWQsLRIaBNmZSlKnCKHHJ8nB2z0Eq7Zbh2uolRti5iglWoIbpSUMVWpB7yq0hAlbpar +wlLmURxkPnbC2FD1oi3KB6tAonLSGpNIABihYtZAqcSHqP2mMcqNF+uqLlU3OX+Npt96atTa7q5 ADREPyUZuDB5RpCUGzglMcPP1pB/BAdnDYmBWA4qC3gNu5gKTfm8jmun1zPVLe4+aBHjd67/fa2q uvPgqzYl3ggmoCre4NjJPMoTFY8NkysVLkibhHS9fn6/TakQZIkIQXLIlBIhwrbtwXQ6AZBqpxmo DPlAMhS9Q+VHajpuDtFq1otMeCzn8rlAR7TkAK4LQVL6km2IWXB/ogJtuckvzfp9UJWf3tEsQpTB ENMpCJxGeZpWTIiIYke8r7LuQtxtCfH47v6P97fNz4/3ahRALYYkSQ7tESHGomTnu7p02WJBOSb5 ouRA4lQbg3Y51Vm0r7Zzu/qxuoXa7s5QFWeYcMOtiUPLHO8g0aAYUOfCBzySJN/Q50MU0+8FiAXx S3PD8ZVlBWcJUr6WNdrCcXzTg3mxmucwKvxXIZyYo/qtFs7PM1wvY/erVhINXO/43Kinzruqo2dU BfCWk4Xc7tYg0eKtNvM0SI8R7nUJmZ7Jne7aHmC7ptM94XNzhNOvF/r9vfOrNZ6pO/Q+kjnURsvr tYfcAxeN4NALnRSoooeJo+RY+dyAlGExKCIsasY6VkcntajyNZMh9vKciBOsUTUx1bhWbLlK4B8p C0GhBIhaAIxPoj/V8xZb7RrfBZKx6EozsqxmVD0BYrMOLCEYE0X9DtFtpriJZas2NYld6F41TaQ0 WpGMCaQqAeAaIh+bKEIM+7U9m8ZMRKXA1IgtjxLCUsS4AuXZZW0K9JlkVKscj4ohJFVoovX4ukyy vezHu2O6fCXmpkXWJaSj8ePSLzBt5f+7at7AxTmDHGqF4bxNT4AFFw6x63aTA3J3UR2H6ol1QUF/ WBM0WYqyKHKOCwIVXFFbgJKmTt8mdc5N4O6pKC1aEqSc13MuP25At4ILAiWOBBuFpipiyMQCZOal oxxmuaboVJmQDI9gSLSUAlVPnmmNWzCOYONqoN+rk1CLbUl20lwtwc6d/D1F9SctFJSvca+a04iU Qq93m2HreDQ2DFVsWzjnOkeJ1m4tR2mZ8XxZHyWUcFMbSRAZKcNV0VGiQub8iAcELeM8e051mFVg MtAUW/SDdZ4AkaCGcy7BpzlHRZkjNKgekcqHXNT5N4XikPCP0pFEHLogIrx5nks0SVwji4Ct1vse e27N1C0blWwbcgpZJICT5JHeA/Jvk/M/kQXKD5rEvKD5X4dPs+nDh+uP04/h093t08P0dwy6nix1 +QoPaVpI3aMqyfTlrbjr7+JVTf54taGpDyaCVvmiJrlv8SryKFcfO3oAdKjpvP0B5x7UFE5IThet 0Cn/Qf3HWvdty1fS7/IMf6gbqo0w+Sqnz2nCwKNHBOepPBWrvExitJGKCRacyPZKaiwz9r/TVFOb kZpdrD8sHu70PbegqHTbgqrqFMea37IknMD4Rl/23CGJtrrGXM/8L1LmIdNxCCY4/1lrzotKiGGO /FYyTluZilgyjtl2jNzCbkrgfC3UkYUgDXieItDNJZQD5bjIRHcAPBQpooyQdlA27dRobdQF9D4F DFl7iLouK39IFpGWFbPuzPTlagYy50u/ufF51poHMdV3xBSS1SptyU789C29TDhH/7zGpSgzEKUe U00vJtqCElnyXdYLrSXnCJ72aDXAcwF27HHFuigTvV46cEkEkxGYxesZSYegFKC2L2whP5joLZEM HtgpsNZoiWTdnD7nR3qPiGBuPbTq3IKWK5QgcR6VME7KSwdJR4XiQylL5Ioj1Ya5LeSsSCgaLr4X uSi5pqf/nLkTKGzN8NyZtiGTFmR9krX6zott+FUtotuyUZgahAjC8UGouxHWOhFJohJEP+r/qG44 NH3ZYdxp2LON6iOirDd2zcB3DD9wjLEF17YHBOCarj0xOO0ter+GvWEYjuDtcNGzbTMIJoYFn93l KLDNsTuZGP7ENh0LVoVpz9q+Ue2+DbDtbIM+I1XU4fBvcDwzevXSwPD9ielNHMPxTMf3DHX4f4ys Ov7w0Aro2PW6h1aHLHdn/H5sZQArx+2VdRZ61frqCiCFm94VNUYTI18Y3rgNe+cwIMnxzmU1aEuB PvCuPTJtv+Vfa+/fo0BdWOIFBnjDt8cK5rZYrC1C2x7a1tABxBXCgeuboxHsALxdu3209chKyhMG 2K5jeu6kY4AWkueZnhN4CFHt8uK0y304wJl4B4bUSfHLcLjZbExG5cLM+c8Bao8sc1yt7CJ9ITns kQfrvNY6s6GnIcg9yvvbYhzE1QVZwJcUw/pHf1BV2PZWH1qoczVYkf7InFyt+/YV5SAUs8G+/HYG OkEAttk7CysDg/E5BlbrHNsKDkNRvBAM1/Yh7f2DtHKC2kjogwC+YuxBv/qmpAPZdcfmxBvvgwIp AYl9BmQXfDuauJcmjzt2zPHIOUged7t4IFg6sB1Tft+n+F8DAHNGzTMKZW5kc3RyZWFtDWVuZG9i ag0xNDIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMCAwIFIgDS9SZXNvdXJjZXMg MTQzIDAgUiANL0NvbnRlbnRzIDE0NCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE0MyAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIx NCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv Q3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTQ0IDAgb2JqDTw8IC9MZW5ndGggMjc0NiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiaxXbXPiuhX+zp+ovzV0gvEL2HA7/cC+dDd3 m97twp1OZ7NzRxgR1NiWV7Yh6a/vkQ3WkS0nkN0wk5HBks7Lc57znPHbPLCi3HKrTx6lg/GHpWvd 5wPXdhzXCueeFbiOPQtn1iicw2IyswQdbAdvVoPxauXBrtV2MLPn89nUcuBzXE59ex66oRX6jj33 Hc9aJQOnekFeMnLgdDh+FcGXq8Pg69WfhiMv9O2JYbFY/XG7eNs87klc0uaJpc2y2Kmv3y8+j77Q 7yXNi/Hy5nb8dkfimKb36o2MRA+0sJvnFW+WEYmjMiZF9fLMsV2w5dvqVzB15Nqu7/vW6t1FJrNC LfNmmZfbLYsYTdWvhTLiIeUHo2tfFv981zyQdNOsP0V6jNRNW8ET41kflsNRYIdXt8dvpkdPV395 3r9CsCymhbrhrjLrunlefnm/vEaW3Q2bhzKnm5fSR0p4SgsWkYLxVCXpDY0I7G/vgRx5Z1qe0uLA xYNKAo1phBzpjXR0QlBuDD7ed4rONXpTLYtCIk9caHexIwomEhvKjBRlwWvWXDRLH0X/w/K2Y6fC CdqEHcrLdR4JtqbqZ4Rjso6R7/xCx1iSUZHz9Fhu9YkYyEwFuZ08VC7Y3IxSoTDzge2pClG2e8oB VrG6K4ponr/efnwxMA0iEbFRADAzACX5k8kZvi4IqgySqrfSMsFp4NtnM2u3nKkZzAvClxks5eCZ uuhAzrG0gyjWjmy1THiJSK9THOp0MzvI/BodO4eaMyB2wLniwz1TcEPAY6JUtqO60MOSAD4jxtGr GaMRNeUn59viQARFLUf3qabi09nnUvHy42+//0PR1BodKXgB3IbYltxDsvKina7mGfqleGLpfSsf yrn1k9nzC+qlG4ZmnyP1ADyu/iufkEZ49sAbFWKNs0jSU5iCbmRvITGiMIHIJ84VUrVmhelRrzYi O/l1245LWKRdOBEv440pq4LuKYlfbqHYwCNv/lUFh6LYAEYYqrS5PT3RhvujuVmyNOp066MFUSlY ofCEKgXE2xhnDJHImuCE9PADnC1oZDwaaaQH+nQpdiOMk3zXl6KCPKCOA0Rq4kD6mHFdyaCnln5D 207yQf142NWXXdazVHSwT4DkNE9YgUljDeChyB9ZOwWjSN3kBRc4K6pKdiCRAKuq1pcFzU5Rx+iy 4We/hpgRYx/JngqWUtwU1Y1LEvMDckkh6TFjgua/NF94oepwmWCxcsJznElljhfaAYwp0Ec0q/Cf tHBmT+q3NDu/fiZoxphOvtWk3uL0kR/gRoxqS+tj5nK7SQsqUsTa74B+iurcxiaj5fKwwGAzlJuR KBeaCK8ucH3ba9/wtbnCG9YbwyEm9sA2XfpbVHAQMlr861j5nWBN4FIUFp2KLuakc+sWFV3MEiTg dKkPBZNxUejVgEGAgVrVA26wNTXpxfBS6fbzBC+LnG1MOrqrBWgKEoenCWRYUyTo9Iin8jhR5T83 IvklczG5gNKHQBGs/NRyDbrKGOGT2OvEEsM2p2KPh5MEmqn0rLa8rYJfLzUUOqC9dvo97rWm5gUD JNAUmhkVwgQ1jLXV2jyEtrr/JT0MAgK9t4CpSBmmVTpqUXCfnHgxQJhR3OMm13bzYhOP/d8slNvi oJ16ZVMCaCGFOd442lvoEAh7bSV2J1NQg/+UiHPR36Qrvxu2wvHqXCjUEWVjntGIbVnta8UmzS0n W88f/dqC0FeJ+AiJ3WPW7usdG07N4DgmBVU0GikokKlKC9IRxTmT0vkzIAJCtKNo4GTmWULWoHlY qLCDuJ8b9z8ndrX3wBo0tcSU1J42UTkXeJcLY72p1SWg8n7XzXwvR98u/qNQC0TMny4sf529R0ds K+GeUFkKLE+MAlnA1mSN7Mk5CmnX4wt6bwazl5x4YxVBbT6sYILqEzWrs6KlYxFvqWCW0jzvceRV vblmzj/nuv1m1uXZUQYYaQyGsu488rzfGyr1CMrgrhYDl00xZ1QoJh+d6VkPf7bda/PhxJ7arl0z emuMeZWq+AywkoyPZCF2TdAR7lYo8T2tYg/2cjQg7lCjWONJTte7LK2r6IKCIFHES6TnmDnxG5qz +9TkAX7r99vVsnlYmF3DJfUJDXyLe0ErynhVIdxdLT4t7oaqcg87FhlxopU78ha3QTirWX9t/fBN VdfNxfVT0XLtYDP9netiC0S6sjdlpq+x95XW6UQUn7zcAm0zyIqKLDsV+Qli58sSLKQ3e5a/LOxa wbdbMXP6h0qtdOc2UkAYde+oYHsM0OmPUkFH3JaZnJmU5w/o+k1zvZmz8bs7BskW0e7JFE4T+72q kLpMGdi9vkU8WbMUAT+XAoPEzTOMWDr2sSpHxcfFBjWWhsTObSP3NJWFgFRSITgobYEDick5gZcF Q4ZiVupsXqz+uF28VeRM4pJ2m+wF9pKoKNHlcCFMGIWiqx56hdZXxlqTAbdUPDc0o+kGq5eEo3c5 HIXlOJyTX78KIwgeujKrFAbS/B3dlxFBEpANAqMgissNdqrbEy8JbXzPQafvktysc8+N9SeGg/yy IvwOCT1jPPgJc6gC3t9RqOkjkZr72pwZrWiJ2Kjwd0rnU4QdRz2NoaC5zoVpWbMCs4RqOoj3/0cF V84tS9S/AflAH5He6hKiwp3VAswYc+hrACWavgZOoHB3KfteYh3Pk+bhidFYw27NHcjTPMdsKiOq XHxDI4KbXR9Oq17bAErvfee03X5cm1qJ6820tJnrSBJR0qLc3sIiaavlYYkhB9q6JtqKSOvuz3qI XelwO/Itlf1JvckFDj5Je2NgN2n4QXVwoyCa73gZqziQOFelsNYUGpZJxxmr3oKDWApMPxmPWfTU sy2O+QHF5G9eqxorRxsTzmUoTVjj2gSVkEHRsD6kt23HwFFlVxYlytZz/gn6vWSiViUXzaIwgKin o1q5RjnRqxUULPQxIhg1UxLKIVnHtBXjI2lnMWcd1rrA6AQIhtwjC+gjdApoEyoVvcPIgcLwKPpC ekAjJ8myGLSlrd3/M8oBpBNKKi5UFaSHlB9SZNaTKZJ8XRCkJyXkIHvq6GeF6BqRBy/Tk8KqHCTt weD9auBa8pNH6WDq2/PQs8K5Z00dWLsBUJZv++7MEnSwHbxZDcar1QTeXm0HrmvP5zPLgc9xOZm7 9tSfzaxw5tqeA7tWycCp3pCnV1F0vSqyn4kMLVz+Ha5n1qDeOrfCcGYHM8/yAtsLA0td/m8rldd3 L5WGTv2gfam85P54x7/6ds5h51TfWac6kPvlCkxaHQZXFHyz+NYKprrZx4ABrU+PIauNdpTRnei6 E9sNtfg6p/j2GurDlmBuQTRCd6rMrBDpVBa67th1xh5YLC0c+aE9mcAJ0GnqsE+qiOyK4hkHXN+z A3/WcsBoUhDYgTcPkEV1yLPnQx7CBd4s6DhSg+KX8fhwONiMFlubi59jqDtx7Knc2bb0BXC4kwD2 Bdo+u+GAMUuhKw9lBy5GG7kgW/hX5OP6YTiSnFd9NYSm712NdmQ4sWdX+6F7Be08penoVH5HB735 HHxzjx5KB+fTcxyU+zzXmXdTkb2QDN8NAfZhB1bevHaSPkrjJWuMhvI/JS2TfX9qz4LpKSkACQD2 GSb7ENvJzL8UPP7Us6cTrwMev9o8ylkycj27eDxB/P8DADHM+sIKZW5kc3RyZWFtDWVuZG9iag0x NDUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMCAwIFIgDS9SZXNvdXJjZXMgMTQ2 IDAgUiANL0NvbnRlbnRzIDE0NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE0NiAwIG9iag08PCAN L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAw IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2 IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTQ3IDAgb2JqDTw8IC9MZW5ndGggMjY1NyAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicRXXW/bOBZ995+oME/xYCzrw5bs2ae0zTTdoJ1s YmAfmkFBS7TNiSy6pGQ3/34vLcW8lCnbagfYBAgoRSTvx7nnnjt8JyMnkY6//5VJ3ht+ePSdpez5 ruf5TjwNnMj33Ek8cQbxFBajiSNob9F7O+sNZ7MAds0WvYk7nU7Gjge/9XIcutPYj5049Nxp6AXO bN3z9h+oSwYenA7HzxJ4Odv1vly96Q+COHRHlgUpCpI868clYbksDs831/fDx4+f3MOL68NqQ6Rk W3p4pmRLZSr4ZkPF4WVC8sM6o0Top/zXh+vP7/XFeX8QufFVWr8Zg4l/zf4NHgx81w/D0Jm9P+3J 9ezrp+t36MD0sF6Tl8N6ri0m80w/FFwbynIdkWLF5OGB5Qsu1qRgPLdtLFb6PFnOZSLYvArGxHOD 2qPZr6f9YCnNC1a8oJjry0hS4JhX2UPxLlZEJ4+tIRWS56Sg2gVyWH14/NRibZ26KiN5IyPn7KdE skzHm88LgFR72tO2BG5JViK7F4KvrYEGiGo3qNgiFyBZ6KaXyp+O7iwh3vmpOB3n65bvKJjxGwpl lpQZwCZfWl24S6wBeXy4eazB419o7amgNeK742Wm7xL0W8kEtZp3jDKO9oGn0r7vmb7Q9IeCvqZS kiWyoIRzIcqJWXoJT/U3izJPjP/egrfV7YPH22t/4AcTF12l2SWIYsUunmJM+Mfsb5N1EJ+eJiAd d4xJoM/DOuUoOTnXpUq/bziKIoC1LaWvWKKpPcuIcFmesi1Ly7qQs45JwPyAEApZlRraDNGN3TVw TLIWpl3zMtdfamqai7JAmeUiaaJR80vekV//LlF/47k+mC/OFadyHUW3Ld0aZbMVFRTMpzpguxXF AM4l8IeoicEsdHApVghUoNyjEt4ZWLyFjgtb0XkGe5AMeOjlOAA33zdQ6fL3w4sg1hjeCJZpYwPP G+3NCWI3AnmhqgRbhX+UhRN3VH1l2PnlHtfyePyXlRMGYYSrDlUj+H1lDcDHvKAipzqd7wVZFPvT DpZY7VWHRRZL2+r22uCf/QV+6AbNG74crgj61ca4j+kmcm2X/pkUfI7bBUS9ilB4FKIRXNoxSCdK 4XyZSVQp1uposFPFY+kFRfKb9Ti6WFAlcSr/acP/c6Wd0XxZrGwF3ZZYCY0G9wyzwu2ElvD1BhiX YT/nL1Z3FqDX0D9IYUW+0YVOOghn64sIatdg0xyYoKUnSNWkSaafV1wUqJ83KN21t/PX3NAG4V4u 0dvzA71Zx5IVOvBt0j1ZMXAq1VT7B9Z6acpUoSKXX5l2X8ASkW0ngEmqTXikptyYumOD+K3YmwkC dlDU9O4w4kqMKdQnAW8FTQrrkTWcO4jEjVJzKMZPV3dfaZ4gBrr7CorrqW/tKxgSn4jEOHpsVNPd MVo7mJmIl03Bl4JsVkC8GZopJN0QyCS1j0hNtQozKC5f1W63dqmV83oKHVxmYQEnMQQy23hoFGIV Z10Awoy4RjrBQGihXlvwK/N515kNJwoZtWWoISidTy6LOMkkbwv/Qb9afdoIWmdArgAxKTL1svpM BJIDrTPjCWlr1KKuiLYG0qyc9u8gv/ozXnkp+l5XCmr16XwtusdXmQLiUt1wA/SLPR5iT+n3ZEVy JPiWNFe8a4ylVK5w1Gv9WzM+uAFVdZ5M4dYfmi43FLMDz6GM5yW2DzFvY561GXp4sWOoueGNn//8 /O7m66cZYmBB1rSosX6Az6UO7IAQ9U1rPNCgHpmsQIrlZtARiS5QoVOc0NcE6gTcAsbRCAONFw2Z xtT0k/rm4frze2Q/kD4oBpSYHUWaR1CjXRqFoUdJYJQt46U+o5Z8dv2J9OAPKRyDQXYsy2yJSRko KQEiQEf4PqNA+cgMvG7qjMCawzVHsWl0IuTLOWyROUeNyEjIPuDdSGTqjrST79neEyI0CK+NKeOn iektTUgpDbYwuKlF0SO0ECl3XGhUKeXFE54heVycO25bZorx5hnqcXVj7s736XHQ6tFMB/bJoEhA fLN7ypc10I1gutU1OqUsuDipODroNhzwhKBYSlXQ1ohhZY+KnTwfJcatVKlpzkkAIlX+DnyEsgPO 1ol7oBowdvwZ9HVxi2zRAQ01pNgJTwPEqAdIxBa1qjYFg0jgw/3Do65XkjLdyXJaQACfZYXEZhlf TnEfF1aDJDQ0u8eWoOPR1RCLBqOz/BJ3T1Rml5mIA/EbFauNWvPyR1KU0CwDpSuQPyAYFiRBnfUc loG3Y5WTPdrevLnuv25TX4eOdwRJVSfGeGOZhnQjJ1sqU8E3nWBVCLJYICrBwyGfF4TlDa8G4cXg Uv1GJ/Tx4UZfuyFMSKxJrC5BAvQDbgWaV+aiRNMH9MmkGS4bCLRnmNBXFuo46WA0GswRTk8NHzYr 1LDxsimwu51yl5KCYGGNOtiaPCOlVdn4DxVQI6qG2mwE5BlNopIqnVzQ7EWb3MI+bTDv4EAjwcEg bMuSBujqAhCy9YYKCR28sIFxSzKmM11ztDWGXf2BDjTAPKymHkw8PyW0rrV/BPTJpYTTYNLD6hfB l6WB5KEB27khjgtiCOLqxqoef+k6Sgm6yYgx1r0ODBkGIsrnuRmlnTMMOoPElxTzWeUAPVaIl49P /xciRDXQqJNm1SLwXi43ZJkkMJQtysw+sZ3E28/UHqLQlCrWrRJUNLJzlhfPwKnuptq5+fEMU91s VHPKqX34gIFly1I0DYDkgAmyo9UAhp0h3dW4kGgXnq7u/3h86ncbBk/c1xzcCtyZGlgU9FvJBK64 U3BAyJ2XLNMuaRwckQ/mnbosO8avyVFPGE5EZyujROqnYz3W1t9r1Dz17UWRcHQqP2qZUIjBhY40 Yt8y8eZ0mbGlav//0p821fiRlcbIYJhMsBIqgWI18syhwO3ozi3fwcAldNTS0qpYpPqK6GFVzaI5 0BBWSHYOxFmq1ZrRrLIlF6xYrStcyWa/upn1fEf9yiTvjUN3GgdOPA2csQdrPwLaDN3QnziC9ha9 t7PecDYbwdezRc/33el0AiOB59TL0dR3x+Fk4sQT3w082DVb97z9F+r0fW36wb5e74kqWLj8G1zP nF61derE8cSNJoETRDCIRI6+/L9Orq4/vlQZOg6j5qXqkmV9x3/adk5h59jcWRFIpParFZg02/Wu KHzs8IUTjU2z64BBaxnXIauM9rTRR9H1R64fG/H1XuPbamgIW6KpA9GI/bE2c89z3t5C3x/63jAA i5WFgzB2RyM0rvmjfURWRXHCAT8M3CicNBywmhRFbhRMI2RRFfLN6ZDHcEEwiY4cqUDx+3C42+1c RouFy8U/Y6g/8tyx2tm09Aw4/FEE+yJjn3voLEOWF1T09018kKoFWcCfQg6rh/5AUcT+VR+ER3A1 WJH+yJ1cbfv+FRUsp/ngtfxqB4PpFHzzaw+Vg9PxJQ6qfYHvTY9TsTmTjNCPAfbxEayCaeUk/a6M Vxpq0Fd/KWmYHIZjdxKNX5MCkABgX2ByCLEdTcKu4AnHgTseBUfgCfebB5KtB37gFt9fIf6/AQDj KZSFCmVuZHN0cmVhbQ1lbmRvYmoNMTQ4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAy MDEgMCBSIA0vUmVzb3VyY2VzIDE0OSAwIFIgDS9Db250ZW50cyAxNTAgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag0xNDkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv VFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+ PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTE1MCAwIG9iag08 PCAvTGVuZ3RoIDIzMzYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV9ty2zgS fddPhI/SVkTxIt6yT47jTTxbdjw2Z+bBTqUgEpKwpggNSFnO32/zIqJBQbI0iVXlAklcTnefPt2Y XBa+kRSGXf+KJB9MPj/YxqIY2KZl2UYQOYZvW2YYhMY4iGAwDQ1BB/PBx3gwiWMHVsXzQWhGUegZ FvzaoeeaUWAHRuBaZuRajhGvBlY9oTpkbMHusH2cwMt4O3gcvhuNncA1p5pBuaTdmM7nNCnZi3zz TH9046IUNF+Uy+4Fn2t3+W+ClxfdA5PD1SaR22S0KNBGJO/vGlqmDYC/xb+BPWPbtF3XNeJPx+2i r2uwhabdC3/aDWeslCc+DXMugXFB9Vimln450zvhwpvY3cPnhxuJK0/Ej3XJeN6a5rSmxf86bhDJ FlywcrnSOXRT0PTfcqqETdR4krIkyTMV3YsEzZ1zkVCtNWuKlpQcH4vmj8a+GQx3b7wT7dpSggGB 45wjNkNMSi34mUQyE/yZyi9MDg9TjUia04Tn6dPIVKCqgYKHoOJgMhi+ezeK/1e9Q1n3OPxCXqhg OUJBcknFB5LxLcqsbnD1umaCFh+6F04gHbMWLHsvv1jWtIbjBKYPiQ/5oKDCfxXC0Jw2sxScj3dk IR3n+d+aGPZCOHZ9nHdWc0S1a5OPjh9U7/Grdqpy2HVeUpFTGb9PgszL+oQOndaGaltfg/7q4k76 9Frm2MUGyJuXLCFVntUH2K7p9E947I5wRs3CYLQLSLXGN3WHfk1KPqNCiUTjNXfPbVM4VO84IMxQ y5wjmfKRJkTNOKw3BxTmbe3IuYxIpSO6xOl5+n2f1kii38r3Wc+KQ0FMOdVjBGXnaD3JZSK9kGyD ViUkSzYZwVVgLvjqTMAsT9kLSzckO1TipDuYhFks+SZLkdnYGIRIUTQIadFXa2kPEbTvkTMKCHit YLNMbnGgdOEgJIKmVSaRTK01BzgywWs1aFvHwJf+DmfYAdV08vnu/gEL9E6XlQRT8ioyfbmgUqIF JIRkDpbne7rOiPx0JyBeSZVPe7Svx5c8n7PWS+2WKruOoDpi5kX8/ebi8j1+vv5TCwC+XN1e3n// dBFfYO4INtuUVE8fJYiooq8FB67TXkgUmX8jWVrPSuBCdSdGnuy7boeidTluTnRM2wN5Sm8o6N8g E6iJw5ig/q55XtDiGF00AFmeZJuU4v5iT+TOYPmSkpQKiSHuK0M/utAM4SybHYh1uoG+ZHEIZOXW yUNJxLniIvgmTwHTWiL+Aj3OCy6USkcJDuQJl5Lak+6nYcMLTKTbr7eXV99v4p8oPoCnwEHL6YID +ZRArokgKwqtSvE00uZOG3zk1JlkRlVu3mLqWyhX0KZCX1aY/U/ez4rKSUx+arUHmY/ahRnBdOK6 FhpqIprSWnNmpIjSwyHFSKl0i0Z6pQUaTVRF8/rPPQvPCNIJfphlPHmW0Nl6iTP6V8X0KxLJTZYd 8OBBPdZJWYG/VvVAS3Wcz/cXt5/OdGAv43ed2d7WICxUZD+wakEL8BZRimRJV7hLTPWbI1HlTRs/ H1n92Jxe//Dee3pVW2zqAifo+FC4JJ0S0FgsLtgmfH8VL80klG2n18ac5wlqEQ+0ffqO4Ti9zH0F +GeEh6wvwVMSGtc3siC+4/u2mk+u23KCZD55RndRLPBstc5YwspM08yd1v2cViualqFXjtEdTfID FLUbQzawF/JLPdq/WfZb+QO3RUm6cpPnNMOWQAVd8vQ93lImBtTc+R7Rz++RHjZJAsVF8kBoj/sP YdkG1+868kevVW2+yeryXh/jc65fe0xAcPVJc/SepdWR9fJHAY7NMkyygiat+WfAzWm55eK5wO0b osEKoaU5wddKgkphfYFFkoV0o6BIvuZwwVSC0PFjV5ZtudY70QSl36QHhBMhWlX6itIsh7jrNKZS WJbQnpWoQ5KuAfHh816CF+eGouVr/76rFCWU94rWn3zblEGj5IUWqeDrNXLZlqHOoqBU6+STc1yb vTgqMK8pxmeG/K1UB9LJCKOcwlYkGSWoTfuLlUs9/usbaRjWijPDy3K4267U7uXmjwfZNtx+lWN0 rSsFyYsVKw/LhDYYWlqpcOEhqOhTMar6a6vJkdoSmYH02K3mUnWh5MhP97z9ApVyqi9RrZIeomtD Mtkl3JLnnn+kWWqRPJWRvwppr7Aine6crU8zOf+MRibl23whiNKb9GUOlwBEyzUvCgb1QKIB59KE qUVJ37GBewV+kIeVTaSW57q/IOgSwPo94LaX20qksB5xQKlvLhr3FsdbMUWq/ynHm24R+US2X9Dw Fzjbck0GAr8SmoI4SkZf7zUV/aggXTj9CgHNqtIJEri04FIqG9jDtmFW9K3LWFFqo1TQrOuazrmI 9vZHLQHNC1xOyiXRJ2iVvDzh0saE5Di5UX7sUguptno5bY44A/9JfY68Fu6SS7teyZe+Y1APhJvQ YzeQbqDUFJ3af4G2Q7Cc5lr4DyTjW3QJkkBe10zQ4kP3wglk0VkLhjp3x7KmNUonMH3DqtumXqXr /iqEoTltZik4H+/IQrrIC75pG5Wx6+N8QU65ige2Uf2KJB94rhkFjhFEjuFZMLarVa7p2qEh6GA+ +BgPJnE8hdnxfGDbZhSFAMky2uE0sk3PDUMjCG3TsWBVvBpY9Yxq9xq37dRn35H28L/heGYMmqWR EQSh6YeO4fjgCt+Qh/9l5NXx+4dWQD3X7x9aHbJoz/j90MoIVnrqysa5frW+GgGkeDsYUsOzDT43 fE+F3ToMPOu1LmtAWxL0nnftqWkHin+tnX8PAnVhiR8Z4I3A9iTMmgNWjdC2J7Y1AU65FcKxG5hT TBd7WntkWZZHDLBdx/TdsGeAFpLvm74T+QhR4/L1cZcHcIAT+nuGNKT4MJlst1uT0XJucvFrgNpT y/SqlX2kb5DDnvqwzlfWmV3WTVgOVWRU30vHaTUgc/hXFpPmYTSu9LJ+NYK8c4bjJRlNzXD4MrKH ja6M68SUBjpRBLbZrYWVgZF3ioHVOse2ov1QrN8IhmsHQPtgj1ZO1BhJXyvwlZqOR9V/SnqQXdcz Q9/bBQUoAcQ+AbILvp2G7rnkcT3H9KbOHnkawRwXbDW2HbN83VH8/wMAo0IrcwplbmRzdHJlYW0N ZW5kb2JqDTE1MSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjAxIDAgUiANL1Jlc291 cmNlcyAxNTIgMCBSIA0vQ29udGVudHMgMTUzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTUyIDAg b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9U VDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNl IDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0xNTMgMCBvYmoNPDwgL0xlbmd0aCAyNDA5 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFfbkts2En3XT5iVJ2lrRPEikmLe lNiJJxuvvR6lUluOHzAkJCEjETQBjqy/34ZIEQ2S0oiOPVVjjASgT58+fcHsZxFaibDc049IstHs 1wfX2oiRazuOa0WxZ4WuYy+ihTWNYljMF1ZBR+vRT6vRbLXy4NRqPVrYcbwILAd+6mXg23HkRlbk O3bsO5612o+c0wZlxLFWifp1GI1fTVZ/w3Lq2q7v+9bq9WjqgGmwDVs+je8zSYuMyleTqRf59nz8 uiBrOfm8+g2MzuE6OODY8JWv9o9fNf/UtWH1vXHhm+WH5q6H+3fNelnKLc0kS4hkPDsZcH3ba1v4 1JjwJtXBqP7/1elMaPcZfZ9I/kiLu8aa5ziTaWhHY7/+KKjPT/05GEVsOJVfyp3Vv/TCuL65trtY imaZUpEU7JGmzScs01TQRPnd/B1orMDYDDNFdjt+0NcCbc06L7jkCd/pL3mzfDxtWwCVtavgxVXo 9KukWYrgPh6RL2uWsWzTfJDRgwYoJfhZSo1LHnMq7ObPPyHSl68SZbIdCLWxKDRtTGtWbHm5035k XCKv5JbonSQ7Yv8L0mMChS/ZlWknngh3lVdeGCklXfUAgjz9SL+UVEgV7NmDJIWGxYvWRpHzTNCe nTlJnqjUGElBsd81PtfAVyv9Kr4LvnYU+G75sza+I1A8tBPZHeIZB6DURwTf68s43KzP5wVNSKmy RG/fl6LK4zMDwY2KeUTiJE9IjihjyDNnGuaep2xdlyfRtx3A7u0WwQDDLCC31o120qccCa8OZJ0t ec6RABKWA2miZCj9Mrrhkp2QDwMY2wudtb8Qoc18pAnPMihaXd6/j8O14JCSdYx4rlwhuswVdFrJ gBhdpPn+r/EPa4y+OKP/4a/JQOFAiU1oWhYUiVkYF+/3ZtlEmfIJvPzc/LU209qslhfqE0pnllX1 ufJ8oBvYdr49CmBstzuiuwVNSlw7qDzw4kkM1U+s9bNMnjJ+2NF0g8iBUlbutH/3WYpTrFOq6lKK TF4eXb5HdkG0n1mqaSB9PiAqVUw2BZNHfIMEoaHtD2WS0CpoQgwMGzL1C2G70pBDQ53dvfXbkvJ+ 3Zd+xginnBGiDyDe1gZbtSmNHfUMjvL0gAeFUuApoQ7hN4mfP6O2ghwrs4LuGHncaaB7mrJy39u3 mCbn6gxmWDtsWTXd9Be9WhYTZ6hLMKpkQjUCJLSLqiZpWuCgGfC5EAwzAAFB4dU+90d+wNBWa+IO w+gfKnJqxCvF/OlGSAtM9J6gSQ4dKfNmuSXPWFF61oNGv6YFzb5ttFA1oIBhRZo9iPfLRcA2+tKm C20Nmhi4LL6hsV+B/17fP6Qx4NlOL6VUid4flT0vM63JlGYMdfSKiAFqUuFnCW2Z1vJEjxcBesCB X5Od0Af/WXUzI/CCTjoFez5+yw/0Gb9UDRm06UxIhvMamjpi4GIGIS/wnjfLSu9nv856v/0R00pB 4/G5Y+CX3lkRuy51xC9ofIumK56A9ApU4Yz+sC9lWU+Bu14XbnnnXECxhgj3d3yMD8diS/KcZujM kcqhw5PraGG8I9mUZVNAN92zNEUFetlS+j/t+ahkFWl/OFsvo4vQ2kmIa7eA+BuBZn/DXsjLu4F5 VAoEMiVS1/GHt+//+P01EqFRo1+a0/jNhXBAmTLm6NMnKyMFzXngHTxakHMPLcr+TY8oVs3yiR41 5RBB9oy8WhdcjzNM67WepJb/G9jtEKkQCG2H9I8XF4nHfikH7pBnes16B1L6FViq34ODWgYEEEPZ 02RLMiY0QVCntn0ufcDlH02vioIbBpody576KRkA/wJxOqJNLI0otQWBGiOGiDl9gS3bGMIbhP2v D6Ob3FqTIEfQyEHQekDtEYInjOAMPzC57XW+FL0jGcnOMTJfpbc0FiyYPZVbbsJgaGjSkMoso7jv dN4W1/SJM+iqrQG1VtAvJc2SXna6Hmo8a77bwWTTqzpKkA8cwlDg4oiSS+Q0Yeu6NX/Tw2/Ii0h0 pKRh3Rtem084sxj0a60dYla7sxnoT/etid5JGkhOCtkXMQ3jWlzrWBplDWWg2PJyhwI7tCMmxTGX fFOQfMsSfQ0zZ3Tw9JmlWEDQSOml92JNS//g0Y6YrLjnE2eonOCR90zRG+b2YiS3BS83WhAF35S9 zz1eoCcMrRkZkLDkEaFAE5ygssx1tDM6PaCnGQKAKK+0Onh0GYD22oBzoZ0ZSYYcrAXTq4+rkjsP 6bfqt36x9RrqDhRbfujd2dY7KiMd6acUXhaouPJOFgyAfy5A2jSqIXVZaCWiWXJwajEs1iNH32Bf RcLz3koj62o/AH7Kk3IPUrXRV+ehw4YP/GryeGH0eEsggixD5QR79UBU7zp2jb/5mjNoGz82H3hR s1zmBdvpmuk5zvwEzIvs0HIUAgMf/qewLux5tcvA+ekD2WjmgsXn3i449UM8lpjPwP734H2mpj2q S9nrgqzl6bYGSS9edVnYgxQPA7gsLHVlUU1cGXB922tb+NSY8CbVwWiCwxvafUbfJ5I/0sJgvWLI 71A0B6MDSYpt19U6+5VmtAAvUG58BNWg19V/yj2gES3T5jjctnFF6kutzs7Qsc93VKUBMZ4DD2/f //H7a1wqe1r/hqNRVPCy6J8CipNvmTEkXWycb1Yj11I/IslGgW/HkWdFsWcFDqxdpU7f9t2FVdDR evTTajRbreawe7UeAcNxvIDYOla9nMeuHfiLhRUtXNtz4NRqP3JOO9TtJ/Zc78ToB6IoBeNfwDyz RtXR2IqihR0uPMsLQWChpY3/aWXKfNeoAhr4YduoMrKpbfz30skYTgbmySrEoTqvVgBpdRiNqRV4 Fl9bYWDCrgkDcQY1ZRVoR4PusOvObTcy+HXO/F4E6sORMLaAjcgNNMyTEp0TQteduc4MsshXCKd+ ZM9xWXLnJ0a2Ul5xwPU9O/QXLQd6IYWQ1l4cIkQV5fl1yiMw4C3CjiOVKH6czQ6Hg82oXNu8+D5A 3bljB+pkG+kL4nDnIZwLjXN2k/szpqrwBF4mVE5TtSBr+CXFrPpjMlV98fTRBEqXN55uyWRuL8bP E3dc9a/pOf1qB70Yilbg1h4qB+PgFgfVOc914m4o8heC4bsRyD7qyMqLKyfpVwVejYTTifpNSQuy 7wf2IgzOQQFJgLBvgOwDt/OFP1Q8fuDZwdzriKdqdFPB9lPXs+XXs8T/PwCW5WxACmVuZHN0cmVh bQ1lbmRvYmoNMTU0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDEgMCBSIA0vUmVz b3VyY2VzIDE1NSAwIFIgDS9Db250ZW50cyAxNTYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNTUg MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIg L1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTE1NiAwIG9iag08PCAvTGVuZ3RoIDIx NzIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0V1t3ozgSfvefaB7jPQ3mYm7z lulOd6cv096EM/uQ0w8yyLbWgBgJ4nif94dvAQ4qMHHibCY+J0cgpPqq6qtPpdkH6Wmx1KzmJ+N8 Mvt8a2lrObEM07Q0P7Q1zzKNwA803Q9hMA80QSerye/RZBZFNqyKVpPACMPA1Uz4HYauY4S+5Wu+ YxqhY9palE3M5oPaiG7C7rB9FMPLaDe5u3g31W3fMeYjgzXNqSAl7V6UGzUWJE941j3mVbakQqpp +lfFBE26Fywf3aYQvOQxT43uzSKlRKoPJG3GgWnYgOxX9BWA65ZhOY6jRR9PO3B38+lD92D5rvmr e1px0Y0zLijCCVMZKRlXgNHwEBOWr18aiYMl5ED0j9OwJY0rwcp994IURcriBpN8DJSrNjPrdMJj 9O/6CaX47gIY1O1yO9z2Q0pYJs/a7wTqaMMkdqEXQUjzPUuoHOXAkb8xBjbCpaX69O7qcvHLGGWI 7fk1Q5A3Pea81K87olhznZc0TxCSSlIVYICign39Q1FKucKGG2AeVoj2/J6qiSUvNyqUm70EMqTp fqp7hn9xnL+T7rC8CbeylNNyx8VWYQQ6jxhTyBQugEXFjslBKo/3HiboOZCXLeGXqdoqowkjyIs4 rRI1u6xKhR8D4Op9yjJWotCXXGnOYvFeJfnq6qp7CEy7G++AhG3MkzODfjLGQ3uGZZ1X5KfIu1Tk /UHjDcmZzM5i7BLEWGHl4yr++fbH6D7Zo0kV3d2GxRtkqEdiCMzUPJfRYCJNab6mM0FlARKpcJEK UOblQTtHo7+lSGfXgtIMFhw70IvH60iAAaiC2WcZLQWL1TllB/qSKQiFoLrcEKx/UGWCls+nkaRS cTwjW6S/Pa1ZHcrTQnQzYM458OvdOzJ9dKaed6CbGCpoQZFgdSkZK7bDWaCAVWVF0idyZgyg6Q7W 8FcWRayK4uhQbM8eFdvo1EEFrhRUlAwFtg3mUYVAkjdcZfCgUWdIYsJkXEk53lHdDo7bcCggb3si Jip+31D5yFJAzsvN88SUVVFwUaqo4SpMqGD3/YLdMXQAQoG0Bdgrk5dFka5Wdaju6ajlYwe+8B2F k1jJF5GvzIjagvUY8qpDXJJMeQBakNQFA9U+egZWT0AE0Z59Xtzcjsoi+g6SOIPkvceox48BiOXr 3DnEHWmVSsoS3TloUsXImRjEHpREQKOwV/BAoQctCxKfXt+Jo5hCntNObMhIW/xMW4XjisAoFBmv 8t7FgZQliVFT0Ov5HrOjuPgJdV70gWQF6o4IOls6fp+hLi0URJkezm60Ao7RI4i9sxEltV/DbfLG bwAjZdkSqSvOV1MJ5Z6kGZdKMf5DBX+7RosqTfxIZSxY0b9CqqLHirNhwF4Rb/YqzYuU9sJI1Xgo KnPDG56Pr3dgha85ybBlQvjvqzSva46lrD75FPI/+xOjYjQimm2m8/Mbv7/h1FOtd3vZgy4m7nUn i/bEVxm8YeuN4tQfHBoX+lY5+al8u17coEpKCb7IMCkrKt8jEFt0VRJ0RQUqu3Et7K+5hdrtN8Io zAuYO+SsPDNjcKmjea0tCizm96Ysi99ms91uZzBargwu1rN6MAPvZ3/8/HZ9eR7dLVtl8zLe5nyX 0mTdODZ+FfvAc+jF4TIJtJLnmkLU6fbhYuQgeR0ZrpHEJwnrMf+JpFL4DBBgZgiV5I9kueQVmv3K ke4smjZ8W6UEXd4OsepH5STqhSCS5DmiFikJvAMOIKA7iiRCsnXOViBAiH7xcUAHXrNhvnrFf7q1 5nFVc8JAU2qH/+uqsQBPu4crwXPUOWHifa22W6IvKPzv3n3h+ZbgBV0QUO1f5jl9UE/P1kc3UBc8 uN+NefWFQDvCngJ8S1JojffHHl89FExQ+Vv3wvYVvEKwVLHJNs15g9L2Da+9UvZQ4b8aYWDMRy6e dwuC7plu+Gu0BdUd7+lsjqe11n+RU0XCj4Ksyma3Dsko3nozbwTpU7ehy96NtzFgOYY9tHDXmbCn 7UJ/iunqGWNGf8YlX+IbDES9jZBzFKI5GD0zSKB7z4vs33IL/VptVK1cpkT/TiqgF0Fqh4BJDrWE pI7khzvklWCq773aQqjQ4QRHHZ7+lO635ftB0b5QB0dLW+11mZelUopvFYPPB5a6p++kvEeT34lE IvOdbkrW2/rrXrAzVfuGgaxkBBmJWKbUNiJbkv13q4xiZbgh+NM/Kw7qnyrwYyKWkVwpCRdszXKS ngkZ7oFk/FAHizEtypPnRvNQCF7ymKdv1lMfEfBttR9vsqFpgVvC/Nzw5TmcgdC8o0vljuxVcBIo LnQnxG3GbsPRqoTe05QX/e5xNbpwGHB7NOBX0cTS6p+M84nrGKFva35oa64JY6uWdcdwrEATdLKa /B5NZlE0h6+j1QS6+TAMQBRN7TCch5bhOkGg+YFl2CasirKJ2XxR794k1rIb2wtyMP4XmGfapF0a ar4fGF5ga7YHyuxpyvi/tLw2f2y0Buo63tBobWR9sPHPp1aGsNLtr2zZ59Xr6xFAinaTC6q5jsZX muf2YR8CBvrqHkLWgjYV6KPoWnPD8nvxNR/j+yRQB5Z4oQbR8C1XwWyKxGwQWtbMMmdw/Dg1Qt3x jTk+z615ExG4A5xwwHJsw3OCgQOjkDw4D+3QQ4jakBenQ+6DATvwjhxpSdG/nbwNUGtuGm69coj0 GXJYcw/Web11RidLM1a3L9P5BXQwelIPyAr+lXLWPkz1ut6aV1M4fe0LfUOmcyO4uJ9aF23jpzfF qBy0wxB8sw4e1g6G7kscrNfZlhkep6J4JhmO5QPt/SNa2WHrJH2owdcqp0/r/5QMIDuOawSe+5gU oAQQ+wWQHYjtPHDOJY/j2oY7t4/I03aIumSZDg1T+fBI8f8NAOmM/KEKZW5kc3RyZWFtDWVuZG9i ag0xNTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMSAwIFIgDS9SZXNvdXJjZXMg MTU4IDAgUiANL0NvbnRlbnRzIDE1OSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE1OCAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIx NCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv Q3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTU5IDAgb2JqDTw8IC9MZW5ndGggMjM2MCAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicxXS3PbOBK+608sKydrK6L4EilmT7LjJHbG Hq/FmlSt7QNEQhLWFMkApGzNH5/rNkhKaFKPSB4fNqpy+AL666+/fqB/IVwtFJpZ/kSYdPpfx6Y2 Ex1TNwxT83xLc01DH3pDref5cOEMNU4708550OkHgQWrgmlnqPv+cKAZ8KsvB7bue6anebah+7Zh acGiY5QfSCM9A3aH7YMQHgYvnYezf3R7lmfrzo6LP0ic55SzzYNbRhfqjiTR5vo7YYKo71YTymeb 2zBNcs4mRU7VAlFMRE6SnJE4Xm2e5qm6nFN5PTR0CxA9BdcAuGfqpm3bWvD5MPCICjZLNrfptL1r ef1MV2gFZ0uSszTZ6R5exmm35+reWY8U8Bg8CJvrMp6GNCo4/Vg/GtT4g38eRo0NzslSWSSxSPH2 SxbRBjbGFdd8leXpjJNszsLNU/qaUZ4zofZkCvCCJKsW1b+CGjERFkKA2wLxEhMc4UYsmcAO5GmY xnpt01Q2DalLuA3+K++QVg+CGbMFov88Js+094MBZ8l+0hapyBXZNM6mRYz0ulhAYBVktNN+0TRd OTrSS8oFlk9CZylkhdxVbwmoSgDL9WQCIK4aiXEsa8GcJM9iV7S+cqpy9z5FopmmSmg4pA02lyQu yCSm++l8GNt1ChmWYVqDJx3B+1tS2O/UOeUJ4Yr20SSdkI+b2z9iErEFyqNRDBkDognn6qNrEv4s qNr+gvA0Ua+/phmJK8dOzPzPkqF8pba6I0LV2UuwQpGdUTErRI4S+AvhvJgx5M4N4c8onmQlMNAb 8oo0jL5L0wp+fmrpuuPkmYj55v5qRbmyd8vEXLnzHao+Ip6FOVLVbynP/1Rvx4QvCUe05DRWb4N0 oV6lPJyD0TfxfwNhJlQVgHt5z6MGaeOcTonifBzO+V+VsQj7ek0FSpgfJH6mCj/O+2CeLojS0g8G 5XPz+ljgOCFbfWDdcxs1GgMIOcuZ1LPKvnFGQ2jIaMt96YQlVIM4oX1AOc5SwRJVZthClmjarBPb 00Ble3ShnCBxWMSqWr5HPzlQGWOqFPCflCc7A8HpktEX7F2j/0VpWEg/dwYF71M1rXqfE9htVONC 0GNbG+b4uCbdaEjH04umkEgOUPkK2YWOGqp7UWQZlAS1QCGfEIEa+h4/Dhl402jZBoRmy4fL0Z1K pfs71NawzySvh2Ec9AV5u4/0NaeJYFUx2nxzQgnBxpE/N+mEoTZ+dbd0lK/3X1QS2rbjPL1j+u0Y FjcP5qhmTihKx4zwPMaz2ZLGaYbYY41v4diBCv4Ly1XzwmEcfR+dmH0PreVPqjc0BnyahBSFE/ks ZBWeto8VLAlTDtKDFogGr3p0X2sdkTPltSDWPfJYQVwTdOIb8efntD2HHg7tbSkohs4v93RKufRX nLTRIZK/jm82N4atW8aTKtLoVUDDeQJMqkiPd5K7td3m7vHsMhgrpRvqzcB2HrufTlTHh89sxnKE J6RxDA0MtXEaU1mli6QNUqxEThcI2R0kg2LZeuz+S7lJw4LXde8EeO0zXELzlxSNktMiCcuJ4oNS 9WUB3Zyi0Shoe6BEOc4hB+RktbP+1o3kIMKrBEbfHKpnex7e3Jq+7+0+OdX1/Y2SwxXPMk1fKW6s Cv05J1GC58EP39GBEbiMUIaiXl+gQKJCBTZ3DiIsiSS39MTw3tOfBeO0MX38Jgsljmfbz8apIpxv 8/weRb+d0Ib9rglt2McktGX//yb0bbGYUA7D4McTAZIo4nAmweMo7kPVgLTm7/S0bgb/IJJG8u9N ZhjQFJlHaQy48GRmy0c7dfeNLCV1aFjADIxJnL6gJFUMvGaQLOKTCojXhKlQW4bhlOAsT3c1o6wy GBX+JxEOdaf6qoHz4Y7MVPhd42nnYbZnu7habo3jdZXbnYJXSU45VPWNlc+cTPNy3w2mncjlZu4O zI2Z90ol3aiAERWUVUmlNGBCY21beNiYsLrVQq+7DoNc4+q7jP4e5ukEV1ngv+LK3iLLAaN7i//f 7ALO0FVlajRJJ0RBOtd3qu0G9QpKopgK1CvwMeG21XpHIcxPp6bcVZ3dlO8r8OCCenNNkoJwlQqQ fv77lfhmYzEcRd03Rcp3Tl7CP1fPH3czFkNlRdXiXr27ICDrnCE2v92MLlTyQh+mUSWS3jci5rgg Hn1SUqAgFjhZm3Lf200NR735Qie8zfY7NtTR5fgJ2YooR03qKqmOfbgb3fE0bDWK7Yr9ePbl6m78 2FWrikmM+toJjcn0PRSsUbQkcEJQiXKZhHyVNRCu4SA04OVjF9F9WyJpeFq3mM2T6oT7puFzmw+c 2uVsksbpbIXwpEsqG7fSgNuoWmY74I0afhDMPM+zT/1+KHioJ0zk+ixd9jMVDtGfsqz6A1SX/9fy h1s9i6bb8n+j1C7OL5TUbq/GQXM4Q9FoqaV8NlzX7p49HCFF3JfTBgXCG5/jLDyP03BdIY893l6w bI7icZNGVLS0UV7+nkHGIMuDsx7K/nyeHlIB+1lQsUeWp5TvPeJ9oxg/07Alxh0C/BWmX8tOPoUH oo8jS/oig3t59a7aG38b9cx3K3Sn1Lk1YZdBx9TkT4RJZ2Drvmdpnm9pAzh3+Kac1WzdNocap51p 5zzo9IPAga+Dacc0dd8fwnxjaPWl45v6wB4ONW9o6pYBq4JFxyi/kLuXrJhWydQdkVSB8Z9gnmmd aqmved5Qd4eWZrkwZLmaMv5DS6T5baMS6MB220alkVlt49/7VvqwctBcWYXOlevlFUAKXjpnVBs4 WjrV3EETdk0Y1LxBTVkF2lCgt9g1Hd30Gvwaa373ArVhietrwIZnDhTMUmFGidA0+6bRh5SwJcKe 7ekOHtJNp2QE5H/AAdO2dNcethzYCcmF0dbyXYSoojw7TLkHBqyhu+VIJQpIzJeXF53RfKqn/H2A mo6hD+TKNtJfiMN0XFjnNtbpm5zuM3kS6TpnMLX1InlBpvAnF/3qptuTDbp81IWOaJ315qTr6MOz Zdc8q05zvXX61Q5aMKyaA7P2UDroD45xUK6D0czfDkX2i2DYpgey97ZkZfmVk/RVgpeloteVfylp QbbtgT50B+uggCRA2EdAtoFbZ2ifKh57YOkDx9oST3XY6wm26JmWnr+uJf6/AQCUbKE1CmVuZHN0 cmVhbQ1lbmRvYmoNMTYwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDEgMCBSIA0v UmVzb3VyY2VzIDE2MSAwIFIgDS9Db250ZW50cyAxNjIgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0x NjEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAw IFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9y U3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTE2MiAwIG9iag08PCAvTGVuZ3Ro IDIwOTggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIm0V113m7gWffefGJbvi31X kJH47jzRfDW9k9QT03bd2/SBENmmwcAIOWn+/T0CgoSNE7uTqddKJUA6W/ucs8/R5Lh0tLjUcPUr 42wwOZ9hbVEOMDIMrLk+0RxsIM/1NN31YWB5GqOD+eB9OJiEIYFV4XzgId/3bM2AXzO0TeS72NVc 00C+aRAtXA2M6gNhRDdgd9g+jOFh+Dj4NvptrBPXRFbPAHuGjo/a6XBG4zWj7fxDVC7byYxH2V3E 7o6G7aOriCd5FqXtg4us5Alfc7lFPt/aoGyfwFyMPQNhwPQ9/AiQdYywaZpaePIy9JDGyyxP88WT xP8ZzVA7OaFFxPiKZrwPzHG+WlEWU7k4KFgiT4Jd+Qb7vo02gIb/FvTGA5iGP8RM4f1F3N+m12ff 29kZvaOsQ+A8Z6uK1vbZlOUxLcskW7xA5c3o7GI6uxnLVevbNInbnQA6kdBfCQpHJ8rGjwmXURAv o2wh3ZvlPInpzViJoZNkkXDlSLNkkUVcDatn9IqNkxlgHx5tk/wi0jeKv53x9DHK1hF7audECQoC 3kYHMhs8REka3aYKvExPk0zOI/5OWSYzgjjuqxmx5Lx4N5nEJYtRlpQcLfKHSSHDoJzMk6L+Ay4e 6w5yRzp5nutEPzQF61jAqLh7Jtn+29lxfXYsKbZMS6ZKiBS/M04z6YsP8lWQPtCSM/CsEpLn6+SO Cp6l6yHN2vFXlnA1uyKZexdBzdNVsH3CFw9yDHwnIrcr5mUM0riT24kcwsnL4ZE67RAh33yKeX5L JXyQJ+/t5AnsEuL637dfnUmW/0vZgkZrheLP4ZnuyXnUjoQvym1Rq5/0penF7NOBMoANx3J2UQdn 2Z3Qb0vdaTCVtP0h2XqfrrP7dkblqaMUKRSe/oSgLhNVHoI1X0IBU3T8uSLwPM7TA3m6GQHCZ5mt ntyxaM71hPK5TqNCZ/OYEM+6TcpGHQwb8Z9cfv+Ys3s9yfSC5QsGNelIMbIPghktOF2pwQsyaqI+ 4ju613FBWyMfJFHXdE4ZzeI2w5/ztKNmv+jXE8FSOzXPp1MpSjN5EhMRVa9eWiVqDThVKZIFjZP5 pp97TB1QbWpA7fSLjHpkIUPWmeG+cM5Zvi4UX7KHJKb91XT2VIKj6yg6UDmDEozz8vd+FspqY6ku uVTxhNEUYlJmYK4eKWBUitIV5SKUlcz4+kdwVXdPByTURcYpExtB9fh94+wyDmgZs6QQTCqZZyrt zznNmkIhMxwqHDwsl0lxoNdBG34Af92c7as32zm81e7UuflWfW9HHtWSnUGdLMtcKehKG/8xL+m8 +/Zcvv1fzpQXJ/LFLFmpSwKkUJvS+4gdHcjrUIguEEul3+BAvZLchNS0V20bZf3xfCy9KAr6k1f6 y9Oy+n8/RPuLc6/skjftGaS4uLbxvc8jp1HJ0+iednKg1+XHcOG5p0wJTMWv8TJJU/Xl8BqEJ19l TeorLt2/db6msbgPwvWg266pXSK0bmtoFJ+GRz3rNwhQokC50UWpelE6oXHlk16R3L8JhxbGQn3v e13aDoAlV+wu3vX6+0P0QBm0zFIwOvoepfkjfdq2e/qzAB0uZXUhrkzCgiVp5wZlVSiJixzNqAq0 ikr9JxB6yKq/6uD8No2U+6iDv/fyqZvO7kagP+Arcc+Ubq0q6NVuLZJevGIzpwepKhezi0tJS6fJ qwxgKN2bFr61Jsi4XuiOVV87qM9oc1nosF4zZG5RZIHRA0l6SRVmpm4QAxNbysGf6ygVmaZk73GV eFzmnFIF7zotFPA3Ad72KqK/pAIbRVctpxJSHq8F3v7uJJydSxcH7fDruSkfNzIiH5j/IkTRQbOp EIcKQc213OiM3rLNck6kUoAyXZ19ur4Mwosvp32dzxvUAtO0lIb4WKnBVPRMpQKG3iU8Z6o+Di8k r5f5bZJ2SFsXRc74jkufsHtofQ/Wi3XJe8my/zYpauoH/wkkJ0plC9j9fS7PozRIrRSrl8XujjvE ZEfzsR8jkQCktifRfaRjo9t0fFxnVCXNVHz6Wud5M/5nWhBiW56keGe3OLxMYpaXuSIxX6AFyJuK rJfNJUiGWHBy8Vle+ALOWXK75rRsad73jrOJVoK6jFi8VIu7/48E4ex62huExxFLO732eyVAb/Pb 6JcCFKw1nM4+BHijR9lfn7uxrUp01XpvBrte20won6tRXLJCh3vNRhSnT72w9hFeiHp5pputNryJ 8sO7st/axqz79S9/dBoOsCZ+ZZwNbBP5LtFcn2g20OFj0SCZyMSexuhgPngfDiZhaMHX4XyAMfJ9 D9oLQ2uGlo+RbXqe5noYQeXxtHA1MKovxO5VUGJS2Z9GjfG/wHyiDeqlvua6HnI8ohEHsDqaNP5V y4T5baMCqG06m0aFkUVj489dK31YaXdX1pnjiPViBJDCx8GIarat5XPNsbuwG8IgKOyGshq0IUFv sYsthN0Ov8YzvzuBmrDE8TVgw8W2hFkluFEhxHiCjYkQW4FQN11kqZ0xtipGlpy/cABsEuSY3sYB eiE50FkS31EQ1ZQXL1PuggHiOVsHqYPi3WTy+PiIRHIiUNw3AYotA9li5SbSV4IDWw6sczrrUCup k0RcBMbWCO4C+p0YRHP4w8tJPRnrosmoHo1BMshIX0ZjC3mjhzEe1bKoV2kvD0h8H86GmxOKA/r2 PgcU6wg2/G1XFK84w8QuhL27FVbErw8J4jgWtR2P9LH4S6MNyKZpI8+xn50CIQGBvQdkE7i1PPPQ 4DFtgmyLbAVPrWh6max0TISGN9v8fwAxFCpgCmVuZHN0cmVhbQ1lbmRvYmoNMTYzIDAgb2JqDTw8 IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDEgMCBSIA0vUmVzb3VyY2VzIDE2NCAwIFIgDS9Db250 ZW50cyAxNjUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNjQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIgL1RUNCAyMTQgMCBSID4+IA0vRXh0 R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiAyMTAgMCBSID4+ IA0+PiANZW5kb2JqDTE2NSAwIG9iag08PCAvTGVuZ3RoIDExMDEgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSInMV01z2zYQvfNPBLeKbQnhgwCBnOLYruPMxHHH7OTgyYGWIYupRKok Zdn/PgBJASIpyXInnUaa4SygXezbt7vQcnxacjApAa6/5STzxhc3GDyUHoYIYRBJAjhGUEQCBJHU QihAobyp9z72xnFMtFU89QSUUjCA9LcVGYUywhGIKIKSIgLihYdqBeMEgXhiHmtv9MaPv2kxwBBT SkF85iFIIiNN9I/mYxTiXxubkV39GKXGMeHRPsddZP8FhJ9DqUtEn6D/ITPHKu3WbvcCpKtYl7He vB19SB5VkWYqe+MHWhWGoyS7t/JNMs/X6tmurXD+tEwLVb61GySy4smySOe/u18QCv2v8UePRJDr Ut9Bmf0YhAKGjVYH5+118qDsmZx89QMOow0gpgXjIqB8T2l2Urkjix1nl1mlikxV1t9ZkUyr2oNF tzMGcyzfgf785NpxevnJUbWqZiqr0klSpXlWO8AUkr6HW+uC+I1h5G8SYmw43OX086TK71TRyUTD Gh3QFmqne3v6hbL6iXuzm4T7tMqL8pedlX6aZ1WR3q26GmY3mbg6uMymebGok2X2BIK4pXCAueN6 2EBW+KCywjVYvx2ZO/7gKVf532liV5/yu3TuuuV6lmeqfOWJ1/AztIv3+ZOVhXjlSX9cXgWURgTb nThZLFWhtlSPOifN5tspO87qPFgk6dxdVDPDN5xteH6XGebgJF8ME3qYH0OqO/Y3yoRdMOREGVo5 FFIOudvTAcfWz8e8VMvZnhv72BSdpuUkd2c8l5Va9Aum03AHTyMSbeV6lhYuZyePKlupnSe3LXvw 5BuVVNVcuSvty4kVpcC2xHbSW9+if7UX5429QJHTPZbzfk19KxvW300Mj5tiek2z9YrJ0UcQdzJz MqUCHQr2X9XSVV64S+QsubvLV2Vf69iQLtRiOR+aH9u21LVNsXI3xcXqOVMLVfTAnMeeG9brKZvU UzpDWsZmJqCQ4s6QHjZDOsZmNK9n8FYMJYaMCgEigSFB2qozpddcYlJzfJ0YgrXzf7T7FHiNqQRR JCAXBBCu88GBc/4FZMb90KkByijvOzVOHloff+6zlNqSdS2bhPP6hUJLGpJ5q1CAcZBPAWdd2C1h ugdZS1kDGjnQA3ZxCPWLzDa/aMPvXqBUm3AJNBsRZg4mdu89GI8xGus5hRqEAY1guD0M4rBmZFZV BwLAlEBORS+AnZC4HpyI5FuIGsqXhymPtAMi+CCQpijejsfr9RqmqprCvPgxQHGIIDOWfaQvFAcO ubbjHTtob4JxauZcPxzpUTe4N0Iy1Y+qHDcLX4dFRvWWr29oMgpmiR9CMXr08aj5+ww27dcGSKTU seE2QhOgZMcEaOwIRnKYiuULyaA40mUfDcqKyCZI9WTAm//1wDdPlfQgU8qg4GyTFF0SurCPgEw1 t6Ggry0eyghkIRkUT3NrB2W6CDCB1dOmxL8PAMzIfmIKZW5kc3RyZWFtDWVuZG9iag0xNjYgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMSAwIFIgDS9SZXNvdXJjZXMgMTY3IDAgUiAN L0NvbnRlbnRzIDE2OCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE2NyAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4g DS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAw IFIgPj4gDT4+IA1lbmRvYmoNMTY4IDAgb2JqDTw8IC9MZW5ndGggMTc0NiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIidRXW3ObRhR+50+EyUultix7gQXcFzup0ziTi2qRtjOePGC0 kkgQEFhZ9r/vLiAWEJbkS2ZaNKPZPWLP+c53bivzdUH1sNBR+SnCRDP/mCJ9UWgIQIh0x8M6RRC4 jqsbjicWlqvnTJtrr3zN9H0sTvlzzQWe59o6FJ96aRPgOcjRHQKBRyDW/ZUGyxekEQMK7UK9Hwqh v9GuRi/GBnYIsAYWHrYsp9ldFMVds4lZ0aw/pOs4Sliwvh1/8d9piAJXWPN/36/8TR4kIevIXQiQ WEglRqnFQAARQg7qOjdWQRSfNPskzQMwC66v03VxumCrLF4XIExX91nzf96vf7JME6bU/0JIs0bN yqKW22ywYLne2MoIBEJAJPmjF/IZ+1+luBWUvTDepYUibLLmS5Z8W8fBatfQXjUXCWdxs3ud5pmg i0dp8kA9GCHl/cdzJbf5stmc3bBkzX5VPrzBhu22lElLsIw0ps7BSL+N4ri4TvNUafx0qRLWQdjq eQHbWaQCcCUj8HlcnZuOt2ag8v3YqPST76uIEshApuJzGknGtwn4hLxTdNtQpSCmVrOmCKPdMD4x 7yZ5UARJEjSCacADIYuSxZI9MGl8UfZFwNWehcskjdNF1HSUY1UhFypEPOCstcsZ4ypFpuuo9Su2 Bkpzr6VpKoIZB99aeez/0ywdCj28j/Qfl2tZHZnilFe8Glzw+QyZNtDfXKRmgeUiy0J7nVaZ1qlu WP2m5HVljrZJ2Sw6qoYy9m1ww3IxeJIGVpDMWjkapxt2N8DhbRblrFDOYuXXWZZHsQqy6OJW6Rl2 AK1mWt/B5pEIXWBVb3VwXk2Chco+Sr6MDQqcUY88g9BOp1I8tUnpKJaNPE+YKqbf82DOS20NkkG8 UhkdQHp+NlH8XXxQtJS9jEdhOSaqKU8A7lu4akzgOsmdJtnlGQqGjH4KeXrN8g7rFUNkhyJLGH0g SWdJwm6VJ6DVeQrF3F9MoMgHOlDXxLF12tF909FtjeZp3qz5UmXGx4upr65HF5Npq9PRihEDN7Ks YOtZaoiyn7UuNsl6JbhstguWMDHbG4PdoXjMwL2aXL75ogosV3CDG9GKguu4JeGDfs3TWJSiGBaN 5PPl+5Neg4JHX/aWnGcnphkWeQiSqOBgkd6YLAnzu0xmpzkrCvP8NhCXPlbUrCGIreuIg2w27908 nj4c/b2eshpIIyiW6WaQpTAV1Zxw9WaqsIq6NNv1mAXhN9Z+VbXA+TqunI57IT80AYJOjQ+21JwZ 3bfA7pS5h81HUXsGUJsC45J9X4vCMi9mEgK/2/Vwt9t17Jc7MtiFOmGM8lb5VmQ320jRri5EWRxE irMePmtUA+/nvCGhDN5OO3Rt2yqsmynaNtXd57dOv0XO4Dx6nc5ao77G1odWnm3P7Z0uv4UDnwin YmsesVyBgvfCGb7ID8ER96vt2r4H4lH43rNkwZcKm63KLuR1FT4O6lMD6d9lrUC2s+44PI8sStwr yiJLk4I9oCofU5NhHAn1P6nii/pF1irMl+JvoAUdiGD1oFMWZEW0AvM0fakuGkVac4UPFuQ2dFEd F96Jjz0YnrxkZqZgbSK+PHJCVk1np2HYR4Wyn2f4mRtGFfBnKNH/XsfAByA+qmMQ/H9tGfc2f/GQ PiRBH+lnXEtm7ZM9wIW9xf1wZluewAGEzoBs6D3FgtG5Dx1p5jGyFz/KyBG+WAPHaX/atmTtJHGO 9WX7IhlQ6A3IZgOFzA77sj1OB1TO98nks9X3yFlKerO0uuCKu7455UHOe7P03NeQLj9FmGg2AZ6D dcfDug3FGsnRRQBBrp4zba698jXT9y3xtj/XEAKe54pqgnq9tDwEbOK6uuMigKE45a80WL4htZcu IFzOlkkg/RLGvwvzka5VRz3dcVxAXaxjKqqK6sr433oize8alUBtQvtGpZFFbePP+0564qTdPVnx TOV5uRKQ/I02Yrrt6Olcp3YXdk2YaAZ2TVkFGirQO+wiCyCnwy/c8nsvUCKOUE8XbDjIVjDLdIAl QoRMBE0sEEuEBhFNqt3pkFUyIv7o7nEAEQwocXsODEKiFFDs0RaiivJsP+WOMIBduuNIlRQnprnZ bEDE+Byk+fMARRYEtjzZR3ogOZBFxTnaOQeaAjSjhLN8bI0Sxo2ZXARz8cULs9rIzoBHpWgsRgUe GctgbAF3dDNGI5ZHCUuMbfnVDmLPE76h2kPpoGcf46A8hxH0dkORHQgGEZMMQ2cnrbBXOcluJXjZ 4oyx/GZBDzIhNnCpvQ2KSAmR2EdAJoJbyyUPTR5iY2BbeCd5qtuqIea1gTDgt9sU/3cAQvc02Apl bmRzdHJlYW0NZW5kb2JqDTE2OSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjAxIDAg UiANL1Jlc291cmNlcyAxNzAgMCBSIA0vQ29udGVudHMgMTcxIDAgUiANL01lZGlhQm94IFsgMCAw IDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv YmoNMTcwIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAy MDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9D b2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0xNzEgMCBvYmoNPDwgL0xl bmd0aCAxOTAxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3FfZcts2FH3nT5hv lToWhYUASXf64Dqa1k3ipBYnfWg6HhAELTYKpZBUnPx9wRUQRVqyZaeLNGODEMB77oJzD6YXGTV5 ZsLym/HEmP48h+ZtZkALAGg6HjIpBJbruObE8eTAds1UGJHxk29MfR/JXX5kuJbnucQE8lsPCbY8 Bzqmg4HlYYBM/6MBygWFEWAhB2PT53LOvzNGJ9Vn7P8lJybQgrj49UXzQzGPLSo3y7kJkMgkNLn5 j5G/ECfjiXyZZY8ykX4W6XdZOxHFaZa3T2vGPwj1uFytPqily/iDelG+iLOz4skFFhydjP/0fzUm hX0NmfKgAd/9FKD97yXG6hGMq5fD+n/Pjh+an0qL0LHsHo8vVqE4a6Fei08bUTmpgy339qJ9ajiX oUjyOIpFqkDBx8MBrU3QQgMDEA/C90okt/lCw0bb4YrnIs8ejrXBhY4Mnf91rWVydv52PKGWM5rM L1+3s11QiDr9oLQYsmPiJWFsAcg2Qb6Fc56z9BH1NpDjnbkHA34/SkV58sP346NgRceE7TzP0zjY 5BqJbEXt3L95N7ueX765unl1OfcfBVTD2lt6jwS67JwQt+eAlI/vR+h7+5FB3pP+XX8Oc4bnG7Zs AUr2z+JVopG6Rv9dN1E/D6CndGuXXA9y613lx1GE+pgjd+B5YzsltGZhGCe3D6mNymzdI7sP9WjL 7i9MpjdOhEovS0LFSmy5uhNfNd5saPXLOpYEoeXdUYdyncbLU/ULAHYJGzmN1hjs8gVCtzc+f7xl tyoy1P6zYvV6hrRyYltNVCbaCCghVBP+ds9NcpEmmpZ5kbIoL9/bYupFXry2T0VJ0leR1Mj/fJMv ivbOWS7rsaoKbKGuBVVzzTl2tiqJ9kq3NzxfBSLdin8VK7wTLFsa3ROubr3sloJyy7L1tju5Ftl6 lWRiKn2ftv1NAyDffW/lHihQ+TKW0dT06lJwjV9ZO0pWCRe9dZ6WUEO16S7OF5pwVbui1VIeCXkq t/zXGW6foh12qpLSZztpuv+FA4L4WBnVFcRVLv+XihgNUvcD8HUVMR7ohP8RRXyItPsnFfEhiv1f qoidY8J2gCK+enN1Mbt5fbQaJs+ohhEYlsPkueTwo6XZkYk/6WFBjXawNmd3Yy/naE/dHARcL4RK ybPlRmw1Lr2DPdgptwbhaWAbTgi0OV6PQ21OdK+Hcu6klQXbdpo1QlvbvItrc41Nps012NwD7DQB ptraJhG2NtckDGlzTWLBPjs7C5+JBeazV7MLf/bi5t3sen755urYi1hv/34iNrCHyQA+Fxn8A5dI pdeGLyH36mvS0defNiLLS3l9sWDLIqpNjBvxCA6+Jt6jS6/El1zdJ3Q1XNJiOii980UqNMG9de1R i9J4vezRR4fJXpW/YoIMEPj1+dULeDq/ns3h6UsOq4oqrf+o1xqAECKIVW5tSCCF6moLXehBBgM1 wWEIBYxOu+jJ/UUw+Cm8gG6PEyEMUYhD+3SYtt2ntcgAgwwxFQ5mM8Ioc3oO5F7T+7KDyuwgmR00 kB0EEEQIKTjIRgRRpLKDXOQhhlR2EEchEugbZEdAgQQW3zA7AQhggAIVjsAOSECDZ8kOLrODZXbw QHYwwBAjrOBgGxNMscoOdrGHGVbZwRyHWOBvkJ0IRijC0TfMDgcccsRVOLjNCad8ODs7F5put6ix HcHWr1+2w1iRNGdLvlmyXITqoKtfs7XgcRRrP8aKuueS7XUqty1qPZDGWyLXOvfruhG/1Nr2j1vN 2e2tVUEcGhLOVIVhJDwPq7sGgG4QwUCtEAI5FHNVpR4J5CNEg5Xi7u/uh/TU8yTszdFKPqiG+kF8 ValgqVoWijT+rCVlk8XJbe8L315f/Xz2fL315Y1IuAKsKEEefkFEwFVx2JQQF6nYy1biCu557YRL RRBQ7Wr4CGK4D6kUID1AVbcgLIKerVIvIh5EtuaCI/nWs7GSq0gSC/McewjxzDegWXwznhgEW56D TMdDJgFyDIscYAtLAkiFERk/+cbU92252o8MCC3PK5gFmPXQ9qBFsOuajgstJCvZ9D8aoFxRvL30 FaIyGm9ZEQZp/JM0H5tGtdUzHce1qItMRGXkqKmM/24mhfldowVQmcmu0cLIbW3jt6GdntxJtndW CaHF/mIkIfl3xkiYctkqMinZhl0HTCac1CGrQAMFeie60LagsxVf0MR3ECiWW6hnymg4kCiYZd2A EiGEUwimSCIuEE6wlPh6iUG7jMgiz+9xQLZHi2K340AvJEotijyqIapCvr4/5I40gFy640hVFGfT 6d3dnRWLPLJW6dMAhTawSLGzi3RPcUCbyn10a5/VntRpnOQiHdujROSTsBiwSP7Js2n1MJ4U99hy aizpAI0mCza2LXf0eQxHkhgTkUya41c7iDxP+gZrDwsHPXKIg8U+BIG3m4r1nmRgeQ9EwNkpK+TV zepLAb6gism4+CtYBzLGxHIpaZIiS0IW9gGQsYyt7eKHFg8myCI22imeil8nWfxxApGVf2lK/O8B ABpkl5gKZW5kc3RyZWFtDWVuZG9iag0xNzIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50 IDIwMSAwIFIgDS9SZXNvdXJjZXMgMTczIDAgUiANL0NvbnRlbnRzIDE3NCAwIFIgDS9NZWRpYUJv eCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+ PiANZW5kb2JqDTE3MyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8 IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBS ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTc0IDAgb2Jq DTw8IC9MZW5ndGggMjM3NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibxXa3Pa yBL9zp+wKh+2YCvI85YmW7fqEptknV0/1lY2yY23UkIa2YoxECQHnF+/I0AaCTVPOxeqXKI9PX36 zOme1uFRIqwgsfDsmwSDxuHbK2zdJA1sI4QtRxJLYGS7jmu1HakfmGuNVSNqvPYah55HtJcXNVxb SpdbSH8Xj5za0sGO5VBkS4qI5d030GxBFgTZxKHU8gJt8yaN5kH+aXlfG9xmepl33GgjjUGD0Ms+ N0+v/jhotbWbzZr/af3jvWvQ+SqzVzPfgYA7UBky7iu/2CZiiiKBcGGQLlXSIb3CIIIoZCKcrXCR jZsHs8jtjBGrjW1Ms8g1DNVPhmjmUIcUUEEd7WkCciFRiGRhCELGpCMMJE54xJyQ/ixIvkC+PkBl SOE84LSHjAH1iGI9pzBQB0sshf+zIDFEOCNSFAHdKMTMd92SgYme9A0k1xWKsfmKXSGt1mAXEKEt 5gs/N4v/1B+4ZFL5JQ6jKBIy5MRwiHkgAmGUwGY5OlFls3Iq8jmoRRoDIjQ0SEXkSCENtZEvuD5b I0ClQhZJuhrYcx17r8dc1eMlSkItTIaZKQ6NBYXSVLSrQkoD6m7GRoTzFGxOIMMoLLEiSRT1wsgc KENRoILIiJb7JJC0J/fmLYPj/Zr9WDxVEP3uf1fjeKAGxf7+wBzrld8fTtRjXZnd6Sgeq+RVYSCm iDqjcdx/af6DEJshJU4u+pX0ZQhdsIY+X/g3prkI/k+rLWwnB8RzMqioUDEPUTAAEXAySNV4oNJi 7+OxH6Wz3QokIN5sMwFVe+fC8Hdyamh5SG/VII0DP42Hg1kATG2yHOFzEYK05o5OKyc/8xE2FPQ8 SIc9Na6wPmeI1ihiOuhmkmo5Z3YKBj9T09RE1lkWz4kaa3mVfvZVkCZGasXTKFEP4XDweA/K0Kwb q3lWbb/CZkmg8xxtsbaVrM4lDrNdUyP562Y8KOUWG/SBn6iXNXbXR54FBsK+mLgTJi/U9Mj/8eHd L9Ojk87l/fTh9I/blF/hZHq5XPV0nyjH3z5edd+87t7Q4+B/FzI4mXqKv2PnjyeTs7d//5iqd+fv 8dsXy2dQj7uiDa7M7hNh0dnV+If7+oI47Ov5O/8Ndj5E0xP307nz10f0LNmh0enHO/nx9PTv84nT Gw/9s1sv+PHw5hunfnd0fndH/0Th/X+VP0riezsaDl+8LOkqGWlpxt9V/3GusOuWXTvb7drseoF5 pfKIhn3dX+PBjamDvh/rhjQ17WgS9/vFj57xVYNg/DhKVQhWTJIOx6V/VSSsFmyTp1dLx/vSPTu6 /HLc8ToGR5qO495Dql7tURyaQtMBD9xF62N5C6x+fqt0RizAO7eTwzEUPI6Uubl0Dmfdj96Xi6vu ++Pzs0+ntQtWrLpgP1cA4QUaCoDdE2lfDW7SW4PVMXPBMEhVqZVeN7H8lV239gWPFgBRARQVrIvl hLbLJkgffCPdeoevJYeA5PbJxaldnKg4FLdkW7eOATZZsnGAr5wnDsRwAV4p4IsBXx+I6wD7ldeR 5bPbActBPltlrFcLUn8YwAYD0OdICZBluAGVAzDJAN/c1gNiQPtBp8oBzBRYB50M3ZAHxMF27DJg Z4hdKBoFGIKYFICNbPDNfaCageIywJcCmCGNIyCG3LDf7tpdd24Qeg6ggtj1gXUMWBcBWKDagjBD XUABNgfIDeoM/gZeKuyi8ihY5RniCuIF4oCv4Rmvza1t7gpUvic233Q126qrzgFfTq/NzGPuOz8M 9WQ3v5FzgOahcq9lu26619xlWtbPQjDQbWehy27nvff7l5PjvaCWZqHa6PAEqMvzguuuHoYIKQ1D ZFf0kET4sgR3TKc6DVXeY82YvvzyWUsZwynzXTPMs5FAkRHABjVC6PpQAGPQJUkAG9QwoVGFADGg qwLKY9OoJwAsUJPa7prxgZ2hFiYAVHgDemgQhE5m3dAHnT50DULXUbQlvk1DS+6LtmYX8nAAGzQw QghytnoAKmjkh5iEhlIoLlQz0AAA6RQ6aaiOoIF7e+2u06kCdt52bIK6ADRubBpUoWEYGsOgoXRd btBLG6SmCNivtzO7kNag8TnYUCn5fhDjkCY3va6uew2F6g1iFxrRy1hyfUJqEoBtd+1WPFas3WoM XD0aPs9cCI5Wi4kavLrRMk9Ln+eaAi86x8cnZ2/3Hf/QsjyeAePyLITJ6vGPlqa/vcHvrAzQVnop eT4N/pxIB6ZWcueW97X0M/tFbQEcl3drDqrbuSipPbhTqTnD4fDOnFM/vitJ8DZOXi0fWRYMPLFm GV2eap5IfUTfTXtHw7BUDZfq24NK0t3VlMMhT4RzMnsriGI1NqDI/nDKrT1/dldA3Arfn0uFqXEB lbkbWPxM3HmVxqaVuXjtujo5Lay7tIecxN5TCNMwKgCSh161AR/d+v2s3akn3RFb3GI7gL7W76yJ Gn9X4Z6ddVN1PtfVddk5O35q6w/3pmnzvcXX3Fu4uLjynm4edD7kp1xl/2cdlKobAa0Iak8EsJVH i62AR/E4MTdRrhKQ570TYgBQDtgEYCu/3q0aWmv9uuQvAZsP2Ho7xAkA/xCwKcC2zRCeH2xZCLkN AzYC2HYWQqKC4SCsKaF07l2vga3smwSDBqe2dIjlSGJxpJ9xNpJQm2LXGqtG1HjtNQ49j+nVXtTA 2JbS1UGRtXhkEtucuq7luNgmSHt59w00W5HtPkOGyWymufCzgUYH/6bDx1Zj7iotx3Ft4RKLCC0/ YZngH6xBFr4eNAPKqVgOmgW5WcT4a5Wn1J686jmnT2T+2ZOG5E0aTWVxaQ0jS/Aq7AVhumr4grI5 aGRA19jFzMZOhV+U87sSKNUuQlqaDQdzA3N2ymiGEONDjA6JRpwhbFOth7IgMJsxcpumaxLAlNiC uksJgJCEsAWRooRoTvloPeWODkBcUUtkLopXh4eTycSOVRrZw/HzAMUM2TzzXEa6QRyYCe0nKn52 UVeH8SBV4xZrDlTaDrMHP9J/0uRw/iN7QSHNmamleypptm/9FrPd5vcWbqpxPFCDdl5+iwSJlDo3 vMgwS1DybRLM/AhGsn4Uow2HQXXTIMipyYrIeZJqmoHPWkW7lf1V/hJkSrntCp4fipaEFvYWkKnm lrl0V/FQTmzOSE0887ekdhLftzGx02ku8X8HAHn9nS8KZW5kc3RyZWFtDWVuZG9iag0xNzUgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMSAwIFIgDS9SZXNvdXJjZXMgMTc2IDAgUiAN L0NvbnRlbnRzIDE3NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE3NiAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4g DS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAw IFIgPj4gDT4+IA1lbmRvYmoNMTc3IDAgb2JqDTw8IC9MZW5ndGggMjM0MSAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiexXXXObSBZ9158wbyulItTNRwOZJ43j2vHWJvEk1OxDnEoh 1FhMFEmLsB3vr59GqOECR0hyXPO0uMpurrv7nnvuJ5PLrTDircF3P9t4NZj88xM37rYDbjLGDS+w DMGZ6Xu+MfYCtXB8I5ODZPBrOJiEoaVOhcnAN4PAdw2mfvZL1zYDj3uGZzMzsJllhN8HbLehUMJM y7NtI4yVLHwcfB5ekMcaqX+aztDZ/70YsaGWuUAmgMwjsouL0ZfwX0rTmJvcLtS+PaDRBzcFQBYB 2ayrMXw1KJbhn8VqzBShilFl8+fhb9GDzNKVXF2MxvsrV/Nq/Slarh/lU/VeLa5+bNJMbt9UAsur ltNNli5f1/9hzNmBsDxTKNaVzTXpDeNLhL7plLsaOD/fRHeyulOIL6OxMD0NyB2Wdo5tQbllpYq9 3UNIwPUql9lK5tXdb7MoyXe3VUgg3uIyAZBeTW9q/q7f1bTc5wu5ytM4ytP1aqeA26bV1lDHQzeC ijPCREo/xPl6JrMG6yVDdociRyktSLKE1yKpEZgVXQgbxReDGJwDmQSyBMZqU4+938PIXi3jQGYB mf5b3PdLg0/uwXjLF2lW58HH6fu3xYvPTK553B2kwXaAJq3aAbBcIBNABorIQZp8cD4AsgjIcOnA emJwfg5kEsiOut1v+7f1nOTDaZ5n6ew+r+tG/rSRdc2ahl+v/3iuW1nbhS8AbylXd/mCFFVWLddx LvNt9Xo7dF85t6OfBU9TqiM7z5rboeoHMnuQ8+fDCkDIcBDWMwBfh6NF4FfAr/eLP5qWBLr8Nix5 iJb3smNCsK+aJ5pAs0u0Q4UUQAvss49lh3piQIEA9OlMo5mtcThdPYx2hqZGndvzvphRsgg4LGgz 0P/o3t43LPnA34czUJj+8wrE1fvLj1/fTsNpJyCKK08IiE5H/HmQ7TLB/Z464dBCYZ2L/qxCcZI5 vXXiRFRuO5xIoFsg7GwgowkxA6GtZfyIDNWsqOcsTTrd1mk7RIk9A3bInn0Ui9ZH23UjwTqlJQIM oVlPo6bDCRpY0EyoWfOBRdRKbR2a6SgWATDrNfpuol7QXqLR5PXopXa4HTv6mNWIaHPQtwlgTQzY of72gTV6HwcsongUYF8CLLR7rcYjrcY1A/ZSzBbA16nvR+PWA6g00yg7PcBGAlDFYB/1YAx0dL47 SJyhlk3v0/fMAWso5ilDmn3KOANneUdHH7MuQKnXNH48sE/7mYN9qC4jJmhMzYBM3xcAJhjQgSoW qsF0XwL2+cCObq71Mct6ECFfJ8Aa9BHJjzCRAB022Ic+4lB30zpoLM7Bvr7qRD2PegYHHPSz64AT CKleC4AexTyyiDIUACY734skN1C3RFlNZX0ziw1kHmCSnu1G2Clxi+InAjLnCDsoblEX1PcIcB+a /Ggv8IAOxKLWQT0Vg30JkM0A5m6l7GOWA5TaMhrHqHIkwGo0EyImUA1FntLWovik+ARgZ96DGcU2 6tA24IUhZns+ZVG3dwBe1PcCwJMFONY+oL5gwAYU+YgnC+jVa+cIZo2LRqW+m0Y5mpbcDi8djvdf a7j2UltjwAmadiKALQHY0ASEJi/U7SIgcwDHDtCr18dmHwZsQ924G3sHK4Q+Vg14reeX6oriLPdM x2CFc8bMZIxxI4zVbdM8z9LZfS6VonJ7/rSRb6q3afj13fSyei0WPjP5/tLx7lbieGaqfXZ5NWoS LsL6TKBLubrLFzVUi1XLdZzLfFu93g7dV87t6GfBox7OOgadZM3tMJNbmT3I+fNhoTTQMlQaaWno hPypwGkwPETLe/lc9BohTTCUxGjI12fIgFIj6LRRu50nB8oq+szsfvL2aUJFEzWTGCDqfv41NZWK RuGf9cvuzTYFcFO4qPOEuiytkyKOlvH9MsrlvE6bB5nVdYBccTW9qdabKP4m8+o1mqlTJNMe03wB Ve+iRVczUk7UwtXBUxgDY+eowVsCKV9Xy//JbH07el29J+vlcv1ITJ49QYPff3h/efX1XdiN9b2Z EdGWR8uawqRdK622cfs55AzjrEAQwLnc3o7MM6nbB07j2rYbyGJqCur88Ue53axXWzn5dP1ucrmI lkXxlS0M6v4Das+K13iZylX+jzpSs73yuvKv19/qfy/Tb6R7LdLtm3ZNOo0bncusXQe6z0ml8nI9 J430IzHivHr5Uniu54rWNEllRnrm8+HQbqgn1vgAxJPw/bvdz33Qz8/Dyl+IurAxE6mEKOvYWGUD yZ3T+9+LjG5FXlIA2/tZc3Zr5OnZPfq8qedU0D89+PzNUy/E16ng/x92/65hl46BemSaAxkddjvf gacCf7FhF30l6nGTDovaEjqC6mGXjqoXdCxErf23SI1y6Uqu6jltVQ89n6JiCHoipUtXth+bVPmK hJlX58QmS5evSQAyZwfC8nRH70w0+ikQ+pDhzzfRXR3kwvvSGBDr4abZv0sV1WyBCLhe5TJbkaHw bRYl+e62CgnEW1yGJhQ6AtOqO71Xc6Pqq3GUp+tVGU22abU11PFgdfxZnBFwLPoQ5+uZzBqslwzZ LYquwgE3ip9tvBq4thl4luEFluEyteYFfbZpc9/I5CAZ/BoOJmHoqN1hMuDcDAJfKWfGfukE3HRt 3zc8n5sWU6fC7wO221HcvkPIrR1vN1HBl1L+X6U+NQbl0cDwPN8UvmVYQjEgjFr5f4xVob6rtADq 2qKttFByt9fx+6GTgTrpNk+WNIrifLFSkMLHwVAaghnrxBBuE/aeMBVi7p6yEjSrQXfY5Y7JvQa/ TPN7EKitjojAUGx43K1h7rzNdgg5n3A2UW62C4RjWxUYmjfc2TGyyPMeA7htmcL2WwZASELFnfq6 IIhKyjf9lHtKgeWLjiFlULyZTB4fH81U5om5zl4GKHeY6RYn20iPBAd3hDonGufMKr8maVEmRs5Q VYrxvFhEifqVbyfly2hcfL/tRCNVgKzheBGNHNMfPoz4sCywY51+ewOtIFC28b2FhYGBe4qBxTmL s6Dris0RZ9iqC1nM64SVFZRGyh8F+KJrjUfFbxm1INu2a/rC1U5RIaEC+wTItuLW8e1zg8d2LdN1 rE7wlJV4vE2/j7ll5j90iP81APy1j3UKZW5kc3RyZWFtDWVuZG9iag0xNzggMCBvYmoNPDwgDS9U eXBlIC9QYWdlIA0vUGFyZW50IDIwMiAwIFIgDS9SZXNvdXJjZXMgMTc5IDAgUiANL0NvbnRlbnRz IDE4MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3 OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE3OSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3Rh dGUgPDwgL0dTMSAyMTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+ IA1lbmRvYmoNMTgwIDAgb2JqDTw8IC9MZW5ndGggMjE1OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIibRXbXOrthL+zp8I0092p8aSeD/3y3WTtMedJjk3oU3vNJ2MgkVC64ALsn2S X19hEAi8fo2LZ3KEDtI+++yj1e7wPHf0MNfx6peHiTb88Q7rz7mGDYSw7vpEdzAyPNfTB64vBpan Z0yLtO8DbRgERKwKIs0zfN+zdSR+1dA2Dd/Fru6ayPBNRPTgVUOrDwojSA/C4s9S6531gz/FcIAN bJqmHlxUU8G3GjKIW0yF2u+9M+Vx+mLesHq0+vesj3phNcbKnBz7ypxZjV1l7uys/0fwU2GxbSeq vgmB9RPAjmrbrsaWnCseaaZ6K72sTBZvpuEIggQFAyTYF/SvXA9e2Fl/UG5zNTqvx3FeD0M6DedT ytmknkoXLKtfuLLF5ehLPZ7R8C/G61f6JFbVbw+9ZcxfQNPFwBPh6ZUuDQrgSgSbwO10bkGn88Zk roDhaT18Z1n60P+ufo/S6TRdKs4+vYGu3t1e3tUvK0u54h1VTHE63ekccdy2c1ItaRXjSIm/jDuq 54q9XIMAHDy9cZY/9I0KgS0NF19vYbXST2urlhPtwchwVQ0M7uZhyPJc+bBS5wY7B+l0SnO+SWWK bmkCyrKC9qmKBN5TZhVQGRZJvakewfbzn1Z0sGtYgF/n6YR96mLrQlutBbGdGs54whIeRzHLGlDm 8XCQIloEJa1D8f3Mkmf+0mCzmpQUcsYPYO5ImXv1+JYN6FwkBMFXSHmcJt3P7Y+r/l5s3yidZVGa vcbJcz2VdTE0aayTlfsDx3B7g1v2t8hTfFjGmb91s8LGdLQT6uZzqCLJ6WvzQptv5vmcTo36NdgA Pp+lSc666K2P3xRhmnAaJzDoNZYbL7tAHnpRlr42egkeL6/Pbx8vRsHowHyzBSzlPIuf5lxhsrhb H/qfNoXzsJxGTprTZNROkEVOmNTQaZKarMScUyY1zzk6q3Wx4g9SF7zNlFCq5+4wPOKRVEEFMwHm LGXO6dKsFEEMCIepzLmADTlHAbseYIMANtCefrh7+kYBu2rRd1ZmQaidsIAt5LYY2NYBIOEd0G1g DgqLu4VGKPQeYMPfQcU2fFCf5AFr0X7UQp+7wJyEOdlhXlL1BEDyd6yFbGyzC52WCPADUigUZugE EeC7PVW7TaEM2BZSCnSQoMNPgTkbsAspGToZNjBnAlgg32zABiSlCNjv6TBqIZWZgKlwxwGR+0F0 Q2qE1to76IGocLdQ6+/AIpUJSckB5jaqFqkVcVM4IfXG27+B8NXCtq7H78ZXQ7ChUK7ZD/QRaj2d s2zBMqW4DdPnJH5nm2rfHaVv03Hk6d4lrpRqXHHOa+6LdTZYiizj6VSBVRSVk/p9GfOXLcRWDUTb FUMJzwquvauKGR8AN2OiSGeLDbTSPE/DmHLWuBCm84QrgVnQ6Zw17D6zhGViQbMfrUdJmoTKp1UY yE6/dncaCsWzOPwLNM6W+6tFaZTiRGFGaRdDmpe+nKZZ+mbOKbpC8ds4v1rez+wgmNxNkpufF8/k t4tfI4Jv/s/xIoniqzC3J8n44vPN+Idf6WJ8+35122XyeBhv7/fO4of3yef7/zI6y+NXI0rTbx76 UoQHtmwHnfgonU7TZZw8N7GcimaXs69cOUDK6Xpq1rIkzN5mqk5VTeQ8zZT/aoWUnY68UfB4eX1+ +3gxCkYNDi4O2NOcs41db5WyIQpbyVu5OHH3wjmmaRpJZA0brTZKuHN+88t1cHnblflejdSu9u5I jNNOF2oBTWh1dPG31kP/o9jVe36zP3s5cw6lzqPwSQD2vxz/65vr88vHu49yCMI8UfwJ2iwA+98S ADpOAA9FQVDUNZOPw1JrUtJNBxvKeFlDugr8vYArOmgrV73ID3ZFdkpqiSw7ILUlkGW/WjbLcrlV DkM9hnjkN2qJLfdSWwppU+3CJDZPjbg006svuhZbn6moXOOEJeBldEfFLcfeWuyV9eDXWSz0oUjb bc7iLIun3ymiR9YKBHHlTbR2T8mnQOiBUf39C31uouh4f8h2onNPte/D0kRzO9Udx/ZuY1ykvoQ1 V/lFRiO+slCjA30otoVuW1E+N5yOrxqqWqVdqWrTIF0LjURI91Ss1jjgFX8T8vSJZa1IlKyZa7RZ wihM3Eo61WDT4ZBo1B5QnmW1v5VnnihzMjespynwUbvI9uHxukmk85zsnrn8LXi8vRz9Enx+HF8c m09wl7ITQO1eN563+bohRLlvyLGJHQEBP7LgGIV8TtVuVGkwN/c8ay5j2GX7UA/drpqEhy4gaafr tSJzlR25ZrLjO7mfD9j1gf2g76CrdQJ85wLRc4HvEIDZBtaqvLQO6mWgYb345WGi2abhu0R3faLb SIxxkbJNw8SenjEt0r4PtGEQWOLrINIwNnzfE3JBejW0fGzYpufprocNgsSq4FVDqy+K3VeawmSV v77QIm8J438L87GulUt93XU9w/GIThwRfEdvjN/rSWF+3WgB1DadrtHCyHNl43+bVvpipd1eWQrf KdYXIwEpWGo9pjtYTyPdsduwK8KEZu2KshI0akCvsYstA7stfpHkdyNQUyxxfF2w4WK7gbk6n2iF EOMhRkNxjZgFwoEpzpJ6lLG1YuSF8y0OYJMYjul1HAAhOeJeI76jICopn22n3BUGiOesOVKK4tNw uFwujZjxyEiz0wDFFjLsYmUX6Q5xYMsR65zWOqPOiMO4KEP6Vk9UIoNJMaCR+MPzYfnSHxSZezXV FxmN9AYvtG8ZXm/Rx72yqBvI41c5SHxf+IYrDwsHfXsfB4t1BCN/PRSzHcEwRcIlyF2TFfFLJ9nX AnxxgQ76xV9GO5BN0zY8x5ZBEZIQwt4Dsim4tTzzUPGYNjFsi6yJp6z0Bnn8OsDE4F+lxP8ZAO3f q8EKZW5kc3RyZWFtDWVuZG9iag0xODEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIw MiAwIFIgDS9SZXNvdXJjZXMgMTgyIDAgUiANL0NvbnRlbnRzIDE4MyAwIFIgDS9NZWRpYUJveCBb IDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiAN ZW5kb2JqDTE4MiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9U VDIgMjA5IDAgUiAvVFQ0IDIxNCAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAyMTUgMCBSID4+ IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDIxMCAwIFIgPj4gDT4+IA1lbmRvYmoNMTgzIDAgb2JqDTw8 IC9MZW5ndGggMjI4MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidxXXXPbNhZ9 158w31bqVDRAECCZTh/c2Jt6vcl6Y053d+JOhiJBm40iuSJlx/31BSWCBMmjzzg7OyvPWOAVgHvu uedegKevc2HFuUVXf3k8G5y+uaHWXT6gNiHU8gLHEpTYvudbYy9QA9e3FnKQDn4KB6dh6KhVYTrw 7SDwuUXUXzXkzA486lkeI3bAiGOFnwdkNaF0QmzHY8wKY2ULnwYfhifGh4/Uj7Y7dKvvkxEZCmDT 89iOedomDZv+PQW22LB51ViA/TzDpjE4AJ8PfKA4kA+xw4e2UcN2MhoL21Nfv4Z/U/yOqU1ZSfZ5 h2fEgcYSAA7cHX63cSV3xCaAX+0vAfMY8MsAPg7W7qsNhMXdxHP43QZ2UfaR6pA3k6FtKtmVBeRD 7+eAtdGOLGxbi5QTgbWoesTe7G6LUuxAgHSAsoWQ6nkE7Ie0hjJDgA31sADYzCxo9vetrXRvdvsr xsSmm2YTENdetvXnh3pKuTv1bFcdEqpZKZekPILUIfFheDuMimKRTZaFVGDWCx6iJMlmd7ej0uI3 AMerPYy215w2BnDSZarz2QvWWQ9U8fwgX9VPZ+HH67Pz88t3bzZidIS3EaMB00Uwj8Q4lbO74r5B SUU9nMeFLPL68XbofuceSfDXKGOjWl5YgdD2TbT+bTyZlFRP4W/Nw+qJ2QKoIrxv9HBxdm0UVfxJ Fo1U5vNPjRym2SdD6fdZ/qqrjNIZFEYLnY5Ux0GRuA+Q+Ot5YhTde/n7UubF4aJ9KTiXiZwVWZrJ hVFjx8MxFTDZ1g72xff3bv37BDSAw8Bqzpyv5C5s9U+lzPVBNb65fFtbj2nzydcQpmC0AOTLSbvP v5cVzGhZ3JfJj6Mim882It7W9A84Og8I4Xa4kLlcPMrkyHbu7yiOlzovL3/52tOGH03S7qPSQZVS HZX8mx+V/+WUq0/S5VTB8oFN369jcLf1DPg18Mtq8Es7ksB2QCSP0XQpeyGUc/cIQcM1r8S6jQaA bfQa2Xox2XFp5oCCrbSgtn6kH74jxnhfP5q0Te38par94t3r9x/Pz8KzYwWqAcK29FL3Y+ZsrnrG jLJ3/k/KXmvMN2CJriSULeiyb7QCU3cJWKvnTYA+UbuJwdrIsLEt+Ey9a39mTUsQLwf4XLCf37Ot rgI7qjfesasETCRg7QREredJgHIC2EHzCNhPgLUJiCMA+6GMmtnjYD+Ntc7KSYtbYl6l2iy7gCnE HgW2ADAVg8g4WNt7g9jQhwXwoW0S+EU6p8BmKsgDtgj40DbRsFwR7beIrloGvh8wQKoLbKjozECQ rFCxo3lpNTYPVp2QFNg4sJmy17Izm4ILMKMkoTLq8XKyvVUEgDMXxK25nwAbATy6gEck9hT4NfMs wX5IDyngTPODWo8Zr25rqPAigC/ak1tnC2c+iAcVL2oaSHsccGu26wnAoscExI2ODpMLdBeXIA6N NQE+UINI9+Q2BXFrzlzAj7uDW3R0IZ0RMC8G85Dm0XGL+pPmLAI+TM6QvvQ+qCbFgdyavtABo8c+ iEcA7GbcbIstBfsh7Zlxc4BPzzPrBR3a/ctVoxEC1nLAgaHbLeT21NP5vNQbz9uz18feynsN5QXw dd91HLL5VYcbbzpHg/8fe9NhQJxalAyIjgMRMwP+XsArDawmPkbTpTwW/QQgRa1R2yJgM8vtZMdx 6QCWImBDd2JTtbvu77pVmkcTulLpPQXIlFn2mz/9F4qK8vW6UfhbyYa+FKsnZguQ0fC+KSkzu1lT P3E0jZfTqJBJU2GPctF0CmOLi7PrevwQxZ9kUT9GE7XKKMqnrLiHrlfC0uGtbFzLq4wBqmtYR9yK 7udIAc1mctagmDVR3ETT+ZN8rp+bKL48ZKpCjebiNZ3wYZFNvzfaDnFX2BxP89tC1UqZQujDuvpw Hd013Ijg1w3ht6Nfu6gzjQi4nBVyMTOycL6I0mK1W40E4i03Q3oxE3xz+bahZalkMCuyOCqy+Wzd Q5jtdD001aIr0mv1HQFF+o+4mE/kosX6miHWo8hVTneT1It5c4XkBnvFvB7+IRfzHxpZGVOKaNoU SloPqd+cUJPnQua3I7vbPrfp+5Cq/ms2i6bT5+9hja5OnqZ8E1Uhj7Ip95l8qsef5HNu109mr/j3 1cV//tKqHBRH1SP7+c+qrOet7HNYHKD/RLkBP4/V1cD4MWuq/UbGpRybHHivulD5pgNreII4rwwY aZuUH+uRL1gSU+OGwhxJfOay2hDTyGHEb4KYuD7zvFQ0exCacj9xD8R/zDlgKuDtzRXsnRetHxay I6dm4jLPZndQh9fv370xzoPZ3Lx93kdFV13OIVWCo7z6KGfxAgZ09TFaNi7zInqGoPPoszy8cLdr SN2rqjK4qb6vmivAj/VwS4l4XCSBdOMapkxEwtW/2uASOWGpbBTnc8HjiHi9Gxyx/e0F0TnRVgv6 kIT00okf+Ubtxan0k6BhP5nE0nVpIx3Xi92Udy+VF+GAWuVfHs8GnNmB51he4FicqDEteWc2o761 kIN08FM4OA1DV80O0wGldhCU4IhVDd2A2pz5vuX51HaIWhV+HpDVjHL3VQTUWUV7HZXRKee/K/eZ NVgvDSzP823hO5YjFDPCapz/y5qV7vtOS6Ccia7T0sld5eOfm1YGaiVvr1zTLMr15UhBCp8GQ2kJ x5qnluBt2BVhKqG8omwNmjSge+xS16Zei1+i+d0IlKklIrAUGx7lDcyVGsgKIaWnlJyqo5uVCMdM vSqYWqbuipH7otgSAGWOLZjfCQBCEuou4QTCQLSm/GE75Z5y4PiiF8haFK9OT5+enuxMFqk9X7wM UOoSm5cru0h3iIO6Qq0TrXV2XX+nWXn1G5XdvBgn5SBK1b8iP10/jMZlR12ZRqrcneH4Phq5tj98 HNHh+tI81uVXBegEgYqNVhGWAQZ8nwDLdQ4lQT8VDzuSwdT7pEO8nqycYB2k/FKCL1vFeFT+l1EH MmPc9gXXSVGSUMLeAzJT3KoT+FDxMO7Y3HV64ln3z3GefR5Txy6+aIn/OQAIErO3CmVuZHN0cmVh bQ1lbmRvYmoNMTg0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDIgMCBSIA0vUmVz b3VyY2VzIDE4NSAwIFIgDS9Db250ZW50cyAxODYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xODUg MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDIwOSAwIFIg L1RUNCAyMTQgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgMjE1IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNiAyMTAgMCBSID4+IA0+PiANZW5kb2JqDTE4NiAwIG9iag08PCAvTGVuZ3RoIDE5 MTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV0tz47gRvvNPmLdIWxGFBwGQ k8pBa7s2TjKeic1sDuOtKZACbWY4lFakR+P99QtQJAFSkCXZViqHpapsqAWgv+7++sHpeUndpHRh /SmTwpn+dAvd+9KBHgDQZSFyKQRewAJ3wkK58AN3JZzU+TFyplGE5KkodQIvDAPiAvlplgR7IYPM ZRh4IQbIjb46oN6glAAPMYzdKJGyaO2MzraecfRfR+mVB6ILZwIkGglHHvg0wvMgTVlAz8YTeYvn jzCnGMQo7gSACpSkCHSCkAZ+AnGqBAHw4Ohs/Ev0d2dSa5hAD2KF5sLAdRwkGgcoDUPUKUxRDGgK NSTixymBIu0ECLMUcR+8BJJCQjzfAuTy/e0/OhXd4q9jMNqWSjREgDnrBAKEAcd+okFjLLiINWjs ExYExB+CVmDewI0xYwgSpCOLAGeMpcCAiH0QBH4n4Cj005jhU0WWpwwClGoXJHPEUmqGek4ZikWo IRGSgmQOTwVJsoYTCLSXmMyHlCLeCWI/YRQg3AlomgJI8fxYSAoFqDcgyraAbFOqW8w8qIN2Ofs4 uRHlclGUYnp79X56Iyb8sXoQRZUlvMoWxQAX2Icp+qH1mfqGPWpxU/QgdNDyTCr7U9kJVg2cTpAV Sf44F3pHZR5fPBaVWOkI621rkede983UmS7yfLHOxhPqsVFxP/QRaWOg0D/Hit0WLnOeSVzfK40m y3PNAo1FFMnqaVmJuTah0OuyWqyMn7LC6oRZ9Pny+vzm88UsmvWMkYFDrzeGV9Uqix8r8e5IBzV8 +KSTCI6batX8H+bWX1p5fT9k1ko6a/FoZzwtO3C1O84//Ps6urzZSiq2qxp+6kEBDQxog/lCjLko 7qsHjVIXykVSiUrz9m4Ef/Dvxq/FDjqYYLTbnoOMOR8k2TeeP4oX4WuB0BPH/+Ps4uLq+qfX+tBK 0zeKP0S7CYBPRYDjZRONoJ/Kp9TUa2wv0Cmf7W718h4lu2S3XvLki9BlPV8svujI5dkXg5QPWflu GMTjKmZrENqRLocn8NzIjxujwx5HsGfr4hF4ruZqwEgzsTLy4eVwTC74zdrfAfEgfP8c5CoNLLl6 HFb4RqGMeqVOMnMzxUzk8Ga0/uMr8vw1/lJjpAmgfIz7JflGNDC3h8sXI95XAY4z4U4NnmL1Tcxf WHmDPbnxVq3t6ufXNgZywq6GwO6uRk7e1U4Q8qYJ7YKVDNNHwkqbNbPIUkPGLcNQB/yqWfzctyT0 kMUS+0Cm9h7gWWIxQTxTWRNLBJAhO9sxLbRmxsZeMnSBlLX3B4bMdnaXHma5sz0H92Bv7eb79ATD wyfK9t573R9J/z9K+j2wYgvDWuaYWdSusSHbIk6PYaNuBOyB/hv/JlZZIXTD5MW8W9/yfLEWT0Yz baeD78tMWmsEimluLVdZ/mcjhMCvQSDWjsPD2bR7FMLA6txPH/m9pgkDv2y6fiMh3RDcn4E3KrrB XC16LwD90VG9iRbGBH6x4mlV39thsiJX19oGfXO4N2eYWW9S2VAKt9XXxow2oqxHQ2p9u/iQVItY rHr+3/gKbznLH5Rxi7vkYhdXWzShhasmB7mlQvrPcrWvp+W42R3au8xqmlr2EYtsl54WE9lznlny 0dZtrHra2tK1mxNV9/ez8z/q+v9PXU+f4as5zNmmkfZ3c/w/CHjDgXqjfY47Er2Jypbpc4uMDNn0 TAa294cWj5iew5Y72317M/BMj9amHmi5M7HcCYdR2/O0fUoB6fWezUndkpoYNBcqObYW+OhBp5UZ 4UznUMLz5DHnldCdfCHbvK4WxhVmk1ry5IvR/3gsTxmJuc6qB6vqmly9htyNCrrZeNROtb0Glwak atEtfxOrxd1Y97l0kathRZscP1kNvv5wfX75+XY7MxoruaGs4rn2YNqzzcyjnba1tGtHM7+XtsSa tfFTJcq7sTd0INmVq5pImzHvcPoU4nu1K/jrLNe2x3a+3D4miShLHYOSf9U7edlnknew23oW2aaS y8iBrvqUSeEQ7IUMuSxELgFyDdWt2MMwcFfCSZ0fI2caRb7cHaUOhF4YBtIvwG2Wfgg9goPAZQH0 EJCnoq8OqHeo22vnQVSD+Mgb5b9K9ZnrbI6GLmOBRwPkIipNoK5W/h+3UOq3lSqgBNOhUqXkvtHx r10nQ3mS9E9uIkzVebWSkKK1MxIuxe4idSnpw24cJj1PGpdtQAMNesu70Pcg6/kXtP7dCRTLIzR0 pTcYJBpmTURQI4RwCsFUTqhYIZxg2Y/MlIB+7ZGHqnrGAIiRR3EwMMAKicqRGYXUQLRx+fJ5lzOp AAV0y5ANKd5Np+v12stElXqL1dsAhT7wiDo5RLqHHNCn8hztnfO61J9m6g1nrPK+mszVgqfyT1VO N1/G0iw0qkVjmZdoNHngY98LRt/GcLR5S5zUmasNRGEobYONhcrAkBxioDqHIAi3Q7HcEwwshxYE 2BatULgxUpY0CV5VmclY/RV8ABlj4gWUtEGRlJDEPgAylr71A3wseTBBHvHRFnk2hW5SZl8nEHnV 95bivw8A0nS5OwplbmRzdHJlYW0NZW5kb2JqDTE4NyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q YXJlbnQgMjAyIDAgUiANL1Jlc291cmNlcyAxODggMCBSIA0vQ29udGVudHMgMTg5IDAgUiANL01l ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl IDAgDT4+IA1lbmRvYmoNMTg4IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0Zv bnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIx NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0xODkg MCBvYmoNPDwgL0xlbmd0aCAxMjg4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ 1Fddc6JIFH33T4TKk2SHtj+ggamaBxNNzH7MZFdqN1tJJkW0jcwYcAGjU+WP327AbkA0OrMvq1XW peX2Pef06QvduUioNko0lH2TUdjqXA2R9py0EIAQabaLNYogcGxHM2yXB6ajxaw1aZ17rY7nYZ7l TVoOcF3H0iD/FqFFgGsjW7MJBC6BWPNeWjC7QRSBmjcSP8tW+0T3vvDQQAARQjSvVwx5Z0cEeT6m tsr/0Sm/L/jfAIEA2yIa8T83mQbka84XnQ/etQf+K4uDkIUnusFvBWbbD8cyHvqzaMm+yWsZ9Ffz IGbJezmAbRl253Ewe6f+gdDUH7yfW9gGlBujjqr8EQgdYOZ3VXDe3fjPTM5powfdoMDeALJ4IEoY hFbY5yXq0lUmvg5TFocslXP3Yn+SZrNJJI14xWS0AWm/e6P0u/5NybJIpyxMg5GfBlGYFUAE4HqF O1kC6wVZfSO+yKGgqeinURo9sbiieq4Q2ZLI5EWPFKkbhmwl5z4HMrxJ2GIcGX9w00QvcvTj4oWD kZdXLGSxn0bZiAMBKqDwKtXilZrbppOBN1VWOF2fyng09WN/lJZKj1kYpSxRd0Qh15+F2Rq8a/T8 6efTnelB+BrNFjw31zYENXEFo5pXtnbpoSSHKZvLC6R22sU0ihLF35dRyJaKUcJGccnUr/5soXIm kVIoLWmZMDbOmRlf2Tc12e0v/b9LAAXT3V3mpLnRHMoUK6bXqilN2cofs1Hw4s8U3yjNllEOzHLC NYdt76x0s6E+HLCzqG1amECkWt/lRa977rhywHXOu72Ly75aLEiwZdpULRnp4T66hDV0hqi4R8Zc SHPTIyqwvGlQsmXSuJxBGKRBSbDdJhjA9QCtB3g9IOuBWVmhMt5659iWNigUDavKNhAoA728vhkq NwxUfDccdA30UPOesVe1HzEfUea7LMnzRUYfZASV5JEMNy3QahvKDaqbRDUiDe1iw8BqfAoSoGa7 Hfb7vcf90Dpnpd0iw2gutk3JGIuk1DKDcL5QjeOsUzeBQLbXtPsJ4EaFg0MVblDTehPZXfU1wy/M CSomdRu3/+2f3V8bsN1Xe+JP9VW515UnIvVswZ+f6nK6u3pADfTTEaCXj016Xt2301JP58QkSutY NKNjJCwrVZYQNenXLCtndLykxQP3WIcSOfeqcXstH+F6+Yjecl/za9V3BH2vpc5t2YELZwc2C/IY CaocM6qc18z8vIaQOKVlx7EiNF0ELOI4mu0ggCHPqhzYMiUQzqDf+EXxf3j5QGvlqa5m2w6gDtYw 5bpSTRX/SwtF+e2iAqhFaL2oKPJc1Ph9V6bLM61qZr5cNDtb8ohDEgdMplFTiyYataqwC8H4wliF ZDloqEBvqYtMwM+0ZX3hRt+dQHlrtqmrcTVsZCmYmatghhChDoId/mJOBEKD2MAsGxCZmSLTNN1D ABEMKHFqBBohUf52gV1aQpRLPt8vuc0LYIduEclN8b7TWS6XIGDpBETxfwMUmRBYIrOO9A1zIJPy PFrJA3IfdwJxsNPFa3FqjEXgT/hPmnTyC53Twu1sSOfbFreNqa+bwGm/6qjN4iBkoZFtbEUQuy7n hgqGgqBrHUJQ5GEE3e2lmL+xGATZ3Pb2lq2wm5NkKwFetD5DF7/Mr0EmxAIOtTaLwi3BjX0AZMK1 NR1yrHmIhYFl4i3z5N3XSIIXA2GQrjYW/3cA1FruXgplbmRzdHJlYW0NZW5kb2JqDTE5MCAwIG9i ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjAyIDAgUiANL1Jlc291cmNlcyAxOTEgMCBSIA0v Q29udGVudHMgMTkyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAw IDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTkxIDAgb2JqDTw8IA0vUHJvY1Nl dCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQgMjE0IDAgUiA+PiAN L0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgMjEwIDAg UiA+PiANPj4gDWVuZG9iag0xOTIgMCBvYmoNPDwgL0xlbmd0aCA2NDQgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIm0VMtunEAQvPMTniNEoZme9/iWh5UoJ0dGysHyAa1Zm8jGmwV5 nb9PD7Cw7MavPBZpVMxSdHVNNdmHxrBFw7C7mkUdZZ/OkF01EQLnyKwXzCAHZx1LrSegHFuX0TJ6 n0dZngti5cvIgfdOM07XALUEb9EyKzl4yQXLbyPePRCKcJYvwrKJ4qMk/04wRUApJcs/Dlv5m1eA ni+Mnfh/+8o/A/9HCAdhA39BW9u9lNMB0QnR5nn8ubgv11Vd1kdJSo+Ciov6csRnxc3dpvw53o/g 5GFVrcvmeNwQdoTvVuvq5u30D+cquci/RMKCoVOkXmaqdn9BoQPVPzXTeX5aXJXjO624SFIDditI EwglUml2PeN9ifDWkzyaktpFTHQR1ZwwBpYEibOEqj6hiCGXXQAHqDyCls4x6xAEJ9Ysop1uFF3t 02Io/oPKVyzqqZ5Z68A4wYQhKwybin9jdSh/WDQI1dLsFw1FroYaXx9jemLqObM313TTRIgkhZEq mdHsbknrXPZgGDmrB8t60XwSfeAuKqAp3vWXb/19VKgkivGM3LCoJ5k4DT1ihjyjTMmgMJUW1G5c UHWOXLftEw2gFGCk22vgt5KMASO82VHUW7562nJLBYQzB430oTjOss1mA1XZLuFu/W+EouKgA3Nf 6TPhQGWIZ2Y8GKcuq+q2XCcqrss2vQygWNLSNll/k1BbIu62Epo7EafXRaLAxfcJxv13Je0Gc2pQ eE+94dBhaNDrlzQYeAK5PzyK1TOHIdFS7O1BrITvmywfgngOGKdJWMtiT7KUGhwNxnAoFAkK9gsk S/JWOfna8EgtQCtxEJ7+g5k21W2KAtqHbcR/CTAAW02UKQplbmRzdHJlYW0NZW5kb2JqDTE5MyAw IG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNMTk0IDAgb2JqDTw8IA0vTnVtcyBbIDAgMTkzIDAg UiBdIA0+PiANZW5kb2JqDTE5NSAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDIwNyAw IFIgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIDEzIDAgUiAxNiAwIFIgMTkgMCBSIDIyIDAgUiAy NSAwIFIgDV0gDS9Db3VudCAxMCANL1BhcmVudCAxOTYgMCBSIA0+PiANZW5kb2JqDTE5NiAwIG9i ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDE5NSAwIFIgMTk3IDAgUiAxOTggMCBSIDE5OSAw IFIgMjAwIDAgUiAyMDEgMCBSIDIwMiAwIFIgXSANL0NvdW50IDY1IA0+PiANZW5kb2JqDTE5NyAw IG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDI4IDAgUiAzMSAwIFIgMzQgMCBSIDM3IDAg UiA0MCAwIFIgNDMgMCBSIDQ2IDAgUiA0OSAwIFIgNTIgMCBSIDU1IDAgUiANXSANL0NvdW50IDEw IA0vUGFyZW50IDE5NiAwIFIgDT4+IA1lbmRvYmoNMTk4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMg DS9LaWRzIFsgNTggMCBSIDYxIDAgUiA2NCAwIFIgNjcgMCBSIDcwIDAgUiA3MyAwIFIgNzYgMCBS IDc5IDAgUiA4MiAwIFIgODUgMCBSIA1dIA0vQ291bnQgMTAgDS9QYXJlbnQgMTk2IDAgUiANPj4g DWVuZG9iag0xOTkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyA4OCAwIFIgOTEgMCBS IDk0IDAgUiA5NyAwIFIgMTAwIDAgUiAxMDMgMCBSIDEwNiAwIFIgMTA5IDAgUiAxMTIgMCBSIA0x MTUgMCBSIF0gDS9Db3VudCAxMCANL1BhcmVudCAxOTYgMCBSIA0+PiANZW5kb2JqDTIwMCAwIG9i ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDExOCAwIFIgMTIxIDAgUiAxMjQgMCBSIDEyNyAw IFIgMTMwIDAgUiAxMzMgMCBSIDEzNiAwIFIgMTM5IDAgUiAxNDIgMCBSIA0xNDUgMCBSIF0gDS9D b3VudCAxMCANL1BhcmVudCAxOTYgMCBSIA0+PiANZW5kb2JqDTIwMSAwIG9iag08PCANL1R5cGUg L1BhZ2VzIA0vS2lkcyBbIDE0OCAwIFIgMTUxIDAgUiAxNTQgMCBSIDE1NyAwIFIgMTYwIDAgUiAx NjMgMCBSIDE2NiAwIFIgMTY5IDAgUiAxNzIgMCBSIA0xNzUgMCBSIF0gDS9Db3VudCAxMCANL1Bh cmVudCAxOTYgMCBSIA0+PiANZW5kb2JqDTIwMiAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lk cyBbIDE3OCAwIFIgMTgxIDAgUiAxODQgMCBSIDE4NyAwIFIgMTkwIDAgUiBdIA0vQ291bnQgNSAN L1BhcmVudCAxOTYgMCBSIA0+PiANZW5kb2JqDTIwMyAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAo RDoyMDAzMTExMDA0Mzg1MlopDS9Nb2REYXRlIChEOjIwMDMxMTEwMTgwMzU1KzEyJzAwJykNL1By b2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA1LjAgXChXaW5kb3dzXCkpDS9BdXRob3IgKGdncikN L0NyZWF0b3IgKFBzY3JpcHQuZGxsIFZlcnNpb24gNS4wKQ0vVGl0bGUgKGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhdmVyaW5lbi1wcHBleHQtZWFwLSkNPj4gDWVu ZG9iag0yMDYgMCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMTk2IDAgUiANL01ldGFk YXRhIDMzNSAwIFIgDS9QYWdlTGFiZWxzIDE5NCAwIFIgDS9OYW1lcyAyMzkgMCBSIA0+PiANZW5k b2JqDTIwNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk1IDAgUiANL1Jlc291cmNl cyAyMDggMCBSIA0vQ29udGVudHMgMjEyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjA4IDAgb2Jq DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAyMDkgMCBSIC9UVDQg MjE0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIxNSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8 IC9DczYgMjEwIDAgUiA+PiANPj4gDWVuZG9iag0yMDkgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0v U3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzEgDS9MYXN0Q2hhciAyNDcgDS9XaWR0aHMg WyAzMjcgMzI3IDMyNyA2MDAgNjAwIDMyNyAzMjcgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCAzMjcgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgMzI3IDYwMCA2MDAgNjAwIA0zMjcgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMzI3IDYwMCAzMjcgMzI3IDMyNyANMzI3 IDMyNyAzMjcgMzI3IDYwMCAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcg MzI3IA0zMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcg MzI3IDMyNyAzMjcgDTMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcg MzI3IDMyNyAzMjcgMzI3IDMyNyANMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcg MzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IA0zMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcg MzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgDTMyNyAzMjcgMzI3IDMyNyAzMjcg MzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyANMzI3IDMyNyAzMjcg MzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgMzI3IA0zMjcg MzI3IDMyNyAzMjcgMzI3IDMyNyAzMjcgNjAwIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5n IA0vQmFzZUZvbnQgL0NvdXJpZXIgDS9Gb250RGVzY3JpcHRvciAyMTEgMCBSIA0+PiANZW5kb2Jq DTIxMCAwIG9iag1bIA0vSUNDQmFzZWQgMjE2IDAgUiANXQ1lbmRvYmoNMjExIDAgb2JqDTw8IA0v VHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODM1IA0vQ2FwSGVpZ2h0IDU2MiANL0Rlc2Nl bnQgLTI5NyANL0ZsYWdzIDM1IA0vRm9udEJCb3ggWyAtMjggLTI1MCA2MjggODA1IF0gDS9Gb250 TmFtZSAvQ291cmllciANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA1MSANL1hIZWlnaHQgNDI2IA0v U3RlbUggNTEgDT4+IA1lbmRvYmoNMjEyIDAgb2JqDTw8IC9MZW5ndGggMTk4NCAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicxXS3PbOBK+80+ENSdpawkRfIo5bSZxEk9VMtk1q+Zg zwEmIQkTvpYELeffT4OkCICiZGnHU7VUlQ0+0P3110+s3jeBmTQm7n5NUhirT3fY3DYGRraNzTBy zADbaB2uTSuMYOGtzZoaG+Pn2FjFsQO74o2xRlG09k0bfsPSd1EU4tAMXRtFru2YcW7Y3QdCiWWD dBAfJ/Aw3hv3i6+U78v6+5ul5YQu8ha/wQ0rtuP9p7psq+Xv8S8GdlAAYuIPho3gnSuE3C/enLs+ L3shaPj/phcUIacXpMC5X3wmT7RmBS1G3Q8LmjJeLq0AhYv6YTm88Ac5losRsIMRdgWaDyDjtuC0 LigfRXyoyYZ3X6+RdyX6E9fXwZhy+P996QQCIBvuyWgsmIcPWIV6Der/ovqXWT5B4jGbdyQr9/TH 5Vy6Kry/ypF+vR/gHhhqBsaSCZMaY/E/dINunitW0+btaJETjst3Vc2yf8o3tu31keZCgFztdGeA E2osO3iG5V8TXj7SWlXdM2y7RwR7erC+LsVw9YrFYqDPFsJBffwHLIVmJwiFZvXREZjTWMQm7M+Q cPPu22j/3e0X6ZWW72jBWUI4K7usXisJAaIuBNAptmdrRirS29odKodVVRV95j0TFiWV1bDcgsLF n2VJOOgXElUEki3gblzoScUJb5tRUrkZl3zH5PMvNC8n7tfdMZWrYJsuYlVwWiZtDpSOD5R3RNbN QxW0uuqnfJHObWzaxz9oIj/jpdyRZeO6qssn1oAjm4knwZizFigs3YGeIRS6e2zPffWfj+8d2wnQ a1Go06EwVtNxvZ+0vQPTJ5xNj4SPD26KLYSiiMftlUTFpJF9+GNZJ1LLw+L2Jv74sJSFhumGkEa+ 0vysfDa1cStae4PG+68lp4qNhF/raOClnkgfb3MiexHJGhljKWt4zR5bfo0zSHPkgCHpe6havTsL uo8JpLyQ+2crw2tGXarl57GZTyRj0pebUrJLFGKfWd7mc3HasOcrXZiXBd+pNSWddeCjNKGtUsJp KqOvplVGEvWJArt8bMqMwvdSlJSqx8/ARu/WkRP/QkOIWvakCs5yKn19O1tIWUEqKHYwUhA1H2TE ts1x+o/Rp4XVXLxehr+mG1rTQikBOaABSNkcrQq4hGlJTPMT9EJ+F3PwftJOA0x+A5RsYf5qekvR T6/X4CTeDGrBXCAnbV2rbe9UbiWKTUqMkiQB4ErQEf72ODFmRhBhincYITWDdpxXb1er/X6PGOUb VNbblVisMEuHWCCPUNhIAsVlZvqYDoN/G3UnZoG7HUnLvQxXGK1hlK0Z/X8hs+kAoh3PMzQRf4Y8 re5fSuP7MtfLbrMr2yydMx5mpZxxtX4pqaeOBTB7/mtTkyYpC4qSUmZhTlim9jbhNzSM7npGvUIP +nDorerQdWpqzeXUqtXDtsgYGE3TqR/Op/y7IfyPC9/fMQg3FU3YRg1fJXpvnjktGvaYSf8cn026 x9/qkpdJKYvsgzjd9O55WF7Zg3KaQJFljXS+1sHnEagtt4FEU999p7KTpXOubRs1tPiuB06vxP3p Tp7h7trHJgE9Sue4TQVsLqF8KdM2U2dVOAQ+LJHiOXqGE81zEF3OhShpAYISqmeuko2qFRdwrXJL oNFRLbz20DppP6pcATFvM84qhZoTOMCR8NXLfQzqyCOcLWaLTwJngL7zXzHuncADbb6Ccx6dHwRn onL2lLTtEMm4gXilxZbvtBHkTOW7ZHpXSy4rUvbE0lYZkdQYOJB8aVxqhxRWJFmbKoRARz0MSkpA aCX7CublrAyzpVIiirL4kaup1rRVVdZ81i9E8d9hBJn372XBAQMfjPFtPQ7MJ0e9qxbaZDDXAz6T Jxh0Czqfp3ckK/f0RwcEOyjox4mZcePFS+h2vIMEDcL9N7KVsYF7Nn9f2tNAtdwQOafb9EszyWE2 k/1azGid5DXyzlgmxM7hhl4libqVsa93u547F5BPNNyPKpxlvzFcqhETzJL1KwyO0B9kDDu23TPm HtHlvUzXNBxiovZtpb68h7OqUvxPRueUwSvnjjtOeDtb4LTp6QtMT+jSC1/ZSA6z1MUK/oKuF/m+ Qrcz0X0TG9gUvyYpDN9FUeiYYeSYvg1rHEBouMjFa7Omxsb4OTZWcezB1/HGwBhFkTg72Oaw9KIQ +W64NsM1Ro4Nu+LcsLsvhPTOvdjp3P6NCJ+D8v+CemYa/VbYGa5RsHZMJ4AQCUyp/DezEOqPlfp2 BDv9qVKhZDvo+PeJndiHnZ6+s4/BQOwXKzcy472xoGByuTEDX0c98AXZ4w+M9ZhtifmIXOwhHGr0 2gd6T+GEb3EYRCaQEWJfouwyxe4AYrzC9grS3BUIRRH0PKUwYK8jBE51ZwzALhRv8IFuwCykAOqO EwUKop7x6jzjIShw1sGRIX1M6OfN1wGKPRv5YucU6Quxgb0A9gXaPjTWphUTbWLZzRxWKhZkA394 s+pvlpZIsO7REmqrs7B2ZOmh9eJpiRd9J7UO2TcY6EQR2IYHC4WBkX+JgWKfg+3o2BXVC85wMXRK OzwKKyfqjaTPAryYXK2l+EvJBLLr+mgd+AenQEhAYF8A2QVuvbV7bfC4voN8zzkKnr6PWA3LLZg+ +PMhxP8cAG0MOW8KZW5kc3RyZWFtDWVuZG9iag0yMTMgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVz Y3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxNiANL0ZsYWdz IDM0IA0vRm9udEJCb3ggWyAtNTY4IC0zMDcgMjAwMCAxMDA3IF0gDS9Gb250TmFtZSAvQUZOSEFN K1RpbWVzTmV3Um9tYW4gDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANL1hIZWlnaHQgMCANL0Zv bnRGaWxlMiAyMTcgMCBSIA0+PiANZW5kb2JqDTIxNCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9T dWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMCANL1dpZHRocyBb IDI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgDTUwMCA1MDAgNTAwIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCA1NTYgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDQ0IDAg MCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAwIA0wIDAgNzc4IDUwMCA1MDAgNTAwIDAgMzMzIDM4 OSAyNzggMCA1MDAgNzIyIDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VG b250IC9BRk5IQU0rVGltZXNOZXdSb21hbiANL0ZvbnREZXNjcmlwdG9yIDIxMyAwIFIgDT4+IA1l bmRvYmoNMjE1IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAy IA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTIxNiAwIG9iag08PCAvTiAzIC9BbHRlcm5hdGUg L0RldmljZVJHQiAvTGVuZ3RoIDI1NzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10Rk9F nS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsAjdag z0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0AQBk4 ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDxaZxX1xmV OCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuUDQbT pSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHBwUJ/ H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2++M59 +KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1MrsSE Px3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au8gDy twsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqACJuAB K2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyDj8EJ 8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3QCqgH 6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14HD8Gj 8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuUiHJR DBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCGcI0w TXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZNE16 TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g5lAr qO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+iP2EwGG6M aEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXGkrBk rFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3mkfk CXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovLFs8s bSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5aQvbetpm 2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSdxmYc bR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r+sxN 4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5qr61e l7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzqEB0T fefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHshN8Q8 cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy/cjJ KMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/TnBK UCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21Mu73Q daF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/mMfOK 8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdWLf2k mFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPqQXlU +WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOpZkaf ot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xxbGlv mVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXvurEq fNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt2NXP 7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuvnByc iZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjE qTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2 AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NY w9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzR vtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A2 4L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070Dv zPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t //8CDAD3hPP7CmVuZHN0cmVhbQ1lbmRvYmoNMjE3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlIC9MZW5ndGggMjMwNTAgL0xlbmd0aDEgNDE3NDAgPj4gDXN0cmVhbQ0KSIlcVQlQlEcW/l73 /88gBC+EIV4MDJcwyBFURKNEGETxwAMFc8ggcgkyIjHqmkBCPAo8Eot4bClqXAIJWTOY1ahxN+iq u2oMGm/XiJYaj12Na4zllji9b9jsVrLz1T/1uvt1v69fv/4aBMAbVZDImDglOi43Pasc+PBd7p0w q9TuaIrwnwBsqQKoYtaCCvOP1ktv89hlwHgk31FQ+ueP+vEKHr8DDLEFJYvyj+w61AwkJADj+xbO tue1vdyvmtc7w3MGF3JHzx96Pga6XuB2cGFpxcKWUX7HuN0B9A4vKZtlp+tPg4GlU7ltLbUvdHhT 9x08P4/9zXPtpbOH/jaoEtjWi/lkOMrmVzBv/m195B53lM923EioYy4DeI1uPvpqQB+HAP76yjr0 AdQ1/m7wd9s1VnXoc2BxFaur0odn//7nDwjBOmxBMB5QLA6iFWPxEV5CBuowGm34DF2xiI5DgwUp aEIIBUAgFSbSsREX8QrKcRNXEY50XKGevI4NDvhhqLrD/+lYofaylyeSsQP7qISmIJrtNGGlSI68 RrXChHB1Ql3g1mbcpGDVgjS2vkcPhKES76MninFMdbgziFw00hK6g0DkoFaL12rUHAzDLpyldLbG Y5F+ocsulPCs7WSiVtWubuFPGmE2r/QOVjDjnWgVA2WyvhVmhOJFTICdR3+Di+RDsTJJhalRaiP3 NuKhiBRHpJF5RGIMZmIVtnE2zuEGfiIvGkSbqZlxiu7r7tNNx+tYzHW1mbPXiE+xl2IpVpiEibNl wgBk8tgaNHD8z3GS0imbWumAbNBjXCNVL+WrbimFCGQxwy04wDEeUQz7cAQZJCu0/lqFHvfsbd5h HjbhJE4xjyuc95/whCIY18RbolJNV03qJnPxQAASMAkzUIYFeAMf8qkexCH8k56KLuzZph3WF+sP 1FrObShGMfeJ7D2F167lU9qJPYxzvMseZOZdJNAEmkwFtIbW0R66SBeFQQSKeeKudMrj8rI2WNdV Iq/kh/4c14LpKOQTeIuzvZb324TDOEq+FEpRvKNzPP+xGCZSGNtFm7gil8o1Woe+zHXV9XfXU1UD I1fZaM7D6/iEs/AD+TGHAVRM8+k6M39P/EF2ld2lRQ6SL8mpMluukHXyr/IbrVxr1i7pY3S73my0 u+a6Tql05b7VBAPzCoMV8RjC9ZPP1TSH+TkY5ViCt1GD1Vwva7EVzbzvr3AUZ/Ed/sEnAApkzkUc vZSrbimtZmykT+kAHaajdI0euyGCGOFisBgpkkWqKBBLGXXipDgnbsu+cpaslFWMerlbXtSgaZrS 4xhpeq3eaDhuDDemGXM9vu649yziWfazKy64ertedq1zHXDdUtPUIuYfgigMZKbLmeVGrsEGxidc ibtxBF/jfCfXhyRI54r3JwtXg5VPbSSNpjGM8TSJkcmYTjMYdsqlQkYlVdE7VE3v0ir6oBMbeG8N 9DHtZnxB+xhnqZ2+p7v0UHARC8nVHCLCRLQYyjtNFqPFRDGZUSDKGA5RLhbwCTWKz8VecU76yBAZ Je1yntwod8iD8oz8lyY0qxatDdemaQVatdamndIuaE/1AN2mF+r1+kFDH0O8IdNQbNhg+Mxw29Bh NBgzjLnGJcYzRuURwmr1F973LvzyF21oo/l6L22haOd74S8d+nLK5IwZxFRZIlfLb/V8eiDNdIlq ZJGco7bLVPFEltE08RUFyQA9UeZjJRQ1i2vikbil+dJUcYfCtffpC1Emk4XBHUQ/rflq1fptQJxH oniTWsVhWS2r1R+RqNdTu14vTsGsXRU+aOdbvVys50nfiCJRiywtXn+KIs77x/pCzvcIsYIi5Bmt HjelRfxID2gdq8YJGqsFi9fEUGpmxX1G/XGP5sFBHyCJvqTvaA+ImmQjjRPP8Wk5hTcN4UfohAyk M9IT2W6OFCp8KUM8EJlyv+GkHETEKvEtFpOkGK6d//5cmMs3oE6EsabZWE1OUxz8sZ71/pFrv1ux 9Qt6LdfZNmnFZMTgVXEciXw3bjKysAxx2Mc1uAIxYgOWqCrKY90fz/opsIeKEU1erJYm5lbJ74Wf CGItnMlRn7D+H2PVT6f7eIPMfLNaEa65R1ZqNlamHNbfWkYeXuXWJqw17NJPYyKZAM3squcqv4zX +M25zvF7Yzjzm4FtmpVZm1mZ5/GMTa40JDGW4TgJvMmcR/A9z9DSWHnXqWLeYRG/UeP4TTyKIrUe yXx2k1W1qsVMtU29ggJMUU2svwvUTgzGcj1bTNMjtXjW2KN0iN+jv1Et63YaLrEehZA/7jL4ncYI /UvUaOdZO0eqleosfDkfQZyhXH5Fb6AU9zlvabIVL7gmiBaVKh38QrVjkmpUAeSJQlXCyrsfDUad tacK/fUGrl0kjcqcmjRyxIvDhyUOTRgyeFD8C3GxMdEDo6yREQPCw0JDgi1BgeaA/v369un9vL/J r5dPzx7du3X1fs7Ls4uH0aBrUhCsNktqjtkZmuPUQi1paVHutsXOHfZfdOQ4zdyV+msfpzmn0838 a88k9sz/P8+k/3gm/c+TupuHY3iU1WyzmJ0nUizmPTRjUhbbq1Is2WbnvU57fKf9XqftzXZgIE8w 2/wLU8xOyjHbnKkLCmtsOSm8XIuXZ7IlebZnlBUtnl5serHlNFkcLWQaQZ2GMNkSWwQ8vJmUs7cl xeZ83pLiZuCUITZ7njNjUpYtpU9gYHaU1UnJsyy5TlhGObtFdroguTPMv1mvGtiojiM8b9+7nxAb n3/48xlyx+OM7LMxP+XnTHGu2HcxmCYxNubOdZozmAhwm1DxE9FGwSjiJw9oS9pGBBGEUBsh3IZn k7Q2lZBRFaG0omlVGZSEtikJbWkTiBC0gkh+/WbfveN8oYVWtfzd7M7s7M7OzuzsM931pkcuE1jH u6E9gb6qIWPvgI9WpcJ5XXpXZ0fCVDuTvEZhGOs2mBO++dHEO11MXlSf2JUt9atGbOK6AHcNY1fA PNKcyJYG+TeZxBymCMVTRhwL74ULm1oCWEvsSCZMZQcWDPA+eE/27tboMeak1gfMB/TF+lpjfQoH U2qYtHxrsL+0NDpofUClsYDRmtCD5sN+PdnZUNZXQsbyrScnRQOTRkuqq/p8hbZb+8YWpBt5+dmN NRmZbMnh3GpanvGrwhbpSxAOZmB1AJYkdOxpAf+sWUDG6gUYhr+kAi2zC+exznygPmX4asH3sb7p Cvn0gHGTcP76Jx+P5nSmOe6Q7yZxk6MkE2iQO20zHDYrKzlAPPU4UdhYJ/tzq6u2DAhT3+ALgMB9 9Dh825msrYHzg0E+3j0DUVqFjtnTnLD7AVrl76doTThpihRLhhzJuBUs6XEkGfWUjjh+g/j7Ypzp Lc/8F/jGF8fW1prK+P8gXmPLm1r0pub2RCBmpNK+bWod1bPlCzKydEuxBXC4qYXgqSU6Qm95e4IZ +HeF4npsXaoRqQYbzeL6hOoXSbsl/KqcCvHbkZmZO4k8nksLuWX8dw14vAhgyVECcdOXarR/k2OC wftUGrA+ZS1J7qil92TWhkf3F47qjzIvz1BhsFYumlrbDWPMKFkcl5VhxPVA3EgZnQNWzyo94NON QTWhJowNsZRz/APWqT1+M743iU2sVWoR2oIW9+nK7ua+qLK7pT0x6MMn1u7WRL9QRH1qcbJvGmSJ wQDuZ8kVzGUmdwLcQX1DVvQLrxzvH4wS9UipJhmyv3pAIcnzOjyFVg8Im+dzeAI8zeZFJY//+Kao b01kx4BMrGS1fADgCzU4EqOVPvps00i5T3Ky/9yGO6KUcUs4wAtbbaAdGr4Bga+5j1OjO4JdfIOa IWsFZoC/X3uBQhj/NPotoPtFhFTwlwKfAlVACxAAVgEJYBnwHNCMsSbwbZ7DgbqPOjxfpU7XWfK5 2mgqsBRtXfuQKrWNFES7kftYb446mSrRngpZhWcyxp61LrMc46bKcW3Q20g9kNeh/yBQ5NlHftAC oBj8UsxzjG0GbVLP8F6ta2hvgR1L0P4MNA5bG0CXgf8Y2ouAfOh8UUSs1WgXor0IvilEOw+IQe8W 62B8PmzsgrwEfcFjsW4+qJ/HYs4K9YLiVw7iTXWB+rRWKoF8rAT2zXt29sT2s03/BnG2Lxu2fRJs q7hj2+cgcrBGnSPPant6r4fEOdqgHrGuo627SyjG8FygKdjfx0BE66JJnsnWX2HjEtcbNBd9LzBR guc8RDvVGxSFLOx+GXHTRXViFgRzrdviWzTZHaJHsF/4m6bD9iTHHmJhGsa1SP0umqJdplK0owwv 0Z8zfoJvcPZNoPXw+1UvWZ9gjnoG5hkEzkB/AtavYR/wuSttI70YewWyZ4GNiJFJwATI98gYhg7r Y50v8Rr2OZBPxiDAsQfMdpA+HwcPOpD+Py4xHpgAzAd43ZeBnwOPAt/nMZh3PMZPgR3Pc8xwbHJ8 cGzI+Ec8yZjlc9wI33CM2TnzI/EU7QZKgCp8lOxMoxJjZb7wObLNnAs8N8cWx4xDIS+34165xvvk mMqiuqtKri1zkGMri1Zw7DNVo3IPFWKI5nHM2r52qLQhxvnIOeFQxx7OT5kjoGo3FbPv+Nwd6vgi Q49QCLJlrnfpEW0WrVTfQvx3oP046Hz457DMwWvaD+gjsYOEZ4iqcJacu6/k0AMMz7CyHvMNwZfl 2jl6RdJhMVUbVlyuXuuKq1c8b8NpZ9NcKEO2jCkjW/bf8v8XiPOuXnoK7b+5hi1LG6aXsFfy/F2Z CQQcCn4/0ANUesPKAW+3MuBZQT7EzQ3gGS2K79cozdeG6GFtnMy7EPgrMHeN1k0LoafiS+1FdQUd dffSF9RhnCPWEufpBQbPD7ohE0e5Mff5WJLUide7UM6BfIfKnIpYf5B5FbH+KHMyYo3YlCJcG/h+ lvWB5N1c6MRrJi5fpXL1ZlZ85sRpVnwuhJ4vNy6z6Fim6dqS7+QpdMZzreH9y/uxTeaTvOcg63fG 59KM/nEaEMet9+U9fI7anbwGZgEhyH+RvkdwD+O8uWbuszrcz1od6lKrA/v8qXsX6HXrpJhu9WVq aohmp++yUqeWsp9c56gsU0dD9Fj6PgtxPdWOoYbbdbRY1s+/0ETXdXm3zZb2ch5yDtbg3puOOv4P 67ZWRE+rLxKpyEvmI0aaWaZ5aZz6J9y5S2mTetj6nbpf3kExdYSSahg5DF34bKJLUJmrgZqgQ3I+ HgPKPLbfrSE++S5oRB9n5dzLfPbu25QPTHddxX3UhjHH5V5D8h4/QNPYD1J3M+oK5vKEqUgTFE6P CUmdr+O9IP2BOzDLF+naXMdzupfLmC2QOnOs294iijBcr9E8rB+SazVSrTdC5a4266p8VxTRo+pZ mqk20kNol8q434UaVYF62Yj6CKgfAiOITZ/dl7VaUuuWrPfbZD3Pc9XQSvmeYJmbprgraAZD0yFL UbX6GuZ5BnF1G+3XLUu+D35Phbw2+PH0+4TfCULmy2+h9zZVc46xDbLesD0HEW/v0ENcEz1H4cMx nIOKAn+XpetgEfoC9DtZ+G6aV2ZTJSjepTYpa6UPxGlxQpy2uvkdqL5HT6o/xPmdoKDajvr9Fmrj QtTwpfDVbyih/hrtqeAfBrbg7beJCrQC6lIvYdxsyDZA7xzmOAo5Yyd0LoK+TovUX9I6dQjvg0v8 RqCgthn0CaCB6pUfU7e4Rd3ueajJC61X5fyMTdZXJI6ibl5K66YhbXVwN5u34m13F3ulrdl2so13 sY/n4HmlHsZoGhUQWReBkE1HmsU+6gWOiPcw9su0VTlmnVIOUVy5DBxK4yfUKGkf0Iwcm6s8B8zQ 5tLPgO1oV4GeBk7YfToIvA/swNxnQE+68anAEIsRz6DgHQYOAL9yZNngte7Gz4bLb50a1X8TtQZQ bmAPN0bL5JrbaR7Wm6ctsk4x1CuoIYB7G5V4tlCJOh38KdDL6bv8uOfepGn3sudeUN6hmdKHNqL3 s8f7Becu1+f/13z3C5zvNuAJacNV3Mcyhmisct66CNqmnEfd3oy7FEC/Gv1ix5/OOYH/PcnPOT/E Cqlk/TOXn9vPPdd79cVJejIbThxk4uElqmNoD2M8kNv3vk11/+K+WmOjOq7wzJ3ru7ss17sshggb MzbrxTZeYrOUmMC2vktMiB+KnYYCcaUs5REkHrIptFFVO4a2tJAmtRtoIJBgh+Amqu16uYvJ8mix VJEoUQKuVLVVpYJpqfqjquo8oKK1cb+ZvdeYdZDjNP1Trb7zzTlnXjt3Zs4ZAe0ifBfH6+rrE6AO OcoRMSfswfzxulZD8gWUPMw1U7TBmQNG9cu4VwFRV7bXES8BeXYB5RRiMTDqX4w7Hxizrg+IdWVH kn77+9jfJfX7YH6GegmoQz57iZSAHwdHbB7d39Z9cdeefyy530d1cZf8JaXOnTNx52zgrNyrz/8n 4Oy8C7wNvPW/HosS7FXAC8gcdRlZoS1G7rma4Lk6/B4hQxng6YgLOHlDAyj/BuX1QBHKb8J2GLwP jKtm6DbsI4gjDHxMzUT+Tsg+AH3cbki2Hb4JPJ3sY/gcIf/+vYVdyfZDzwEPw4fMbOgU8Abwc6Ac bex+fgx9B/hX0Fcm+xpCefga8AOgCjiU5KFnAeF3YYzfiXzkE96hnyvf6/3xadl6Z4RtHveGmAwv +1R815vD/v4Tsf2W+ASW62DNXxszn3u9ce5i7B/XWCCX9oucUuTRIpdNQ/4s8sdRFu+2RyRPt/qx 2SNioMidRf6atgg5c/KdVzTmPbjCjhtj71b6MTkGeIEsi7eizi28dS4hNnlwp97A/zshIGObiGsA 5ntZ+n87ckHUAb8PPRt8w45p9t067o6dIKZ93vpkY+RniKkhC9EU3MtuY4mFCoHUWDxZTBS7P3Ms v0eMHhun/1vdjvM2JspLx+UBE+gT9TdZPTXvmLSekpfYeirG+VP3np3PZJLMUaScu8lCvC3U3ju5 vz2H1HM8et7sN0IzYuoY4B4oQMwqBI7jvigBsgEf8AJszziHSMjZTULQe4HTsP0dvFH4wG30eVxu N0eGoX8Huld9X9Zda2HjRPs5dd+K/Fzmh1gzeQ+2ivmTYmAZ4ANOAtvtby3enhj7r8p5QsQ7V60b uaFeAlJywAl5MdkBdEP3QPecJatG+ti1+IoVISMBLrpfsllQGDojHGbm7NAv2DWli+QTDsNVc2aW 9Fwxly+3Cg8sSRbi8xeErkamsCvkH4DCrrCrWHTZKl5wf2gwosNA2TO4qSnhpJ39kcQAhRjsD/G8 eaG2C+w9+N9l75CNstk7pj4thA7fZm8SH+HsNOu1PL3x9GkhEtmJkEJJH2Q/MAAMAiqpZ6+TZqAF 6AFU4oHkQDFQIyysk3Vinh1o74EsBuqBFkAlq9jPYN8qJHuDbSFz0fY5dpDMAP+QHZB8ApwJPg77 HPCr0AW3WfpRsPAfsewvQZ8JPmzxIdizwC9CF/wTS/8mtrVot8vidrbTnMO9kTnw5wAlAEPpIEoH sXQHoRFIyr7LtsmRToJD4O1JxnI1mbl++Y2a4vfNCrVjSZuw9E1YuSasXBNR4Wq06zQm6yxgjajT iDqNqNOIVSlhOzHeTpEsQHqBHIBh3Xdi3YU9BtkH9Ev79yBbgXahsaexjoWY1X62xSzg2GSb4w8a obJz7CkstcGeis/KDrXc0VxTxEYEp1vsEXU3Se+muGuqsG6KZ2YnGbW2RtLZBvJtQMHVuIHkAV8A ygGVbTDzivlZ9ijZ7iRGOm9Wmlmz2pymlpRT3wUWIrXIpDnxsQUkjAqFPBqmpetcDa7dLuZ15bhK XIar1pVWz5pZC2OcFbMyVsOiLC0x0mc6li4CGSu1pYta3e3umLvP3e9Oi2l9Wr82oA1qaTlaiWZo tdo6rUHbrbVq7ZqrVWt1KOvcDe7dbuZ157hL3Ia71p3GHbQ9spetx98kkF6gAWgFVKxxFPYc9iQQ xdeIYimehJ1AEmheoB/lAXAaNA/qeVDPA6sHVg+sBFJ4aoF1QIPl1UY9dhtRf1B4ADwLWDqs6Vjb AchBUQIqoenQdGg6avUrQ5ihFzIHqAWYtA0A2DWQtq/E8q8DNOkflHVsnyHaKkPG1/L7CmmskLYX 0tZCaoTLIiFjLoTP54v6o4FoQbRDrffXB+oL6jvUGn9NoKagpkMt85cFygrKOtRif3GguKC4Q+V+ HuAFvENtqe6pvlB9uVqNVtdXN1ezUny6uFlUEpI8NyC415yVGSr1RJYpPfg7Ucg24CrACIcsBsqA ekBVeiC50g1rN6zdpAaIAmlo0S2uF0hu+YS9TfpESfiVu/wMf7zLXLqoJlKJKzcKtAEMfXfB3yVr J0s90h6DHJD2Gqt+u7RzSLsNwwVXJ6+5Ohy/OlIGRIEGII1cZmvIVQA9Q3KgAegBVFaH3xq2RunG r0vpYkFDXziDk5kzCSG+aU5vxKtMxR7QEVyFPCzlfinLpMwz0iv1m5X6Lyv171fq+SgoBSQCx0Ep cw13RD8V0WsiemFER2/3kVyiKzOk1ISkf5PyUSmDRkaufitX/yhX/yBXfyVX35GrfzFXtJuNs6sr GVK6haQvSlkp5TzDzfW3uL6G66Vcj+j0GMXoZLmUc6TMEpJ+eMpT7iGuc/RDUo6eqBku5AmFSKIj ZjgCum2GV4KGzfAx0L/M8AF+nt6iMqTRm2bedR6ZQT+mFarQP7L4A1pBOsGD4M3gn5IwDYBPmOE9 ov5raH8E+nEy1ynqv0pqZbs2WiHtr1jtXjaD6zHqUTP4LYx6hATlqIfM4HVYD5jB/aAXzOA2UIsZ EBPcYobn88g0upnkKaLuBhJQxEyqrREfQc/bwCuTjVeYQdGqXAyQoA+Z/oWgfDHL89RPauVw3PTL P5lN/LKL2cQvJ51FApLTqUdOXidzJTtN/x70op0KXOf/DJ8Tf5zcoB7zGP/zefy/1VD/RCvMTv7r M2K5TH45mKCB0/yS/xy/mJegq03eF0w44bgQTCi0l5/EIsdQV6GneU9wM+/2S2+HH1586rbwAn7U X8dfCkA3+Z7geTENsh3/eDXcTwS/xKvDnfzhQILCbYQxmDGFL/V/nT8I85IErYh38oV5CTGVEvTR eZrPx4jz/HIqXyk9qywmDvoNI+jY5VjvWO14zLHMscixwJHjyHbMdmQ4fU6vM9051TnF6XRqTtWp OIkzIzEyYBQRnMIMzStIU4VUZdmrCAkhbn2FOhWcndh0VqVUPb6cxnxVpGrV8lhpUVXCMfLl2JKi qpiz9qtrT1L6oyegxZR9CUpWrcUGFaa9WTHfQ2vPEEqL9z7/H9arPqat64rfc5+fzcMG2xjs9/iK vxPyCjFgIG5f4RnsdIlDmoaowzQMA2FJ1m2EGEda1BS6qcuqNYFp67opWWGbhtYkU2xcGkOkkmXZ R9Y/qNT90y1T0EqlrBtqtLXJ0gTYuXaUtFL+mbSrd865Pufnc+6959z77itj8rkXj0ejEEle7CeR PnvyZgfOI/+priTvahWJ9XCL2FLUbA5sCT2Exe5x+UET5c82sSL5w0hHZ/J0RTRZxzprFdFI8okO +57OWTpEB8OhWXqQiWjnLByhQ+FdTA9HQtH7MOKkBxFGFCYYLE2cDEackM7CtmdhWKbOcCjldOZA l2ArA2H5XMqC9uV8uTEE+trJBMJoJXFnfblpJYNhPeScGT/rzEDAmHVmNJCss3IGSnk8CHnEwyCp Jg8CUp6mrPnMA7PLkxtOlHiycTwQzcYBeIDZkMNgFdzD0DzEyP/PNtD6P4Ah3Xt1b394wBWOucID SLHkdw/vF5OjfXZ7au9VZrAnOW+sr38/k70DyauugVByrytkT/X2P8Tcz8y9rlCK9Id3d6b61YHQ dK/aG3b1hqLpqZG2yOdivXQ/VtvIQ5yNMGdtLNZU5CHmCDNPsVgRFivCYk2pU9lYkV2tENnZmcoj rdG2PTmZpvp83A+xMke01Wo62JzdHI85xOfL5jQEX1t6OZo0uFqTBUjMVB2sDjIT7k5mKkS18Z5J fP4xR9kc/PKeyYRqs6uVyEQMHwjdf+Lx+DCjREJGPpwQs7ph3LSOjkhyy1NdnUklqYSTaiwUBZaO xL3W1qma5pUFhQ4qI8qYMqGcU/hEIorqonnngpP2OAedI84x54TznFPLDHs631SVCedHTi6B1QTD 2MKhbMwESnzYz+FEnDWCAeJIuXByQm7rDDpJP952AW/m1cSC5EKqR+pA4slvkL+L9D7Sv5E05FvI v4/0c6Q003DVXHVYPBBiEaMyO3REri7ta6jbnEHZ++Wc7OjKyfCOnFSCdSLK6Zb6/KARL95A5pD/ EenPSB8ifYrEc3VcXdZ5Ile10TiJy4DDJ/hjmLG4PAwydoAt93BclgkjVuCYAYTK8Pm6JxBPEFwK TAgKBGW1cfa3BJMPgHgGlxPCl7PbMtGR9hSFC/QtvKbq6Pw04TUZ+tYbHMnXsc4MEClPy8+jnRIO qogAz8KXiCibbioryg7Tx0r7ikJasG+6i6zW5zA7zB5kUK4hd+3cxbsqT+4Qu+YirkQHjNJOvARx pEW1U360Ym/jCA+Q/bDiCDXBTojBOEzCO6CFDPhnyKhmdxeLtdKtmBSyaRl5rQ+6ZYujxNFB+ZU7 1PYqe618b20JBskloieyWk5UrZ5TBfXRBkFtaegRYEI4J1DhRcNXjjBfQ4dkeZm0LNf6PHXWkmKt y+lt8DcC2aQGa2qCwUtZXrNJZX65tSXazJ/AEe9SBcK/vW5fI75yMtx6tYByxZTisHE19SQD69Ri O+fjYtxB/KJd5LTcBfgVfVuTgcHUNRZ1+eNuDKq0KMf4Gvmo6XKtTwZwAW1eLdkJ/+BPfPo0fxp9 kW1r17nz/H5iIm4yN92bZ8ebxTTPlzBRUFCaAaNaJJQSr+qlqjfmnfQuejVeM1MX9pBBMkLGyCTW t+SZg0pcWlHGHHW3L+8wdQ/dbGfTZhNv+4a6Hdwut9NNtRQ4oFqdp7ysoqyyjNNavEaP3itKNolq HRpzH1mnLe2D4kLsWQ3Yc4O9D8rykBWZSvqIlI8se+4ytjFLGze+YPEXNTXW19ms5mKKK7ze22Sy WevrGpsazf713vVel1OnpdteHu6KnXru5Hfe7bv0wtcuhwNDjcOVNT53oOrRUMMX/PS16/DkruDE b1fP/XP1zVc++PWt1eupV3oPnYXA9ZNxn+PxjtVTmKMbWMZaXDEreVUtVsWYOCkuihoiqiI9TL5N aGHQAgfw/ivAJHFiDbN+HvZdmOD/ECMcIFbUEPiXijc7IxUo8EKegXJkDm4hfKtaVFhoVM0NPuOI cdw4adQYJdscdcPSvcWVlXbT8pJJyWbXXBQAc4B8snwXPpHlWh/phqFui6feXGy12kocDc20gS0A m/8N2OawKHtWaWyzNV/nKfW0an7/0zvHDm2upB4Prag9Qq/+YKO9ch2rw0dwjmdwjpWwX/2mTtQH bGL5435RRSYxZqy0Wqt0im6r7nWdVrU/o+nKe8bWJT6bN2weLjql/0nhj81n9WcLr/BXbH8Q37O9 Jy7ab2tu20rwlquR+LISySrZKkSdYNOL+gq/9IT0km3MrhMlSm2lkkHSFnAS5bWiDfeLzqIpyOAw BEEtNrSMCiBkuHrVYOJLxySYkM5JVJrj6nHhjqeBGiozcFwtINq/PWnpsQxaRiwaSwZ0qkXFSZUS u2oftXMx+6Sd2qULcBv3WQGoanEPHaQjdIzO0wV6jX5E86i0bg5OPKjnJSVX0d3tuK1MbGMtr3QP KS0rQyktbdvdeX5MgHlhQaCkeygqL5mLbIFsZooCAWrKQd44Kh2X0B4tVI6Z+KOXC3FLwtChbswY OyRl4BwNhDT4MVVanasRi5lNXqujOkddY2MTd6bn7iL0gv21r++d8HqkhZO/+Ktv29TtZuj76he3 lAK/escDrfCj11+YSgzN/u5P4/v2/Wxm9cZmUy17KXXgLn8a81kH22dJ/tritCEgZNYuqoohEBTC +Vv0EadmQYCqqs1Vqj/mX/Av+m/l64gfgsKI60jNafese67mSs011zXPX2o+dP7dY9iaV5WBl9Mb NphIhi6l3/GBL8P5ZzjeZAVrBiZmKlR5k78CP3rSpoKqDRdgPykmAn1f1e/EHNDxbA4wk+mkAQwZ GEd99Wg1Ha+erKbVqJ/p0Y3g3DP0AzVf9cOk/6Kf+vHcaz6vWv5LdZkHN3Ffcfz39l5Ja13YumWt ZWl1GAkQMjEwYe3SQMphMjQ4plExpjHGOAU7XDZQhGPKYagpCTQtrREFwjWZ2IEaYxiYdAptU6Yz baflmnYcxpOEZty/3GmbYtO3K+WoZ3b3aaXxH+993+f7/d20U3ZXSgPOJ18MSJ/OWKZtXLuNok8g euJj7fPGMmO2qmSeQZWJpD9sMDNcmRyUy+WQzHBsqCgcNiBckszURvCbsZKNSiMYxAQ3rRFKJZ9G G8vcgvvFduOfvmPtpC0et1fqzME5lejDknW0a69KdPqkdfaEg0FtD7XJ8s2zB7pP1dUM78xuPDL5 6f41Sdnltm5zhGJNPwq6S+PHlgZqTyzc3XC8mfnG/qMttSvf7Js+uL1/97n5iq9CYOdxxr7W2kXP +CLVfsO3u2vX7npbY3gAt/UqTtdAJHJXjZRIGMi/LqlmWjVDzATFPAIXaJHlgDEZJcKYJIYzSbhV XtXGC1N4XhBohudMAimVQLoGP0VvNsIJVWKBEwWOE1jGZGKu4ZmBRpI1qUZRNNNwgn6Xpugh+Jfq hHn6epmhAXk1YqbNnMoD7yr6yg61zdUnNBcXCMuPLJqLz6tKWtBhLWOWifa51iqrvjB7E3EG/Uor zWYzEq09A5m2digOWoNWOQ0pfAB9dfDMxC+pzd89M1kO4z+Y/Ak0ZemuJwepkxOrNH41ot472MVE Br/6tdMM2Or96/y72F3cLt9B5pCPT1Np+UX6xUCdvN67he3w7qUOuA94T9HnxFxwJGgmQTBbrDZ7 cYlDmILOS2utsgZktFwmILs9Xpp3Miy+PXEpEJDtw0gSJ21XsafwiFCPZBnz3TA8Szyw4BdZPqfp GP6JOg6CGmwIUkFckP8MWqicDLL2T1QxoFpyFsriKhuGo/BY79hoBjFvyWjd0aU9itDBGv1UFzRS X6PMXiERZ7FdRPuQB40qtUM71R7ogi6qK8AhcTTQIGcw4qrG9cwG23f8G9mNPjZTDxngZZ7RFMxx fCGZIHgK4kXtKkB3LJ1srgfx+J667hde6+jckAi6leSiJZsH+npevQ4Mu/jCoNK3b2j9YFaZtXyG N26RZw7s2v7n2VN5yqyp8yWcxQCq00ki5Ika2yxuMWwt6hLvhx6HOI6GnXQn01myx8HMFSIcSwdd ERdHB1YJICA7BgNhCIfNGM4OXXISVgsnl8wSZlxQtRmpNqObxNQYpcYaYrnYSIyJufJ9x6+I3WIP 2KfZVfthe87O213RLyPKk8ySidFCRtFRgUDHrmbG2rGN8GUvLxs5D0fpLUR+VHhDos3n9XspzhqS wiExiISweBqJXIRVuSHcCF5boJGUmfBGPs8oGjR0ZEBxEc1/znUto1hn2sorU8AVT/mi4wh/+lj3 2VPryw//sOfO2h13elbfOALmf6+fuGNb8Fzq+br9+3aG69jmkFT781/vXzPSf+HghZcvgW8QFk6+ NDF/7/KGD2uSp9+6+FkAt2Dx01H6DG6Bkbx/lTBPRy7ZPc+yQ09H1DgWLgFYOibWEFVqkHLSB/Bb 6h7co0YkbCkYgUiqRFMsg4nyDdVNU1NommJoiVUXpNlHwOGDewQo8yH48WDOCEaXiR2mPiE09bFq IoyFUZllTI5hmevUR8RU6LtFk7GO63HNQeOWsXg+n+4t2vmrgnjFTewmrpvt5piCcNEh27GPmMAx vsoY43jl99Tdybkb4ehkT9u0b6Z87OLwZzeYW55Eg1E7YexAvR1AvblImKSgUx2uBxBTpamYsiHV WZY1Zk1Zd9bTFcqGD6TOO8+4z4YumS67r4SvKbcMt4x3pRKeGICTKLeolEgOd0gKFS2Cg/C6tKfo PCmaQ2bDIrIIno+sgm8pL6daSAuso9aGW5Tm1HbYoWyp2JHqZXrZLJ8Vuqxdtt4pvSVvMceEN63H bMdL3g6/o7yTGmIGhcfGv5seFz1WHs+I8pKozCZV8MwMdr5ATG6F0W8Wh57FOXaq9rBLvmoRuS6i 8rVrGtYWZLGFpNU0paYb0rn0SJpJB6/jFzTuQAx3wDDNoToOO2iHa+Yw/KMAFi2ej+tQGRsdzyd0 TfDgqNJFPiOe9JdZSxihOCSzQYzjvK8RKqbEGknCho5YxqBF+rU4Hi+Z2kiS1ql5qRe0rvmjBps2 bWrhAk6QLnyJI3/2UbR3ocqC1jXl2zntUXBL2H8yc+f86d+0XuyvWvxg4P3WFR0wfZu6pakpm55e uXzZoVdbu8ILqIvduRXdN99rX9y3ft/Sprbe33Wsfm3lwF9ad9au27qldmZzcvLj58407D7eWbew qgUZ9AJuwjnUhIMoYFJT25X77N2y+wrTzHSwO4VOcatpm9Rh3xroEV63G0ShN0rNEVjFKStOlvaH GMKzw7CGOEG9rCxDZ0MyqWIytCGEyZn4tfEUsciog5cdDiI5NQK5wXyF2Cy2gI22DcErSKOoGs1G aTXaEM1FR6JMFDSGyfgz1XDTQBlckf/LM2P5QDORp/68Apws4zgqnft6tNTnFfOUC1ZT2BLyhoPh UkluJD6zdmwSsAoY/Xh2suKtTAx9FUnaoHRPcKQrK22z8uSfVQgzFNIJtAHlJ6SjqbVr5A/Rn+3q vdO0/fbZrUf+dvvkDSplq+lYUv/9+upVie95Q9RmKH/3lb9eea/n/IGL/3002bG7hbratXT1h9ty fX/auqICp9D/dBQO0/3IIwepGaBdQxBSfdLaysOuHB7+VMKbEOhmtZhWxZmHi3PFVPF1CKFv/BFI nh7jevbWj5SQicOMvKQ0Rdm/UoOcqK5O4FWRrK7RnnS//hGvCXtNvqrRnKmMECaOfCwlFbDtKklg IH5jdjqZ2Ozc5Nnk3RHZmDjq5TucV8qHIw89D70PyjmXYklEwlWhKmVOZFpipbJO2ZjIJoy3Cbi9 Ue8i713XQw97LgIflN93PCi/r9yLfFrOedWgLyIUlXoEuQxKPbz8P6qrNbZt6wrfS1IiJdIURYm0 rBfpB/2iLNqR/KCtVEzlxHGc1EFjp+ky1doKJMWQLbawV9NmEdZkg9NtNTYg2X5sSbdgj+5HPOdR t/mjYemadjNgbEGXbfBqFAW2YTPgYS5QoHW8cyltwCjpnsvLe8V7zv2+82gNaDGluRUl9FR3ojPf OgkpQSurdHdCFklxLCejqBTtjTrR2agnOp4mifoj+X6Uxk56MU1dSVfTq2k6ncLeUIiaxgIUkdA2 NEDbEhAFSaKmRXdQjJJB8Qc96WX8pRvNn3o6YpqPbcHh5w5tuy1grGxCUVM49hpqp3v+HnPFxpNu aSkRrFkkfbZl2yTFJaAt3tbVGI8Yne1dje0Z3BaHpqOpO4ONWGsG1dEF4W586llHSrY0a60jTEtS H0HNuoYwSfag0qk5CEhSICrCKQYJwjJQq2Z2DQ641Srky8271PqBdqj10EjSZ3wt3n4ou30nc9QI xzoOZfC/bv9u4c/3+sp7+h9PPHN5//mpzGHquYdfqGgpwxjSPk+fIr2JpTM/XhXH/P6XK8cuT4Tg 5Md3Nuh5+jrahXbT47+g3Mij5x1irrxDrKrE2LTB8Tw1bbiWNZCQWd7ZdHhZpqYzKpkC93+5SYwN nS1HIQbPuHMzNutKtsc9Ot0HS9IZlGS6Ur1ZwfHBnwpOIkHaIDwSlnfuO0kyCZLscxEccUcj7oyI ZCTZXIpBFoD+rmkW4USIiVesbeIA7psr2IIbl9HV6ppp3pXur/T1mmbMOc3HL2Yo+cgAlnXNruR/ 6rvtp2VTPovOZr6GXuRf7PcmZHVYylfyjC9+0HPQu1ff23Jw2MnPJzi/yOqoZRxP+Mf58f6JwcLw +O4n+JP8Bd95/3k+MKW+oFJafiZPlbgMyubSXT3ZOziGBCTsVG/7bKGTtwWie3S4XxIOC5QDTUmg dVd8UWCEXGR554HTxduTkZnI6QhtRc5FqMhXNAkTjXtzTo4CtWdJSdjTD3Zbpvc5QYZPV3twT8lA mQZByGbB8B/DCXinM3fwSdSGDPJG0UaGZlSMBYNxjE2DqhjYkMgk4w5VQCxSdqpLmq0s45NOMmbZ fawj2jp7mK2wtMTiTRYTB194pPC5mieeK5dNEi9NadskbMltmzmp9oFqBuW3tt8vShtz+Y3ydnHO DNpkjmlatWxmiRYwpDE1p13312P9I/FWT2hwaGCIgurKz1FQNuotlLeft3UUTITiSA4FtIY4bmkd 8dhxNMRlddyf5eW4FMdiCzTD3lyc+PKcW5dCA1+zu5sUp7iM59AcZE2Q7h9bysuYJPkmKkPuf7MP NAVEri9Jrrgt2oM66L6887clgYh1h+ftiM7bjfCLE7RHedsPRznYSaQfpB+kD6TPRub/X0+CnsZ/ a4jBgYHBWr3rVRrD/6srGkkSEAwTQg8ODCouu4Owphb/qbFvtg3snnku2fWbfz5xJG+0U1a7YS1e OfPYSFz2NwYkQcnNnugbxpdTk6NHhw6e/2yw6aufKfSNfvlo2/yJlpbUcHpXtufoQpf2qHnh4Vsv jITZhtzQpdHv4GKuKVWy988Qnz+68z7j8XwLfH4PNVFnfrvlEB53eSOEtl6OUNnr+lEv0hOqn4yq vE5oHiT81wXCf92dDaMfOq631SNkhR5/nX4PJQgN4C6hycv0e44UcnwiNR0KI8PwsakU7fI5v2Zu WPDDdf6uAXurpE8YHKvnw4/LsAoCOU2TpfHZBHYSpQSV0Hj4G14FR+OdVhmCb9hhmEidCQSgpcgT XbfSXe4cVznvtNdrpYlbN1fMYM2XVFdMk8TUtWJxBfKMRju/Bu+HSGDtVG+MjWUtwuNHzXS2ZD3P PO+5yFSs61bVYh2rYlHIUrsVc9ozzU2Zl1h2P4t1a9A/5j/q/y7zk+6rFlu1Nk1K15He/PrOOuIB Y3tz+qT+lH7Cf0o/o19BV/RX2NfYX3fz7VyoQ9gjJ0OjSqJD3RNPJkY1WMYzKcW1mpbCqZRG8xri mwWd0FdWSmpFva7SmrqgUuo/ug57Ya83OtNZIl+FCqWQLpxzaWwCh7fLxdx2jlyk+CiDysFGW/pg 42P8AaoJl5/RdpPhOox2rktHJgNNJ2vouNuT0lE9wJFybgguN4zh8lwR0A/Yr8FcBpjXg1WHkamD vdHT2h9MUy4fXKi/WagcuLT+4a+enQzokajZgIM9gWY11sM/3Ex7c09bx/YeXzx1/OS+3R+98QYe O/Sz7++PSq2zH629PBYPts69hR+MztqTz9x7+w+AaFLlHYGsKowS9Nk6ojs5NawgIQAQRKIrRDck iUqvg7COemEdkqABQ90MhWEWOeVgMAg9xMeMIItYiaVY8pisJp1bZB7LLO+8466AztuvEjYwfTwP AILYA/HJzVRBFosurNfMqrVSBTjV0ZxQKugqWkQ02YIDxZq7idobOfISp41AWGJ1dpGlEVsCt3yV ZdhvMz9klhiavIoF1QgT2wmcw2EtCXqSLmgLsCfaghBVMiSKWrKGcoiM1RrsV1dgr8W7xaK5q5ZV A+xhf06TPBMpNpVQKfwO7WnS4+AE47bqxG2N7MpfOJDltEJDcUBzIdaZdYePdKezMW+T71joKXWm 8ROR41EW0z4v6+MEjzLunae+4f26cFG6kPgR9fPIrdB96o+BP0lb1L/pkFxiS9wsaDfv+yV7L7DJ cgxmG85TtI/wxAs8OTDg20eN+Sa1KWrK92mqTM2H5pu+F7rmu+Zf5m75Fv1vUn+l1oUtf5hbZTFi V1lqjkhiuwUw2iLrZc8yYdSrKmSrIdmWZ5RzyhXlXYVRlNjvGQwnuLoUthkSAEJEPHD2yzax8Sdj mJwI+1tO7YzZARWfVs+pL6m0uhUOVzjcyy1wVC/3EvcuR0ucw4Em3CK3znm5V0SFQfMEV3TKkXtF Rzws0kiURF2kN0Uskp34wJZiIVmYqDETAuyh7bmcBOGzCGIDoqib5JcJpMxy8D9UV21sU9cZPude +9q+8ce144/r+Mb2TXz9EecmDrEdO4T45oOUOoQECCTBC0SANLXSlMQqrOIPoYwx1mqJmNouaCL8 KZ26H6WpAVONkk0RUruloP1AWydWOqH+WGFiXYWmrUn3nmNnY7buOe95z8f1vX6f93kf+IuAyaZd wGRAvl1AyUCxWSIAUCYDOhP3jZc4hBlmdoJSL/lQvruBDHC3msasWVOzFriMcPflaNZQ6UiOWPZV Rr7KXHXEV0Z8ZWSiI81qyroEb9YbtGctcNFU8H8cODExUctRrdThIbmAobnA7VLkcIQqqU/x0aNn D5xRA66Pf/bWl3+/duH2+ln8C73gPZLee5rZ+ruXXjrysvPc5xj/8Uts+O07neOhjHYKYTSMEHtC /xqKM8YquhWV8pWqEdpRadXqi2PBymGjNYaNVAk44F3/VXMQgFodFPoVScARejIBJ/HGkOL3IGSL 2crYt+zgjKg193hFWMmtgcqqkBJQ0oqwKtwm31VSVm7S0g1ko3sQbNXqY1wITjLGMAUi5ggCMUOA TH/GH7Qaikbqh/Gn18mU1ao2b1LQfdLA7dfWKuLOp3W/Glx0LYbZfrbfvMN7hj1j1l/Q4Vb1pLzA LRiWjEumi8JF+xXVJHCQpw41HYozktFa8hvPN+CS31BmjVqg0b/kv+Vn/PaQ4sHxESgtE00xh50z GngBAryM97w/D+VkmXm6jJviZSxolmgMO2x24bzNhkMkWN+fmkrSvrOz0udylT7URnvNLcnJBSsm IX7IOmNdsd61clZv8wcsxxpQpYKsBOXQYwhdWjd2QffF5MMiFVldXevFrtw61I2tVYXlUCJOd1hx hRV3VEIRZ0jCVdYhVIPgmph4VjOlQTM1ptqhwKIVVkU0QchBxHEuV7sLX5aU7r3r92PRXu/y8vjV 2RfGO5N+T3s+EAi3aNIjduf65bmG5lAo2n+YObCj69yHx/rVjD8lf6+2tu2793p3QPihbRsD7J9A L21Fz6MJ9k3tFYd75M3wYppFqlBgjjcd38ugJq6F2/NqUJfrGC5MdxwLzxTmdfP6054fiPOpH3ef 3j4/+MPh1z2vi4vDZd0NfclTEj9KfjS4UrhbeFB4UvDVBV3tQsqZDhT0bxvz6ZwPudm0nPchb5/D LtisFnMNbzLV1jpNRijpHQpRXw7gIYX8HU5zjvQgz2pyS8q7yi2FVcr44tXx+JyMZViqWchax5L8 rnxLZuXqHtrDFhnWauJCHuc18OY1cOWbCXTyI07sLGOjVjttxCeNYNjhGGOKW+zDfWW2TTN783yr F49457yM9ybze8QBuIZQF0zxnMG7G+9ubrYNfcgmgO/80GbREJvQAkICTyfmE0sJNiESfk2YCSQS qWwLOzeKR8mzWQCtYHxcEpzU+DNVOqOkLOctAKRRJRDFURqDnrrkfBQPR2eiK9G7UV3USlbC1Ncl Ankw/qY5SMKIHgsWEgWtcAneub5Atko15mTBOv/GAB6gGmmgLejGNveM+w4k+/K3X2l2ss9tJoWB m/5Gd5m5qdUu5nCuLcGOsMwIixErsAxLXqW3Pkl7OJUltydlMjGuk2dkXzhQ+AC/jGTMv3dOjMef ElhALgflRI3H8eJDIT77lA7iRZL947PCQ6jdJouQkaqksP4FoYic8LgI3AFVRlEg62ExsETpjvyZ zABPFL9+DEVZnHiUzxTwFAnw7FDcEhkGFyb9piI7MTjWuT2Ukuo9ItaHlS1t7W3JNpbrCQ+HW5Sm 8H5lVMLSVr+EBlNDQdSLc0G0TZ+T0Ig6JKE98dEg7hcHJLwvMibh/WP1nT5Y7tuKdrblg3gwn0pr TF8Q8ni3rkvCu1p3S2hvbHcQbff0SYgyCBVw/2so2v/7aQLgn6LCbpKQ3SylNo1vESBGU4KDKLkn 7zmoHJvA4arOAt4hmQCUVWNjJSNEqMjy0C+dARcVavClu3ADLKD0lUpGwph7dgTj1OiBtUunp34T t7KcnrXFv59Zfav/ueaAnJBmPtk2Of3iz//96zODNfaU4VAynsWu/NH+5MjOw9vbN/7Zmug8erP0 y/bkhc/xrthPJ360quk5k6eO13M7ZuauOcNZpz1o0LF6k2Vmz+yR82Nb0qKo9JqOBNoCjQeZs8dP XBzrLZ5YOtD7zan2cSUR6j65I+l264D0kQWS0z9AzaWZ+So31mc0AlyBt/OUCHkxRMZiHRmIINYo JkSidqnCE60kSMUwYcsAcYTlZCqiYllnNjP7ZHqGrIrkDLX87b9KxAvG0xKZUDcxBsYjzUZJmZ6n YlBhPTxQrQMuBa4oXBGUBOK1pTQT7E2lUcRe36wzQFi3thItCKz76BEEZVUP0qJVWL29RViNVzxr IBBXn9GG40kHgWSKtnDHSBIOJUfaIzylX55SLk9pmRepS6QukbpEMdOBZeqWqVumbhme5gnNNmB8 VSITYHxzncypaqajytqUtKv2Gim64ClARq7ZKa4giH1aa0ZrSvGZKaibbYotPJdZyOiuZFYydzNs nMMjmanMDHFpGRw0ijG/vczaNHuDGvNH8g18zC/kG+WYP1xmrVpLYyrS0pP0p/pxMJJG9CmhrLLb Bd4rhkwLPL7CYxs/wy/xd3gdT5KUoiI51BJQR9QpdUbVzakLKnNFxcBY6op6V9WpUx2XQR0KT0lB SSrL9UoPvEyQCM/SZc9mqTAkL5+mCmedpDdyii8s6b0SNhjrDPWEngG0lKBni2gSQ/KKE4omfExg SLjaXeXqDiBrKg45A5WG4N3Skd50gmLEQ9Ov9Oya8dVa+YS20e3StvBsoD/R9mLelR3Y6NzW6BRt gTpXqxU79D9ZP3xi+/7vaO9s/GosKEqhUCQs7ML9bxxsTQ5vSAdbAqFQLZ/Zz26rqEcEZXkXNAbA Sw1qYJ6vIOYGCgER1JNwdlhouFtkkUSyLJLIlmtF1gQMQnM5GA9o4JuICiTTYHxyjaw2WcTNjA/G X0pVuD3YhNu9qxRtwTIgwDMsT8sngYYbpgHDUxzmaCVLKvLr5ACugauFavAeJPW1SeF+RUpCkFVa gATkzPgqibFNJFiCFAMybck5pcHBqtHTUzE0b0cHt0/jMOIucQy5KUJBucHwH8arP7aNq47fO1/s 8/lsn+3kfLZj5xyf41zOTWwnjpc4kPPSJm1tt2Gt07gjI5OKCusk0qK2a+m6aGJDg2mykBD/rUWo 4i9Ut3Qjm/gRlVExiaqR4J8hwV8TtGMZE6qAos7h+31np5kAaVbu3nvf9yPv2Z/v5/N5ATzeP8xe nOl0agk3zQc3i7B303zAk1n5oGDi0/yByE+tFNISO3LAumPC3v94e/r2Er2PtFMh1NDIsraiNbTL 2sdal6rNa6yJLw0FM5cbo+Vjk1a5K2OViSQtzeFQeAwSJLC/363H/JAWqVBJjcV3iyEx0ICjTDBM v+gI+IWGkzgnUIOvz+SxML3TedsJUXSH3JpiGhMKxsLjk2MNhcwrZFlZURrKZeVjpUu5nrj+Q5oO uO1NzAGQ3k3LpoLywtGkdjLQI8EHoL5ETgHWc23bCToS2MY1hXWqg2t9qFgcGpoqXgxlS62ZmeGI 0xEL9w56SHfXa9gxNTRUbMU/URcmAMjhqRp5+ntpNeTVVgAhPoaxZ8B9HrH9rs3ywTpl+Tq9+wR9 FLa+WiXT4WOofHADAYcR04ugyhh0lJEtzHZGzXZGYcSM46jZ0lyJjitxOKJkR74vVbrxv1U68yod /q90FoDKv80Qjq0IuEzFoNMNOt0ooGlzYaAg4TRo/9504bxCLy5coOKDQwss7WdxjYKPruGja/jU ta271hpqBsdA+6a1hjqEa0D7D6YLh6psu/+h6cJ1VDk0ktuzFxNPnTtcM3HMSI0crH2t9kLNVluw z2WVZNrlmEp3oRahGgF+l5Yg0z5Zx09HjxDh/11F2IMsoY95B7ISy1s0O7cvi+YULA+ruxxdjsO1 BYeSnfPRJPOpHBaqQcXHoDGjUKKtEm2VKnCOD2imqepiAeUbwwVLx2nl77S3UFisIEthsNJJV6j8 i/ZWKvXFdpb6tt8S7Jw+cASGnvn29DT6TIB3010+vPhLZnbrLrMHnhF4Mlt33wgrIQVE0/rUI2bv mGOj/jfZtgp0X0eVM9ykUQcxU/WYssY+vNFf0GNZqJiu/ooem9vf79NjQdCzGwlDj2XWbO4biZIe m4WK+flELVUtHY7VdvN6oWpO6IM840jOLRzBHyaZFgWXw851OeZmsxklKNSDwbDk0+IZlayoTZVV 10je9Bb0YUN7LFMgK4VmgS1gTK4eKWmVSl91vsquVhtVlqlKVbYKNPBmtzxWXV6sr7FHfxIHJVwj x14yjAP30ZNPVSUQxPuoh+9bxdSBPV/e/WcGb6xTeG+Fvyp8V9PUVaOdZraVsqOV/ZrodScTA5oY 7yUeb78nuVMrQSoNQi+zoIpUKv+HYBYsxaS3WYcj+IhbtsOOHUr6KcYZJfPH/Lu+Mrpwoef4a+V9 J+OyWxj/XGsqUIwHBS6SWsifqLBsz+RsK1uZcHXF0wfH84d2hbLlVnE6F6bslPKSboP98Jh3YOjY l54rl2uTF1pnFlQZhDUoJXzz5Nsrw2Z+r8tolanaaprvCYhlzWi60Oo5Oh7RtEixRp76fjreZjIR /Oo/gclG2W0my1Mmy1AzmqVvD++VE0gJw9hKRDWdp5TEUz7gKR/wMrW1MrW1soh5LnfoSbYui7Ty kTmAw2UmSidH6UJRukRUp65Wp4ZVx+TBOTomDw7VOySnI7cJOENnelktg0TizJpO3G/O/QvwtRI8 /ZbPNZ2aV8s5wmmWcsnICDW1Erhb36edrbG+gz8kJBDJMrePaOOpERmzOEPvnVlapxvIWut7NZ7K M0+ZgqeswcsshmQaknkMyXJ+jInSkVEaiNLOKD0oRvUOXehIJjhC1/Njn9XkgrRP5sHl8nnM/0x+ Pr+cX8k38l27OGLS+iq0mnl7M7+RZ5t5sgyB9bwtyst6zGsZXl2Pafv7eT3m2Z+I6rGEZXizqaFS Jpbd3cskcqP0xFoi4fV6hKCsORo8afLEy6/wl/g7PMej4Y3oo1FtqE+f15f1FZ1b1Rt6U7cxuqSz Osq+ExJeXx6zTK/x2U2vXwnZ7FwyZAv2ki670hXupDFk8dJJ+APTe4p63v/reCEjdwYf+d1RUv7B d8vPqrLHlX28VQyYowJXqp494/JgInbPZsHttvNw82Z5YepC69yRvhD1ut6D5OzzJ19sRZfkKGTa 3DFy+MreMOYZC6T9vu0tyDMvE2XFdqb1dot2RLgoIrzBEgG2RcnlgneYw9zBTqyYAQxydBgXTPIu KclYykjx27ah2UwHp07sx3FhnBxBTIW5boq4blFCQIkSNkSO+gCsclxMFPtiCCwqRQgu0CL6T2Bh c49/tYf8SH5T/jV51/lO9D2n3f8Xgex17pGP9LxEXnW+4n0v4ugzc3mubwZgd6mP3Op5N8yafWQf 39mNn8Mf3fC7pg8CFDmyge95bplb4Rpck7NzH4omdJriJZEVZ2IzZcU4IN0/ZVQ38UJklJuDh8rN +S8cvSbG9l3r4/Y9cXTx54y4tc5w8PRtraMEziz+jAnbcgzHdNty96R7kR1NUId6+0AAonES9Sc9 A2yyd0BI2gd83m6ViZKwSmQn1BQH1AJuSSURG7x6XEGVCXXBi9pMY/sDskHQngLqyMyi6TvNnraf F857zvufk08rp3v5pfoSszTzRfhReiXfRASeHvjSr7kmcKU6WtUgelUwqyl0q+PBfru9p9uPmATl YJmNiyfO3Hnhzvnjz//2UP7E45defPriV+dsV1//1tVvPFy98p0fX3xwtjT9+oXftP50+Vf3X12G 69TWg9Z+29uAtRQzwfa3saYXTWTVnDCEhWBHKAlKIMSoNj1AOTigytScAbne6Pg1yrsqgshNjZ1t 0PBzHnv4beDWIHCrC+zHcNIzXrc7UpSFGcrCDAF0AsOCc9ukhEslecQi2vV16RYQ6whFbIda32Jy Ww/fQCDmBMSkglVBKE7C7ihuA5QjA6qlAXbc1EdmhJo1FUYN2j0phoQ8sBkX7gY3gL/0tGQxI7EY E8hzwyLP2wai+qJQRLROSPukJ6VXfNzLaVJMTxfL6SfTz/ieSX+dP+c7l/4mf8Vxj3/gdGeKi6P1 sWfHOLNIRnjboO4PgK0KvdwfAHOVSjCp+MFUjNnN+o1BGzcsjRPcCevAPYUUTy7bJzQEdllYFa4K NuGvKhtYI8fNiKrOx1fi7GqcMHEp3oyvxzfiXfHlyZvl9t1nSqKseGoTLz6b0//hu/pj27jq+L07 n+0727lftnN3duyzz/b5V+wkzg8uGs2N9Xe3lWmINlA36Y8hCmVNMtBWbaUpgnYFRAKdxLIMMlUC lSHRLbDW29Stlawx1GWroCvjj7EJRVUn1WygUqFVSfi+5yQtQsLyu+/Tvbv3nu4+9/mBk0/ravJh WkTsfwiijXKPJ+BNd2f8mY50j6fLQOUAHCpcr4E6fSWDolahC0Q5OlalRqsAQSZdCWGng3HoITi0 VgxMJdzXu8qNbJMwwQL1LBsdGumZDRNbv79j9MmR5zf3Zrta7S2LhtZnKSHRjKlp1M21fOPBvWse 2OFs7yinGHvsysFd+797uTF9OCS0L360sxJLp1HY17mX2T3YobYcXnz+gNm//f6vvPzH0ftVmQJ/ EgBAnwUsZ9FLy0jO5gmS3fFWySIWwlLjaDlw3ZlP4ivuI77iG+IYMxIGcpzEpzgxGnGSS8iFSGTU sPYqgFulMgDnlq3WAeuwxVhZj+pnAFJzOIc0IIX8j3cQ62+s+IUVFjbxdBm49wB3mKM5mEB1w04J nCWSM/AePyVwjuPchokZd87isXg8n7st+TA/VR6Ym6uuKn3EOQAmW+iiuwSHdoTvuDxOHg3lURxj kbj6o6ZlGXdnYtZaivflpaAhIpc6ziHOFv3IP8gwlAd8+5AbOW7kLsXzKE9JqXg8bqBxY9KgKUME H3/euGSwxnDulw8TMl514mPzo2MYj3eJjbFGVWo6bptagSU4kTFQYaC3EJZgIDgzueKNl1V3xUov 6y6695GDfRu7U+a2kBxq71ACn1uzWFif1Hg2YOpxi0ch5vTbb99TtHrXBXM7Fzfda4HEpsLE9e55 7rNRLLOAl71L8/S7gJdOV/cyXqwKwUvFwRpKIxW/f6Ti942EiO61/Pi8lRBqSx8SwRUw3XXhcaHT 47WEhEsusOggi/aziE2XEUJ5j/ZoDO2JoVja0NGwPqLTuuyjBurVKihVGSqUKlDeAIYIqPPc5Tnx cpPvVtHRlRAsrysfjsklls53eprTaPIWFn2dfZyl2XTeszaG9sa+GaNjadmH8A7/6egYLYJQ6dK9 LcRrWjIullXpWua1erPWQemqVdzEer06INZlGwZgUxg6Oa6oFWlZLjk+u5j12Wpw0P+lzLT4VIrl PXyWzw1XRirjFbdQqSHDOQYUeTFwsaWeqqf/bF5J/aV41XXVvJr6qOiTB4rV4sPth4oTaIKeYMZD 4/p4ZDx6vH2iFBCQQPMM53dH+eKbyT+Y3igTDsrRcJuWixSnuCl+2jhhnkj55EIgW9xc3FoZqjyW e6x4tOWUebpyjbka9ee8nTHqHB1DcVRGNKqhwix1rlRDuiPl1Zh2LhLT4zoSdQOeHB7UzoXxYFKW U2bA5xIsUtgY+j1VKuc7KQo/VP3bmqbWmPVOMFzGD5Z+S0ZIfifxQeLjBJOoMUHHNyKgYWFEmBQY oYZ6Hc3StVLci7zFGQsNWyPWuMUYVodFW68gg+pCxotbVj6O+xpjN4iFXajes312KYGqg3YZ1H92 CUEXGLwxD+MgTNjczouN5azaaoN34MFNpwK+YCDgO9ZSKrQcEuuDKiVev9GojiGxcaPR7JNuE0S/ KxlcoJsqDBL6j2ZzcUOU3J64BPHWnfNG4ROORSlPlo2iJvUfOYIdMqzF3fLcFG9Kt7Ku6iAEX/hU 4aQ2g2boGWbG90xgMjSpT0Ymo1PJn5oz7X4wMQU0SoHPgct8ZbOc+kFxOjVdZKuD2NpIWUOzuaxm I4e3aWgRMHqzvK1jv6fxdglOFUnjbL8YkwdaDHwAoZ+N2KRodqq2dG1Wsc1m8UM5o9hFVWnOJTfn EmRYQoYlZLtoyPieTxxBgMsEmxEDsE4AT/CJIwdgnQBcA02VSKMK/+8Hz2aQ0JVkYj4CB9Yabm1t 8hbROlOqYO0D6cukiFHDeonTBD2ZyDy6Y/0XjfjQTy6e+9YX9idCrYFEIvrz3eu27Vr8a3v79OO9 91UkUfYzpxffPPG1ze2fyeZKG/acPDQV43W04Yc/esBet3Oy3942+nSr0KIChwWX/kHf5bpARdDC Moel2xwZOKzNwQTl86tYvfwhBbEK6SpEyJTa0r+J4ClY+Yilw8/Cj+9RfN6iEA66aigySyE3KNnC pblyo76sYe+DJyv/Nz9prSTlhskxdEcf3sc1kk71lY4GHSeIeyM+5BMiKLQviDYFEVnOASjC2r4I YomFY0nkZYkKsrDBv5Mp8E6J/kHn07PE8Clt0Tsi76U57NwXLlWr58U5sV5tRt1CAV5r5GUqABu4 228PoSGaHmibkqa010Ovh2vaNc0z04aO62irf2tgyD8U+JcKeTGkWioTDqmaziB8CEaeQ0yoY3m3 TAdNI7e/B286/E7og9DHISb0UDDyFuWroetO0QDxLJXbXmij2yiEXC42Ffy8gsYVRCmi8oJyXrmk fKi4leHor4+vGLgFEmXF6g3wDg3gCQi3C/NYOsUGDM0jkE8KmgzcDJaMOLMxnF6lSsgEK4ZhVsEJ IZPpkcyeXtDNPrT5ypVKNrFGsszxtaXt+R/3PdLemnNdWPzT+oXfDK7JZXfvqQztob+aCO/bmHkI K6MECbTBPEUZ9IUmqs5wHKXL7uBr4HckaAY0mvnbixTAo9G4fn2gDF9b+Xaq7FR5LuLluGQC7vMF w/i9BRW3lCdWRnbT5Aw8O4N0DDzPXOH2X2668PfnwJNjEeLkB/nt6pc1BvDz3qyvJ4m/8F2hnqAW 1E0uySckQ06phmbo/ZzN98u22qP165u9m7i1/Dp1nbZJ3+d91jvF/Ux/JjKT/BV1yvsL7qR2Uj8V ec37EneGP6Oe1V7RX42cT76r3uRvqrf09hkO4VV+2zXcTWqhs1ljuWbdsKFZLatZTbNZJYlUx9Gi 3ULyCWoMjdEj7BPGEfZ70kSS6/d2892qHXnDfT7xnu55kj+uHtOYPnmjSitqMKZQESNGybwUk2tL R50ip2uGqmkdHB/kOD6i6ynOCz2vx826/sN+tcXGcZXhc/biuex654z3MjPeu3dndgbvzjjeXdtj Ld1FTdO4SRQ3kJSkLCmiFQ0qamyRhEhYtniIXSRkVAoPFVIiHggv0CROHBsL1ZWMlAda8kCjNgJR CVOoiFGIAqpEbPOfGZsmpVIfKhAPM6Pv/GfOnLnP9/3fH2Ah3UW7ICWhjm4lJC9goP5RHhO+yJ/l 5/nf8EF+gkvSyoG0Oqxz7CL7ButnJzjlRPcSTqIc4uB+ha4aR+9bSTvxUn+dhqvhOuKWwYou4Ffn SQ+e6nHfBsyicV6I1vL0p1UI1LPjd9uUX93r8rsK/LLy3e41GsflNdf20XWN/rnTbqqaDpqy0+mF nLWGyfL9LbAVHNHYttqiNoaT43HIHVf4XKKzyYKCXIXIFcGLgBGDDABl4DstPmqzOUgBAOyynQr1 4cPRfNwV6WjUKUa0Qj0f7wB3iQtY02gBg19JlYz4mzckNtRTw721WCG1sWRsLCb0rNjvf0nVcoW+ jQ5f51A6wgkhVQ2ImV33/uoPDliEY2ndsbkavAxsKftf32KLls+IEV+ZlrkRxGkyG9DVbIfQQX/z ZtOyoCZbvw7L8n2cWUQaKNNOqmdyyrFrTgseFAjCuq2scQGkOyc/XcZldELFauiEjvWQe/ZyuZLP mxVKHdG26LWa7Wab/K7tXEx0HJ3zVpMXu0z6k6aa9UQJzLuolnLmUfMYd9x8T31Pf199Xw/TCZei dWfetWS2ljdN4+mBtKJkkwViBngtrZU1WzsonZfOy+c1NqQOFgdL+9FevI8ZYR8t7irt0/cZM8wU mRK/o87oM8aU+TJ5iU5Wl8iiuqi/al5Tr+lvq2/r180sCgaYjnhA4lSmxOkdRl16mDwsjgYPMIfk A8YLoVkyI7+gvFCYUWe0KVOa5s5I05q/kzuMT5FTYgA4AV9TVXnMACuIJGZIrpDP5JBRziCBj2SE rJLJQMl0Zo7VS7mFzYlWS1aLOZZhOaZo6DHD0OFvUEt9LBdjWQ6UX4kXeTXG82qhWOyTlZgsK4ZW UKAQAv7x8B2W8C0gUQbfmstiQaRbBEVA93lBIASKoxzy0UGMyjAFSCov4a8iFbH4xy1Bb8HNFot6 KHdPeIYHv3rx8jJ6xigsYLYVbyWtUQWfU/AvlF8rvwfVe7FoAb2TV3OCigl8dErFULimLmGCNBQH hodbvHVUwy1tSvNpkHwucxMli/050JyFVMXnkI6n9Nu6T4dDr8Ch+jmGCkNy1MBTBkYGMXJGy7hg LBvXDcZ4qvLvjLR2t7c9pnSvra+CoRzb4jYMdcMA7JZXuyFNUVCyU6p301zVbND01dha3f6a62GB /a4KREAF2G05YO8f6f0oYfjPliFsg204gjGG26AU49SetXupVmgkFm5S0zcHMUp1Im1L94UYDbcv SbZKQ9zZuhh3pYMurnJ0uMJRojrhysa2kGxt44Lf1ZFOPFXPiyu/rMmlRANf3p2Jsddfi5VsnH/C 2HjD+OPG39WNm+mhBuhJIJPKltf/hn863ZAiflX1S6QQi6/fwf8cyEUzPlXtPHbvL76R9at+30i1 k+bjJEL+P4HCDPnvbLm8sMbLNS1QQXAqC3TmciVKfEPQmUeVjOgKjWVRlVl2Gqd4oGLTmu56hMez nbORWXFam67dCN2QbpZuVjnB1Hg1VAyP8ydC7/YzqWFTODIQMJvBJmmKQ1pTt2t9wyOh/WS/uCsz ou3V99Raw4eUQ+ro8AlmMjRJJsXJxKT0feYsOSuel5e0TCQoEEEUylmSFbNlgzcka5gnwwe5IwOj w4Etp1CE+z49hIfog5y0sGVqNZkPIJM+Q8ZMp23THLa3Bc2ymk36JI6iLbstfaYfacBNKZEo1Wp1 PhQOV8F+MIyi1eq1al3tmk1YIhbr4CMT4fSEMprBGUt9vjBZ8BVmC7igqKZpVyt3DKNUHYW3PVHH 9WCQURWGKdbVWL2uhhOlUl81HKtWw/DlZS4sVUuqEhqyNJn3h2tMXUjhVBa+hGXSzwAJXBRpVjYD FVypZDJpPryAH7nyfAInTHUBR+ZyClaoroZJvaVcUN5RbisBOkCzsbLkG0BVxOCvXKqbJdCDOVTF 1SXfa8hGw759c/nXgZq9/2hDaUfWe9u9Y2vgFV3utbez7Xqj4TSk0aZGyjGNlHpQK05HJlyi0Q6W u+wJS75FVtv0Ha86L7rLblttGCHOJvnmLegxLGlEGtMR0phYWaFhhV1hILAwCiUlHm+3aaoeQ2NA vkUUAk7xdgiqjKucLdEKDvp/noMYpwUAlxKbna0kacp0FDZobEWlSDPY6go1GRmaAdobplYEoqEL 9Gy35wVbzQk04b91SbAZSmTB7ocw3wk7Op0RWvlpOQoRxkR6HFhGxyRAbegE0bUMyU6bwAsQARKU iYQItggot+J21FWFhBu6aCqM07rydisatwfYuK33xWwDILIJm3NOlrCNlgiI2/0UcGWJXh1AD78o fqAtDy4frjbxAzscGdouMgep8Gz7FyaaSEjxfL2fjpZKVJqcbWr5B6nPSeJXjHwhlPjMnt09Gh7Y UdxxcGL1c7vtjdGKEm2d+d7OSmXjzWJSO7L8s8ce/zQIU0qS+0nPs89+uTueBlmSe8bPbyyc3uEv FmMRSWqvrDwpyiVfsRiMpU9t3ntuELnLyU+I6yBxOuBlhHy/AqW7gFBwCiHmiwixxxHi7iEUgnnh 5xCKwDjpAPzgv4Ou735yJL79AZQvIJRuIJRdRqj4eYRKMwh96qEHYbEI9cNz1n6L0OBPXNhvIfTQ DxFq3XGxM4fQ7m8htC/lwYMHDx48ePDgwYMHDx48ePDgwYMHDx48ePDw/wPkQxjRJYb8tIe7AR3o Yxf//RtE7IrG4glJVrqTqfRHzq9+eGAnQo/uHnlsz17ojz5+4LPo4KEn0OEjT378pf83SwA9BW0X IvCoPpRDw2gUfQkdQ8fR19E3NjdhXw5VnLGn0dfQODq5ubn5hwfXfw0asuiAGasoMuBgSIPqZQbG CwOUzQJki0DZbECWBijGWDiBIhoMNlA2EwMf0D0QNjNQvAjKZgGyZ0HZbED2IUc3Pw9HX+2QzNzU Yr/U8qD83MQ8YsUYHBncGPwYPIC0L4M2QwgwVHIZUhmKgWKpDOUMQQz5QH4iQx6QlcqQzlDKkAPk FRGti9rqgCHG1sXwCRhGZQzswBASYNBnCGNgYD3FLwyOW2DgME5gYGXgYAGyQDwYzZDGJAQMfDhA jyZ7IGBwAKaDCg6QMWc4+JiLobEFjOPHq1tt4/ltvnJIcoBVL3osewhE77y6VeN3yd8eAQYOPiAX FH9gkwHl337kCmVuZHN0cmVhbQ1lbmRvYmoNMjIwIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9S ZWN0IFsgMTAwLjAzNDM5IDU5NS44NjkyIDE4MC42NzY5NyA2MDUuOTU2MTkgXSANL05NICgxOTAw MGRjKQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMjIxIDAgUiANL00gKEQ6MjAw MzExMTAxNTQxNDArMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKGF1 dGhlbnRpY2F0aW9uIGFuZCBrZXkgZGVyaXZhdGlvbikNL1QgKGdncikNL1AgNCAwIFIgDS9RdWFk UG9pbnRzIFsgMTAyLjU2ODggNjA1LjY1OTM4IDE3OC4xNDI1NSA2MDUuNjU5MzggMTAyLjU2ODgg NTk2LjE2NjAyIDE3OC4xNDI1NSANNTk2LjE2NjAyIF0gDS9BUCA8PCAvTiAyMjMgMCBSID4+IA0+ PiANZW5kb2JqDTIyMSAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9S ZWN0IFsgMTg1LjAwMjI0IDQwMi43MTAzOSAzODUuMDAzODEgNjAyLjcxMTk2IF0gDS9PcGVuIGZh bHNlIA0vRiAyOCANL1BhcmVudCAyMjAgMCBSIA0+PiANZW5kb2JqDTIyMiAwIG9iag1bIA0yMjAg MCBSIDIyMSAwIFIgMjI3IDAgUiAyMjggMCBSIDIzMSAwIFIgMjMyIDAgUiAyMzQgMCBSIDIzNSAw IFIgDV0NZW5kb2JqDTIyMyAwIG9iag08PCAvTGVuZ3RoIDE4NCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDEwMC4wMzQzOSA1OTUuODY5MiAxODAuNjc2 OTcgNjA1Ljk1NjE5IF0gDS9NYXRyaXggWyAxIDAgMCAxIC0xMDAuMDM0MzkgLTU5NS44NjkyIF0g L1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3RyZWFtDQoxIDAuOTkyMDA0 IDAuMTc5OTkzIFJHCjAuNTkzMyB3CjEwMi41Njg4IDU5Ni4xNjYgbQoxMDAuMzMxMiA1OTguNDAz NiAxMDAuMzMxMiA2MDMuNDIxOCAxMDIuNTY4OCA2MDUuNjU5NCBjCjE3OC4xNDI1IDYwNS42NTk0 IGwKMTgwLjM4MDIgNjAzLjQyMTggMTgwLjM4MDIgNTk4LjQwMzYgMTc4LjE0MjUgNTk2LjE2NiBj CnMKZW5kc3RyZWFtDWVuZG9iag0yMjcgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyA1 MS40MzcyOSA1NzUuNDczMjEgNDA1LjAzNTcyIDU5NS43NTgxOSBdIA0vTk0gKDE5MDAwZTMpDS9G IDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAyMjggMCBSIA0vTSAoRDoyMDAzMTExMDE1 NDMxNCsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoIG9wZXJhdG9y LXNwZWNpZmljIGFsZ29yaXRobXMsKQ0vVCAoZ2dyKQ0vUCA0IDAgUiANL1F1YWRQb2ludHMgWyAz ODMuMzAwNzIgNTk1LjQ2MTM4IDQwMi41MDEzIDU5NS40NjEzOCAzODMuMzAwNzIgNTg1Ljk2ODAy IDQwMi41MDEzIA01ODUuOTY4MDIgNTMuOTcxNjkgNTg1LjI2MzM4IDIyMS4zMjcwMyA1ODUuMjYz MzggNTMuOTcxNjkgNTc1Ljc3MDAyIA0yMjEuMzI3MDMgNTc1Ljc3MDAyIF0gDS9BUCA8PCAvTiAy MjkgMCBSID4+IA0+PiANZW5kb2JqDTIyOCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlw ZSAvUG9wdXAgDS9SZWN0IFsgMzgzLjMwMDcyIDM5NS40NjEzOCA1ODMuMzAwNzIgNTk1LjQ2MTM4 IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAyMjcgMCBSIA0+PiANZW5kb2JqDTIyOSAw IG9iag08PCAvRmlsdGVyIFsgL0ZsYXRlRGVjb2RlIF0gL0xlbmd0aCAyMzAgMCBSIC9UeXBlIC9Y T2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIA0vRm9ybVR5cGUgMSAvQkJveCBbIDUxLjQzNzI5IDU3NS40 NzMyMSA0MDUuMDM1NzIgNTk1Ljc1ODE5IF0gL01hdHJpeCBbIDEgMCAwIDEgLTUxLjQzNzI5IC01 NzUuNDczMjEgXSANL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3RyZWFt DQpIiUyOuQ1CQQwF863CFVg+1lcF5LTwU4gIaB8j4JvMGmmeh4GwSoh2HxxVpXC9LEIrVXguTUUl CrA0LE+4N2IkV26UKGQOQ0pRRBNGK8PtvOFYmwSNWIfdmm0MzRpzyG99vG/CsR7LFCu498MwoquM W9udEIn92OEEnUJiCafSM+L6ThJhVPlDt0aK5tvHG/KbPrXP83fPS4ABABKHP+gNZW5kc3RyZWFt DWVuZG9iag0yMzAgMCBvYmoNMTU5IA1lbmRvYmoNMjMxIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3Qg DS9SZWN0IFsgMjU2LjU4NTQgNTc1LjQ3MzIxIDI4OC42NDU0OCA1ODUuNTYwMiBdIA0vTk0gKDE5 MDAwZTcpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAyMzIgMCBSIA0vTSAoRDoy MDAzMTExMDE1NDMxOSsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAo dGFrZSkNL1QgKGdncikNL1AgNCAwIFIgDS9RdWFkUG9pbnRzIFsgMjU5LjExOTgxIDU4NS4yNjMz OCAyODYuMTExMDUgNTg1LjI2MzM4IDI1OS4xMTk4MSA1NzUuNzcwMDIgMjg2LjExMTA1IA01NzUu NzcwMDIgXSANL0FQIDw8IC9OIDIzMyAwIFIgPj4gDT4+IA1lbmRvYmoNMjMyIDAgb2JqDTw8IA0v VHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyAyNTkuMTE5ODEgMzg1LjI2MzM4 IDQ1OS4xMTk4MSA1ODUuMjYzMzggXSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDIzMSAw IFIgDT4+IA1lbmRvYmoNMjMzIDAgb2JqDTw8IC9MZW5ndGggMTgyIC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgMjU2LjU4NTQgNTc1LjQ3MzIxIDI4OC42 NDU0OCA1ODUuNTYwMiBdIA0vTWF0cml4IFsgMSAwIDAgMSAtMjU2LjU4NTQgLTU3NS40NzMyMSBd IC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAw NCAwLjE3OTk5MyBSRwowLjU5MzMgdwoyNTkuMTE5OCA1NzUuNzcgbQoyNTYuODgyMiA1NzguMDA3 NiAyNTYuODgyMiA1ODMuMDI1OCAyNTkuMTE5OCA1ODUuMjYzNCBjCjI4Ni4xMTExIDU4NS4yNjM0 IGwKMjg4LjM0ODcgNTgzLjAyNTggMjg4LjM0ODcgNTc4LjAwNzYgMjg2LjExMTEgNTc1Ljc3IGMK cwplbmRzdHJlYW0NZW5kb2JqDTIzNCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDI1 Ni42MDM2MiA1NjUuMjc1MjEgMzA0Ljg1Nzg2IDU3NS4zNjIyIF0gDS9OTSAoMTkwMDBlYSkNL0Yg NCANL1N1YnR5cGUgL0hpZ2hsaWdodCANL1BvcHVwIDIzNSAwIFIgDS9NIChEOjIwMDMxMTEwMTU0 MzMyKzEyJzAwJykNL0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChwcm9kdWNlKQ0v VCAoZ2dyKQ0vUCA0IDAgUiANL1F1YWRQb2ludHMgWyAyNTkuMTM4MDMgNTc1LjA2NTM4IDMwMi4z MjM0NCA1NzUuMDY1MzggMjU5LjEzODAzIDU2NS41NzIwMiAzMDIuMzIzNDQgDTU2NS41NzIwMiBd IA0vQVAgPDwgL04gMjM2IDAgUiA+PiANPj4gDWVuZG9iag0yMzUgMCBvYmoNPDwgDS9UeXBlIC9B bm5vdCANL1N1YnR5cGUgL1BvcHVwIA0vUmVjdCBbIDI1OS4xMzgwMyAzNzUuMDY1MzggNDU5LjEz ODAzIDU3NS4wNjUzOCBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMjM0IDAgUiANPj4g DWVuZG9iag0yMzYgMCBvYmoNPDwgL0xlbmd0aCAxODIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3ggWyAyNTYuNjAzNjIgNTY1LjI3NTIxIDMwNC44NTc4NiA1 NzUuMzYyMiBdIA0vTWF0cml4IFsgMSAwIDAgMSAtMjU2LjYwMzYyIC01NjUuMjc1MjEgXSAvUmVz b3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4x Nzk5OTMgUkcKMC41OTMzIHcKMjU5LjEzOCA1NjUuNTcyIG0KMjU2LjkwMDQgNTY3LjgwOTYgMjU2 LjkwMDQgNTcyLjgyNzggMjU5LjEzOCA1NzUuMDY1NCBjCjMwMi4zMjM0IDU3NS4wNjU0IGwKMzA0 LjU2MTEgNTcyLjgyNzggMzA0LjU2MTEgNTY3LjgwOTYgMzAyLjMyMzQgNTY1LjU3MiBjCnMKZW5k c3RyZWFtDWVuZG9iag0yMzkgMCBvYmoNPDwgDS9BUCAyNDAgMCBSIA0+PiANZW5kb2JqDTI0MCAw IG9iag08PCANL05hbWVzIFsgKP7/AGkAYwBvAG4AKwBOAG8AdABlACsAMgA1ADUAOgAyADUANQA6 ADEAMgA4KTI0MyAwIFIgKP7/AH4AaQBjAG8AbgArAE4AbwB0AGUAKwAyADUANQA6ADIANQA1ADoA MQAyADgpDTI0MSAwIFIgXSANPj4gDWVuZG9iag0yNDEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCAyNDIgMCBSIC9CQm94IFsgMCAwIDE4IDIyIF0gL1Jlc291cmNlcyA8PCAv UHJvY1NldCBbIC9QREYgXSA+PiANL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1U eXBlIDEgL01hdHJpeCBbIDEgMCAwIDEgMCAwIF0gPj4gDXN0cmVhbQ0KSIlkjz0OQjEMg6/iE0RJ 2vRnZWFi4hCA1Ldw/4EEXkXhqUvt2p9VJsMNTNVwBuOBjAuUuKcGaaRiDds02MMDEqroVJXEaoWR FVmN2R7/uIE7ThA/QXj6ekz7VTo1J/teqL3lQFeseTFiKyN2LH31rI8f2L7GlIsTJKX4z0c6oNS9 r2qulYN/RSa2VOOhN1/e3n9enTWkh5AeQn1mGvUuOrUnXgIMAAx/TWQNZW5kc3RyZWFtDWVuZG9i ag0yNDIgMCBvYmoNMTcwIA1lbmRvYmoNMjQzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMjQ0IDAgUiAvQkJveCBbIDAgMCAxOCAyMiBdIC9SZXNvdXJjZXMgPDwgL1Byb2NT ZXQgWyAvUERGIF0gPj4gDS9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAx IC9NYXRyaXggWyAxIDAgMCAxIDAgMCBdID4+IA1zdHJlYW0NCkiJZI87DsMwDEOvwhMIlmz5s3bJ 1KU9RFrAuf9aKYlRt4EHgzT5CAdSrAhUFAsC3ki4Qyi0WMGVhLViG0awcAe7yjJUIdZSoKSZZ2O0 +z+u44Wbba1gO055LPvFjaqRbc/V2TKgqSBpMnwrwXc0fvWo9x/YsWaMlI3AMfp/DmmAXM6+iJqW 4PwnEgWNxR9ateVt//PszCG5hOQSaiNTqTWWoS3xEWAA7PVNRA1lbmRzdHJlYW0NZW5kb2JqDTI0 NCAwIG9iag0xNzEgDWVuZG9iag0yNDUgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAy MTMuMzk5MzQgNTQ0Ljg3OTIxIDI0MC4wNjEzNiA1NTQuOTY2MiBdIA0vTk0gKDE5MDAwZjUpDS9G IDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAyNDYgMCBSIA0vTSAoRDoyMDAzMTExMDE1 NTQ0MCsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAocmVhbG0pDS9U IChnZ3IpDS9QIDEwIDAgUiANL1F1YWRQb2ludHMgWyAyMTUuOTMzNzUgNTU0LjY2OTM5IDIzNy41 MjY5MyA1NTQuNjY5MzkgMjE1LjkzMzc1IDU0NS4xNzYwMyAyMzcuNTI2OTMgDTU0NS4xNzYwMyBd IA0vQVAgPDwgL04gMjQ4IDAgUiA+PiANPj4gDWVuZG9iag0yNDYgMCBvYmoNPDwgDS9UeXBlIC9B bm5vdCANL1N1YnR5cGUgL1BvcHVwIA0vUmVjdCBbIDIxNS45MzM3NSAzNTQuNjY5MzkgNDE1Ljkz Mzc1IDU1NC42NjkzOSBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMjQ1IDAgUiANPj4g DWVuZG9iag0yNDcgMCBvYmoNWyANMjQ1IDAgUiAyNDYgMCBSIDI0OSAwIFIgMjUwIDAgUiAyNTIg MCBSIDI1MyAwIFIgMjczIDAgUiAyNzQgMCBSIDMwNCAwIFIgDTMwNSAwIFIgDV0NZW5kb2JqDTI0 OCAwIG9iag08PCAvTGVuZ3RoIDE4NCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9y bVR5cGUgMSAvQkJveCBbIDIxMy4zOTkzNCA1NDQuODc5MjEgMjQwLjA2MTM2IDU1NC45NjYyIF0g DS9NYXRyaXggWyAxIDAgMCAxIC0yMTMuMzk5MzQgLTU0NC44NzkyMSBdIC9SZXNvdXJjZXMgPDwg L1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwow LjU5MzMgdwoyMTUuOTMzNyA1NDUuMTc2IG0KMjEzLjY5NjIgNTQ3LjQxMzYgMjEzLjY5NjIgNTUy LjQzMTggMjE1LjkzMzcgNTU0LjY2OTQgYwoyMzcuNTI2OSA1NTQuNjY5NCBsCjIzOS43NjQ1IDU1 Mi40MzE4IDIzOS43NjQ1IDU0Ny40MTM2IDIzNy41MjY5IDU0NS4xNzYgYwpzCmVuZHN0cmVhbQ1l bmRvYmoNMjQ5IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgMjU2LjU4ODEyIDM2MS40 MzQxNCAyODMuMjUwMTQgMzcxLjUyMTEzIF0gDS9OTSAoMTkwMDBmOSkNL0YgNCANL1N1YnR5cGUg L0hpZ2hsaWdodCANL1BvcHVwIDI1MCAwIFIgDS9NIChEOjIwMDMxMTEwMTU1NDQ1KzEyJzAwJykN L0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChyZWFsbSkNL1QgKGdncikNL1AgMTAg MCBSIA0vUXVhZFBvaW50cyBbIDI1OS4xMjI1MyAzNzEuMjI0MzIgMjgwLjcxNTcxIDM3MS4yMjQz MiAyNTkuMTIyNTMgMzYxLjczMDk2IDI4MC43MTU3MSANMzYxLjczMDk2IF0gDS9BUCA8PCAvTiAy NTEgMCBSID4+IA0+PiANZW5kb2JqDTI1MCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlw ZSAvUG9wdXAgDS9SZWN0IFsgMjU5LjEyMjUzIDE3MS4yMjQzMiA0NTkuMTIyNTMgMzcxLjIyNDMy IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAyNDkgMCBSIA0+PiANZW5kb2JqDTI1MSAw IG9iag08PCAvTGVuZ3RoIDE4NCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5 cGUgMSAvQkJveCBbIDI1Ni41ODgxMiAzNjEuNDM0MTQgMjgzLjI1MDE0IDM3MS41MjExMyBdIA0v TWF0cml4IFsgMSAwIDAgMSAtMjU2LjU4ODEyIC0zNjEuNDM0MTQgXSAvUmVzb3VyY2VzIDw8IC9Q cm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcKMC41 OTMzIHcKMjU5LjEyMjUgMzYxLjczMSBtCjI1Ni44ODQ5IDM2My45Njg2IDI1Ni44ODQ5IDM2OC45 ODY3IDI1OS4xMjI1IDM3MS4yMjQzIGMKMjgwLjcxNTcgMzcxLjIyNDMgbAoyODIuOTUzMyAzNjgu OTg2NyAyODIuOTUzMyAzNjMuOTY4NiAyODAuNzE1NyAzNjEuNzMxIGMKcwplbmRzdHJlYW0NZW5k b2JqDTI1MiAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDgzLjgzMTk5IDI0OS4zMTU2 IDI4OC42NDQ1MyAyNTkuNDAyNTkgXSANL05NICgxOTAwMGZjKQ0vRiA0IA0vU3VidHlwZSAvSGln aGxpZ2h0IA0vUG9wdXAgMjUzIDAgUiANL00gKEQ6MjAwMzExMTAxNTU2NDUrMTInMDAnKQ0vQyBb IDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKFRvIGJlIHRlY2huaWNhbCwgYSBTSU0gKmlz KiBhIHNtYXJ0Y2FyZCwgdW5saWtlIGEgVVNJTSB0aGF0IGlzIG9ubHkgYW4gYVwNcHBsaWNhdGlv biBvbiBhIFVJQ0MuIFNvIEkgZG9uJ3QgdGhpbmsgdGhlIHdvcmQgInRyYWRpdGlvbmFsbHkiIGlz IGFwcHJvXA1wcmlhdGUgaGVyZS4pDS9UIChnZ3IpDS9QIDEwIDAgUiANL1F1YWRQb2ludHMgWyA4 Ni4zNjYzOSAyNTkuMTA1NzcgMjg2LjExMDExIDI1OS4xMDU3NyA4Ni4zNjYzOSAyNDkuNjEyNDEg Mjg2LjExMDExIA0yNDkuNjEyNDEgXSANL0FQIDw8IC9OIDI1NCAwIFIgPj4gDT4+IA1lbmRvYmoN MjUzIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyA4Ni4z NjYzOSA1OS4xMDU3NyAyODYuMzY2MzkgMjU5LjEwNTc3IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCAN L1BhcmVudCAyNTIgMCBSIA0+PiANZW5kb2JqDTI1NCAwIG9iag08PCAvTGVuZ3RoIDE3OCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDgzLjgzMTk5IDI0 OS4zMTU2IDI4OC42NDQ1MyAyNTkuNDAyNTkgXSANL01hdHJpeCBbIDEgMCAwIDEgLTgzLjgzMTk5 IC0yNDkuMzE1NiBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVh bQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwo4Ni4zNjY0IDI0OS42MTI0IG0KODQu MTI4OCAyNTEuODUgODQuMTI4OCAyNTYuODY4MiA4Ni4zNjY0IDI1OS4xMDU4IGMKMjg2LjExMDEg MjU5LjEwNTggbAoyODguMzQ3NyAyNTYuODY4MiAyODguMzQ3NyAyNTEuODUgMjg2LjExMDEgMjQ5 LjYxMjQgYwpzCmVuZHN0cmVhbQ1lbmRvYmoNMjU1IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9S ZWN0IFsgNjcuNjQyMDMgMTc3LjkyOTUgMzIzLjk4MjI0IDE4OC4wMTY0OSBdIA0vTk0gKDE5MDAw ZmYpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAyNTYgMCBSIA0vTSAoRDoyMDAz MTExMDE1NTgzNysxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoQ2Fu IHRoaXMgZmlndXJlIGFwcGVhciBlYXJsaWVyLCBuZWFyZXIgdG8gd2hlcmUgaXQgaXMgZmlyc3Qg cmVmZXJlbmNlZD8pDS9UIChnZ3IpDS9QIDE2IDAgUiANL1F1YWRQb2ludHMgWyA3MC4xNzY0NCAx ODcuNzE5NjggMzIxLjQ0NzgxIDE4Ny43MTk2OCA3MC4xNzY0NCAxNzguMjI2MzIgMzIxLjQ0Nzgx IA0xNzguMjI2MzIgXSANL0FQIDw8IC9OIDI1OCAwIFIgPj4gDT4+IA1lbmRvYmoNMjU2IDAgb2Jq DTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyA3MC4xNzY0NCAtMTIu MjgwMzIgMjcwLjE3NjQ0IDE4Ny43MTk2OCBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQg MjU1IDAgUiANPj4gDWVuZG9iag0yNTcgMCBvYmoNWyANMjU1IDAgUiAyNTYgMCBSIDMwOCAwIFIg MzA5IDAgUiANXQ1lbmRvYmoNMjU4IDAgb2JqDTw8IC9MZW5ndGggMTgyIC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgNjcuNjQyMDMgMTc3LjkyOTUgMzIz Ljk4MjI0IDE4OC4wMTY0OSBdIA0vTWF0cml4IFsgMSAwIDAgMSAtNjcuNjQyMDMgLTE3Ny45Mjk1 IF0gL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3RyZWFtDQoxIDAuOTky MDA0IDAuMTc5OTkzIFJHCjAuNTkzMyB3CjcwLjE3NjQgMTc4LjIyNjMgbQo2Ny45Mzg4IDE4MC40 NjM5IDY3LjkzODggMTg1LjQ4MjEgNzAuMTc2NCAxODcuNzE5NyBjCjMyMS40NDc4IDE4Ny43MTk3 IGwKMzIzLjY4NTQgMTg1LjQ4MjEgMzIzLjY4NTQgMTgwLjQ2MzkgMzIxLjQ0NzggMTc4LjIyNjMg YwpzCmVuZHN0cmVhbQ1lbmRvYmoNMjYyIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsg NTEuNDM3MzIgNDAyLjE2NjY5IDQzMi4wMzA2MiA0MjIuNDUxNjggXSANL05NICgxOTAwMTA2KQ0v RiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMjYzIDAgUiANL00gKEQ6MjAwMzExMTAx NjAyMzYrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKFRyaXBsZXRz IG1heSBiZSBzdG9yZWQgaW4gdGhlIEFBQSBmb3IgdXNlIGF0IGEgbGF0ZXIgdGltZSwgYnV0IHRy aXBsZXRzIFwNbWF5IG5vdCBiZSByZXVzZWQuKQ0vVCAoZ2dyKQ0vUCAxMyAwIFIgDS9RdWFkUG9p bnRzIFsgMTc4LjE0NTI5IDQyMi4xNTQ4NiAzOTQuMDk0MTYgNDIyLjE1NDg2IDE3OC4xNDUyOSA0 MTIuNjYxNSAzOTQuMDk0MTYgDTQxMi42NjE1IDM0NS41MDcwMiA0MjIuMTU0ODYgMzQ4LjQ0OTQ4 IDQyMi4xNTQ4NiAzNDUuNTA3MDIgNDEyLjY2MTUgDTM0OC40NDk0OCA0MTIuNjYxNSAzOTQuMDkz MiA0MjIuMTU0ODYgNDI5LjQ5NjIgNDIyLjE1NDg2IDM5NC4wOTMyIA00MTIuNjYxNSA0MjkuNDk2 MiA0MTIuNjYxNSA1My45NzE3MyA0MTEuOTU2ODYgMTA1LjUxMTI5IDQxMS45NTY4NiANNTMuOTcx NzMgNDAyLjQ2MzUgMTA1LjUxMTI5IDQwMi40NjM1IF0gDS9BUCA8PCAvTiAyNjUgMCBSID4+IA0+ PiANZW5kb2JqDTI2MyAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9S ZWN0IFsgMTc4LjE0NTI5IDIyMi4xNTQ4NiAzNzguMTQ1MjkgNDIyLjE1NDg2IF0gDS9PcGVuIGZh bHNlIA0vRiAyOCANL1BhcmVudCAyNjIgMCBSIA0+PiANZW5kb2JqDTI2NCAwIG9iag1bIA0yNjIg MCBSIDI2MyAwIFIgMjcwIDAgUiAyNzEgMCBSIDI5NyAwIFIgMjk4IDAgUiAzMDAgMCBSIDMwMSAw IFIgDV0NZW5kb2JqDTI2NSAwIG9iag08PCAvRmlsdGVyIFsgL0ZsYXRlRGVjb2RlIF0gL0xlbmd0 aCAyNjYgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIA0vRm9ybVR5cGUgMSAvQkJv eCBbIDUxLjQzNzMyIDQwMi4xNjY2OSA0MzIuMDMwNjIgNDIyLjQ1MTY4IF0gL01hdHJpeCBbIDEg MCAwIDEgLTUxLjQzNzMyIC00MDIuMTY2NjkgXSANL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9Q REYgXSA+PiA+PiANc3RyZWFtDQpIiVSSMW4FMQgF+z2FT4DAgPE7Qfpc4bf/Vyly/Xij9cJ21kiD BmRpTEBntvWQAKDt++tgcqi230NikphrM+k0hnj7LOYEjljMaALSCgFBQlt6vZO4ob0OhRHDerL3 YoNUZaZZyDU9vd3wOn4ONSfnqGFqSn3Aippkj99a6bJJZvBHlzONGVLEJPfw7T26/mu1P8IgNN1H 3ekm997byzLrIMN4XMxUKFTLxQq5pqdXy1wJIWt17mRDzzA/TVsCGwWLtASgkPUZbkmE4OOsEl4n FNFk78WCwiZSLOSand4OOKv+BBgAeoV9OA1lbmRzdHJlYW0NZW5kb2JqDTI2NiAwIG9iag0yMzMg DWVuZG9iag0yNzAgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAyNzguMTc3NjkgMTg4 LjEyNzUyIDMxNS42MzU4MiAxOTguMjE0NTEgXSANL05NICgxOTAwMTBlKQ0vRiA0IA0vU3VidHlw ZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMjcxIDAgUiANL00gKEQ6MjAwMzExMTAxNjA0NDErMTInMDAn KQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKENhbiB0aGlzIGJlIGNhbGxlZCBB VF9NQUNfUkVTIG9yIHNvbWV0aGluZywgdG8gZGlzdGluZ3Vpc2ggaXQgZnJvbSB0aGUgQVwNVF9N QUMgdGhhdCB3ZW50IGluIHRoZSBvdGhlciBkaXJlY3Rpb24/KQ0vVCAoZ2dyKQ0vUCAxMyAwIFIg DS9RdWFkUG9pbnRzIFsgMjgwLjcxMjEgMTk3LjkxNzY5IDMxMy4xMDEzOSAxOTcuOTE3NjkgMjgw LjcxMjEgMTg4LjQyNDMzIDMxMy4xMDEzOSANMTg4LjQyNDMzIF0gDS9BUCA8PCAvTiAyNzIgMCBS ID4+IA0+PiANZW5kb2JqDTI3MSAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9w dXAgDS9SZWN0IFsgMjgwLjcxMjEgLTIuMDgyMzEgNDgwLjcxMjEgMTk3LjkxNzY5IF0gDS9PcGVu IGZhbHNlIA0vRiAyOCANL1BhcmVudCAyNzAgMCBSIA0+PiANZW5kb2JqDTI3MiAwIG9iag08PCAv TGVuZ3RoIDE4NCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJv eCBbIDI3OC4xNzc2OSAxODguMTI3NTIgMzE1LjYzNTgyIDE5OC4yMTQ1MSBdIA0vTWF0cml4IFsg MSAwIDAgMSAtMjc4LjE3NzY5IC0xODguMTI3NTIgXSAvUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsg L1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcKMC41OTMzIHcKMjgw LjcxMjEgMTg4LjQyNDMgbQoyNzguNDc0NSAxOTAuNjYxOSAyNzguNDc0NSAxOTUuNjgwMSAyODAu NzEyMSAxOTcuOTE3NyBjCjMxMy4xMDE0IDE5Ny45MTc3IGwKMzE1LjMzOSAxOTUuNjgwMSAzMTUu MzM5IDE5MC42NjE5IDMxMy4xMDE0IDE4OC40MjQzIGMKcwplbmRzdHJlYW0NZW5kb2JqDTI3MyAw IG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDI2MS45OTgwNiAxNDcuMzM1NDYgMzA0Ljg1 NDI1IDE1Ny40MjI0NSBdIA0vTk0gKDE5MDAxMTEpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQg DS9Qb3B1cCAyNzQgMCBSIA0vTSAoRDoyMDAzMTExMDE2MjkxNisxMicwMCcpDS9DIFsgMSAwLjk5 MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoIm5ldHdvcmsiIGlzIG5vdCBhIGRlZmluZWQgdGVybSBo ZXJlLikNL1QgKGdncikNL1AgMTAgMCBSIA0vUXVhZFBvaW50cyBbIDI2NC41MzI0NyAxNTcuMTI1 NjQgMzAyLjMxOTgyIDE1Ny4xMjU2NCAyNjQuNTMyNDcgMTQ3LjYzMjI4IDMwMi4zMTk4MiANMTQ3 LjYzMjI4IF0gDS9BUCA8PCAvTiAyNzUgMCBSID4+IA0+PiANZW5kb2JqDTI3NCAwIG9iag08PCAN L1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9SZWN0IFsgMjY0LjI4ODkzIC01MC4wMDkz OCA1NTguMjkxMjMgMTU2Ljk5MjIzIF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAyNzMg MCBSIA0+PiANZW5kb2JqDTI3NSAwIG9iag08PCAvTGVuZ3RoIDE4NCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDI2MS45OTgwNiAxNDcuMzM1NDYgMzA0 Ljg1NDI1IDE1Ny40MjI0NSBdIA0vTWF0cml4IFsgMSAwIDAgMSAtMjYxLjk5ODA2IC0xNDcuMzM1 NDYgXSAvUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45 OTIwMDQgMC4xNzk5OTMgUkcKMC41OTMzIHcKMjY0LjUzMjUgMTQ3LjYzMjMgbQoyNjIuMjk0OSAx NDkuODY5OSAyNjIuMjk0OSAxNTQuODg4IDI2NC41MzI1IDE1Ny4xMjU2IGMKMzAyLjMxOTggMTU3 LjEyNTYgbAozMDQuNTU3NCAxNTQuODg4IDMwNC41NTc0IDE0OS44Njk5IDMwMi4zMTk4IDE0Ny42 MzIzIGMKcwplbmRzdHJlYW0NZW5kb2JqDTI5NyAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVj dCBbIDExNi4yMzIyNCAxNDcuMzM1NDYgMjAyLjI3NjU0IDE1Ny40MjI0NSBdIA0vTk0gKDE5MDAx MjkpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAyOTggMCBSIA0vTSAoRDoyMDAz MTExMDE2MTQyMisxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoZGVy aXZlKQ0vVCAoZ2dyKQ0vUCAxMyAwIFIgDS9RdWFkUG9pbnRzIFsgMTE4Ljc2NjY1IDE1Ny4xMjU2 NCAxOTkuNzQyMTEgMTU3LjEyNTY0IDExOC43NjY2NSAxNDcuNjMyMjggMTk5Ljc0MjExIA0xNDcu NjMyMjggXSANL0FQIDw8IC9OIDI5OSAwIFIgPj4gDT4+IA1lbmRvYmoNMjk4IDAgb2JqDTw8IA0v VHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyAxMTguNzY2NjUgLTQyLjg3NDM2 IDMxOC43NjY2NSAxNTcuMTI1NjQgXSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDI5NyAw IFIgDT4+IA1lbmRvYmoNMjk5IDAgb2JqDTw8IC9MZW5ndGggMTg0IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgMTE2LjIzMjI0IDE0Ny4zMzU0NiAyMDIu Mjc2NTQgMTU3LjQyMjQ1IF0gDS9NYXRyaXggWyAxIDAgMCAxIC0xMTYuMjMyMjQgLTE0Ny4zMzU0 NiBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5 MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwoxMTguNzY2NiAxNDcuNjMyMyBtCjExNi41MjkxIDE0 OS44Njk5IDExNi41MjkxIDE1NC44ODggMTE4Ljc2NjYgMTU3LjEyNTYgYwoxOTkuNzQyMSAxNTcu MTI1NiBsCjIwMS45Nzk3IDE1NC44ODggMjAxLjk3OTcgMTQ5Ljg2OTkgMTk5Ljc0MjEgMTQ3LjYz MjMgYwpzCmVuZHN0cmVhbQ1lbmRvYmoNMzAwIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0 IFsgNTEuNDM3MzIgMTM3LjE5NjkgNDQyLjgyNjc0IDE1Ny40MjI0NSBdIA0vTk0gKDE5MDAxMmMp DS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAzMDEgMCBSIA0vTSAoRDoyMDAzMTEx MDE2MzU1MSsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoVGhlIGRl cml2ZWQga2V5aW5nIG1hdGVyaWFsIGlzLCBvZiBjb3Vyc2UsIG5vdCBmb3J3YXJkZWQgdG8gdGhl IHBlZXIgYWxvXA1uZyB3aXRoIHRoZSBFQVAtU3VjY2VzcyBtZXNzYWdlLCBhcyBpdCBoYXMgZGVy aXZlZCB0aGUgc2FtZSBrZXlpbmcgbWF0ZXJcDWlhbC4pDS9UIChnZ3IpDS9QIDEzIDAgUiANL1F1 YWRQb2ludHMgWyAyOTEuNTE5MSAxNTcuMTI1NjQgNDMxLjk0ODIxIDE1Ny4xMjU2NCAyOTEuNTE5 MSAxNDcuNjMyMjggNDMxLjk0ODIxIA0xNDcuNjMyMjggNDE1LjY4OTEgMTU3LjEyNTY0IDQxOC42 MzE1NiAxNTcuMTI1NjQgNDE1LjY4OTEgMTQ3LjYzMjI4IA00MTguNjMxNTYgMTQ3LjYzMjI4IDQz MS45NDcyNyAxNTcuMTI1NjQgNDQwLjI5MjMxIDE1Ny4xMjU2NCA0MzEuOTQ3MjcgDTE0Ny42MzIy OCA0NDAuMjkyMzEgMTQ3LjYzMjI4IDUzLjk3MTczIDE0Ni45ODcwOCAxNjcuMzQ2NDUgMTQ2Ljk4 NzA4IA01My45NzE3MyAxMzcuNDkzNzEgMTY3LjM0NjQ1IDEzNy40OTM3MSBdIA0vQVAgPDwgL04g MzAyIDAgUiA+PiANPj4gDWVuZG9iag0zMDEgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5 cGUgL1BvcHVwIA0vUmVjdCBbIDI5MC43MTc4MiAtNDkuNDM3OTkgNDkwLjcxOTM5IDE1MC41NjM1 OCBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzAwIDAgUiANPj4gDWVuZG9iag0zMDIg MCBvYmoNPDwgL0ZpbHRlciBbIC9GbGF0ZURlY29kZSBdIC9MZW5ndGggMzAzIDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvRm9ybSANL0Zvcm1UeXBlIDEgL0JCb3ggWyA1MS40MzczMiAxMzcu MTk2OSA0NDIuODI2NzQgMTU3LjQyMjQ1IF0gL01hdHJpeCBbIDEgMCAwIDEgLTUxLjQzNzMyIC0x MzcuMTk2OSBdIA0vUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0N CkiJVJA7bkUhDAV7VsEKLPzD9grSZwuvfalSZPtxImFzOzTSHAZwLoigtSQPaBHB8/NjLNBgnj+D AkExcKIYbCaeX4M8gBw1WYDviNlEBdx9tqYGSLrnawgjhDg1eycTQFcvscHZbu0UvMb3EFTY/uwS ZBC9u5qc+dKuLvRcwP3oovW3QC0W6O2jPbr+a40fXRRgK+xyi9Szj3Z1yQIK4keXECjlQokFaru0 u0sZwjAvZAMJtsxSBGPJr+CMYeRZQARMQmdJsiHcMJdwG7BsbfZOFqB+i03Odnsn4K/qV4ABAOiN fOwNZW5kc3RyZWFtDWVuZG9iag0zMDMgMCBvYmoNMjI5IA1lbmRvYmoNMzA0IDAgb2JqDTw8IA0v VHlwZSAvQW5ub3QgDS9SZWN0IFsgMTQzLjIyMjUzIDE2Ny43MzE0OSA0MTguMjI0NTIgMTc3Ljgx ODQ4IF0gDS9OTSAoMTkwMDEzMCkNL0YgNCANL1N1YnR5cGUgL0hpZ2hsaWdodCANL1BvcHVwIDMw NSAwIFIgDS9NIChEOjIwMDMxMTEwMTYzMzAyKzEyJzAwJykNL0MgWyAxIDAuOTkyIDAuMTc5OTkg XSANL0NvbnRlbnRzIChJIHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgY2xlYXJlci4gSG93IGFib3V0 OlxyXHIiVGhlIGF1dGhlbnRpY2F0b3Igc2hvd25cDSBpbiB0aGUgZmlndXJlIGlzIG9mdGVuIHNp bXBseSByZWxheWluZyBFQVAgbWVzc2FnZXMgdG8gYW5kIGZyb20gdGhlIEVBUFwNIHNlcnZlciwg YnV0IHRoZXNlIGJhY2sgZW5kIEFBQSBjb21tdW5pY2F0aW9ucyBhcmUgbm90IHNob3duLiIpDS9U IChnZ3IpDS9QIDEwIDAgUiANL1F1YWRQb2ludHMgWyAxNDUuNzU2OTQgMTc3LjUyMTY3IDMwMi4z MTYyNSAxNzcuNTIxNjcgMTQ1Ljc1Njk0IDE2OC4wMjgzMSAzMDIuMzE2MjUgDTE2OC4wMjgzMSAy ODAuNzE5MzkgMTc3LjUyMTY3IDI4My42NjE4NSAxNzcuNTIxNjcgMjgwLjcxOTM5IDE2OC4wMjgz MSANMjgzLjY2MTg1IDE2OC4wMjgzMSAzMDIuMzE1MjkgMTc3LjUyMTY3IDQxNS42OTAwOSAxNzcu NTIxNjcgMzAyLjMxNTI5IA0xNjguMDI4MzEgNDE1LjY5MDA5IDE2OC4wMjgzMSBdIA0vQVAgPDwg L04gMzA2IDAgUiA+PiANPj4gDWVuZG9iag0zMDUgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1 YnR5cGUgL1BvcHVwIA0vUmVjdCBbIDE0Ni40MzAzNCAtMzEuNTgwNjMgMzQ2LjQzMTkyIDE2OC40 MjA5NCBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzA0IDAgUiANPj4gDWVuZG9iag0z MDYgMCBvYmoNPDwgL0ZpbHRlciBbIC9GbGF0ZURlY29kZSBdIC9MZW5ndGggMzA3IDAgUiAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSANL0Zvcm1UeXBlIDEgL0JCb3ggWyAxNDMuMjIyNTMg MTY3LjczMTQ5IDQxOC4yMjQ1MiAxNzcuODE4NDggXSAvTWF0cml4IFsgMSAwIDAgMSAtMTQzLjIy MjUzIC0xNjcuNzMxNDkgXSANL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiAN c3RyZWFtDQpIiUyPu5FDMQgAc1WhChi+Aipw7hac+qILrv3T2O8JMs2KZRaaCJmMqPtBnpkyn4+B YCky/wapgdvKSSsAOWT+bCZgtAfJEXjZ/ixiwKE0y3MHY/L5GoIMQkuKvTdTMJMss5Fre3l3w2v8 Dg4Ep9Rexh6gQVFuI9f+8qps27DWZ+qUcRhEpnXzkHv78XrZt9eklwkioLv3qw45l99elSkZrETq ZUoOyd1s5NpeXi/7F2AADhhgPA1lbmRzdHJlYW0NZW5kb2JqDTMwNyAwIG9iag0xODIgDWVuZG9i ag0zMDggMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAxMjEuNjIxIDI1OS41MTM2MSAx NDguMjgzMDIgMjY5LjYwMDYgXSANL05NICgxOTAwMTM0KQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxp Z2h0IA0vUG9wdXAgMzA5IDAgUiANL00gKEQ6MjAwMzExMTAxNjM2MjErMTInMDAnKQ0vQyBbIDEg MC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKEFUX01BQ19SRVMpDS9UIChnZ3IpDS9QIDE2IDAg UiANL1F1YWRQb2ludHMgWyAxMjQuMTU1NDEgMjY5LjMwMzc5IDE0NS43NDg2IDI2OS4zMDM3OSAx MjQuMTU1NDEgMjU5LjgxMDQyIDE0NS43NDg2IA0yNTkuODEwNDIgXSANL0FQIDw8IC9OIDMxMCAw IFIgPj4gDT4+IA1lbmRvYmoNMzA5IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Q b3B1cCANL1JlY3QgWyAxMjQuMTU1NDEgNjkuMzAzNzkgMzI0LjE1NTQxIDI2OS4zMDM3OSBdIA0v T3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzA4IDAgUiANPj4gDWVuZG9iag0zMTAgMCBvYmoN PDwgL0xlbmd0aCAxODQgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEg L0JCb3ggWyAxMjEuNjIxIDI1OS41MTM2MSAxNDguMjgzMDIgMjY5LjYwMDYgXSANL01hdHJpeCBb IDEgMCAwIDEgLTEyMS42MjEgLTI1OS41MTM2MSBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAv UERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwoxMjQu MTU1NCAyNTkuODEwNCBtCjEyMS45MTc4IDI2Mi4wNDggMTIxLjkxNzggMjY3LjA2NjIgMTI0LjE1 NTQgMjY5LjMwMzggYwoxNDUuNzQ4NiAyNjkuMzAzOCBsCjE0Ny45ODYyIDI2Ny4wNjYyIDE0Ny45 ODYyIDI2Mi4wNDggMTQ1Ljc0ODYgMjU5LjgxMDQgYwpzCmVuZHN0cmVhbQ1lbmRvYmoNMzExIDAg b2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgODkuMjM4MjcgNTA0LjE0NjY3IDE4MC42ODA2 MyA1MTQuMjMzNjYgXSANL05NICgxOTAwMTM3KQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0v UG9wdXAgMzEyIDAgUiANL00gKEQ6MjAwMzExMTAxNjQzMjUrMTInMDAnKQ0vQyBbIDEgMC45OTIg MC4xNzk5OSBdIA0vQ29udGVudHMgKFNob3VsZCByZWZlciB0byB0aGUgZmlndXJlIGJ5IG51bWJl ci4pDS9UIChnZ3IpDS9QIDY3IDAgUiANL1F1YWRQb2ludHMgWyA5MS43NzI2NyA1MTMuOTM2ODQg MTc4LjE0NjIxIDUxMy45MzY4NCA5MS43NzI2NyA1MDQuNDQzNDggMTc4LjE0NjIxIA01MDQuNDQz NDggXSANL0FQIDw8IC9OIDMxNCAwIFIgPj4gDT4+IA1lbmRvYmoNMzEyIDAgb2JqDTw8IA0vVHlw ZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyA5MS43NzI2NyAzMTMuOTM2ODQgMjkx Ljc3MjY3IDUxMy45MzY4NCBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzExIDAgUiAN Pj4gDWVuZG9iag0zMTMgMCBvYmoNWyANMzExIDAgUiAzMTIgMCBSIDMxNSAwIFIgMzE2IDAgUiAz MTggMCBSIDMxOSAwIFIgMzIxIDAgUiAzMjIgMCBSIA1dDWVuZG9iag0zMTQgMCBvYmoNPDwgL0xl bmd0aCAxODIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3gg WyA4OS4yMzgyNyA1MDQuMTQ2NjcgMTgwLjY4MDYzIDUxNC4yMzM2NiBdIA0vTWF0cml4IFsgMSAw IDAgMSAtODkuMjM4MjcgLTUwNC4xNDY2NyBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERG IF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwo5MS43NzI3 IDUwNC40NDM1IG0KODkuNTM1MSA1MDYuNjgxMSA4OS41MzUxIDUxMS42OTkyIDkxLjc3MjcgNTEz LjkzNjggYwoxNzguMTQ2MiA1MTMuOTM2OCBsCjE4MC4zODM4IDUxMS42OTkyIDE4MC4zODM4IDUw Ni42ODExIDE3OC4xNDYyIDUwNC40NDM1IGMKcwplbmRzdHJlYW0NZW5kb2JqDTMxNSAwIG9iag08 PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDEyNy4wMjgzNCAzNTEuMjM2MTUgMTgwLjY4MDYzIDM2 MS4zMjMxNCBdIA0vTk0gKDE5MDAxM2IpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1 cCAzMTYgMCBSIA0vTSAoRDoyMDAzMTExMDE2NDUyNCsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3 OTk5IF0gDS9Db250ZW50cyAoV2h5IGlzIHRoaXMgZW5jcnlwdGVkPyBJZiBpdCdzIGp1c3QgYSBy YW5kb20gbm9uY2UgaXQgc2hvdWxkbid0IGJlIG5lY2VzXA1zYXJ5OyBpZiBpdCdzIG5lY2Vzc2Fy eSBJJ20gd29ycmllZC4pDS9UIChnZ3IpDS9QIDY3IDAgUiANL1F1YWRQb2ludHMgWyAxMjkuNTYy NzQgMzYxLjAyNjMyIDE3OC4xNDYyMSAzNjEuMDI2MzIgMTI5LjU2Mjc0IDM1MS41MzI5NiAxNzgu MTQ2MjEgDTM1MS41MzI5NiBdIA0vQVAgPDwgL04gMzE3IDAgUiA+PiANPj4gDWVuZG9iag0zMTYg MCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL1BvcHVwIA0vUmVjdCBbIDEyOS41NjI3 NCAxNjEuMDI2MzIgMzI5LjU2Mjc0IDM2MS4wMjYzMiBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9Q YXJlbnQgMzE1IDAgUiANPj4gDWVuZG9iag0zMTcgMCBvYmoNPDwgL0xlbmd0aCAxODQgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3ggWyAxMjcuMDI4MzQgMzUx LjIzNjE1IDE4MC42ODA2MyAzNjEuMzIzMTQgXSANL01hdHJpeCBbIDEgMCAwIDEgLTEyNy4wMjgz NCAtMzUxLjIzNjE1IF0gL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3Ry ZWFtDQoxIDAuOTkyMDA0IDAuMTc5OTkzIFJHCjAuNTkzMyB3CjEyOS41NjI3IDM1MS41MzMgbQox MjcuMzI1MSAzNTMuNzcwNiAxMjcuMzI1MSAzNTguNzg4NyAxMjkuNTYyNyAzNjEuMDI2MyBjCjE3 OC4xNDYyIDM2MS4wMjYzIGwKMTgwLjM4MzggMzU4Ljc4ODcgMTgwLjM4MzggMzUzLjc3MDYgMTc4 LjE0NjIgMzUxLjUzMyBjCnMKZW5kc3RyZWFtDWVuZG9iag0zMTggMCBvYmoNPDwgDS9UeXBlIC9B bm5vdCANL1JlY3QgWyAyMTMuNDA4MTkgMTY3LjczMTQ5IDI1MC44NjYzMiAxNzcuODE4NDggXSAN L05NICgxOTAwMTNlKQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMzE5IDAgUiAN L00gKEQ6MjAwMzExMTAxNjQ2MzIrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29u dGVudHMgKEFUX01BQ19SRVMpDS9UIChnZ3IpDS9QIDY3IDAgUiANL1F1YWRQb2ludHMgWyAyMTUu OTQyNiAxNzcuNTIxNjcgMjQ4LjMzMTg5IDE3Ny41MjE2NyAyMTUuOTQyNiAxNjguMDI4MzEgMjQ4 LjMzMTg5IA0xNjguMDI4MzEgXSANL0FQIDw8IC9OIDMyMCAwIFIgPj4gDT4+IA1lbmRvYmoNMzE5 IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyAyMTUuOTQy NiAtMjIuNDc4MzMgNDE1Ljk0MjYgMTc3LjUyMTY3IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1Bh cmVudCAzMTggMCBSIA0+PiANZW5kb2JqDTMyMCAwIG9iag08PCAvTGVuZ3RoIDE4NCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDIxMy40MDgxOSAxNjcu NzMxNDkgMjUwLjg2NjMyIDE3Ny44MTg0OCBdIA0vTWF0cml4IFsgMSAwIDAgMSAtMjEzLjQwODE5 IC0xNjcuNzMxNDkgXSAvUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJl YW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcKMC41OTMzIHcKMjE1Ljk0MjYgMTY4LjAyODMgbQoy MTMuNzA1IDE3MC4yNjU5IDIxMy43MDUgMTc1LjI4NDEgMjE1Ljk0MjYgMTc3LjUyMTcgYwoyNDgu MzMxOSAxNzcuNTIxNyBsCjI1MC41Njk1IDE3NS4yODQxIDI1MC41Njk1IDE3MC4yNjU5IDI0OC4z MzE5IDE2OC4wMjgzIGMKcwplbmRzdHJlYW0NZW5kb2JqDTMyMSAwIG9iag08PCANL1R5cGUgL0Fu bm90IA0vUmVjdCBbIDE5Ny4yMTAzNyAxNDcuMzM1NDYgMjM0LjY2ODUgMTU3LjQyMjQ1IF0gDS9O TSAoMTkwMDE0MSkNL0YgNCANL1N1YnR5cGUgL0hpZ2hsaWdodCANL1BvcHVwIDMyMiAwIFIgDS9N IChEOjIwMDMxMTEwMTY0NjM5KzEyJzAwJykNL0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRl bnRzIChBVF9NQUNfUkVTKQ0vVCAoZ2dyKQ0vUCA2NyAwIFIgDS9RdWFkUG9pbnRzIFsgMTk5Ljc0 NDc4IDE1Ny4xMjU2NCAyMzIuMTM0MDggMTU3LjEyNTY0IDE5OS43NDQ3OCAxNDcuNjMyMjggMjMy LjEzNDA4IA0xNDcuNjMyMjggXSANL0FQIDw8IC9OIDMyMyAwIFIgPj4gDT4+IA1lbmRvYmoNMzIy IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyAxOTkuNzQ0 NzggLTQyLjg3NDM2IDM5OS43NDQ3OCAxNTcuMTI1NjQgXSANL09wZW4gZmFsc2UgDS9GIDI4IA0v UGFyZW50IDMyMSAwIFIgDT4+IA1lbmRvYmoNMzIzIDAgb2JqDTw8IC9MZW5ndGggMTg0IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgMTk3LjIxMDM3IDE0 Ny4zMzU0NiAyMzQuNjY4NSAxNTcuNDIyNDUgXSANL01hdHJpeCBbIDEgMCAwIDEgLTE5Ny4yMTAz NyAtMTQ3LjMzNTQ2IF0gL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3Ry ZWFtDQoxIDAuOTkyMDA0IDAuMTc5OTkzIFJHCjAuNTkzMyB3CjE5OS43NDQ4IDE0Ny42MzIzIG0K MTk3LjUwNzIgMTQ5Ljg2OTkgMTk3LjUwNzIgMTU0Ljg4OCAxOTkuNzQ0OCAxNTcuMTI1NiBjCjIz Mi4xMzQxIDE1Ny4xMjU2IGwKMjM0LjM3MTcgMTU0Ljg4OCAyMzQuMzcxNyAxNDkuODY5OSAyMzIu MTM0MSAxNDcuNjMyMyBjCnMKZW5kc3RyZWFtDWVuZG9iag0zMjQgMCBvYmoNPDwgDS9UeXBlIC9B bm5vdCANL1JlY3QgWyA2Ny42NDI0MyAzMzAuODQwMTUgMTI2LjY5Mjc4IDM0MC45MjcxNCBdIA0v Tk0gKDE5MDAxNDQpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAzMjUgMCBSIA0v TSAoRDoyMDAzMTExMDE3MDAyNisxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250 ZW50cyAoNTM5NTM3NTRhQFxyXHJJcyB0aGUgImEiIHN1cHBvc2VkIHRvIGJlIHRoZXJlPyBXaGF0 IGhhcHBlbmVkIHRvIGl0IG9uIHRoXA1lIG5leHQgbGluZT8pDS9UIChnZ3IpDS9QIDIyIDAgUiAN L1F1YWRQb2ludHMgWyA3MC4xNzY4MyAzNDAuNjMwMzMgMTI0LjE1ODM2IDM0MC42MzAzMyA3MC4x NzY4MyAzMzEuMTM2OTYgMTI0LjE1ODM2IA0zMzEuMTM2OTYgXSANL0FQIDw8IC9OIDMyNyAwIFIg Pj4gDT4+IA1lbmRvYmoNMzI1IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1 cCANL1JlY3QgWyA3MC4xNzY4MyAxNDAuNjMwMzMgMjcwLjE3NjgzIDM0MC42MzAzMyBdIA0vT3Bl biBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzI0IDAgUiANPj4gDWVuZG9iag0zMjYgMCBvYmoNWyAN MzI0IDAgUiAzMjUgMCBSIA1dDWVuZG9iag0zMjcgMCBvYmoNPDwgL0xlbmd0aCAxNzggL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3ggWyA2Ny42NDI0MyAzMzAu ODQwMTUgMTI2LjY5Mjc4IDM0MC45MjcxNCBdIA0vTWF0cml4IFsgMSAwIDAgMSAtNjcuNjQyNDMg LTMzMC44NDAxNSBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVh bQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwo3MC4xNzY4IDMzMS4xMzcgbQo2Ny45 MzkyIDMzMy4zNzQ2IDY3LjkzOTIgMzM4LjM5MjcgNzAuMTc2OCAzNDAuNjMwMyBjCjEyNC4xNTg0 IDM0MC42MzAzIGwKMTI2LjM5NiAzMzguMzkyNyAxMjYuMzk2IDMzMy4zNzQ2IDEyNC4xNTg0IDMz MS4xMzcgYwpzCmVuZHN0cmVhbQ1lbmRvYmoNMzI4IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9S ZWN0IFsgNjcuNjQyNCA2MjYuNDYzMiA5OS43MDYxMyA2MzYuNTUwMTkgXSANL05NICgxOTAwMTQ4 KQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMzI5IDAgUiANL00gKEQ6MjAwMzEx MTAxNzAzMDMrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKE1BWSBi ZSBhICkNL1QgKGdncikNL1AgMjUgMCBSIA0vUXVhZFBvaW50cyBbIDcwLjE3NjggNjM2LjI1MzM3 IDk3LjE3MTcxIDYzNi4yNTMzNyA3MC4xNzY4IDYyNi43NjAwMSA5Ny4xNzE3MSA2MjYuNzYwMDEg DV0gDS9BUCA8PCAvTiAzMzEgMCBSID4+IA0+PiANZW5kb2JqDTMyOSAwIG9iag08PCANL1R5cGUg L0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9SZWN0IFsgNzAuMTc2OCA0MzYuMjUzMzcgMjcwLjE3 NjggNjM2LjI1MzM3IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAzMjggMCBSIA0+PiAN ZW5kb2JqDTMzMCAwIG9iag1bIA0zMjggMCBSIDMyOSAwIFIgMzMyIDAgUiAzMzMgMCBSIA1dDWVu ZG9iag0zMzEgMCBvYmoNPDwgL0xlbmd0aCAxNzQgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zv cm0gL0Zvcm1UeXBlIDEgL0JCb3ggWyA2Ny42NDI0IDYyNi40NjMyIDk5LjcwNjEzIDYzNi41NTAx OSBdIA0vTWF0cml4IFsgMSAwIDAgMSAtNjcuNjQyNCAtNjI2LjQ2MzIgXSAvUmVzb3VyY2VzIDw8 IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcK MC41OTMzIHcKNzAuMTc2OCA2MjYuNzYgbQo2Ny45MzkyIDYyOC45OTc2IDY3LjkzOTIgNjM0LjAx NTggNzAuMTc2OCA2MzYuMjUzNCBjCjk3LjE3MTcgNjM2LjI1MzQgbAo5OS40MDkzIDYzNC4wMTU4 IDk5LjQwOTMgNjI4Ljk5NzYgOTcuMTcxNyA2MjYuNzYgYwpzCmVuZHN0cmVhbQ1lbmRvYmoNMzMy IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgMzIxLjM5MTMxIDYzNi42NjExOSAzOTEu MjQxNDQgNjQ2Ljc0ODE4IF0gDS9OTSAoMTkwMDE0YykNL0YgNCANL1N1YnR5cGUgL0hpZ2hsaWdo dCANL1BvcHVwIDMzMyAwIFIgDS9NIChEOjIwMDMxMTEwMTcwMzUwKzEyJzAwJykNL0MgWyAxIDAu OTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChXaGljaCBvcGVyYXRvcj8pDS9UIChnZ3IpDS9QIDI1 IDAgUiANL1F1YWRQb2ludHMgWyAzMjMuOTI1NzIgNjQ2LjQ1MTM3IDM4OC43MDcwMiA2NDYuNDUx MzcgMzIzLjkyNTcyIDYzNi45NTgwMSAzODguNzA3MDIgDTYzNi45NTgwMSBdIA0vQVAgPDwgL04g MzM0IDAgUiA+PiANPj4gDWVuZG9iag0zMzMgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5 cGUgL1BvcHVwIA0vUmVjdCBbIDMyMy45MjU3MiA0NDYuNDUxMzcgNTIzLjkyNTcyIDY0Ni40NTEz NyBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzMyIDAgUiANPj4gDWVuZG9iag0zMzQg MCBvYmoNPDwgL0xlbmd0aCAxODIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1U eXBlIDEgL0JCb3ggWyAzMjEuMzkxMzEgNjM2LjY2MTE5IDM5MS4yNDE0NCA2NDYuNzQ4MTggXSAN L01hdHJpeCBbIDEgMCAwIDEgLTMyMS4zOTEzMSAtNjM2LjY2MTE5IF0gL1Jlc291cmNlcyA8PCAv UHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3RyZWFtDQoxIDAuOTkyMDA0IDAuMTc5OTkzIFJHCjAu NTkzMyB3CjMyMy45MjU3IDYzNi45NTggbQozMjEuNjg4MSA2MzkuMTk1NiAzMjEuNjg4MSA2NDQu MjEzOCAzMjMuOTI1NyA2NDYuNDUxNCBjCjM4OC43MDcgNjQ2LjQ1MTQgbAozOTAuOTQ0NiA2NDQu MjEzOCAzOTAuOTQ0NiA2MzkuMTk1NiAzODguNzA3IDYzNi45NTggYwpzCmVuZHN0cmVhbQ1lbmRv YmoNMzM1IDAgb2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGggMTQ0 NiA+PiANc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6 a2M5ZCcgYnl0ZXM9JzE0NDYnPz4KCjxyZGY6UkRGIHhtbG5zOnJkZj0naHR0cDovL3d3dy53My5v cmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycKIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUu Y29tL2lYLzEuMC8nPgoKIDxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycKICB4bWxucz0naHR0cDov L25zLmFkb2JlLmNvbS9wZGYvMS4zLycKICB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20v cGRmLzEuMy8nPgogIDxwZGY6Q3JlYXRpb25EYXRlPjIwMDMtMTEtMTBUMDQ6Mzg6NTJaPC9wZGY6 Q3JlYXRpb25EYXRlPgogIDxwZGY6TW9kRGF0ZT4yMDAzLTExLTEwVDE4OjAzOjU1KzEyOjAwPC9w ZGY6TW9kRGF0ZT4KICA8cGRmOlByb2R1Y2VyPkFjcm9iYXQgRGlzdGlsbGVyIDUuMCAoV2luZG93 cyk8L3BkZjpQcm9kdWNlcj4KICA8cGRmOkF1dGhvcj5nZ3I8L3BkZjpBdXRob3I+CiAgPHBkZjpD cmVhdG9yPlBzY3JpcHQuZGxsIFZlcnNpb24gNS4wPC9wZGY6Q3JlYXRvcj4KICA8cGRmOlRpdGxl Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhdmVyaW5lbi1wcHBl eHQtZWFwLTwvcGRmOlRpdGxlPgogPC9yZGY6RGVzY3JpcHRpb24+CgogPHJkZjpEZXNjcmlwdGlv biBhYm91dD0nJwogIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJwogIHhtbG5z OnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyc+CiAgPHhhcDpDcmVhdGVEYXRlPjIw MDMtMTEtMTBUMDQ6Mzg6NTJaPC94YXA6Q3JlYXRlRGF0ZT4KICA8eGFwOk1vZGlmeURhdGU+MjAw My0xMS0xMFQxODowMzo1NSsxMjowMDwveGFwOk1vZGlmeURhdGU+CiAgPHhhcDpBdXRob3I+Z2dy PC94YXA6QXV0aG9yPgogIDx4YXA6TWV0YWRhdGFEYXRlPjIwMDMtMTEtMTBUMTg6MDM6NTUrMTI6 MDA8L3hhcDpNZXRhZGF0YURhdGU+CiAgPHhhcDpUaXRsZT4KICAgPHJkZjpBbHQ+CiAgICA8cmRm OmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWhhdmVyaW5lbi1wcHBleHQtZWFwLTwvcmRmOmxpPgogICA8L3JkZjpBbHQ+CiAg PC94YXA6VGl0bGU+CiA8L3JkZjpEZXNjcmlwdGlvbj4KCiA8cmRmOkRlc2NyaXB0aW9uIGFib3V0 PScnCiAgeG1sbnM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJwogIHhtbG5zOmRj PSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyc+CiAgPGRjOmNyZWF0b3I+Z2dyPC9k YzpjcmVhdG9yPgogIDxkYzp0aXRsZT5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1oYXZlcmluZW4tcHBwZXh0LWVhcC08L2RjOnRpdGxlPgogPC9yZGY6RGVzY3JpcHRp b24+Cgo8L3JkZjpSREY+Cjw/eHBhY2tldCBlbmQ9J3InPz4NZW5kc3RyZWFtDWVuZG9iag14cmVm DTAgMzM2IA0wMDAwMDAwMjA0IDY1NTM1IGYNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDE2 OCAwMDAwMCBuDQowMDAwMDAwMzE4IDAwMDAwIG4NCjAwMDAwMDIyMjggMDAwMDAgbg0KMDAwMDAw MjM5NyAwMDAwMCBuDQowMDAwMDAyNTQ3IDAwMDAwIG4NCjAwMDAwMDUyMTkgMDAwMDAgbg0KMDAw MDAwNTM3MSAwMDAwMCBuDQowMDAwMDA1NTIxIDAwMDAwIG4NCjAwMDAwMDc0MjEgMDAwMDAgbg0K MDAwMDAwNzU5MyAwMDAwMCBuDQowMDAwMDA3NzQ0IDAwMDAwIG4NCjAwMDAwMDk2MDMgMDAwMDAg bg0KMDAwMDAwOTc3NSAwMDAwMCBuDQowMDAwMDA5OTI2IDAwMDAwIG4NCjAwMDAwMTIxOTcgMDAw MDAgbg0KMDAwMDAxMjM2OSAwMDAwMCBuDQowMDAwMDEyNTIwIDAwMDAwIG4NCjAwMDAwMTQyODkg MDAwMDAgbg0KMDAwMDAxNDQ0NCAwMDAwMCBuDQowMDAwMDE0NTk1IDAwMDAwIG4NCjAwMDAwMTcw NTUgMDAwMDAgbg0KMDAwMDAxNzIyNyAwMDAwMCBuDQowMDAwMDE3Mzc4IDAwMDAwIG4NCjAwMDAw MTk4MTIgMDAwMDAgbg0KMDAwMDAxOTk4NCAwMDAwMCBuDQowMDAwMDIwMTM1IDAwMDAwIG4NCjAw MDAwMjI3ODYgMDAwMDAgbg0KMDAwMDAyMjk0MSAwMDAwMCBuDQowMDAwMDIzMDkyIDAwMDAwIG4N CjAwMDAwMjUzODcgMDAwMDAgbg0KMDAwMDAyNTU0MiAwMDAwMCBuDQowMDAwMDI1NjkzIDAwMDAw IG4NCjAwMDAwMjgwNDAgMDAwMDAgbg0KMDAwMDAyODE5NSAwMDAwMCBuDQowMDAwMDI4MzQ2IDAw MDAwIG4NCjAwMDAwMzA3NDcgMDAwMDAgbg0KMDAwMDAzMDkwMiAwMDAwMCBuDQowMDAwMDMxMDUz IDAwMDAwIG4NCjAwMDAwMzMwNjcgMDAwMDAgbg0KMDAwMDAzMzIyMiAwMDAwMCBuDQowMDAwMDMz MzczIDAwMDAwIG4NCjAwMDAwMzU4MjUgMDAwMDAgbg0KMDAwMDAzNTk4MCAwMDAwMCBuDQowMDAw MDM2MTMxIDAwMDAwIG4NCjAwMDAwMzgwMjUgMDAwMDAgbg0KMDAwMDAzODE4MCAwMDAwMCBuDQow MDAwMDM4MzMxIDAwMDAwIG4NCjAwMDAwNDAxOTUgMDAwMDAgbg0KMDAwMDA0MDM1MCAwMDAwMCBu DQowMDAwMDQwNTAxIDAwMDAwIG4NCjAwMDAwNDIxNDggMDAwMDAgbg0KMDAwMDA0MjMwMyAwMDAw MCBuDQowMDAwMDQyNDU0IDAwMDAwIG4NCjAwMDAwNDQxNDAgMDAwMDAgbg0KMDAwMDA0NDI5NSAw MDAwMCBuDQowMDAwMDQ0NDQ2IDAwMDAwIG4NCjAwMDAwNDYxNjMgMDAwMDAgbg0KMDAwMDA0NjMx OCAwMDAwMCBuDQowMDAwMDQ2NDY5IDAwMDAwIG4NCjAwMDAwNDgyNjIgMDAwMDAgbg0KMDAwMDA0 ODQxNyAwMDAwMCBuDQowMDAwMDQ4NTY4IDAwMDAwIG4NCjAwMDAwNTA5MTYgMDAwMDAgbg0KMDAw MDA1MTA3MSAwMDAwMCBuDQowMDAwMDUxMjIyIDAwMDAwIG4NCjAwMDAwNTM2OTcgMDAwMDAgbg0K MDAwMDA1Mzg2OSAwMDAwMCBuDQowMDAwMDU0MDIwIDAwMDAwIG4NCjAwMDAwNTYyMzMgMDAwMDAg bg0KMDAwMDA1NjM4OCAwMDAwMCBuDQowMDAwMDU2NTM5IDAwMDAwIG4NCjAwMDAwNTg0ODQgMDAw MDAgbg0KMDAwMDA1ODYzOSAwMDAwMCBuDQowMDAwMDU4NzkwIDAwMDAwIG4NCjAwMDAwNjEwNDcg MDAwMDAgbg0KMDAwMDA2MTIwMiAwMDAwMCBuDQowMDAwMDYxMzUzIDAwMDAwIG4NCjAwMDAwNjM2 NzUgMDAwMDAgbg0KMDAwMDA2MzgzMCAwMDAwMCBuDQowMDAwMDYzOTgxIDAwMDAwIG4NCjAwMDAw NjYyMDcgMDAwMDAgbg0KMDAwMDA2NjM2MiAwMDAwMCBuDQowMDAwMDY2NTEzIDAwMDAwIG4NCjAw MDAwNjg1ODIgMDAwMDAgbg0KMDAwMDA2ODczNyAwMDAwMCBuDQowMDAwMDY4ODg4IDAwMDAwIG4N CjAwMDAwNzE2NTggMDAwMDAgbg0KMDAwMDA3MTgxMyAwMDAwMCBuDQowMDAwMDcxOTY0IDAwMDAw IG4NCjAwMDAwNzQ2MzAgMDAwMDAgbg0KMDAwMDA3NDc4NSAwMDAwMCBuDQowMDAwMDc0OTM2IDAw MDAwIG4NCjAwMDAwNzY5NTAgMDAwMDAgbg0KMDAwMDA3NzEwNSAwMDAwMCBuDQowMDAwMDc3MjU2 IDAwMDAwIG4NCjAwMDAwNzk1OTQgMDAwMDAgbg0KMDAwMDA3OTc0OSAwMDAwMCBuDQowMDAwMDc5 OTAwIDAwMDAwIG4NCjAwMDAwODE4MDYgMDAwMDAgbg0KMDAwMDA4MTk2NCAwMDAwMCBuDQowMDAw MDgyMTE2IDAwMDAwIG4NCjAwMDAwODQxMTIgMDAwMDAgbg0KMDAwMDA4NDI3MCAwMDAwMCBuDQow MDAwMDg0NDIyIDAwMDAwIG4NCjAwMDAwODYzMDIgMDAwMDAgbg0KMDAwMDA4NjQ2MCAwMDAwMCBu DQowMDAwMDg2NjEyIDAwMDAwIG4NCjAwMDAwODg5NTEgMDAwMDAgbg0KMDAwMDA4OTEwOSAwMDAw MCBuDQowMDAwMDg5MjYxIDAwMDAwIG4NCjAwMDAwOTE0OTUgMDAwMDAgbg0KMDAwMDA5MTY1MyAw MDAwMCBuDQowMDAwMDkxODA1IDAwMDAwIG4NCjAwMDAwOTM4NDMgMDAwMDAgbg0KMDAwMDA5NDAw MSAwMDAwMCBuDQowMDAwMDk0MTUzIDAwMDAwIG4NCjAwMDAwOTY0MjIgMDAwMDAgbg0KMDAwMDA5 NjU4MCAwMDAwMCBuDQowMDAwMDk2NzMyIDAwMDAwIG4NCjAwMDAwOTg4NDcgMDAwMDAgbg0KMDAw MDA5OTAwNSAwMDAwMCBuDQowMDAwMDk5MTU3IDAwMDAwIG4NCjAwMDAxMDA1MzAgMDAwMDAgbg0K MDAwMDEwMDY4OCAwMDAwMCBuDQowMDAwMTAwODQwIDAwMDAwIG4NCjAwMDAxMDMxNzYgMDAwMDAg bg0KMDAwMDEwMzMzNCAwMDAwMCBuDQowMDAwMTAzNDg2IDAwMDAwIG4NCjAwMDAxMDU2MzYgMDAw MDAgbg0KMDAwMDEwNTc5NCAwMDAwMCBuDQowMDAwMTA1OTQ2IDAwMDAwIG4NCjAwMDAxMDc1MjMg MDAwMDAgbg0KMDAwMDEwNzY4MSAwMDAwMCBuDQowMDAwMTA3ODMzIDAwMDAwIG4NCjAwMDAxMTAx NTAgMDAwMDAgbg0KMDAwMDExMDMwOCAwMDAwMCBuDQowMDAwMTEwNDYwIDAwMDAwIG4NCjAwMDAx MTIxMjMgMDAwMDAgbg0KMDAwMDExMjI4MSAwMDAwMCBuDQowMDAwMTEyNDMzIDAwMDAwIG4NCjAw MDAxMTUwMjggMDAwMDAgbg0KMDAwMDExNTE4NiAwMDAwMCBuDQowMDAwMTE1MzM4IDAwMDAwIG4N CjAwMDAxMTgxNjAgMDAwMDAgbg0KMDAwMDExODMxOCAwMDAwMCBuDQowMDAwMTE4NDcwIDAwMDAw IG4NCjAwMDAxMjEyMDMgMDAwMDAgbg0KMDAwMDEyMTM2MSAwMDAwMCBuDQowMDAwMTIxNTEzIDAw MDAwIG4NCjAwMDAxMjM5MjUgMDAwMDAgbg0KMDAwMDEyNDA4MyAwMDAwMCBuDQowMDAwMTI0MjM1 IDAwMDAwIG4NCjAwMDAxMjY3MjAgMDAwMDAgbg0KMDAwMDEyNjg3OCAwMDAwMCBuDQowMDAwMTI3 MDMwIDAwMDAwIG4NCjAwMDAxMjkyNzggMDAwMDAgbg0KMDAwMDEyOTQzNiAwMDAwMCBuDQowMDAw MTI5NTg4IDAwMDAwIG4NCjAwMDAxMzIwMjQgMDAwMDAgbg0KMDAwMDEzMjE4MiAwMDAwMCBuDQow MDAwMTMyMzM0IDAwMDAwIG4NCjAwMDAxMzQ1MDggMDAwMDAgbg0KMDAwMDEzNDY2NiAwMDAwMCBu DQowMDAwMTM0ODE4IDAwMDAwIG4NCjAwMDAxMzU5OTUgMDAwMDAgbg0KMDAwMDEzNjE1MyAwMDAw MCBuDQowMDAwMTM2MzA1IDAwMDAwIG4NCjAwMDAxMzgxMjcgMDAwMDAgbg0KMDAwMDEzODI4NSAw MDAwMCBuDQowMDAwMTM4NDM3IDAwMDAwIG4NCjAwMDAxNDA0MTQgMDAwMDAgbg0KMDAwMDE0MDU3 MiAwMDAwMCBuDQowMDAwMTQwNzI0IDAwMDAwIG4NCjAwMDAxNDMxNzcgMDAwMDAgbg0KMDAwMDE0 MzMzNSAwMDAwMCBuDQowMDAwMTQzNDg3IDAwMDAwIG4NCjAwMDAxNDU5MDQgMDAwMDAgbg0KMDAw MDE0NjA2MiAwMDAwMCBuDQowMDAwMTQ2MjE0IDAwMDAwIG4NCjAwMDAxNDg0NDggMDAwMDAgbg0K MDAwMDE0ODYwNiAwMDAwMCBuDQowMDAwMTQ4NzU4IDAwMDAwIG4NCjAwMDAxNTExMTYgMDAwMDAg bg0KMDAwMDE1MTI3NCAwMDAwMCBuDQowMDAwMTUxNDI2IDAwMDAwIG4NCjAwMDAxNTM0MTUgMDAw MDAgbg0KMDAwMDE1MzU3MyAwMDAwMCBuDQowMDAwMTUzNzI1IDAwMDAwIG4NCjAwMDAxNTUwODkg MDAwMDAgbg0KMDAwMDE1NTI0NyAwMDAwMCBuDQowMDAwMTU1Mzk5IDAwMDAwIG4NCjAwMDAxNTYx MTggMDAwMDAgbg0KMDAwMDE1NjE1MCAwMDAwMCBuDQowMDAwMTU2MTk2IDAwMDAwIG4NCjAwMDAx NTYzNDMgMDAwMDAgbg0KMDAwMDE1NjQ2MCAwMDAwMCBuDQowMDAwMTU2NjA5IDAwMDAwIG4NCjAw MDAxNTY3NTggMDAwMDAgbg0KMDAwMDE1NjkxMyAwMDAwMCBuDQowMDAwMTU3MDcyIDAwMDAwIG4N CjAwMDAxNTcyMzEgMDAwMDAgbg0KMDAwMDE1NzM0OCAwMDAwMCBuDQowMDAwMDAwMjA1IDAwMDAx IGYNCjAwMDAwMDAyMTggMDAwMDEgZg0KMDAwMDE1NzYxMCAwMDAwMCBuDQowMDAwMTU3NzIzIDAw MDAwIG4NCjAwMDAxNTc4ODEgMDAwMDAgbg0KMDAwMDE1ODAzMyAwMDAwMCBuDQowMDAwMTU5MDg4 IDAwMDAwIG4NCjAwMDAxNTkxMjkgMDAwMDAgbg0KMDAwMDE1OTMzNiAwMDAwMCBuDQowMDAwMTYx Mzk2IDAwMDAwIG4NCjAwMDAxNjE2MjMgMDAwMDAgbg0KMDAwMDE2MjA1NyAwMDAwMCBuDQowMDAw MTYyMTM2IDAwMDAwIG4NCjAwMDAxNjQ4MTQgMDAwMDAgbg0KMDAwMDAwMDIxOSAwMDAwMSBmDQow MDAwMDAwMjI0IDAwMDAxIGYNCjAwMDAxODc5NTYgMDAwMDAgbg0KMDAwMDE4ODMzOCAwMDAwMCBu DQowMDAwMTg4NDgyIDAwMDAwIG4NCjAwMDAxODg1NjkgMDAwMDAgbg0KMDAwMDAwMDIyNSAwMDAw MSBmDQowMDAwMDAwMjI2IDAwMDAxIGYNCjAwMDAwMDAyMzcgMDAwMDEgZg0KMDAwMDE4ODk3NSAw MDAwMCBuDQowMDAwMTg5NDMzIDAwMDAwIG4NCjAwMDAxODk1NzcgMDAwMDAgbg0KMDAwMDE4OTk4 OSAwMDAwMCBuDQowMDAwMTkwMDExIDAwMDAwIG4NCjAwMDAxOTAzNjUgMDAwMDAgbg0KMDAwMDE5 MDUwOSAwMDAwMCBuDQowMDAwMTkwOTEyIDAwMDAwIG4NCjAwMDAxOTEyNzAgMDAwMDAgbg0KMDAw MDE5MTQxNCAwMDAwMCBuDQowMDAwMDAwMjM4IDAwMDAxIGYNCjAwMDAwMDAyNTkgMDAwMDEgZg0K MDAwMDE5MTgxOSAwMDAwMCBuDQowMDAwMTkxODU3IDAwMDAwIG4NCjAwMDAxOTIwMDUgMDAwMDAg bg0KMDAwMDE5MjM3NyAwMDAwMCBuDQowMDAwMTkyMzk5IDAwMDAwIG4NCjAwMDAxOTI3NzIgMDAw MDAgbg0KMDAwMDE5Mjc5NCAwMDAwMCBuDQowMDAwMTkzMTUxIDAwMDAwIG4NCjAwMDAxOTMyOTUg MDAwMDAgbg0KMDAwMDE5MzM5OSAwMDAwMCBuDQowMDAwMTkzODA2IDAwMDAwIG4NCjAwMDAxOTQx NjQgMDAwMDAgbg0KMDAwMDE5NDMwOCAwMDAwMCBuDQowMDAwMTk0NzE2IDAwMDAwIG4NCjAwMDAx OTUyMjUgMDAwMDAgbg0KMDAwMDE5NTM2NyAwMDAwMCBuDQowMDAwMTk1NzY1IDAwMDAwIG4NCjAw MDAxOTYxODUgMDAwMDAgbg0KMDAwMDE5NjMyOCAwMDAwMCBuDQowMDAwMTk2MzgzIDAwMDAwIG4N CjAwMDAwMDAyNjAgMDAwMDEgZg0KMDAwMDAwMDI2MSAwMDAwMSBmDQowMDAwMDAwMjY3IDAwMDAx IGYNCjAwMDAxOTY3ODUgMDAwMDAgbg0KMDAwMDE5NzQ1OCAwMDAwMCBuDQowMDAwMTk3NjAyIDAw MDAwIG4NCjAwMDAxOTc2ODkgMDAwMDAgbg0KMDAwMDE5ODE3NSAwMDAwMCBuDQowMDAwMDAwMjY4 IDAwMDAxIGYNCjAwMDAwMDAyNjkgMDAwMDEgZg0KMDAwMDAwMDI3NiAwMDAwMSBmDQowMDAwMTk4 MTk3IDAwMDAwIG4NCjAwMDAxOTg2NjEgMDAwMDAgbg0KMDAwMDE5ODgwMiAwMDAwMCBuDQowMDAw MTk5MjEwIDAwMDAwIG4NCjAwMDAxOTk2MDAgMDAwMDAgbg0KMDAwMDE5OTc0NCAwMDAwMCBuDQow MDAwMDAwMjc3IDAwMDAxIGYNCjAwMDAwMDAyNzggMDAwMDEgZg0KMDAwMDAwMDI3OSAwMDAwMSBm DQowMDAwMDAwMjgwIDAwMDAxIGYNCjAwMDAwMDAyODEgMDAwMDEgZg0KMDAwMDAwMDI4MiAwMDAw MSBmDQowMDAwMDAwMjgzIDAwMDAxIGYNCjAwMDAwMDAyODQgMDAwMDEgZg0KMDAwMDAwMDI4NSAw MDAwMSBmDQowMDAwMDAwMjg2IDAwMDAxIGYNCjAwMDAwMDAyODcgMDAwMDEgZg0KMDAwMDAwMDI4 OCAwMDAwMSBmDQowMDAwMDAwMjg5IDAwMDAxIGYNCjAwMDAwMDAyOTAgMDAwMDEgZg0KMDAwMDAw MDI5MSAwMDAwMSBmDQowMDAwMDAwMjkyIDAwMDAxIGYNCjAwMDAwMDAyOTMgMDAwMDEgZg0KMDAw MDAwMDI5NCAwMDAwMSBmDQowMDAwMDAwMjk1IDAwMDAxIGYNCjAwMDAwMDAyOTYgMDAwMDEgZg0K MDAwMDAwMDAwMCAwMDAwMSBmDQowMDAwMjAwMTUyIDAwMDAwIG4NCjAwMDAyMDA1MTEgMDAwMDAg bg0KMDAwMDIwMDY1NSAwMDAwMCBuDQowMDAwMjAxMDYzIDAwMDAwIG4NCjAwMDAyMDE4MDMgMDAw MDAgbg0KMDAwMDIwMTk0NyAwMDAwMCBuDQowMDAwMjAyNDI3IDAwMDAwIG4NCjAwMDAyMDI0NDkg MDAwMDAgbg0KMDAwMDIwMzE3NCAwMDAwMCBuDQowMDAwMjAzMzE4IDAwMDAwIG4NCjAwMDAyMDM3 NTUgMDAwMDAgbg0KMDAwMDIwMzc3NyAwMDAwMCBuDQowMDAwMjA0MTM1IDAwMDAwIG4NCjAwMDAy MDQyNzggMDAwMDAgbg0KMDAwMDIwNDY4MSAwMDAwMCBuDQowMDAwMjA1MDY4IDAwMDAwIG4NCjAw MDAyMDUyMTEgMDAwMDAgbg0KMDAwMDIwNTI5OCAwMDAwMCBuDQowMDAwMjA1NzAyIDAwMDAwIG4N CjAwMDAyMDYxNjUgMDAwMDAgbg0KMDAwMDIwNjMwOSAwMDAwMCBuDQowMDAwMjA2NzE3IDAwMDAw IG4NCjAwMDAyMDcwNzggMDAwMDAgbg0KMDAwMDIwNzIyMCAwMDAwMCBuDQowMDAwMjA3NjI4IDAw MDAwIG4NCjAwMDAyMDc5OTAgMDAwMDAgbg0KMDAwMDIwODEzNCAwMDAwMCBuDQowMDAwMjA4NTQx IDAwMDAwIG4NCjAwMDAyMDg5NzcgMDAwMDAgbg0KMDAwMDIwOTEyMCAwMDAwMCBuDQowMDAwMjA5 MTU5IDAwMDAwIG4NCjAwMDAyMDk1NTkgMDAwMDAgbg0KMDAwMDIwOTkxMSAwMDAwMCBuDQowMDAw MjEwMDUyIDAwMDAwIG4NCjAwMDAyMTAxMDcgMDAwMDAgbg0KMDAwMDIxMDQ5OCAwMDAwMCBuDQow MDAwMjEwODY2IDAwMDAwIG4NCjAwMDAyMTEwMTAgMDAwMDAgbg0KMDAwMDIxMTQxNiAwMDAwMCBu DQp0cmFpbGVyDTw8DS9TaXplIDMzNg0vSW5mbyAyMDMgMCBSIA0vUm9vdCAyMDYgMCBSIA0vSURb PGVhMjlmMTcyMzE4MjZlNjUyNzExZWY3N2IxMzcxNTNmPjwwZmU0NjM5NGZiYjdjMzRlMDA1Mjdk NTczZDg4ZmE1YT5dDT4+DXN0YXJ0eHJlZg0yMTI5NDgNJSVFT0YNMjggMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDE5NyAwIFIgDS9SZXNvdXJjZXMgMjkgMCBSIA0vQ29udGVudHMgMzAg MCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0g DS9Sb3RhdGUgMCANL0Fubm90cyAyMjUgMSBSIA0+PiANZW5kb2JqDTMxIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCAxOTcgMCBSIA0vUmVzb3VyY2VzIDMyIDAgUiANL0NvbnRlbnRzIDMz IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBd IA0vUm90YXRlIDAgDS9Bbm5vdHMgMjgwIDEgUiANPj4gDWVuZG9iag0zNCAwIG9iag08PCANL1R5 cGUgL1BhZ2UgDS9QYXJlbnQgMTk3IDAgUiANL1Jlc291cmNlcyAzNSAwIFIgDS9Db250ZW50cyAz NiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIg XSANL1JvdGF0ZSAwIA0vQW5ub3RzIDI5MSAxIFIgDT4+IA1lbmRvYmoNNjEgMCBvYmoNPDwgDS9U eXBlIC9QYWdlIA0vUGFyZW50IDE5OCAwIFIgDS9SZXNvdXJjZXMgNjIgMCBSIA0vQ29udGVudHMg NjMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzky IF0gDS9Sb3RhdGUgMCANL0Fubm90cyAyOTUgMSBSIA0+PiANZW5kb2JqDTY0IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAxOTggMCBSIA0vUmVzb3VyY2VzIDY1IDAgUiANL0NvbnRlbnRz IDY2IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vUm90YXRlIDAgDS9Bbm5vdHMgMzM4IDAgUiANPj4gDWVuZG9iag04MiAwIG9iag08PCAN L1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk4IDAgUiANL1Jlc291cmNlcyA4MyAwIFIgDS9Db250ZW50 cyA4NCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3 OTIgXSANL1JvdGF0ZSAwIA0vQW5ub3RzIDM0MSAwIFIgDT4+IA1lbmRvYmoNODUgMCBvYmoNPDwg DS9UeXBlIC9QYWdlIA0vUGFyZW50IDE5OCAwIFIgDS9SZXNvdXJjZXMgODYgMCBSIA0vQ29udGVu dHMgODcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIg NzkyIF0gDS9Sb3RhdGUgMCANL0Fubm90cyAzNTAgMCBSIA0+PiANZW5kb2JqDTExMiAwIG9iag08 PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTk5IDAgUiANL1Jlc291cmNlcyAxMTMgMCBSIA0vQ29u dGVudHMgMTE0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAg NjEyIDc5MiBdIA0vUm90YXRlIDAgDS9Bbm5vdHMgMzU0IDAgUiANPj4gDWVuZG9iag0xMjQgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMCAwIFIgDS9SZXNvdXJjZXMgMTI1IDAgUiAN L0NvbnRlbnRzIDEyNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vQW5ub3RzIDM1OCAwIFIgDT4+IA1lbmRvYmoNMTMw IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyMDAgMCBSIA0vUmVzb3VyY2VzIDEzMSAw IFIgDS9Db250ZW50cyAxMzIgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJv eCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANL0Fubm90cyAzNjIgMCBSIA0+PiANZW5kb2Jq DTEzNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjAwIDAgUiANL1Jlc291cmNlcyAx MzcgMCBSIA0vQ29udGVudHMgMTM4IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Ny b3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDS9Bbm5vdHMgMzY3IDAgUiANPj4gDWVu ZG9iag0xNDUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDIwMCAwIFIgDS9SZXNvdXJj ZXMgMTQ2IDAgUiANL0NvbnRlbnRzIDE0NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g DS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vQW5ub3RzIDM3NSAwIFIgDT4+ IA1lbmRvYmoNMjAzIDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDMxMTEwMDQzODUyWikN L01vZERhdGUgKEQ6MjAwMzExMTIxNDEzNTgrMTInMDAnKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlz dGlsbGVyIDUuMCBcKFdpbmRvd3NcKSkNL0F1dGhvciAoZ2dyKQ0vQ3JlYXRvciAoUHNjcmlwdC5k bGwgVmVyc2lvbiA1LjApDS9UaXRsZSAoaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaGF2ZXJpbmVuLXBwcGV4dC1lYXAtKQ0+PiANZW5kb2JqDTIwNCAxIG9iag08PCAN L1R5cGUgL0Fubm90IA0vUmVjdCBbIDY3LjY0MjQgNDUzLjE1NjY4IDE0Mi44ODY5MiA0NjMuMjQz NjcgXSANL05NICgxOTAwMGNjKQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMjA1 IDEgUiANL00gKEQ6MjAwMzExMTIxMTMwNDUrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBd IA0vQ29udGVudHMgKE5vdGUgdGhhdCB0aGlzIGlzIE5va2lhIElQUiwgXChhY2NvcmRpbmcgdG8g dGhlIFdJUE9cKSB3aGljaCBpcyBuZWl0aGVyIFwNbWVudGlvbmVkIGluIHRoZSBJUFIgc2VjdGlv biBub3IgY292ZXJlZCBpbiB0aGUgc3RhdGVtZW50IGxvZGdlZC4gVGhpcyBuXA1lZWRzIHRvIGJl IGV4cGxpY2l0bHkgZGlzY2xvc2VkLikNL1QgKGdncikNL1AgMjUgMCBSIA0vUXVhZFBvaW50cyBb IDcwLjE3NjggNDYyLjk0Njg1IDE0MC4zNTI0OSA0NjIuOTQ2ODUgNzAuMTc2OCA0NTMuNDUzNDkg MTQwLjM1MjQ5IA00NTMuNDUzNDkgXSANL0FQIDw8IC9OIDIxOCAxIFIgPj4gDT4+IA1lbmRvYmoN MjA1IDEgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyA3MC4x NzY4IDI2Mi45NDY4NSAyNzAuMTc2OCA0NjIuOTQ2ODUgXSANL09wZW4gZmFsc2UgDS9GIDI4IA0v UGFyZW50IDIwNCAxIFIgDT4+IA1lbmRvYmoNMjA2IDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyAN L1BhZ2VzIDE5NiAwIFIgDS9NZXRhZGF0YSAzODQgMCBSIA0vUGFnZUxhYmVscyAxOTQgMCBSIA0v TmFtZXMgMjM5IDAgUiANPj4gDWVuZG9iag0yMTggMSBvYmoNPDwgL0xlbmd0aCAxODIgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JCb3ggWyA2Ny42NDI0IDQ1My4x NTY2OCAxNDIuODg2OTIgNDYzLjI0MzY3IF0gDS9NYXRyaXggWyAxIDAgMCAxIC02Ny42NDI0IC00 NTMuMTU2NjggXSAvUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0N CjEgMC45OTIwMDQgMC4xNzk5OTMgUkcKMC41OTMzIHcKNzAuMTc2OCA0NTMuNDUzNSBtCjY3Ljkz OTIgNDU1LjY5MTEgNjcuOTM5MiA0NjAuNzA5MyA3MC4xNzY4IDQ2Mi45NDY5IGMKMTQwLjM1MjUg NDYyLjk0NjkgbAoxNDIuNTkwMSA0NjAuNzA5MyAxNDIuNTkwMSA0NTUuNjkxMSAxNDAuMzUyNSA0 NTMuNDUzNSBjCnMKZW5kc3RyZWFtDWVuZG9iag0yMTkgMSBvYmoNPDwgDS9UeXBlIC9Bbm5vdCAN L1JlY3QgWyA2Ny42NDI0IDUzNC42ODEyMSAxNjkuODg4MTcgNTQ0Ljc2ODIgXSANL05NICgxOTAw MGRiKQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMjI0IDEgUiANL00gKEQ6MjAw MzExMTIxMTQxNTQrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKEl0 J3MgYmVlbiBsb25nIGVub3VnaCBzaW5jZSB0aGlzIHdhcyBtZW50aW9uZWQgdGhhdCBJIHRoaW5r IHlvdSBzaG91bGQgaFwNYXZlIHRoZSBbRUFQIEFLQV0gcmVmZXJlbmNlIHRvby4pDS9UIChnZ3Ip DS9QIDI4IDAgUiANL1F1YWRQb2ludHMgWyA3MC4xNzY4IDU0NC40NzEzOSAxNjcuMzUzNzQgNTQ0 LjQ3MTM5IDcwLjE3NjggNTM0Ljk3ODAzIDE2Ny4zNTM3NCANNTM0Ljk3ODAzIF0gDS9BUCA8PCAv TiAyMjYgMSBSID4+IA0+PiANZW5kb2JqDTIyNCAxIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3Vi dHlwZSAvUG9wdXAgDS9SZWN0IFsgNzAuMTc2OCAzNDQuNDcxMzkgMjcwLjE3NjggNTQ0LjQ3MTM5 IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAyMTkgMSBSIA0+PiANZW5kb2JqDTIyNSAx IG9iag1bIA0yMTkgMSBSIDIyNCAxIFIgMjM3IDEgUiAyMzggMSBSIDI2MCAxIFIgMjYxIDEgUiAN XQ1lbmRvYmoNMjI2IDEgb2JqDTw8IC9MZW5ndGggMTgwIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgNjcuNjQyNCA1MzQuNjgxMjEgMTY5Ljg4ODE3IDU0 NC43NjgyIF0gDS9NYXRyaXggWyAxIDAgMCAxIC02Ny42NDI0IC01MzQuNjgxMjEgXSAvUmVzb3Vy Y2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5 OTMgUkcKMC41OTMzIHcKNzAuMTc2OCA1MzQuOTc4IG0KNjcuOTM5MiA1MzcuMjE1NiA2Ny45Mzky IDU0Mi4yMzM4IDcwLjE3NjggNTQ0LjQ3MTQgYwoxNjcuMzUzNyA1NDQuNDcxNCBsCjE2OS41OTE0 IDU0Mi4yMzM4IDE2OS41OTE0IDUzNy4yMTU2IDE2Ny4zNTM3IDUzNC45NzggYwpzCmVuZHN0cmVh bQ1lbmRvYmoNMjM3IDEgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgMTkxLjgwODY5IDMz MC44NDAxNSAzODUuODI4NzggMzQwLjkyNzE0IF0gDS9OTSAoMTkwMDBlZCkNL0YgNCANL1N1YnR5 cGUgL0hpZ2hsaWdodCANL1BvcHVwIDIzOCAxIFIgDS9NIChEOjIwMDMxMTEyMTE0NDU1KzEyJzAw JykNL0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChEbyB5b3Ugd2FudCB0byBzYXkg c29tZXRoaW5nIGFib3V0IHRoaXMgYmVpbmcgIm1vc3QgcmVjZW50bHkgdXNlZCI/IE90aGVcDXJ3 aXNlIGl0IGNvdWxkIGJlIGFuY2llbnQsIHdoaWNoIHByb2JhYmx5IHdvdWxkbid0IGhlbHAuKQ0v VCAoZ2dyKQ0vUCAyOCAwIFIgDS9RdWFkUG9pbnRzIFsgMTk0LjM0MzA5IDM0MC42MzAzMyAzODMu Mjk0MzYgMzQwLjYzMDMzIDE5NC4zNDMwOSAzMzEuMTM2OTYgMzgzLjI5NDM2IA0zMzEuMTM2OTYg XSANL0FQIDw8IC9OIDI1OSAxIFIgPj4gDT4+IA1lbmRvYmoNMjM4IDEgb2JqDTw8IA0vVHlwZSAv QW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3QgWyAxOTQuMzQzMDkgMTQwLjYzMDMzIDM5NC4z NDMwOSAzNDAuNjMwMzMgXSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDIzNyAxIFIgDT4+ IA1lbmRvYmoNMjU5IDEgb2JqDTw8IC9MZW5ndGggMTgyIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgMTkxLjgwODY5IDMzMC44NDAxNSAzODUuODI4Nzgg MzQwLjkyNzE0IF0gDS9NYXRyaXggWyAxIDAgMCAxIC0xOTEuODA4NjkgLTMzMC44NDAxNSBdIC9S ZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAw LjE3OTk5MyBSRwowLjU5MzMgdwoxOTQuMzQzMSAzMzEuMTM3IG0KMTkyLjEwNTUgMzMzLjM3NDYg MTkyLjEwNTUgMzM4LjM5MjcgMTk0LjM0MzEgMzQwLjYzMDMgYwozODMuMjk0NCAzNDAuNjMwMyBs CjM4NS41MzIgMzM4LjM5MjcgMzg1LjUzMiAzMzMuMzc0NiAzODMuMjk0NCAzMzEuMTM3IGMKcwpl bmRzdHJlYW0NZW5kb2JqDTI2MCAxIG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDEyNy4w MjgzMiA5Ni40MDQ4NSA0MjMuNjc1NDYgMTA2LjQ5MTg0IF0gDS9OTSAoMTkwMDEwNCkNL0YgNCAN L1N1YnR5cGUgL0hpZ2hsaWdodCANL1BvcHVwIDI2MSAxIFIgDS9NIChEOjIwMDMxMTEyMTE0OTU5 KzEyJzAwJykNL0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChGb3IgcmVhdXRoZW50 aWNhdGlvbiwgSSBoYXZlIGEgbmFnZ2luZyB3b3JyeSB0aGF0IHlvdSBzaG91bGQgbmV2ZXIgYWxs b3dcDSBvbmUgdG8gYmUgcmV1c2VkLiBJJ2xsIHNlZSBpZiB0aGlzIGRldmVsb3BzIGludG8gYSBy ZWFsIHdvcnJ5LCBhbmQgaG9wZVwNZnVsbHkgY29tZSBiYWNrIHRvIHRoaXMgY29tbWVudC5cclxy QWgsIGZvdW5kIHRoZSBzdGF0ZW1lbnQganVzdCBiZWxvdy4gXA1Hb29kLikNL1QgKGdncikNL1Ag MjggMCBSIA0vUXVhZFBvaW50cyBbIDEyOS41NjI3MyAxMDYuMTk1MDIgNDIxLjE0MTA0IDEwNi4x OTUwMiAxMjkuNTYyNzMgOTYuNzAxNjYgNDIxLjE0MTA0IA05Ni43MDE2NiBdIA0vQVAgPDwgL04g MjY3IDEgUiA+PiANPj4gDWVuZG9iag0yNjEgMSBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5 cGUgL1BvcHVwIA0vUmVjdCBbIDEyOS41NjI3MyAtOTMuODA0OTggMzI5LjU2MjczIDEwNi4xOTUw MiBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMjYwIDEgUiANPj4gDWVuZG9iag0yNjcg MSBvYmoNPDwgL0xlbmd0aCAxNzggL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1U eXBlIDEgL0JCb3ggWyAxMjcuMDI4MzIgOTYuNDA0ODUgNDIzLjY3NTQ2IDEwNi40OTE4NCBdIA0v TWF0cml4IFsgMSAwIDAgMSAtMTI3LjAyODMyIC05Ni40MDQ4NSBdIC9SZXNvdXJjZXMgPDwgL1By b2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5 MzMgdwoxMjkuNTYyNyA5Ni43MDE3IG0KMTI3LjMyNTEgOTguOTM5MyAxMjcuMzI1MSAxMDMuOTU3 NCAxMjkuNTYyNyAxMDYuMTk1IGMKNDIxLjE0MSAxMDYuMTk1IGwKNDIzLjM3ODYgMTAzLjk1NzQg NDIzLjM3ODYgOTguOTM5MyA0MjEuMTQxIDk2LjcwMTcgYwpzCmVuZHN0cmVhbQ1lbmRvYmoNMjY4 IDEgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgNjcuNjQyNCA3MTguMTg1NzMgMjA3LjY3 MDkxIDcyOC4yNzI3MiBdIA0vTk0gKDE5MDAxMGMpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQg DS9Qb3B1cCAyNjkgMSBSIA0vTSAoRDoyMDAzMTExMjExNDgzMCsxMicwMCcpDS9DIFsgMSAwLjk5 MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoSSB0aGluayB0aGlzIGlzIGFtYmlndW91cywgc2luY2Ug dGhlIGF1dGhlbnRpY2F0aW9uIGhhc24ndCB5ZXQgaGFwcGVuZWQuXA0gKQ0vVCAoZ2dyKQ0vQVAg PDwgL04gMjc3IDEgUiA+PiANL1F1YWRQb2ludHMgWyA3MC4xNzY4IDcyNy45NzU5MSAyMDUuMTM2 NDkgNzI3Ljk3NTkxIDcwLjE3NjggNzE4LjQ4MjU0IDIwNS4xMzY0OSANNzE4LjQ4MjU0IF0gDT4+ IA1lbmRvYmoNMjY5IDEgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1Jl Y3QgWyA3MC4xNzY4IDUyNy45NzU5MSAyNzAuMTc2OCA3MjcuOTc1OTEgXSANL09wZW4gZmFsc2Ug DS9GIDI4IA0vUGFyZW50IDI2OCAxIFIgDT4+IA1lbmRvYmoNMjc2IDEgb2JqDVsgDQ1dDWVuZG9i ag0yNzcgMSBvYmoNPDwgL0xlbmd0aCAxODIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0g L0Zvcm1UeXBlIDEgL0JCb3ggWyA2Ny42NDI0IDcxOC4xODU3MyAyMDcuNjcwOTEgNzI4LjI3Mjcy IF0gDS9NYXRyaXggWyAxIDAgMCAxIC02Ny42NDI0IC03MTguMTg1NzMgXSAvUmVzb3VyY2VzIDw8 IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcK MC41OTMzIHcKNzAuMTc2OCA3MTguNDgyNSBtCjY3LjkzOTIgNzIwLjcyMDIgNjcuOTM5MiA3MjUu NzM4MyA3MC4xNzY4IDcyNy45NzU5IGMKMjA1LjEzNjUgNzI3Ljk3NTkgbAoyMDcuMzc0MSA3MjUu NzM4MyAyMDcuMzc0MSA3MjAuNzIwMiAyMDUuMTM2NSA3MTguNDgyNSBjCnMKZW5kc3RyZWFtDWVu ZG9iag0yNzggMSBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAxMTAuODM0MTcgNTY1LjI3 NTIxIDEzMi4wOTgxMyA1NzUuMzYyMiBdIA0vTk0gKDE5MDAxMTYpDS9GIDQgDS9TdWJ0eXBlIC9I aWdobGlnaHQgDS9Qb3B1cCAyNzkgMSBSIA0vTSAoRDoyMDAzMTExMjExNTAyMysxMicwMCcpDS9D IFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoYSkNL1QgKGdncikNL1AgMzEgMCBSIA0v UXVhZFBvaW50cyBbIDExMy4zNjg1OCA1NzUuMDY1MzggMTI5LjU2MzcxIDU3NS4wNjUzOCAxMTMu MzY4NTggNTY1LjU3MjAyIDEyOS41NjM3MSANNTY1LjU3MjAyIF0gDS9BUCA8PCAvTiAyODEgMSBS ID4+IA0+PiANZW5kb2JqDTI3OSAxIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9w dXAgDS9SZWN0IFsgMTEzLjM2ODU4IDM3NS4wNjUzOCAzMTMuMzY4NTggNTc1LjA2NTM4IF0gDS9P cGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAyNzggMSBSIA0+PiANZW5kb2JqDTI4MCAxIG9iag1b IA0yNzggMSBSIDI3OSAxIFIgMjg1IDEgUiAyODYgMSBSIA1dDWVuZG9iag0yODEgMSBvYmoNPDwg L0xlbmd0aCAxODIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEgL0JC b3ggWyAxMTAuODM0MTcgNTY1LjI3NTIxIDEzMi4wOTgxMyA1NzUuMzYyMiBdIA0vTWF0cml4IFsg MSAwIDAgMSAtMTEwLjgzNDE3IC01NjUuMjc1MjEgXSAvUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsg L1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcKMC41OTMzIHcKMTEz LjM2ODYgNTY1LjU3MiBtCjExMS4xMzEgNTY3LjgwOTYgMTExLjEzMSA1NzIuODI3OCAxMTMuMzY4 NiA1NzUuMDY1NCBjCjEyOS41NjM3IDU3NS4wNjU0IGwKMTMxLjgwMTMgNTcyLjgyNzggMTMxLjgw MTMgNTY3LjgwOTYgMTI5LjU2MzcgNTY1LjU3MiBjCnMKZW5kc3RyZWFtDWVuZG9iag0yODIgMSBv YmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAyMzQuOTkzMTYgNTQ0Ljg3OTIxIDM5MS4yMTk1 NiA1NTQuOTY2MiBdIA0vTk0gKDE5MDAxMWEpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Q b3B1cCAyODMgMSBSIA0vTSAoRDoyMDAzMTExMjExNTIyNSsxMScwMCcpDS9DIFsgMSAwLjk5MiAw LjE3OTk5IF0gDS9Db250ZW50cyAoSG93ZXZlciwfIGFzHyBkaXNjdXNzZWQfIGFib3ZlLCkNL1Qg KGdncikNL0FQIDw8IC9OIDI4NCAxIFIgPj4gDS9RdWFkUG9pbnRzIFsgMjM3LjUyNzU3IDU1NC42 NjkzOSAzODguNjg1MTMgNTU0LjY2OTM5IDIzNy41Mjc1NyA1NDUuMTc2MDMgMzg4LjY4NTEzIA01 NDUuMTc2MDMgXSANPj4gDWVuZG9iag0yODMgMSBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5 cGUgL1BvcHVwIA0vUmVjdCBbIDIzNy41Mjc1NyAzNTQuNjY5MzkgNDM3LjUyNzU3IDU1NC42Njkz OSBdIA0vT3BlbiBmYWxzZSANL0YgMjggDS9QYXJlbnQgMjgyIDEgUiANPj4gDWVuZG9iag0yODQg MSBvYmoNPDwgL0xlbmd0aCAxODAgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1U eXBlIDEgL0JCb3ggWyAyMzQuOTkzMTYgNTQ0Ljg3OTIxIDM5MS4yMTk1NiA1NTQuOTY2MiBdIA0v TWF0cml4IFsgMSAwIDAgMSAtMjM0Ljk5MzE2IC01NDQuODc5MjEgXSAvUmVzb3VyY2VzIDw8IC9Q cm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQgMC4xNzk5OTMgUkcKMC41 OTMzIHcKMjM3LjUyNzYgNTQ1LjE3NiBtCjIzNS4yOSA1NDcuNDEzNiAyMzUuMjkgNTUyLjQzMTgg MjM3LjUyNzYgNTU0LjY2OTQgYwozODguNjg1MSA1NTQuNjY5NCBsCjM5MC45MjI3IDU1Mi40MzE4 IDM5MC45MjI3IDU0Ny40MTM2IDM4OC42ODUxIDU0NS4xNzYgYwpzCmVuZHN0cmVhbQ1lbmRvYmoN Mjg1IDEgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgNTEuNDM3MjkgNDYzLjM1NDY4IDQw NS4wMzY2NCA0ODMuNjM5NjYgXSANL05NICgxOTAwMTFkKQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxp Z2h0IA0vUG9wdXAgMjg2IDEgUiANL00gKEQ6MjAwMzExMTIxMTU1MTArMTInMDAnKQ0vQyBbIDEg MC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKEhtbW0sIHlvdSBkaXNjdXNzIHJlYWxtcyBhYm92 ZSwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhlIGRpc2N1c3Npb24gYXBwbGllc1wNIGhlcmUuIFRoZSBy dWxlcyBmb3IgY29uc3RydWN0aW5nIGEgcmVhbG0gYXJlIGJhc2VkIG9uIHRoZSBJTVNJLCBhbmQg bm90XA0gdGhlIHBzZXVkb255bSwgc28gdGhleSB3b24ndCBoZWxwLCBhbmQgaWYgdGhlIHRlcm1p bmFsIGhhcyBhIGNvbmZpZ3VyZWRcDSByZWFsbSwgaXQgaXNuJ3QgbGlrZWx5IHRvIGJlIHRoZSBj b3JyZWN0IG9uZSBmb3IgdGhlIEVBUCBzZXJ2ZXIgdGhhdCBpc1wNc3VlZCB0aGlzIHBzZXVkb255 bS4gSSB0aGluayBtb3JlIHRob3VnaHQgaXMgbmVlZGVkIGhlcmUuXHJcclNpbWlsYXIgY29tXA1t ZW50IGZvciByZWF1dGguKQ0vVCAoZ2dyKQ0vUCAzMSAwIFIgDS9RdWFkUG9pbnRzIFsgMzc3Ljkw MjcxIDQ4My4zNDI4NSA0MDIuNTAyMjEgNDgzLjM0Mjg1IDM3Ny45MDI3MSA0NzMuODQ5NDkgNDAy LjUwMjIxIA00NzMuODQ5NDkgNTMuOTcxNjkgNDczLjE0NDg1IDE3OC4xNDk4NyA0NzMuMTQ0ODUg NTMuOTcxNjkgNDYzLjY1MTQ5IA0xNzguMTQ5ODcgNDYzLjY1MTQ5IDE1Ni41NTMwMiA0NzMuMTQ0 ODUgMTU5LjQ5NTQ4IDQ3My4xNDQ4NSAxNTYuNTUzMDIgDTQ2My42NTE0OSAxNTkuNDk1NDggNDYz LjY1MTQ5IDE3OC4xNDg5MSA0NzMuMTQ0ODUgMzMyLjMxOTE3IDQ3My4xNDQ4NSANMTc4LjE0ODkx IDQ2My42NTE0OSAzMzIuMzE5MTcgNDYzLjY1MTQ5IF0gDS9BUCA8PCAvTiAyODcgMSBSID4+IA0+ PiANZW5kb2JqDTI4NiAxIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9S ZWN0IFsgMzY1LjcxODczIDIzMi40MjI5NiA1NzMuNzIwMzcgNTE4LjQyNTIyIF0gDS9PcGVuIGZh bHNlIA0vRiAyOCANL1BhcmVudCAyODUgMSBSIA0+PiANZW5kb2JqDTI4NyAxIG9iag08PCAvRmls dGVyIFsgL0ZsYXRlRGVjb2RlIF0gL0xlbmd0aCAyODggMSBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9Gb3JtIA0vRm9ybVR5cGUgMSAvQkJveCBbIDUxLjQzNzI5IDQ2My4zNTQ2OCA0MDUuMDM2 NjQgNDgzLjYzOTY2IF0gL01hdHJpeCBbIDEgMCAwIDEgLTUxLjQzNzI5IC00NjMuMzU0NjggXSAN L1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3RyZWFtDQpIiVSRMY4EMQgE c7/CL0BgwMALNt8vTLobXXDfP+YkG09iWS1Vu1qmjhAxECUvZBHB/f1qCBrM/bexGQQO62IMLqH9 m5nCnEqZTUA36pU4AaFyL84ZWIb3qwkOUByjsk9mAsbhRVay2otbDlf7acoQRvnAZMinbzGlJCWB qeAe1HdguRKN+4ayiUQim8g8rxGVfRo5ArtpgZWs7uKWwG1FOkHvFWVFKsB5HOhOdv3CDi8NyK36 8Jr3ID4GVVLli3t4/dt6PMTy14KIz00r2f2bKzPmkfoxTjNmyQHTi6xktRd3mv0JMACR/31+DWVu ZHN0cmVhbQ1lbmRvYmoNMjg4IDEgb2JqDTIzNSANZW5kb2JqDTI4OSAxIG9iag08PCANL1R5cGUg L0Fubm90IA0vUmVjdCBbIDIwNy45OTkxOSAzNTEuMjM2MTUgMzY0LjIyOTI2IDM2MS4zMjMxNCBd IA0vTk0gKDE5MDAxMjEpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAyOTAgMSBS IA0vTSAoRDoyMDAzMTExMjEyMDExOCsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9D b250ZW50cyAoU291bmRzIHRvIG1lIGxpa2UgdGhlcmUncyBhIGdvb2QgY2FzZSBmb3IgTVVTVCBo ZXJlLikNL1QgKGdncikNL1AgMzQgMCBSIA0vUXVhZFBvaW50cyBbIDIxMC41MzM2IDM2MS4wMjYz MiAzNjEuNjk0ODQgMzYxLjAyNjMyIDIxMC41MzM2IDM1MS41MzI5NiAzNjEuNjk0ODQgDTM1MS41 MzI5NiBdIA0vQVAgPDwgL04gMjkyIDEgUiA+PiANPj4gDWVuZG9iag0yOTAgMSBvYmoNPDwgDS9U eXBlIC9Bbm5vdCANL1N1YnR5cGUgL1BvcHVwIA0vUmVjdCBbIDIxMC41MzM2IDE2MS4wMjYzMiA0 MTAuNTMzNiAzNjEuMDI2MzIgXSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDI4OSAxIFIg DT4+IA1lbmRvYmoNMjkxIDEgb2JqDVsgDTI4OSAxIFIgMjkwIDEgUiANXQ1lbmRvYmoNMjkyIDEg b2JqDTw8IC9MZW5ndGggMTgyIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlw ZSAxIC9CQm94IFsgMjA3Ljk5OTE5IDM1MS4yMzYxNSAzNjQuMjI5MjYgMzYxLjMyMzE0IF0gDS9N YXRyaXggWyAxIDAgMCAxIC0yMDcuOTk5MTkgLTM1MS4yMzYxNSBdIC9SZXNvdXJjZXMgPDwgL1By b2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5 MzMgdwoyMTAuNTMzNiAzNTEuNTMzIG0KMjA4LjI5NiAzNTMuNzcwNiAyMDguMjk2IDM1OC43ODg3 IDIxMC41MzM2IDM2MS4wMjYzIGMKMzYxLjY5NDggMzYxLjAyNjMgbAozNjMuOTMyNCAzNTguNzg4 NyAzNjMuOTMyNCAzNTMuNzcwNiAzNjEuNjk0OCAzNTEuNTMzIGMKcwplbmRzdHJlYW0NZW5kb2Jq DTI5MyAxIG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDc4LjQzMTI0IDM4MS44MzAxNCAx NzUuMjY3OTkgMzkxLjkxNzEzIF0gDS9OTSAoMTkwMDEyNSkNL0YgNCANL1N1YnR5cGUgL0hpZ2hs aWdodCANL1BvcHVwIDI5NCAxIFIgDS9NIChEOjIwMDMxMTEyMTMwMzMxKzEyJzAwJykNL0MgWyAx IDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChJJ20gbm90IGNvbnZpbmNlZCB0aGVyZSdzIGEg Z29vZCBjYXNlIGZvciByZWF1dGhlbnRpY2F0aW9uLiBJdCBjZXJ0YWlubHlcDSBjb21wbGljYXRl cyBsaWZlIGEgbG90LikNL1QgKGdncikNL1AgNjEgMCBSIA0vUXVhZFBvaW50cyBbIDgwLjk2NTY1 IDM5MS42MjAzMiAxNzIuNzMzNTcgMzkxLjYyMDMyIDgwLjk2NTY1IDM4Mi4xMjY5NSAxNzIuNzMz NTcgDTM4Mi4xMjY5NSBdIA0vQVAgPDwgL04gMjk2IDEgUiA+PiANPj4gDWVuZG9iag0yOTQgMSBv YmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL1BvcHVwIA0vUmVjdCBbIDgwLjk2NTY1IDE5 MS42MjAzMiAyODAuOTY1NjUgMzkxLjYyMDMyIF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVu dCAyOTMgMSBSIA0+PiANZW5kb2JqDTI5NSAxIG9iag1bIA0yOTMgMSBSIDI5NCAxIFIgDV0NZW5k b2JqDTI5NiAxIG9iag08PCAvTGVuZ3RoIDE4MCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9y bSAvRm9ybVR5cGUgMSAvQkJveCBbIDc4LjQzMTI0IDM4MS44MzAxNCAxNzUuMjY3OTkgMzkxLjkx NzEzIF0gDS9NYXRyaXggWyAxIDAgMCAxIC03OC40MzEyNCAtMzgxLjgzMDE0IF0gL1Jlc291cmNl cyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3RyZWFtDQoxIDAuOTkyMDA0IDAuMTc5OTkz IFJHCjAuNTkzMyB3CjgwLjk2NTcgMzgyLjEyNyBtCjc4LjcyODEgMzg0LjM2NDYgNzguNzI4MSAz ODkuMzgyNyA4MC45NjU3IDM5MS42MjAzIGMKMTcyLjczMzYgMzkxLjYyMDMgbAoxNzQuOTcxMiAz ODkuMzgyNyAxNzQuOTcxMiAzODQuMzY0NiAxNzIuNzMzNiAzODIuMTI3IGMKcwplbmRzdHJlYW0N ZW5kb2JqDTMzMCAwIG9iag1bIA0zMjggMCBSIDMyOSAwIFIgMzMyIDAgUiAzMzMgMCBSIDIwNCAx IFIgMjA1IDEgUiANXQ1lbmRvYmoNMzM2IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsg MjY1LjcxNzUzIDI1Ny4xMzY2IDI4My43MTc1MyAyNzkuMTM2NiBdIA0vTk0gKDE5MDAxNTApDS9G IDI4IA0vU3VidHlwZSAvVGV4dCANL1BvcHVwIDMzNyAwIFIgDS9NIChEOjIwMDMxMTEyMTMwNjUz KzEyJzAwJykNL0MgWyAxIDEgMC41IF0gDS9UIChnZ3IpDS9QIDY0IDAgUiANL0FQIDw8IC9OIDI0 MSAwIFIgL0QgMjQzIDAgUiA+PiANL0NvbnRlbnRzIChJIHRoaW5rIGl0J3MgYWxzbyB3b3J0aCBz YXlpbmcgdGhhdCBpZiB0aGUgRUFQIHNlcnZlciBkb2VzIG5vdCBpbmNsdWRlIHRcDWhlIEFUX05F WFRfUkVBVVRIX0lELCB0aGUgcGVlciBNVVNUIGRpc2NhcmQgdGhlIGN1cnJlbnQgb25lIFwoYXMg c3BlY2lmaVwNZWQgYWJvdmUsIFJFQVVUSF9JRCBNVVNUIE5PVCBiZSByZXVzZWRcKS4pDT4+IA1l bmRvYmoNMzM3IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9Qb3B1cCANL1JlY3Qg WyAyNjUuNzE3NTMgNzkuMTM2NiA0NjUuNzE3NTMgMjc5LjEzNjYgXSANL09wZW4gZmFsc2UgDS9G IDI4IA0vUGFyZW50IDMzNiAwIFIgDT4+IA1lbmRvYmoNMzM4IDAgb2JqDVsgDTMzNiAwIFIgMzM3 IDAgUiANXQ1lbmRvYmoNMzM5IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgNTEuNDM3 MjkgMjA4LjUyMzU0IDc4LjA5OTMgMjE4LjYxMDUzIF0gDS9OTSAoMTkwMDE1MykNL0YgNCANL1N1 YnR5cGUgL0hpZ2hsaWdodCANL1BvcHVwIDM0MCAwIFIgDS9NIChEOjIwMDMxMTEyMTMxMjA1KzEy JzAwJykNL0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzICg0LjUuNCkNL1QgKGdncikN L1AgODIgMCBSIA0vUXVhZFBvaW50cyBbIDUzLjk3MTY5IDIxOC4zMTM3MiA3NS41NjQ4OCAyMTgu MzEzNzIgNTMuOTcxNjkgMjA4LjgyMDM2IDc1LjU2NDg4IA0yMDguODIwMzYgXSANL0FQIDw8IC9O IDM0MiAwIFIgPj4gDT4+IA1lbmRvYmoNMzQwIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9TdWJ0 eXBlIC9Qb3B1cCANL1JlY3QgWyA1My45NzE2OSAxOC4zMTM3MiAyNTMuOTcxNjkgMjE4LjMxMzcy IF0gDS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAzMzkgMCBSIA0+PiANZW5kb2JqDTM0MSAw IG9iag1bIA0zMzkgMCBSIDM0MCAwIFIgDV0NZW5kb2JqDTM0MiAwIG9iag08PCAvTGVuZ3RoIDE3 NiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDUxLjQz NzI5IDIwOC41MjM1NCA3OC4wOTkzIDIxOC42MTA1MyBdIA0vTWF0cml4IFsgMSAwIDAgMSAtNTEu NDM3MjkgLTIwOC41MjM1NCBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4g DXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwo1My45NzE3IDIwOC44MjA0 IG0KNTEuNzM0MSAyMTEuMDU4IDUxLjczNDEgMjE2LjA3NjEgNTMuOTcxNyAyMTguMzEzNyBjCjc1 LjU2NDkgMjE4LjMxMzcgbAo3Ny44MDI1IDIxNi4wNzYxIDc3LjgwMjUgMjExLjA1OCA3NS41NjQ5 IDIwOC44MjA0IGMKcwplbmRzdHJlYW0NZW5kb2JqDTM0MyAwIG9iag08PCANL1R5cGUgL0Fubm90 IA0vUmVjdCBbIDUxLjQzNzI5IDU1LjYxMjc5IDQ0OC4yMzIwNCAxOTguMjE0NTEgXSANL05NICgx OTAwMTU3KQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMzQ0IDAgUiANL00gKEQ6 MjAwMzExMTIxMzE1MzArMTEnMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMg KEtleR8gZGVyaXZhdGlvbh8gaXMfIGJhc2VkHyBvbh8gdGhlHyByYW5kb20fIG51bWJlch8gZ2Vu ZXJhdGlvbh8gc3BlY2lmaVwNZWQfIGluHyAfXHIfIB8gHyBOSVNUHyBGZWRlcmFsHyBJbmZvcm1h dGlvbh8gUHJvY2Vzc2luZx8gU3RhbmRhcmRzHyBcKEZJXA1QU1wpHyBQdWJsaWNhdGlvbh8gH1xy HyAfIB8gMTg2LTIfIFtQUkZdLh8gVGhlHyBwc2V1ZG8tcmFuZG9tHyBudW1iZXIfIGdcDWVuZXJh dG9yHyBpcx8gc3BlY2lmaWVkHyBpbh8gdGhlHyAfXHIfIB8gHyBjaGFuZ2UfIG5vdGljZR8gMR8g XCgyMDAxHyBPY1wNdG9iZXIfIDVcKR8gb2YfIFtQUkZdHyBcKEFsZ29yaXRobR8gMVwpLh8gQXMf IB9cch8gHyAfIHNwZWNpZmllZB8gaW4fIHRoXA1lHyBjaGFuZ2UfIG5vdGljZR8gXChwYWdlHyA3 NFwpLB8gd2hlbh8gQWxnb3JpdGhtHyAxHyBpcx8gdXNlZB8gH1xyHyAfIB9cDSBhcx8gYR8gZ2Vu ZXJhbC1wdXJwb3NlHyBwc2V1ZG8tcmFuZG9tHyBudW1iZXIfIGdlbmVyYXRvciwfIHRoZR8gIm1v ZB8gcVwNIh8gH1xyHyAfIB8gdGVybR8gaW4fIHN0ZXAfIDMuMx8gaXMfIG9taXR0ZWQuHyBUaGUf IGZ1bmN0aW9uHyBHHyB1c2VkHyBpXA1uHyB0aGUfIGFsZ29yaXRobR8gaXMfIB9cch8gHyAfIGNv bnN0cnVjdGVkHyB2aWEfIFNlY3VyZR8gSGFzaB8gU3RhbmRhcmRcDR8gYXMfIHNwZWNpZmllZB8g aW4fIEFwcGVuZGl4HyAzLjMfIG9mHyAfXHIfIB8gHyB0aGUfIHN0YW5kYXJkLh8gSXQfIHNob1wN dWxkHyBiZR8gbm90ZWQfIHRoYXQfIHRoZR8gZnVuY3Rpb24fIEcfIGlzHyB2ZXJ5HyBzaW1pbGFy HyAfXHIfIB8gHyB0bx8gXA1TSEEtMSwfIGJ1dB8gdGhlHyBtZXNzYWdlHyBwYWRkaW5nHyBpcx8g ZGlmZmVyZW50Lh8gUGxlYXNlHyByZWZlch8gdG8fIB9cDVxyHyAfIB8gW1BSRl0fIGZvch8gZnVs bB8gZGV0YWlscy4fIEZvch8gY29udmVuaWVuY2UsHyB0aGUfIHJhbmRvbR8gbnVtYlwNZXIfIGFs Z29yaXRobR8gH1xyHyAfIB8gd2l0aB8gdGhlHyBjb3JyZWN0HyBtb2RpZmljYXRpb24fIGlzHyBj aXRlZB8gaW4fXA0gQW5uZXgfIEIuHyAfIB9cch8gHyAfIB8gH1xyHyAfIB8gMTYwLWJpdB8gWEtF WR8gYW5kHyBYVkFMHyB2YWx1ZXMfIGFyZR9cDSB1c2VkLB8gc28fIGIfID0fIDE2MC4fIE9uHyBl YWNoHyBmdWxsHyAfKQ0vVCAoZ2dyKQ0vQVAgPDwgL04gMzQ2IDAgUiA+PiANL1F1YWRQb2ludHMg WyA3MC4xNzY4IDE5Ny45MTc2OSAyNjkuOTI3NzggMTk3LjkxNzY5IDcwLjE3NjggMTg4LjQyNDMz IDI2OS45Mjc3OCANMTg4LjQyNDMzIDIzMi4xMzY3NiAxOTcuOTE3NjkgMjM1LjA3OTIyIDE5Ny45 MTc2OSAyMzIuMTM2NzYgMTg4LjQyNDMzIA0yMzUuMDc5MjIgMTg4LjQyNDMzIDI2OS45MjY4MiAx OTcuOTE3NjkgNDQwLjI4NDAxIDE5Ny45MTc2OSAyNjkuOTI2ODIgDTE4OC40MjQzMyA0NDAuMjg0 MDEgMTg4LjQyNDMzIDUzLjk3MTY5IDE4Ny43MTk2OCAzMTMuMTA0OTUgMTg3LjcxOTY4IA01My45 NzE2OSAxNzguMjI2MzIgMzEzLjEwNDk1IDE3OC4yMjYzMiAyNTkuMTE5NzUgMTg3LjcxOTY4IDI2 Mi4wNjIyMSANMTg3LjcxOTY4IDI1OS4xMTk3NSAxNzguMjI2MzIgMjYyLjA2MjIxIDE3OC4yMjYz MiAzMTMuMTAzOTkgMTg3LjcxOTY4IA00MjQuMDc5ODIgMTg3LjcxOTY4IDMxMy4xMDM5OSAxNzgu MjI2MzIgNDI0LjA3OTgyIDE3OC4yMjYzMiA1My45NzE2OSANMTc3LjUyMTY3IDU2LjkxNDE1IDE3 Ny41MjE2NyA1My45NzE2OSAxNjguMDI4MzEgNTYuOTE0MTUgMTY4LjAyODMxIA03MC4xNzY4IDE3 Ny41MjE2NyA5MS43Njk5OSAxNzcuNTIxNjcgNzAuMTc2OCAxNjguMDI4MzEgOTEuNzY5OTkgDTE2 OC4wMjgzMSA2NC43NzUxIDE3Ny41MjE2NyA2Ny43MTc1NiAxNzcuNTIxNjcgNjQuNzc1MSAxNjgu MDI4MzEgDTY3LjcxNzU2IDE2OC4wMjgzMSA1OS4zNzM0IDE3Ny41MjE2NyA2Mi4zMTU4NiAxNzcu NTIxNjcgNTkuMzczNCANMTY4LjAyODMxIDYyLjMxNTg2IDE2OC4wMjgzMSA5MS43NjkwMyAxNzcu NTIxNjcgMjY5LjkyMDQ5IDE3Ny41MjE2NyANOTEuNzY5MDMgMTY4LjAyODMxIDI2OS45MjA0OSAx NjguMDI4MzEgMjMyLjEyOTQ3IDE3Ny41MjE2NyAyMzUuMDcxOTMgDTE3Ny41MjE2NyAyMzIuMTI5 NDcgMTY4LjAyODMxIDIzNS4wNzE5MyAxNjguMDI4MzEgMjY5LjkxOTUzIDE3Ny41MjE2NyANNDMx Ljg4MDYyIDE3Ny41MjE2NyAyNjkuOTE5NTMgMTY4LjAyODMxIDQzMS44ODA2MiAxNjguMDI4MzEg NDEwLjI4Mzc1IA0xNzcuNTIxNjcgNDEzLjIyNjIxIDE3Ny41MjE2NyA0MTAuMjgzNzUgMTY4LjAy ODMxIDQxMy4yMjYyMSAxNjguMDI4MzEgDTQzMS44Nzk2NSAxNzcuNTIxNjcgNDQwLjI4NDEgMTc3 LjUyMTY3IDQzMS44Nzk2NSAxNjguMDI4MzEgNDQwLjI4NDEgDTE2OC4wMjgzMSA1My45NzE2OSAx NjcuMzIzNjUgMTQzLjI5NzY1IDE2Ny4zMjM2NSA1My45NzE2OSAxNTcuODMwMjkgDTE0My4yOTc2 NSAxNTcuODMwMjkgMTU2LjU1NjY3IDE2Ny4zMjM2NSAxNjEuOTU1NjkgMTY3LjMyMzY1IDE1Ni41 NTY2NyANMTU3LjgzMDI5IDE2MS45NTU2OSAxNTcuODMwMjkgMTUxLjE1NDk3IDE2Ny4zMjM2NSAx NTEuMTU1OTMgMTY3LjMyMzY1IA0xNTEuMTU0OTcgMTU3LjgzMDI5IDE1MS4xNTU5MyAxNTcuODMw MjkgMTYxLjk1NDczIDE2Ny4zMjM2NSAyOTEuNTIzNjggDTE2Ny4zMjM2NSAxNjEuOTU0NzMgMTU3 LjgzMDI5IDI5MS41MjM2OCAxNTcuODMwMjkgMjY0LjUzMjQ0IDE2Ny4zMjM2NSANMjY5LjkzMTQ2 IDE2Ny4zMjM2NSAyNjQuNTMyNDQgMTU3LjgzMDI5IDI2OS45MzE0NiAxNTcuODMwMjkgMjkxLjUy MjcyIA0xNjcuMzIzNjUgMzk3LjEwMzIzIDE2Ny4zMjM2NSAyOTEuNTIyNzIgMTU3LjgzMDI5IDM5 Ny4xMDMyMyAxNTcuODMwMjkgDTY0Ljc3NTEgMTU3LjEyNTY0IDY3LjcxNzU2IDE1Ny4xMjU2NCA2 NC43NzUxIDE0Ny42MzIyOCA2Ny43MTc1NiANMTQ3LjYzMjI4IDU5LjM3MzQgMTU3LjEyNTY0IDYy LjMxNTg2IDE1Ny4xMjU2NCA1OS4zNzM0IDE0Ny42MzIyOCANNjIuMzE1ODYgMTQ3LjYzMjI4IDUz Ljk3MTY5IDE1Ny4xMjU2NCA1Ni45MTQxNSAxNTcuMTI1NjQgNTMuOTcxNjkgDTE0Ny42MzIyOCA1 Ni45MTQxNSAxNDcuNjMyMjggNzAuMTc2OCAxNTcuMTI1NjQgMjQyLjkzMzg0IDE1Ny4xMjU2NCAN NzAuMTc2OCAxNDcuNjMyMjggMjQyLjkzMzg0IDE0Ny42MzIyOCAyMzIuMTMzMTIgMTU3LjEyNTY0 IDM3NS40Mzk3MyANMTU3LjEyNTY0IDIzMi4xMzMxMiAxNDcuNjMyMjggMzc1LjQzOTczIDE0Ny42 MzIyOCAzODguNjk4NzkgMTU3LjEyNTY0IA0zOTkuNDk1ODYgMTU3LjEyNTY0IDM4OC42OTg3OSAx NDcuNjMyMjggMzk5LjQ5NTg2IDE0Ny42MzIyOCAzODMuMjk3MDcgDTE1Ny4xMjU2NCAzODMuMjk4 MDMgMTU3LjEyNTY0IDM4My4yOTcwNyAxNDcuNjMyMjggMzgzLjI5ODAzIDE0Ny42MzIyOCANMzk5 LjQ5NDkgMTU3LjEyNTY0IDQzNC44OTQyMSAxNTcuMTI1NjQgMzk5LjQ5NDkgMTQ3LjYzMjI4IDQz NC44OTQyMSANMTQ3LjYzMjI4IDUzLjk3MTY5IDE0Ni45ODcwOCA4MC45NzM4OCAxNDYuOTg3MDgg NTMuOTcxNjkgMTM3LjQ5MzcxIA04MC45NzM4OCAxMzcuNDkzNzEgOTEuNzcyNjcgMTQ2Ljk4NzA4 IDkxLjc3MzY0IDE0Ni45ODcwOCA5MS43NzI2NyANMTM3LjQ5MzcxIDkxLjc3MzY0IDEzNy40OTM3 MSA4MC45NzI5MiAxNDYuOTg3MDggODMuOTE1MzcgMTQ2Ljk4NzA4IA04MC45NzI5MiAxMzcuNDkz NzEgODMuOTE1MzcgMTM3LjQ5MzcxIDk3LjE3NDM4IDE0Ni45ODcwOCAzNzIuNDkwOTcgDTE0Ni45 ODcwOCA5Ny4xNzQzOCAxMzcuNDkzNzEgMzcyLjQ5MDk3IDEzNy40OTM3MSAzNTAuODk0MDcgMTQ2 Ljk4NzA4IA0zNTMuODM2NTMgMTQ2Ljk4NzA4IDM1MC44OTQwNyAxMzcuNDkzNzEgMzUzLjgzNjUz IDEzNy40OTM3MSAzNzIuNDkwMDEgDTE0Ni45ODcwOCA0MjQuMDg2MjYgMTQ2Ljk4NzA4IDM3Mi40 OTAwMSAxMzcuNDkzNzEgNDI0LjA4NjI2IDEzNy40OTM3MSANNTMuOTcxNjkgMTM2Ljc4OTA2IDU2 LjkxNDE1IDEzNi43ODkwNiA1My45NzE2OSAxMjcuMjk1NyA1Ni45MTQxNSANMTI3LjI5NTcgNzAu MTc2OCAxMzYuNzg5MDYgOTEuNzY5OTkgMTM2Ljc4OTA2IDcwLjE3NjggMTI3LjI5NTcgOTEuNzY5 OTkgDTEyNy4yOTU3IDY0Ljc3NTEgMTM2Ljc4OTA2IDY3LjcxNzU2IDEzNi43ODkwNiA2NC43NzUx IDEyNy4yOTU3IDY3LjcxNzU2IA0xMjcuMjk1NyA1OS4zNzM0IDEzNi43ODkwNiA2Mi4zMTU4NiAx MzYuNzg5MDYgNTkuMzczNCAxMjcuMjk1NyA2Mi4zMTU4NiANMTI3LjI5NTcgOTEuNzY5MDMgMTM2 Ljc4OTA2IDIyMS4zNDE2IDEzNi43ODkwNiA5MS43NjkwMyAxMjcuMjk1NyANMjIxLjM0MTYgMTI3 LjI5NTcgMTcyLjc1NDQ5IDEzNi43ODkwNiAxNzUuNjk2OTUgMTM2Ljc4OTA2IDE3Mi43NTQ0OSAN MTI3LjI5NTcgMTc1LjY5Njk1IDEyNy4yOTU3IDIyMS4zNDA2NCAxMzYuNzg5MDYgMzY3LjExMTE1 IDEzNi43ODkwNiANMjIxLjM0MDY0IDEyNy4yOTU3IDM2Ny4xMTExNSAxMjcuMjk1NyAzNDUuNTE0 MjggMTM2Ljc4OTA2IDM0OC40NTY3NCANMTM2Ljc4OTA2IDM0NS41MTQyOCAxMjcuMjk1NyAzNDgu NDU2NzQgMTI3LjI5NTcgMzY3LjExMDE4IDEzNi43ODkwNiANNDQ1LjY5NzYyIDEzNi43ODkwNiAz NjcuMTEwMTggMTI3LjI5NTcgNDQ1LjY5NzYyIDEyNy4yOTU3IDUzLjk3MTY5IA0xMjYuNTkxMDUg MTUxLjE1MjI4IDEyNi41OTEwNSA1My45NzE2OSAxMTcuMDk3NjkgMTUxLjE1MjI4IDExNy4wOTc2 OSANMTI5LjU1NTQyIDEyNi41OTEwNSAxMzIuNDk3ODggMTI2LjU5MTA1IDEyOS41NTU0MiAxMTcu MDk3NjkgMTMyLjQ5Nzg4IA0xMTcuMDk3NjkgMTUxLjE1MTMyIDEyNi41OTEwNSAzMzQuNzA0NTMg MTI2LjU5MTA1IDE1MS4xNTEzMiAxMTcuMDk3NjkgDTMzNC43MDQ1MyAxMTcuMDk3NjkgMjgwLjcx OTMzIDEyNi41OTEwNSAyODMuNjYxNzkgMTI2LjU5MTA1IDI4MC43MTkzMyANMTE3LjA5NzY5IDI4 My42NjE3OSAxMTcuMDk3NjkgMzM0LjcwMzU3IDEyNi41OTEwNSA0NDUuNjg2NjkgMTI2LjU5MTA1 IA0zMzQuNzAzNTcgMTE3LjA5NzY5IDQ0NS42ODY2OSAxMTcuMDk3NjkgNTkuMzczNCAxMTYuMzkz MDQgNjIuMzE1ODYgDTExNi4zOTMwNCA1OS4zNzM0IDEwNi44OTk2NyA2Mi4zMTU4NiAxMDYuODk5 NjcgNTMuOTcxNjkgMTE2LjM5MzA0IA0yMTAuNTQxODUgMTE2LjM5MzA0IDUzLjk3MTY5IDEwNi44 OTk2NyAyMTAuNTQxODUgMTA2Ljg5OTY3IDE5NC4zNDMwNiANMTE2LjM5MzA0IDE5Ny4yODU1MiAx MTYuMzkzMDQgMTk0LjM0MzA2IDEwNi44OTk2NyAxOTcuMjg1NTIgMTA2Ljg5OTY3IA0yMTAuNTQw ODkgMTE2LjM5MzA0IDM0My4wNTEzNSAxMTYuMzkzMDQgMjEwLjU0MDg5IDEwNi44OTk2NyAzNDMu MDUxMzUgDTEwNi44OTk2NyAzNTYuMzEwMzkgMTE2LjM5MzA0IDM2Ny4xMDc0NyAxMTYuMzkzMDQg MzU2LjMxMDM5IDEwNi44OTk2NyANMzY3LjEwNzQ3IDEwNi44OTk2NyAzNTAuOTA4NjggMTE2LjM5 MzA0IDM1MC45MDk2NCAxMTYuMzkzMDQgMzUwLjkwODY4IA0xMDYuODk5NjcgMzUwLjkwOTY0IDEw Ni44OTk2NyAzNjcuMTA2NTEgMTE2LjM5MzA0IDQ0NS42OTM5OCAxMTYuMzkzMDQgDTM2Ny4xMDY1 MSAxMDYuODk5NjcgNDQ1LjY5Mzk4IDEwNi44OTk2NyA1My45NzE2OSAxMDYuMTk1MDIgODAuOTcz ODggDTEwNi4xOTUwMiA1My45NzE2OSA5Ni43MDE2NiA4MC45NzM4OCA5Ni43MDE2NiA2NC43NzUx IDEwNi4xOTUwMiANNjcuNzE3NTYgMTA2LjE5NTAyIDY0Ljc3NTEgOTYuNzAxNjYgNjcuNzE3NTYg OTYuNzAxNjYgODAuOTcyOTIgMTA2LjE5NTAyIA0yNDguMzMxOTEgMTA2LjE5NTAyIDgwLjk3Mjky IDk2LjcwMTY2IDI0OC4zMzE5MSA5Ni43MDE2NiAyMDUuMTQyODQgDTEwNi4xOTUwMiAyMDguMDg1 MyAxMDYuMTk1MDIgMjA1LjE0Mjg0IDk2LjcwMTY2IDIwOC4wODUzIDk2LjcwMTY2IA0yNDguMzMw OTUgMTA2LjE5NTAyIDQxMy4yMzM0NCAxMDYuMTk1MDIgMjQ4LjMzMDk1IDk2LjcwMTY2IDQxMy4y MzM0NCANOTYuNzAxNjYgNTMuOTcxNjkgOTUuOTk3MDEgMTk0LjM0NDAyIDk1Ljk5NzAxIDUzLjk3 MTY5IDg2LjUwMzY1IA0xOTQuMzQ0MDIgODYuNTAzNjUgMTQ1Ljc1NjkgOTUuOTk3MDEgMTQ4LjY5 OTM2IDk1Ljk5NzAxIDE0NS43NTY5IA04Ni41MDM2NSAxNDguNjk5MzYgODYuNTAzNjUgMTk0LjM0 MzA2IDk1Ljk5NzAxIDM4My4yOTQzNiA5NS45OTcwMSANMTk0LjM0MzA2IDg2LjUwMzY1IDM4My4y OTQzNiA4Ni41MDM2NSAzNDUuNTAzMzMgOTUuOTk3MDEgMzQ4LjQ0NTc5IA05NS45OTcwMSAzNDUu NTAzMzMgODYuNTAzNjUgMzQ4LjQ0NTc5IDg2LjUwMzY1IDM4My4yOTM0IDk1Ljk5NzAxIA00NDUu NjgzMDMgOTUuOTk3MDEgMzgzLjI5MzQgODYuNTAzNjUgNDQ1LjY4MzAzIDg2LjUwMzY1IDUzLjk3 MTY5IA04NS43OTkgMTU2LjU1Mzk3IDg1Ljc5OSA1My45NzE2OSA3Ni4zMDU2MyAxNTYuNTUzOTcg NzYuMzA1NjMgMTEzLjM2NDkgDTg1Ljc5OSAxMTYuMzA3MzYgODUuNzk5IDExMy4zNjQ5IDc2LjMw NTYzIDExNi4zMDczNiA3Ni4zMDU2MyAxNTYuNTUzMDEgDTg1Ljc5OSAzMjMuOTEyMDUgODUuNzk5 IDE1Ni41NTMwMSA3Ni4zMDU2MyAzMjMuOTEyMDUgNzYuMzA1NjMgMjkxLjUxOTA3IA04NS43OTkg Mjk0LjQ2MTUzIDg1Ljc5OSAyOTEuNTE5MDcgNzYuMzA1NjMgMjk0LjQ2MTUzIDc2LjMwNTYzIDMy My45MTEwOSANODUuNzk5IDM1My45MTUwOCA4NS43OTkgMzIzLjkxMTA5IDc2LjMwNTYzIDM1My45 MTUwOCA3Ni4zMDU2MyA1My45NzE2OSANNzUuNjAwOTggNzguNTIxMTUgNzUuNjAwOTggNTMuOTcx NjkgNjYuMTA3NjIgNzguNTIxMTUgNjYuMTA3NjIgNTkuMzczNCANNjUuNDAyOTcgNjIuMzE1ODYg NjUuNDAyOTcgNTkuMzczNCA1NS45MDk2MSA2Mi4zMTU4NiA1NS45MDk2MSA1My45NzE2OSANNjUu NDAyOTcgMjIxLjMzNzk3IDY1LjQwMjk3IDUzLjk3MTY5IDU1LjkwOTYxIDIyMS4zMzc5NyA1NS45 MDk2MSANMTgzLjU0Njk3IDY1LjQwMjk3IDE4Ni40ODk0MyA2NS40MDI5NyAxODMuNTQ2OTcgNTUu OTA5NjEgMTg2LjQ4OTQzIA01NS45MDk2MSAyMjEuMzM3MDEgNjUuNDAyOTcgMzAyLjMyMzQ5IDY1 LjQwMjk3IDIyMS4zMzcwMSA1NS45MDk2MSANMzAyLjMyMzQ5IDU1LjkwOTYxIDMxMy4xMjIzIDY1 LjQwMjk3IDMxMy4xMjMyNiA2NS40MDI5NyAzMTMuMTIyMyANNTUuOTA5NjEgMzEzLjEyMzI2IDU1 LjkwOTYxIDMwMi4zMjI1MyA2NS40MDI5NyAzMDUuMjY0OTggNjUuNDAyOTcgDTMwMi4zMjI1MyA1 NS45MDk2MSAzMDUuMjY0OTggNTUuOTA5NjEgMzE4LjUyNDAyIDY1LjQwMjk3IDQxOC43MDY0NyAN NjUuNDAyOTcgMzE4LjUyNDAyIDU1LjkwOTYxIDQxOC43MDY0NyA1NS45MDk2MSBdIA0+PiANZW5k b2JqDTM0NCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9SZWN0IFsg NzAuMTc2OCAtMi4wODIzMSAyNzAuMTc2OCAxOTcuOTE3NjkgXSANL09wZW4gZmFsc2UgDS9GIDI4 IA0vUGFyZW50IDM0MyAwIFIgDT4+IA1lbmRvYmoNMzQ1IDAgb2JqDVsgDQ1dDWVuZG9iag0zNDYg MCBvYmoNPDwgL0ZpbHRlciBbIC9GbGF0ZURlY29kZSBdIC9MZW5ndGggMzQ3IDAgUiAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvRm9ybSANL0Zvcm1UeXBlIDEgL0JCb3ggWyA1MS40MzcyOSA1NS42 MTI3OSA0NDguMjMyMDQgMTk4LjIxNDUxIF0gL01hdHJpeCBbIDEgMCAwIDEgLTUxLjQzNzI5IC01 NS42MTI3OSBdIA0vUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0N CkiJbJc9tmQnDITzXkWv4B5A/K7Aubcw6XPkwNt3iYukYs5M9LqmS/0BQhL5m561SkoVf+Sx1pLv 33990tOWyPe/z1C1z2+e86mlyvefTx/PklW+eaWn97y+IbSnz5S/blr4nzzG99en9PWsMkj7+ZRR ntxbDSMpJ3b4DODX599PEXxPbqxS1jMXc5Fi8d1HZNKeNPa3gkzGI3l/z52uWHT3XWSb9zcybFCf F1koFt99QVZresqsDFZreVrJPYyknOBuY64mzxp5fPOYTyldsVp+htSM76WndlnfENpTZ8lfN83x DFAgkmR5cqortB9o7ZFaehhJObHDZwB7t9p6cl6TsUrrz5ylhJeUEz98QVZ6eVLf33Ky0utT1v6e OUOx6O5jssPLYJLTM3uvvChXfOHHFlw4As2TyVzYGmTTICMpJ3j4mMuPpM8nlXmdI65d6Y3OcTRN BDrHMTRXlApbunItIf18dE9bnmRzwQKbyX5cifyyB5EXBDOGcEK7KYgWqAfzLKw/jR6mEE7YY2Ea HO8YLV80uCAyGtG4cAK7KWi6ntX+LefRG9oaLSKEWOZrYiLsouA4rhMbqEKNN9aF2PrXREQFCdLW RVSf1uReyBFiqa+JiXTb+mKgubAjuYYvBNv74wmet2KlxkC7frdJqUfKCR0+ZtqVuazGVG/9zou8 oVh89xHZrsz52qpdv9Nq7HTForvvIlPe/BvZrt8XWSgW331BViWjkqUrrapU1LJJeUXKiR4+JqtZ C71cV68m/Fk7e0Ox+O4jMhQuFJmrIFRUcZSiyU5XLLr7LjLlHesqUxVn12uhTCDFV24+InvbWb7I 3qY3yBmKRXffdRutFOLKTUlX/ewJjWBQ/ezIh9mpfuKQBXmDSLli3WuQ9gOt4dY0CSMpJ3b4DECp Mipra/3Cyq3i7i7iIsXiu4/IetaydJOhMGQd6MIZikV3302WcX/bBVanjiOVF+WKgx0bcb3Suriw s7K0YIXRFV+1+S6uTVt/27Gl9ffaMVd83eYLsoLi1vRPIitLUPAy7RgpJ3r4mEwnjCalMpnOGGXV Sd5QLL77iExrCAr4RbZnZM4CUjy6+S6yzVuuPSuo9GU29obiKzdfkAlm0pykMJksdC2Um3CScqKH j8m8AVdUUUTjrl1R8vuiro1bMOeMpq3NEyMiN22TqGmbyz57WPPYT189O3i8RZvRhRPZPcRj3Zd4 rEPHKt7PtMzXc/FYASIeK1LOY4LxUKU7PD6/BY/PeLGK97OHNQ/z+PhG52UjHm3sK5zI7gmegqKN GjQZqKBk4sZW94VgkcPGTO/bTq4keueFRtsbioV3W3AhzZ4qazCXoPv0McSNIVjssDGX4BnW17w2 S2ZHH820W6FYeLcRF65TXXdC1aTnThkVgsd22821O1G+ufKT2mKvK85lNuLa2nWMMnfn6+QzIUIf 10W1Weu6qFAzSrt22hWL7rag0jFqrjvdq+itpXwPwWKH7Y83EN+vC+WObqCgyeDhFzewojRhw+MK VlyiiT379cHrbg1ZIf18dBuy1mqzuWCB3WQ/blP8KBfRntobEblgod0URFuSzkT60Mo7O81mggV2 ExNtzLKYCE/XsecfM7rgizUT7RG2Dedz7VFHWWLX+ewLNcu1QzjaUSvzYCFLtAj5QkzwpZopeAT9 tWp7DR4Z+HqZPXyhWGi3MZO0pNmVGUowPvXW6cBD8fDuIy7k15T9rQBDvU6DkzAUj+6+i2zjXlw6 SjedSGJJpsSyX1dQ1VK1+QtT1dJ1SFjhC8Vih4+p/AoV3PjVrntXNLuF7p1oM81076Q/A+9Fbn0m Uetzmwke2Ez241fvCyJvdWZ0wUK7KYj2FWIevWRJJxEzuWBhj4VpfAoiGhuUnMYEC+ymoPExKHh8 VHKbCbTM18REPgfRidmo5BtrAm39ayIiG4SIyIYlWsgr0FJfExPptvXFQLsu6khhPhd8748neErJ mGXztUWlyNMGH3QoFjp8zJRxb0arjan06dryJj3eUCx++IIsY+7oq19blYemYO3sNCWim4/JXt7U mazkpVM7LcqEWLe5gkuQHxn/mEu6vggmHX0oFjx8zCWYA1uuwlxS0SpHH+R1xeO7j8hQX2vr1/XT CttXpRwIJaKb7yLbvKlcZEjNOUrnVZkSKzdfkNWqZ3JfxFr15PgmhmLRw3fdRSuEeTxpjat64gRF O3GU0/qIXqYouf1pb4LhOxkvXZeQX/iWzLXCFopFDpv9/M58RW7aqwNKoSWPSV5XPL77gku0+YzF XNgiDBiNfK54bLddXJs2y8WF817oR+R1JdZtPucS/cm0L7dxCY4TQyVtcygWO2zMVTAhjbwuroIx qs5MXKFY/PA5V8GY1PvucMZVMJbj0Cr7TPHYbmOul1ZnwOAS3dneeUlHiFWby6l26s4+iGrnd9l3 /fhCsdBhYypvJKnrKq7uk1Cz8J/RfXLFySGj3JQxlCzh5nMU6j1mcsHCusd++rqBxGMXznn8ShqP X1vjKRmNoGYGKhmdYCwiCsUih42ZMgYL1MnMUHkVFPRG3lAsfvicK+tDbO4vGVfGUwyXPrPPlIht NuZ6adNirpLmI0mbla/JlVi3+ZxL20B6L7NxaR8oc4XNBYscJqbS+VlyulJK8HpMmPbJ64qHd19Q acFPg3fr7X6NdisUj+22mwsvpzSv1NrvhpHZ60pwmS+4trQ6cyEHcx2FfabEms12cW3a3i4u7X39 2mtXYt3mc663qVXCehufDlNmC8VCu+tP93Chq6bM13BNndXpFiZ8tQ26hYiTcat+vQ9cWa786FO1 ZB2uzGSCRTWL/S7P7MFiE7q5fGK3sD6xO4vP3s7i47mbjuBRj4VZNl9ZxIJGMrS+mss+xxKPJVgK kkwk88YU5Ebri5bgigV2F/OU1JBluEcBVFJBmtE6XIjY5iImlIk0mzAT6oSUTW4+UyL0cV1MGzTx JhW8bROmaVrMESK2uYKpZmSHnO70MtXcnvre2ONzxUK7i5ksOSdaprbTyOeJ84LF83kJHgwr0nm1 570UbzmvJmjlRrCJq2QWFyymWexXdzfBdRs4WELBtI2RW7PffCZ4ZDMFjRYqHTsCR8sLJi33nM8R 9DguGutRRGONLFZxhFjnMTmN6D1evDmCsahJcY99tqDuYJr99tBeFTT7gdJbLMMFj2ymoNFnR8XE EjT6NJmaE2YyIcIez8WzIaUyz8xoevo9X8gRYqXH5Dzv6CWB805nKTLHBYtqFqaxjByo7qlxDqPm tIrN9ZxG+vQcOYy9H3hp6MsE8dAFjqBJgx9cmrLH4oLFNIv96s4aXDF0pEUoeH8+eIRI+EzwyGYK Gu1TaTBOVncjz/s5gh7HRbMJhWEwXWC2rLSII8QyX4+zSMFe5RIoguk649njFhcsqFmYpaysNzcT DGYmzE05FuGCRXaT0+Bm4B2gXzGcgtqC25vJdAQPax7meRkz80jJGHGk0TqOECs9ptgdzSS82mh7 sIF4rNL2mOBhzcM8lpG964jGOdynjnGRw0OzRSKHBy5E0vePxi+6olf40Z482pzusM8W0Qz2m/zu ae0dyeLZg/zfY5t97v9TXUZJEIMgDL3Rjgq19v4X21gJpJ/NTNgHugIY46YsPRPtpunOE0KtPHTw mxFp4G9qPYQj8k8O1occrCA5Bo7PbBXHwPFd6BZpSYExaVGSvg/SlaTjZUND9rSlwMD0JEvHe+Xr 8YLp+0XDrSjL+a6Y4VCWw6csA2tse4QlhUryeJLFMPbgJl/FYs33Xa1apsCo6VEaw8PVUUPBwaLy W8srjRQyNE3F8ypmwoPRxSZGnjKFUGHD8+F5IcelPK1hDnMxUqhUwyT1uXYj1fLcaDZjiieEinos 3+rsv5d/ijPxvk2XLEKoPI8nWRzC3RTGB6YXl3ufAqOmR2n+AgwAG9XmHg1lbmRzdHJlYW0NZW5k b2JqDTM0NyAwIG9iag0yOTQ5IA1lbmRvYmoNMzQ4IDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9S ZWN0IFsgMjI5LjU5ODcxIDc2LjAwODgyIDM0Mi42NDQzIDg2LjA5NTgxIF0gDS9OTSAoMTkwMDE1 YykNL0YgNCANL1N1YnR5cGUgL0hpZ2hsaWdodCANL1BvcHVwIDM0OSAwIFIgDS9NIChEOjIwMDMx MTEyMTMxODI4KzEyJzAwJykNL0MgWyAxIDAuOTkyIDAuMTc5OTkgXSANL0NvbnRlbnRzIChJJ20g bm90IHN1cmUgaXQncyB3b3J0aCBpbmNsdWRpbmcgdGhpcywgaXQgc3RpbGwgY2FuJ3QgYmUgdW5k ZXJzdG9vZCB3aXRcDWhvdXQgcmVmZXJyaW5nIHRvIHRoZSBGSVBTLikNL1QgKGdncikNL1AgODUg MCBSIA0vUXVhZFBvaW50cyBbIDIzMi4xMzMxMiA4NS43OTkgMzQwLjEwOTg4IDg1Ljc5OSAyMzIu MTMzMTIgNzYuMzA1NjMgMzQwLjEwOTg4IDc2LjMwNTYzIA1dIA0vQVAgPDwgL04gMzUxIDAgUiA+ PiANPj4gDWVuZG9iag0zNDkgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL1BvcHVw IA0vUmVjdCBbIDIzMi4xMzMxMiAtMTE0LjIwMSA0MzIuMTMzMTIgODUuNzk5IF0gDS9PcGVuIGZh bHNlIA0vRiAyOCANL1BhcmVudCAzNDggMCBSIA0+PiANZW5kb2JqDTM1MCAwIG9iag1bIA0zNDgg MCBSIDM0OSAwIFIgDV0NZW5kb2JqDTM1MSAwIG9iag08PCAvTGVuZ3RoIDE3NiAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDIyOS41OTg3MSA3Ni4wMDg4 MiAzNDIuNjQ0MyA4Ni4wOTU4MSBdIA0vTWF0cml4IFsgMSAwIDAgMSAtMjI5LjU5ODcxIC03Ni4w MDg4MiBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAw Ljk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwoyMzIuMTMzMSA3Ni4zMDU2IG0KMjI5Ljg5NTUg NzguNTQzMiAyMjkuODk1NSA4My41NjE0IDIzMi4xMzMxIDg1Ljc5OSBjCjM0MC4xMDk5IDg1Ljc5 OSBsCjM0Mi4zNDc1IDgzLjU2MTQgMzQyLjM0NzUgNzguNTQzMiAzNDAuMTA5OSA3Ni4zMDU2IGMK cwplbmRzdHJlYW0NZW5kb2JqDTM1MiAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vUmVjdCBbIDY3 LjY0MjQgNTk1Ljg2OTIgODMuNTA4MyA2MDUuOTU2MTkgXSANL05NICgxOTAwMTYwKQ0vRiA0IA0v U3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMzUzIDAgUiANL00gKEQ6MjAwMzExMTIxMzI3Mjkr MTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKGF0KQ0vVCAoZ2dyKQ0v UCAxMTIgMCBSIA0vUXVhZFBvaW50cyBbIDcwLjE3NjggNjA1LjY1OTM4IDgwLjk3Mzg4IDYwNS42 NTkzOCA3MC4xNzY4IDU5Ni4xNjYwMiA4MC45NzM4OCA1OTYuMTY2MDIgDV0gDS9BUCA8PCAvTiAz NTUgMCBSID4+IA0+PiANZW5kb2JqDTM1MyAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlw ZSAvUG9wdXAgDS9SZWN0IFsgNzAuMTc2OCA0MDUuNjU5MzggMjcwLjE3NjggNjA1LjY1OTM4IF0g DS9PcGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAzNTIgMCBSIA0+PiANZW5kb2JqDTM1NCAwIG9i ag1bIA0zNTIgMCBSIDM1MyAwIFIgMzgwIDAgUiAzODEgMCBSIA1dDWVuZG9iag0zNTUgMCBvYmoN PDwgL0xlbmd0aCAxNzYgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zvcm0gL0Zvcm1UeXBlIDEg L0JCb3ggWyA2Ny42NDI0IDU5NS44NjkyIDgzLjUwODMgNjA1Ljk1NjE5IF0gDS9NYXRyaXggWyAx IDAgMCAxIC02Ny42NDI0IC01OTUuODY5MiBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERG IF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwo3MC4xNzY4 IDU5Ni4xNjYgbQo2Ny45MzkyIDU5OC40MDM2IDY3LjkzOTIgNjAzLjQyMTggNzAuMTc2OCA2MDUu NjU5NCBjCjgwLjk3MzkgNjA1LjY1OTQgbAo4My4yMTE1IDYwMy40MjE4IDgzLjIxMTUgNTk4LjQw MzYgODAuOTczOSA1OTYuMTY2IGMKcwplbmRzdHJlYW0NZW5kb2JqDTM1NiAwIG9iag08PCANL1R5 cGUgL0Fubm90IA0vUmVjdCBbIDEzMi40MjY0NyAyMzkuMTE3NTggMTk2Ljg4MjE5IDI0OS4yMDQ1 NyBdIA0vTk0gKDE5MDAxNjQpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAzNTcg MCBSIA0vTSAoRDoyMDAzMTExMjEzMzE1NisxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0g DS9Db250ZW50cyAoXChuIGNhbiBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBhdHRyaWJ1dGUgbGVuZ3Ro XCkpDS9UIChnZ3IpDS9QIDEyNCAwIFIgDS9RdWFkUG9pbnRzIFsgMTM0Ljk2MDg4IDI0OC45MDc3 NiAxOTQuMzQ3NzYgMjQ4LjkwNzc2IDEzNC45NjA4OCAyMzkuNDE0NCAxOTQuMzQ3NzYgDTIzOS40 MTQ0IF0gDS9BUCA8PCAvTiAzNTkgMCBSID4+IA0+PiANZW5kb2JqDTM1NyAwIG9iag08PCANL1R5 cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9SZWN0IFsgMTM0Ljk2MDg4IDQ4LjkwNzc2IDMz NC45NjA4OCAyNDguOTA3NzYgXSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDM1NiAwIFIg DT4+IA1lbmRvYmoNMzU4IDAgb2JqDVsgDTM1NiAwIFIgMzU3IDAgUiANXQ1lbmRvYmoNMzU5IDAg b2JqDTw8IC9MZW5ndGggMTg0IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlw ZSAxIC9CQm94IFsgMTMyLjQyNjQ3IDIzOS4xMTc1OCAxOTYuODgyMTkgMjQ5LjIwNDU3IF0gDS9N YXRyaXggWyAxIDAgMCAxIC0xMzIuNDI2NDcgLTIzOS4xMTc1OCBdIC9SZXNvdXJjZXMgPDwgL1By b2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5 MzMgdwoxMzQuOTYwOSAyMzkuNDE0NCBtCjEzMi43MjMzIDI0MS42NTIgMTMyLjcyMzMgMjQ2LjY3 MDIgMTM0Ljk2MDkgMjQ4LjkwNzggYwoxOTQuMzQ3OCAyNDguOTA3OCBsCjE5Ni41ODU0IDI0Ni42 NzAyIDE5Ni41ODU0IDI0MS42NTIgMTk0LjM0NzggMjM5LjQxNDQgYwpzCmVuZHN0cmVhbQ1lbmRv YmoNMzYwIDAgb2JqDTw8IA0vVHlwZSAvQW5ub3QgDS9SZWN0IFsgODMuODMyMjYgMTQ3LjMzNTQ2 IDQxNS44MjE1MiAxNTcuNDIyNDUgXSANL05NICgxOTAwMTY4KQ0vRiA0IA0vU3VidHlwZSAvSGln aGxpZ2h0IA0vUG9wdXAgMzYxIDAgUiANL00gKEQ6MjAwMzExMTIxMzMzMjUrMTInMDAnKQ0vQyBb IDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKEkgZG9uJ3QgdGhpbmsgdGhpcyBzaG91bGQg YmUgaGVyZS4pDS9UIChnZ3IpDS9QIDEzMCAwIFIgDS9RdWFkUG9pbnRzIFsgODYuMzY2NjcgMTU3 LjEyNTY0IDIwMi42ODQwMSAxNTcuMTI1NjQgODYuMzY2NjcgMTQ3LjYzMjI4IDIwMi42ODQwMSAN MTQ3LjYzMjI4IDIxNS45NDMwMiAxNTcuMTI1NjQgMjIxLjM0MjA0IDE1Ny4xMjU2NCAyMTUuOTQz MDIgMTQ3LjYzMjI4IA0yMjEuMzQyMDQgMTQ3LjYzMjI4IDIxMC41NDEzMiAxNTcuMTI1NjQgMjEw LjU0MjI4IDE1Ny4xMjU2NCAyMTAuNTQxMzIgDTE0Ny42MzIyOCAyMTAuNTQyMjggMTQ3LjYzMjI4 IDIyMS4zNDQyNCAxNTcuMTI1NjQgMjYyLjA5NTM4IDE1Ny4xMjU2NCANMjIxLjM0NDI0IDE0Ny42 MzIyOCAyNjIuMDk1MzggMTQ3LjYzMjI4IDI3NS4zNTgxNyAxNTcuMTI1NjQgMjc4LjMwMDYzIA0x NTcuMTI1NjQgMjc1LjM1ODE3IDE0Ny42MzIyOCAyNzguMzAwNjMgMTQ3LjYzMjI4IDI2OS45NTY0 MiAxNTcuMTI1NjQgDTI3Mi44OTg4OCAxNTcuMTI1NjQgMjY5Ljk1NjQyIDE0Ny42MzIyOCAyNzIu ODk4ODggMTQ3LjYzMjI4IDI2NC41NTQ2NyANMTU3LjEyNTY0IDI2Ny40OTcxMyAxNTcuMTI1NjQg MjY0LjU1NDY3IDE0Ny42MzIyOCAyNjcuNDk3MTMgMTQ3LjYzMjI4IA0yODAuNzU5OTIgMTU3LjEy NTY0IDM0OC40NjYxMSAxNTcuMTI1NjQgMjgwLjc1OTkyIDE0Ny42MzIyOCAzNDguNDY2MTEgDTE0 Ny42MzIyOCAzNjEuNzI4OSAxNTcuMTI1NjQgMzY0LjY3MTM2IDE1Ny4xMjU2NCAzNjEuNzI4OSAx NDcuNjMyMjggDTM2NC42NzEzNiAxNDcuNjMyMjggMzU2LjMyNzE1IDE1Ny4xMjU2NCAzNTkuMjY5 NjEgMTU3LjEyNTY0IDM1Ni4zMjcxNSANMTQ3LjYzMjI4IDM1OS4yNjk2MSAxNDcuNjMyMjggMzUw LjkyNTQgMTU3LjEyNTY0IDM1My44Njc4NiAxNTcuMTI1NjQgDTM1MC45MjU0IDE0Ny42MzIyOCAz NTMuODY3ODYgMTQ3LjYzMjI4IDM2Ny4xMzA2NSAxNTcuMTI1NjQgNDEzLjI4NzA5IA0xNTcuMTI1 NjQgMzY3LjEzMDY1IDE0Ny42MzIyOCA0MTMuMjg3MDkgMTQ3LjYzMjI4IF0gDS9BUCA8PCAvTiAz NjMgMCBSID4+IA0+PiANZW5kb2JqDTM2MSAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlw ZSAvUG9wdXAgDS9SZWN0IFsgODYuMzY2NjcgLTQyLjg3NDM2IDI4Ni4zNjY2NyAxNTcuMTI1NjQg XSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDM2MCAwIFIgDT4+IA1lbmRvYmoNMzYyIDAg b2JqDVsgDTM2MCAwIFIgMzYxIDAgUiANXQ1lbmRvYmoNMzYzIDAgb2JqDTw8IC9GaWx0ZXIgWyAv RmxhdGVEZWNvZGUgXSAvTGVuZ3RoIDM2NCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0Zv cm0gDS9Gb3JtVHlwZSAxIC9CQm94IFsgODMuODMyMjYgMTQ3LjMzNTQ2IDQxNS44MjE1MiAxNTcu NDIyNDUgXSAvTWF0cml4IFsgMSAwIDAgMSAtODMuODMyMjYgLTE0Ny4zMzU0NiBdIA0vUmVzb3Vy Y2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCkiJVJUxmhsxCEZ7n2JOwCeB AHGC9LnCttkqRa4fbC0IOs9vPfyA8cx8BpjhGMs/TDUzen7/eg1gI3r+vbYAiegzl4IQ0vP92gsm 2vTIYIvZkwEv2Hs/ybD6FyzP1wsHgux1oz8eLTCcktgNonBS8eNfr78vnAy2qBrhJNDBq5CZRPGg ihNOoIXNCQlYTS+WQVYOqjv5wNbsUmMDDapoJikVWLH6ZEhNayKo76aAEdyGA2teH9lq+x6WwRxS x5xJdh1Y8RKEYdxXKAuI6HJxnZUTalbKQLy7lZJXHdUqk6ieWLHS90g/h67V9lHQ59wPmMGtHVjz EgNjWc1LFHR6kdJTJNl1YNULYdu25uX+k4RbQye4XoF1rwXMS7sXAk2dfdYnKds4WN2iwrLPobJF A6WlraET1J4P1rx8rspmfY8bGJH6rE9S1nGw60VrwxJpXsR+rv5dbhC1L1a9SCYo7uZFbN7BLF43 ifKJFS+foehsd70/28CGFe7nOisn1KzYH4tYZ/i2WjC2SbWKJJsOrFi5ui9JutUEHoqtnRPUjg/W vfwNgNzu+vdcZevukz5JWcbBqhf5abW+RfGHC3Nr6ATXK7C+Ra9B9T/6/VnHNpp91ifJtgO7Xv6I Bdz9rl/+QmAsd/0NovbFqtd/AQYAUN1oZw1lbmRzdHJlYW0NZW5kb2JqDTM2NCAwIG9iag00OTgg DWVuZG9iag0zNjUgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAyNjEuOTk0NCA2NTcu MDU3MTkgMzEwLjI0ODY0IDY2Ny4xNDQxOCBdIA0vTk0gKDE5MDAxNmQpDS9GIDQgDS9TdWJ0eXBl IC9IaWdobGlnaHQgDS9Qb3B1cCAzNjYgMCBSIA0vTSAoRDoyMDAzMTExMjEzMzUxMisxMicwMCcp DS9DIFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAocmVzZXJ2ZWQgYnkgTm9raWFcclxy U2hvdWxkIHlvdSBoYXZlIGEgc3RhdGVtZW50IGhlcmUgYWJvdXQgZnV0dXJlIHN1cHBvXA1ydCBv ciBpbnRlbnRpb25zIHcuci50LiB0aGlzIGRvbWFpbiBuYW1lPykNL1QgKGdncikNL1AgMTM2IDAg UiANL1F1YWRQb2ludHMgWyAyNjQuNTI4ODEgNjY2Ljg0NzM3IDMwNy43MTQyMiA2NjYuODQ3Mzcg MjY0LjUyODgxIDY1Ny4zNTQgMzA3LjcxNDIyIA02NTcuMzU0IF0gDS9BUCA8PCAvTiAzNjggMCBS ID4+IA0+PiANZW5kb2JqDTM2NiAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9w dXAgDS9SZWN0IFsgMjY0LjUyODgxIDQ2Ni44NDczNyA0NjQuNTI4ODEgNjY2Ljg0NzM3IF0gDS9P cGVuIGZhbHNlIA0vRiAyOCANL1BhcmVudCAzNjUgMCBSIA0+PiANZW5kb2JqDTM2NyAwIG9iag1b IA0zNjUgMCBSIDM2NiAwIFIgDV0NZW5kb2JqDTM2OCAwIG9iag08PCAvTGVuZ3RoIDE4NCAvVHlw ZSAvWE9iamVjdCAvU3VidHlwZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDI2MS45OTQ0IDY1 Ny4wNTcxOSAzMTAuMjQ4NjQgNjY3LjE0NDE4IF0gDS9NYXRyaXggWyAxIDAgMCAxIC0yNjEuOTk0 NCAtNjU3LjA1NzE5IF0gL1Jlc291cmNlcyA8PCAvUHJvY1NldCBbIC9QREYgXSA+PiA+PiANc3Ry ZWFtDQoxIDAuOTkyMDA0IDAuMTc5OTkzIFJHCjAuNTkzMyB3CjI2NC41Mjg4IDY1Ny4zNTQgbQoy NjIuMjkxMiA2NTkuNTkxNiAyNjIuMjkxMiA2NjQuNjA5OCAyNjQuNTI4OCA2NjYuODQ3NCBjCjMw Ny43MTQyIDY2Ni44NDc0IGwKMzA5Ljk1MTggNjY0LjYwOTggMzA5Ljk1MTggNjU5LjU5MTYgMzA3 LjcxNDIgNjU3LjM1NCBjCnMKZW5kc3RyZWFtDWVuZG9iag0zNjkgMCBvYmoNPDwgDS9UeXBlIC9B bm5vdCANL1JlY3QgWyAyNjIuMDAxNjkgMjE4LjcyMTU2IDM2NC4yNDM4NSAyMjguODA4NTUgXSAN L05NICgxOTAwMTcxKQ0vRiA0IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMzcwIDAgUiAN L00gKEQ6MjAwMzExMTIxMzQxMzgrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29u dGVudHMgKGJydXRlHyBmb3JjZR8gYXR0YWNrIG9yIG90aGVyIGNyeXB0YW5hbHlzaXMgdGVjaG5p cXVlc1xyXHJcKG5vdGluZyB0aGF0IFwNQTUvMiBhbmQgQTUvMSBhcmUgd2Vha1wpKQ0vVCAoZ2dy KQ0vQVAgPDwgL04gMzcyIDAgUiA+PiANL1F1YWRQb2ludHMgWyAyNjQuNTM2MSAyMjguNTExNzMg MzYxLjcwOTQzIDIyOC41MTE3MyAyNjQuNTM2MSAyMTkuMDE4MzcgMzYxLjcwOTQzIA0yMTkuMDE4 MzcgXSANPj4gDWVuZG9iag0zNzAgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL1Bv cHVwIA0vUmVjdCBbIDI2NC41MzYxIDI4LjUxMTczIDQ2NC41MzYxIDIyOC41MTE3MyBdIA0vT3Bl biBmYWxzZSANL0YgMjggDS9QYXJlbnQgMzY5IDAgUiANPj4gDWVuZG9iag0zNzEgMCBvYmoNWyAN DV0NZW5kb2JqDTM3MiAwIG9iag08PCAvTGVuZ3RoIDE4MiAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvRm9ybSAvRm9ybVR5cGUgMSAvQkJveCBbIDI2Mi4wMDE2OSAyMTguNzIxNTYgMzY0LjI0Mzg1 IDIyOC44MDg1NSBdIA0vTWF0cml4IFsgMSAwIDAgMSAtMjYyLjAwMTY5IC0yMTguNzIxNTYgXSAv UmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCjEgMC45OTIwMDQg MC4xNzk5OTMgUkcKMC41OTMzIHcKMjY0LjUzNjEgMjE5LjAxODQgbQoyNjIuMjk4NSAyMjEuMjU2 IDI2Mi4yOTg1IDIyNi4yNzQxIDI2NC41MzYxIDIyOC41MTE3IGMKMzYxLjcwOTQgMjI4LjUxMTcg bAozNjMuOTQ3IDIyNi4yNzQxIDM2My45NDcgMjIxLjI1NiAzNjEuNzA5NCAyMTkuMDE4NCBjCnMK ZW5kc3RyZWFtDWVuZG9iag0zNzMgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyAyNjIu MDAxNjkgMjE4LjcyMTU2IDM2NC4yNDM4NSAyMjguODA4NTUgXSANL05NICgxOTAwMTcxKQ0vRiA0 IA0vU3VidHlwZSAvSGlnaGxpZ2h0IA0vUG9wdXAgMzc0IDAgUiANL00gKEQ6MjAwMzExMTIxMzQx MzgrMTInMDAnKQ0vQyBbIDEgMC45OTIgMC4xNzk5OSBdIA0vQ29udGVudHMgKGJydXRlHyBmb3Jj ZR8gYXR0YWNrIG9yIG90aGVyIGNyeXB0YW5hbHlzaXMgdGVjaG5pcXVlc1xyXHJcKG5vdGluZyB0 aGF0IFwNQTUvMiBhbmQgQTUvMSBhcmUgd2Vha1wpKQ0vVCAoZ2dyKQ0vUCAxNDUgMCBSIA0vUXVh ZFBvaW50cyBbIDI2NC41MzYxIDIyOC41MTE3MyAzNjEuNzA5NDMgMjI4LjUxMTczIDI2NC41MzYx IDIxOS4wMTgzNyAzNjEuNzA5NDMgDTIxOS4wMTgzNyBdIA0vQVAgPDwgL04gMzc2IDAgUiA+PiAN Pj4gDWVuZG9iag0zNzQgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL1BvcHVwIA0v UmVjdCBbIDI2NC41MzYxIDI4LjUxMTczIDQ2NC41MzYxIDIyOC41MTE3MyBdIA0vT3BlbiBmYWxz ZSANL0YgMjggDS9QYXJlbnQgMzczIDAgUiANPj4gDWVuZG9iag0zNzUgMCBvYmoNWyANMzczIDAg UiAzNzQgMCBSIDM3NyAwIFIgMzc4IDAgUiANXQ1lbmRvYmoNMzc2IDAgb2JqDTw8IC9MZW5ndGgg MTgyIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlwZSAxIC9CQm94IFsgMjYy LjAwMTY5IDIxOC43MjE1NiAzNjQuMjQzODUgMjI4LjgwODU1IF0gDS9NYXRyaXggWyAxIDAgMCAx IC0yNjIuMDAxNjkgLTIxOC43MjE1NiBdIC9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWyAvUERGIF0g Pj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5MzMgdwoyNjQuNTM2MSAy MTkuMDE4NCBtCjI2Mi4yOTg1IDIyMS4yNTYgMjYyLjI5ODUgMjI2LjI3NDEgMjY0LjUzNjEgMjI4 LjUxMTcgYwozNjEuNzA5NCAyMjguNTExNyBsCjM2My45NDcgMjI2LjI3NDEgMzYzLjk0NyAyMjEu MjU2IDM2MS43MDk0IDIxOS4wMTg0IGMKcwplbmRzdHJlYW0NZW5kb2JqDTM3NyAwIG9iag08PCAN L1R5cGUgL0Fubm90IA0vUmVjdCBbIDE5MS44MTU5NiAxODguMTI3NTIgMzA0Ljg1NDE5IDE5OC4y MTQ1MSBdIA0vTk0gKDE5MDAxNzkpDS9GIDQgDS9TdWJ0eXBlIC9IaWdobGlnaHQgDS9Qb3B1cCAz NzggMCBSIA0vTSAoRDoyMDAzMTExMjEzNDMyNSsxMicwMCcpDS9DIFsgMSAwLjk5MiAwLjE3OTk5 IF0gDS9Db250ZW50cyAoQnV0IGEgcGFzc2l2ZSBhdHRhY2tlciBjYW4ndCBpbXBlcnNvbmF0ZSBh bnlvbmUuLi4gbm90IHN1cmUgd2hhdCB5b3UgbWVhXA1uIGhlcmUuKQ0vVCAoZ2dyKQ0vUCAxNDUg MCBSIA0vUXVhZFBvaW50cyBbIDE5NC4zNTAzNyAxOTcuOTE3NjkgMzAyLjMxOTc2IDE5Ny45MTc2 OSAxOTQuMzUwMzcgMTg4LjQyNDMzIDMwMi4zMTk3NiANMTg4LjQyNDMzIF0gDS9BUCA8PCAvTiAz NzkgMCBSID4+IA0+PiANZW5kb2JqDTM3OCAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlw ZSAvUG9wdXAgDS9SZWN0IFsgMTk0LjM1MDM3IC0yLjA4MjMxIDM5NC4zNTAzNyAxOTcuOTE3Njkg XSANL09wZW4gZmFsc2UgDS9GIDI4IA0vUGFyZW50IDM3NyAwIFIgDT4+IA1lbmRvYmoNMzc5IDAg b2JqDTw8IC9MZW5ndGggMTg2IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9Gb3JtIC9Gb3JtVHlw ZSAxIC9CQm94IFsgMTkxLjgxNTk2IDE4OC4xMjc1MiAzMDQuODU0MTkgMTk4LjIxNDUxIF0gDS9N YXRyaXggWyAxIDAgMCAxIC0xOTEuODE1OTYgLTE4OC4xMjc1MiBdIC9SZXNvdXJjZXMgPDwgL1By b2NTZXQgWyAvUERGIF0gPj4gPj4gDXN0cmVhbQ0KMSAwLjk5MjAwNCAwLjE3OTk5MyBSRwowLjU5 MzMgdwoxOTQuMzUwNCAxODguNDI0MyBtCjE5Mi4xMTI4IDE5MC42NjE5IDE5Mi4xMTI4IDE5NS42 ODAxIDE5NC4zNTA0IDE5Ny45MTc3IGMKMzAyLjMxOTggMTk3LjkxNzcgbAozMDQuNTU3NCAxOTUu NjgwMSAzMDQuNTU3NCAxOTAuNjYxOSAzMDIuMzE5OCAxODguNDI0MyBjCnMKZW5kc3RyZWFtDWVu ZG9iag0zODAgMCBvYmoNPDwgDS9UeXBlIC9Bbm5vdCANL1JlY3QgWyA1MS40Mzc0MSAyMTguNzIx NTYgNDA1LjAyOTUzIDIzOS4wMDY1NiBdIA0vTk0gKDE5MDAxN2MpDS9GIDQgDS9TdWJ0eXBlIC9I aWdobGlnaHQgDS9Qb3B1cCAzODEgMCBSIA0vTSAoRDoyMDAzMTExMjE0MTAzNysxMicwMCcpDS9D IFsgMSAwLjk5MiAwLjE3OTk5IF0gDS9Db250ZW50cyAoSSB0aGluayB5b3Ugc2hvdWxkIHVzZSBD VFIgbW9kZSBpbnN0ZWFkIG9mIENCQyBtb2RlLiBUaGVuIHlvdSBkb24ndCBuZWVkXA0gdGhlIHBh ZGRpbmcgYXR0cmlidXRlLCBhbmQgdGhlIElWIG9ubHkgbmVlZHMgdG8gYmUgdW5pcXVlLCBub3Qg cmFuZG9tLikNL1QgKGdncikNL1AgMTEyIDAgUiANL1F1YWRQb2ludHMgWyAzMjkuMzA5MzYgMjM4 LjcwOTc1IDQwMi40OTUxIDIzOC43MDk3NSAzMjkuMzA5MzYgMjI5LjIxNjM4IDQwMi40OTUxIA0y MjkuMjE2MzggNTMuOTcxODIgMjI4LjUxMTczIDE3Mi43NDgyOCAyMjguNTExNzMgNTMuOTcxODIg MjE5LjAxODM3IA0xNzIuNzQ4MjggMjE5LjAxODM3IF0gDS9BUCA8PCAvTiAzODIgMCBSID4+IA0+ PiANZW5kb2JqDTM4MSAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvUG9wdXAgDS9S ZWN0IFsgMzI5LjMwOTM2IDM4LjcwOTc1IDUyOS4zMDkzNiAyMzguNzA5NzUgXSANL09wZW4gZmFs c2UgDS9GIDI4IA0vUGFyZW50IDM4MCAwIFIgDT4+IA1lbmRvYmoNMzgyIDAgb2JqDTw8IC9GaWx0 ZXIgWyAvRmxhdGVEZWNvZGUgXSAvTGVuZ3RoIDM4MyAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0Zvcm0gDS9Gb3JtVHlwZSAxIC9CQm94IFsgNTEuNDM3NDEgMjE4LjcyMTU2IDQwNS4wMjk1 MyAyMzkuMDA2NTYgXSAvTWF0cml4IFsgMSAwIDAgMSAtNTEuNDM3NDEgLTIxOC43MjE1NiBdIA0v UmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsgL1BERiBdID4+ID4+IA1zdHJlYW0NCkiJTI67EcNACAXz q4IKGL7HUYFzt6BUjhy4fSNrZJQ9dlh4DISZQmQVODJT4fkYhJ6q8BkqiUppIBWEp8GrWCAFLxBl NDe4gYkWItCaLgzKgG0YCVo6N9uLGUbpbd7Ieby1q8E23sMV8/eRE4nXUcu5RJPaYxSf0PNECWP4 O7LQmY9OHIJhS5vtxQxzebZ4I+fp1q73R6evAAMA6mRAeg1lbmRzdHJlYW0NZW5kb2JqDTM4MyAw IG9iag0xNTkgDWVuZG9iag0zODQgMCBvYmoNPDwgL1R5cGUgL01ldGFkYXRhIC9TdWJ0eXBlIC9Y TUwgL0xlbmd0aCAxNDQ2ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBpZD0nVzVNME1w Q2VoaUh6cmVTek5UY3prYzlkJyBieXRlcz0nMTQ0Nic/PgoKPHJkZjpSREYgeG1sbnM6cmRmPSdo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJwogeG1sbnM6aVg9J2h0 dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+CgogPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJwog IHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJwogIHhtbG5zOnBkZj0naHR0cDov L25zLmFkb2JlLmNvbS9wZGYvMS4zLyc+CiAgPHBkZjpDcmVhdGlvbkRhdGU+MjAwMy0xMS0xMFQw NDozODo1Mlo8L3BkZjpDcmVhdGlvbkRhdGU+CiAgPHBkZjpNb2REYXRlPjIwMDMtMTEtMTJUMTQ6 MTM6NTgrMTI6MDA8L3BkZjpNb2REYXRlPgogIDxwZGY6UHJvZHVjZXI+QWNyb2JhdCBEaXN0aWxs ZXIgNS4wIChXaW5kb3dzKTwvcGRmOlByb2R1Y2VyPgogIDxwZGY6QXV0aG9yPmdncjwvcGRmOkF1 dGhvcj4KICA8cGRmOkNyZWF0b3I+UHNjcmlwdC5kbGwgVmVyc2lvbiA1LjA8L3BkZjpDcmVhdG9y PgogIDxwZGY6VGl0bGU+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aGF2ZXJpbmVuLXBwcGV4dC1lYXAtPC9wZGY6VGl0bGU+CiA8L3JkZjpEZXNjcmlwdGlvbj4KCiA8 cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnCiAgeG1sbnM9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8nCiAgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJz4KICA8eGFw OkNyZWF0ZURhdGU+MjAwMy0xMS0xMFQwNDozODo1Mlo8L3hhcDpDcmVhdGVEYXRlPgogIDx4YXA6 TW9kaWZ5RGF0ZT4yMDAzLTExLTEyVDE0OjEzOjU4KzEyOjAwPC94YXA6TW9kaWZ5RGF0ZT4KICA8 eGFwOkF1dGhvcj5nZ3I8L3hhcDpBdXRob3I+CiAgPHhhcDpNZXRhZGF0YURhdGU+MjAwMy0xMS0x MlQxNDoxMzo1OCsxMjowMDwveGFwOk1ldGFkYXRhRGF0ZT4KICA8eGFwOlRpdGxlPgogICA8cmRm OkFsdD4KICAgIDxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+aHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGF2ZXJpbmVuLXBwcGV4dC1lYXAtPC9yZGY6bGk+CiAg IDwvcmRmOkFsdD4KICA8L3hhcDpUaXRsZT4KIDwvcmRmOkRlc2NyaXB0aW9uPgoKIDxyZGY6RGVz Y3JpcHRpb24gYWJvdXQ9JycKICB4bWxucz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEu MS8nCiAgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJz4KICA8ZGM6 Y3JlYXRvcj5nZ3I8L2RjOmNyZWF0b3I+CiAgPGRjOnRpdGxlPmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhdmVyaW5lbi1wcHBleHQtZWFwLTwvZGM6dGl0bGU+CiA8 L3JkZjpEZXNjcmlwdGlvbj4KCjwvcmRmOlJERj4KPD94cGFja2V0IGVuZD0ncic/Pg1lbmRzdHJl YW0NZW5kb2JqDXhyZWYNMCAxIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjI4IDEgDTAwMDAyMTk4MzEg MDAwMDAgbg0KMzEgMSANMDAwMDIyMDAwMyAwMDAwMCBuDQozNCAxIA0wMDAwMjIwMTc1IDAwMDAw IG4NCjYxIDEgDTAwMDAyMjAzNDcgMDAwMDAgbg0KNjQgMSANMDAwMDIyMDUxOSAwMDAwMCBuDQo4 MiAxIA0wMDAwMjIwNjkxIDAwMDAwIG4NCjg1IDEgDTAwMDAyMjA4NjMgMDAwMDAgbg0KMTEyIDEg DTAwMDAyMjEwMzUgMDAwMDAgbg0KMTI0IDEgDTAwMDAyMjEyMTAgMDAwMDAgbg0KMTMwIDEgDTAw MDAyMjEzODUgMDAwMDAgbg0KMTM2IDEgDTAwMDAyMjE1NjAgMDAwMDAgbg0KMTQ1IDEgDTAwMDAy MjE3MzUgMDAwMDAgbg0KMjAzIDQgDTAwMDAyMjE5MTAgMDAwMDAgbg0KMDAwMDIyMjE3MiAwMDAw MSBuDQowMDAwMjIyNjk5IDAwMDAxIG4NCjAwMDAyMjI4NDAgMDAwMDAgbg0KMjE4IDIgDTAwMDAy MjI5NTMgMDAwMDEgbg0KMDAwMDIyMzM1NSAwMDAwMSBuDQoyMjQgMyANMDAwMDIyMzgwNyAwMDAw MSBuDQowMDAwMjIzOTQ4IDAwMDAxIG4NCjAwMDAyMjQwMTkgMDAwMDEgbg0KMjM3IDIgDTAwMDAy MjQ0MTggMDAwMDEgbg0KMDAwMDIyNDkwMSAwMDAwMSBuDQoyNTkgMyANMDAwMDIyNTA0NSAwMDAw MSBuDQowMDAwMjI1NDUxIDAwMDAxIG4NCjAwMDAyMjYwMjggMDAwMDEgbg0KMjY3IDMgDTAwMDAy MjYxNzIgMDAwMDEgbg0KMDAwMDIyNjU3MiAwMDAwMSBuDQowMDAwMjI2OTgzIDAwMDAxIG4NCjI3 NiAyMSANMDAwMDIyNzEyNCAwMDAwMSBuDQowMDAwMjI3MTQ3IDAwMDAxIG4NCjAwMDAyMjc1NDkg MDAwMDEgbg0KMDAwMDIyNzkwMiAwMDAwMSBuDQowMDAwMjI4MDQ2IDAwMDAxIG4NCjAwMDAyMjgx MDEgMDAwMDEgbg0KMDAwMDIyODUwNiAwMDAwMSBuDQowMDAwMjI4ODc4IDAwMDAxIG4NCjAwMDAy MjkwMjIgMDAwMDEgbg0KMDAwMDIyOTQyNSAwMDAwMSBuDQowMDAwMjMwNDA0IDAwMDAxIG4NCjAw MDAyMzA1NDggMDAwMDEgbg0KMDAwMDIzMTAzNiAwMDAwMSBuDQowMDAwMjMxMDU4IDAwMDAxIG4N CjAwMDAyMzE0NjEgMDAwMDEgbg0KMDAwMDIzMTYwMyAwMDAwMSBuDQowMDAwMjMxNjQyIDAwMDAx IG4NCjAwMDAyMzIwNDggMDAwMDEgbg0KMDAwMDIzMjQ5NiAwMDAwMSBuDQowMDAwMjMyNjM5IDAw MDAxIG4NCjAwMDAyMzI2NzggMDAwMDEgbg0KMzMwIDEgDTAwMDAyMzMwODAgMDAwMDAgbg0KMzM2 IDQ5IA0wMDAwMjMzMTUxIDAwMDAwIG4NCjAwMDAyMzM1OTIgMDAwMDAgbg0KMDAwMDIzMzczMyAw MDAwMCBuDQowMDAwMjMzNzcyIDAwMDAwIG4NCjAwMDAyMzQxMjMgMDAwMDAgbg0KMDAwMDIzNDI2 NSAwMDAwMCBuDQowMDAwMjM0MzA0IDAwMDAwIG4NCjAwMDAyMzQ3MDAgMDAwMDAgbg0KMDAwMDI0 MjI1NCAwMDAwMCBuDQowMDAwMjQyMzk0IDAwMDAwIG4NCjAwMDAyNDI0MTcgMDAwMDAgbg0KMDAw MDI0NTYxNyAwMDAwMCBuDQowMDAwMjQ1NjQwIDAwMDAwIG4NCjAwMDAyNDYwODMgMDAwMDAgbg0K MDAwMDI0NjIyMyAwMDAwMCBuDQowMDAwMjQ2MjYyIDAwMDAwIG4NCjAwMDAyNDY2NTggMDAwMDAg bg0KMDAwMDI0NzAwMyAwMDAwMCBuDQowMDAwMjQ3MTQ0IDAwMDAwIG4NCjAwMDAyNDcxOTkgMDAw MDAgbg0KMDAwMDI0NzU5MSAwMDAwMCBuDQowMDAwMjQ3OTkwIDAwMDAwIG4NCjAwMDAyNDgxMzMg MDAwMDAgbg0KMDAwMDI0ODE3MiAwMDAwMCBuDQowMDAwMjQ4NTgwIDAwMDAwIG4NCjAwMDAyNDk4 NTMgMDAwMDAgbg0KMDAwMDI0OTk5NiAwMDAwMCBuDQowMDAwMjUwMDM1IDAwMDAwIG4NCjAwMDAy NTA3ODYgMDAwMDAgbg0KMDAwMDI1MDgwOCAwMDAwMCBuDQowMDAwMjUxMjcyIDAwMDAwIG4NCjAw MDAyNTE0MTYgMDAwMDAgbg0KMDAwMDI1MTQ1NSAwMDAwMCBuDQowMDAwMjUxODYxIDAwMDAwIG4N CjAwMDAyNTIyOTkgMDAwMDAgbg0KMDAwMDI1MjQ0MCAwMDAwMCBuDQowMDAwMjUyNDYzIDAwMDAw IG4NCjAwMDAyNTI4NjkgMDAwMDAgbg0KMDAwMDI1MzMxOSAwMDAwMCBuDQowMDAwMjUzNDYwIDAw MDAwIG4NCjAwMDAyNTM1MTUgMDAwMDAgbg0KMDAwMDI1MzkyMSAwMDAwMCBuDQowMDAwMjU0MzU2 IDAwMDAwIG4NCjAwMDAyNTQ0OTkgMDAwMDAgbg0KMDAwMDI1NDkwOSAwMDAwMCBuDQowMDAwMjU1 NDg0IDAwMDAwIG4NCjAwMDAyNTU2MjcgMDAwMDAgbg0KMDAwMDI1NjAzOSAwMDAwMCBuDQowMDAw MjU2MDYxIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgMzg1DS9JbmZvIDIwMyAwIFIgDS9Sb290 IDIwNiAwIFIgDS9QcmV2IDIxMjk0OCANL0lEWzxlYTI5ZjE3MjMxODI2ZTY1MjcxMWVmNzdiMTM3 MTUzZj48MzBhMzA4Y2VhNjE2YzIwNDE3YzVlMzNhZDA1NDk3NzQ+XQ0+Pg1zdGFydHhyZWYNMjU3 NTkzDSUlRU9GDQ== ------_=_NextPart_001_01C3B283.49DE1476 Content-Type: text/plain; name="ATT78840.txt" Content-Description: ATT78840.txt Content-Disposition: attachment; filename="ATT78840.txt" Content-Transfer-Encoding: base64 DQpHcmVnIFJvc2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJTlRFUk5F VDogZ2dyQHF1YWxjb21tLmNvbQ0KUXVhbGNvbW0gQXVzdHJhbGlhICAgICAgICAgIFZPSUNFOiAg KzYxLTItOTgxNyA0MTg4ICAgRkFYOiArNjEtMi05ODE3IDUxOTkNCkxldmVsIDMsIDIzMCBWaWN0 b3JpYSBSb2FkLCAgICAgICAgICAgICAgICBodHRwOi8vcGVvcGxlLnF1YWxjb21tLmNvbS9nZ3Iv DQpHbGFkZXN2aWxsZSBOU1cgMjExMSAgICAyMzJCIEVDOEYgNDRDNiBDODUzIEQ2OEYgIEUxMDcg RTZCRiBDRDJGIDEwODEgQTM3Qw0K ------_=_NextPart_001_01C3B283.49DE1476-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Nov 25 22:08:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23192 for ; Tue, 25 Nov 2003 22:07:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2E813580014; Tue, 25 Nov 2003 21:08:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D78B580016; Tue, 25 Nov 2003 21:08:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8FB0A580027 for ; Tue, 25 Nov 2003 21:07:07 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6439A580016 for ; Tue, 25 Nov 2003 21:07:05 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQ3QYp27917; Tue, 25 Nov 2003 19:26:34 -0800 From: Bernard Aboba To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 25 Nov 2003 19:26:34 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Do we agree there is no problem on the peer side? If so, let's turn to the > authenticator... Yes, I agree with this. Not sure about the IEEE 802.1aa folks. Can anyone who was there fill us in? > It seems to me what you are saying is that even after receiving an > Accept-Accept, the passthrough does not know it is allowed to have access > even though it is allowed. Yes, the pass-through knows it will provide access to the peer, but doesn't know whether the peer will accept the access. Note that if the authenticator was not a pass-through, then it would know, because it would have received the result indication from the peer. > There are two possible solutions I see- > 1. make Access-Accept mean that BOTH things are ok and that mutual auth > is known to have succeeded or I don't think we can change the meaning of Access-Accept at this point. > 2. make Access-Accept strictly mean the Peer is to be given access, and > make some other AAA signal/message provide the other information. This one could work. For example, we could add a "P2P complete" attribute to tell the pass-through that the peer has sent a successful result indication. > If mutual auth is required, the server can tie the auth directly to the EAP > aaaEapSuccess signal. That is, both must be authenticated for > aaaEapSuccess to be true. This > only works for case 1 above, as the AAA layer can't separate these two if > it is only given binary input. I believe THIS is the missing variable you > describe? I think another variable is needed on the authenticator SM to indicate that a result indication has been received from the peer. > I am really having trouble with the model for why the passthrough needs > this information. when using a peer and a passthrough authenticator, it's > tough for me to see the true peer-to-peer relationship we are describing > in any real-world scenario. The scenario that IEEE 802.1af has been looking are bridges talking to one another. I think that the IEEE 802.11 adhoc scenario may also be affected. The way to think about this is "can the two sides confirm that both controlled ports are passing packets, so that another EAP authentication will not have to be run in both directions". If the answer is no, then you need to do another authentication, which is wasteful. > That being said, this does not mean we > shouldn't handle the situation. My understanding of all passthrough > implementations is that if there was to be mutual authentication, but > the peer failed to authenticate the authenticator the peer will just go > away (or try again) anyway. Yes. > Additionally, I understand the argument that we want > passthrough and standalone to have the same semantics, but I think even > in the peer and standalone statemachines it is policy that is tying > together the two authentication decisions into a single signal. The method > should be set to only succeed in the case of mutual authentication if > mutual auth is required. I think there may be subtle distinction being made between mutual auth (where the authenticator might not know whether the peer is going to accept the access it granted), and protected result indications, where the authenticator would know the peer decision, absent the pass-through issues we just talked about. > My current position is that I don't see why you need two answers. If you > know you are using a method with mutual authentication, then you should be > able to tie the outcome of that method to a two-way relationship. As mentioned above, I think it's about both sides being able to confirm that they are willing to talk at L3, not just for the authenticator to confirm its willingness to offer access to the peer. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 05:23:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01082 for ; Wed, 26 Nov 2003 05:22:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1510580016; Wed, 26 Nov 2003 04:23:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C55D58012F; Wed, 26 Nov 2003 04:23:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BC1BB58012F for ; Wed, 26 Nov 2003 04:22:06 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 36A51580016 for ; Wed, 26 Nov 2003 04:22:05 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 588826A904; Wed, 26 Nov 2003 12:22:03 +0200 (EET) Message-ID: <3FC47DC2.2010704@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Nick Petroni , eap@frascone.com Subject: Re: [eap] Issue 204: Peer-to-peer operation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 12:17:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Interesting discussion! When we come to a conclusion, we should document the result in the state machine spec just to avoid people asking about it later. A couple of points: o Assuming 802.11i, wouldn't mutual authentication be required in any case, so in theory 802.11i equipment could assume Access-Accept = mutual authentication? o But in general, I agree that if methods could provide information to other layers about the type of authentication they performed, this would be useful. o If we do provide such information over an API, we also need new AAA attributes as Bernard pointed out. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 10:48:22 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13359 for ; Wed, 26 Nov 2003 10:48:21 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 217375801A5; Wed, 26 Nov 2003 09:48:32 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7576A5801A1; Wed, 26 Nov 2003 09:48:20 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB08A580131 for ; Wed, 26 Nov 2003 09:47:35 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id A9D4758012F for ; Wed, 26 Nov 2003 09:47:30 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQG6tA07537; Wed, 26 Nov 2003 08:06:55 -0800 From: Bernard Aboba To: Jari Arkko Cc: Nick Petroni , eap@frascone.com Subject: Re: [eap] Issue 204: Peer-to-peer operation In-Reply-To: <3FC47DC2.2010704@piuha.net> Message-ID: References: <3FC47DC2.2010704@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 08:06:55 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Interesting discussion! When we come to a conclusion, we > should document the result in the state machine > spec just to avoid people asking about it later. > > A couple of points: > > o Assuming 802.11i, wouldn't mutual authentication be > required in any case, so in theory 802.11i equipment > could assume Access-Accept = mutual authentication? I think the issue may in part be that mutual auth != confirmed result indications. > o But in general, I agree that if methods could provide > information to other layers about the type of > authentication they performed, this would be useful. > > o If we do provide such information over an API, we > also need new AAA attributes as Bernard pointed out. Yes, I think that may be required. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 11:45:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16587 for ; Wed, 26 Nov 2003 11:44:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44D05580016; Wed, 26 Nov 2003 10:45:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D3C0B58012B; Wed, 26 Nov 2003 10:45:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4719058012B for ; Wed, 26 Nov 2003 10:44:20 -0600 (CST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id AFAC8580016 for ; Wed, 26 Nov 2003 10:44:18 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAQGiDjs020754; Wed, 26 Nov 2003 08:44:15 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.113.48]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 08:49:25 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , "'Jari Arkko'" Cc: "'Nick Petroni'" , Subject: RE: [eap] Issue 204: Peer-to-peer operation Message-ID: <001201c3b43c$8651c890$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Nov 2003 16:49:25.0292 (UTC) FILETIME=[3FCD26C0:01C3B43D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 08:44:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Wednesday, November 26, 2003 8:07 AM > To: Jari Arkko > Cc: Nick Petroni; eap@frascone.com > Subject: Re: [eap] Issue 204: Peer-to-peer operation > > > > Interesting discussion! When we come to a conclusion, we should > > document the result in the state machine spec just to avoid people > > asking about it later. > > > > A couple of points: > > > > o Assuming 802.11i, wouldn't mutual authentication be > > required in any case, so in theory 802.11i equipment > > could assume Access-Accept = mutual authentication? > > I think the issue may in part be that mutual auth != > confirmed result indications. [Joe] Yes this seems to be the issue, but I'm still not sure what the value is in confirmed result indicators or why it has to be done in EAP and not the layer calling EAP. > > > o But in general, I agree that if methods could provide > > information to other layers about the type of > > authentication they performed, this would be useful. > > > > o If we do provide such information over an API, we > > also need new AAA attributes as Bernard pointed out. > > Yes, I think that may be required. [Joe] If these attributes are not present do you deny access or is this a local policy decision on the NAS? Shouldn't this be centralized with the rest of the access policy in AAA? > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 11:53:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16975 for ; Wed, 26 Nov 2003 11:53:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22335580016; Wed, 26 Nov 2003 10:54:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A24658012B; Wed, 26 Nov 2003 10:54:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5863658012B for ; Wed, 26 Nov 2003 10:53:47 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 7C9A9580016 for ; Wed, 26 Nov 2003 10:53:45 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQHCkO11339; Wed, 26 Nov 2003 09:12:46 -0800 From: Bernard Aboba To: Joseph Salowey Cc: "'Jari Arkko'" , "'Nick Petroni'" , eap@frascone.com Subject: RE: [eap] Issue 204: Peer-to-peer operation In-Reply-To: <001201c3b43c$8651c890$0200000a@amer.cisco.com> Message-ID: References: <001201c3b43c$8651c890$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:12:46 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > > Yes, I think that may be required. > > [Joe] If these attributes are not present do you deny access or is this > a local policy decision on the NAS? Shouldn't this be centralized with > the rest of the access policy in AAA? I think this is more about whether it is necessary to rerun EAP in the other direction. The authenticator will still provide access either way. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 12:15:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17835 for ; Wed, 26 Nov 2003 12:14:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE3B2580016; Wed, 26 Nov 2003 11:15:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CA84658012F; Wed, 26 Nov 2003 11:15:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07FD358012F for ; Wed, 26 Nov 2003 11:14:29 -0600 (CST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 41ADA580016 for ; Wed, 26 Nov 2003 11:14:27 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAQHEMAt004800; Wed, 26 Nov 2003 09:14:23 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.113.48]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 09:18:35 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: "'Jari Arkko'" , "'Nick Petroni'" , Subject: RE: [eap] Issue 204: Peer-to-peer operation Message-ID: <001401c3b440$998fa360$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Nov 2003 17:18:35.0558 (UTC) FILETIME=[530A8C60:01C3B441] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:13:23 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, November 26, 2003 9:13 AM > To: Joseph Salowey > Cc: 'Jari Arkko'; 'Nick Petroni'; eap@frascone.com > Subject: RE: [eap] Issue 204: Peer-to-peer operation > > > > > Yes, I think that may be required. > > > > [Joe] If these attributes are not present do you deny > access or is this > > a local policy decision on the NAS? Shouldn't this be > centralized with > > the rest of the access policy in AAA? > > I think this is more about whether it is necessary to rerun > EAP in the other direction. The authenticator will still > provide access either way. > [Joe] OK, sorry to be playing catch up, so the possibility is that the Peer has not had its policy satisfied so it will not open its port, but the authenticator may not have any way to know this since it may have considered its policy complete. It would seem that in this case the peer would then want to reverse roles and authenticate the previous authenticator. Can't this be signaled in 802.1x? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 12:28:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18306 for ; Wed, 26 Nov 2003 12:28:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0CF3580016; Wed, 26 Nov 2003 11:29:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05ACD58012B; Wed, 26 Nov 2003 11:29:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 599A658012B for ; Wed, 26 Nov 2003 11:28:19 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 1220D580016 for ; Wed, 26 Nov 2003 11:28:17 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQHlid13432 for ; Wed, 26 Nov 2003 09:47:44 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:47:43 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 204 has been filed against the state machine document, but it has been an open question as to what effect it would have (if any) on RFC 2284bis. After looking at the revised section 2.4 "Peer to Peer operation", the first four paragraphs of the section are about limitations on peer-to-peer operation, which is somewhat orthogonal to Issue 204. The next two paragraphs seem to be about a slightly different subject -- whether an authentication is necessary in each direction, which is the subject of Issue 204. My suggestion is that we replace the last two paragraphs in Section 2.4, with the following text: "Lower layer considerations may dictate whether two EAP authentications, (one in each direction) are required, rather than a single EAP method supporting mutual authentication and protected result indications. These include: [1] Support for bi-direction session key derivation. Lower layers such as IEEE 802.11 only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 only the Access Point (AP) sends multicast traffic. This means that in ad-hoc operation where either peer may send multicast traffic, two uni-directional group-key exchanges are required. Due to constraints imposed by the 4-way unicast key handshake state machine, this also implies two 4-way handshake and EAP method exchanges. [2] Support for tie-breaking. Lower layers such as IEEE 802.11 adhoc do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. [3] Support for protected result indications. When an EAP method supporting mutual authentiation and protected result indication is in use, the EAP peer and server will typically be aware of each other's access decision, as well as their own. For example, the EAP server will indicate to the peer whether the peer has successfully authenticated to it, and the peer will indicate to the EAP server whether the server has successfully authenticated to the peer. As a result, the EAP peer and server can determine whether an authentication is required in the opposite direction. However, where the authenticator operates as a pass-through, it will not be aware whether the peer has accepted the access offered to it by the EAP server unless this information is provided to it via the AAA protocol. As a result, two authentications, one in each direction, may still need to occur." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 12:36:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18495 for ; Wed, 26 Nov 2003 12:36:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2EE00580016; Wed, 26 Nov 2003 11:37:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7C7B58012F; Wed, 26 Nov 2003 11:37:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B2A658012F for ; Wed, 26 Nov 2003 11:36:12 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DCDA6580016 for ; Wed, 26 Nov 2003 11:36:10 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQHtZk13876; Wed, 26 Nov 2003 09:55:35 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Issue 204: Peer-to-peer operation In-Reply-To: <001401c3b440$998fa360$0200000a@amer.cisco.com> Message-ID: References: <001401c3b440$998fa360$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:55:35 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] OK, sorry to be playing catch up, so the possibility is that the > Peer has not had its policy satisfied so it will not open its port, but > the authenticator may not have any way to know this since it may have > considered its policy complete. It would seem that in this case the > peer would then want to reverse roles and authenticate the previous > authenticator. Can't this be signaled in 802.1x? The authenticator originates EAP authentication and then it offers access to the peer, or it doesn't. It might like to send some packets to the peer, in which case it is interested in whether the peer has accepted the access it offered, but it may not know that. If so, then it could send an EAP-Start to the peer, to signal the peer that it would like to start an authentication in the other direction. So it's not a big deal, really. The point (for RFC 2284bis at least) is just to describe the situation in Section 2.4, Peer-to-peer operation. I think that some changes may be required in the EAP SM to allow the signals to be passed to the lower layer though. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 12:45:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19067 for ; Wed, 26 Nov 2003 12:45:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 218B058012B; Wed, 26 Nov 2003 11:46:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A8B5258012F; Wed, 26 Nov 2003 11:46:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4C5C58012F for ; Wed, 26 Nov 2003 11:45:57 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 1589958012B for ; Wed, 26 Nov 2003 11:45:56 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAQHjt4u001744; Wed, 26 Nov 2003 12:45:55 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 12:45:55 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [3] Support for protected result indications. When an EAP method > supporting mutual authentiation and protected result indication is > in use, the EAP peer and server will typically be aware of each other's > access decision, as well as their own. For example, the EAP server will > indicate to the peer whether the peer has successfully authenticated to > it, and the peer will indicate to the EAP server whether the server has > successfully authenticated to the peer. As a result, the EAP peer and > server can determine whether an authentication is required in the > opposite direction. However, where the authenticator operates as a > pass-through, it will not be aware whether the peer has > accepted the access offered to it by the EAP server unless this > information is provided to it via the AAA protocol. As a result, two > authentications, one in each direction, may still need to occur." based on this text, a proposed change to the state machine doc would (roughly) look something like this: In Figure 5 "EAP Backend Authenticator State Machine", change the METHOD_RESPONSE state to read m.process(aaaEapRespData) if (m.isDone()) { Policy.update(<...>) aaaEapKeyData = m.getKey() aaaEapPeerDecision = m.getPeerDecision() methodState = END } else methodState = CONTINUE aaaEapPeerDecision would take values UNKNOWN, KNOWN_ACCEPT and KNOWN_REJECT and be exported to the lower layer. thoughts? any other required changes? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 13:01:27 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19816 for ; Wed, 26 Nov 2003 13:01:23 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2EA0A58013E; Wed, 26 Nov 2003 12:01:20 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB65C580141; Wed, 26 Nov 2003 12:01:14 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D6D058012B for ; Wed, 26 Nov 2003 12:00:53 -0600 (CST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id A4850580016 for ; Wed, 26 Nov 2003 12:00:51 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAQI0miN024681; Wed, 26 Nov 2003 10:00:48 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.113.48]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 10:05:58 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Issue 204: Peer-to-peer operation Message-ID: <001701c3b447$38738b80$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Nov 2003 18:05:59.0105 (UTC) FILETIME=[F1ED6310:01C3B447] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 10:00:46 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, November 26, 2003 9:56 AM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Issue 204: Peer-to-peer operation > > > > [Joe] OK, sorry to be playing catch up, so the possibility > is that the > > Peer has not had its policy satisfied so it will not open its port, > > but the authenticator may not have any way to know this > since it may > > have considered its policy complete. It would seem that in > this case > > the peer would then want to reverse roles and authenticate the > > previous authenticator. Can't this be signaled in 802.1x? > > The authenticator originates EAP authentication and then it > offers access to the peer, or it doesn't. It might like to > send some packets to the peer, in which case it is interested > in whether the peer has accepted the access it offered, but > it may not know that. [Joe] So the protected result is not just signaling that the authentication was successful, but also that the peer has authorized the opening of its port. If the Peer actually wanted to do bi-drection authenticaiton perhaps using a different EAP method then it wouldn't send a protected result indication of succss even if the first method succeeded? > If so, then it could send an EAP-Start > to the peer, to signal the peer that it would like to start > an authentication in the other direction. So it's not a big > deal, really. > [Joe] Couldn't the peer to signal to the authenticator to start authentication in the other direction since it is the peer that knows if it has opened. If it can't then this seems like a .1x problem. If it can then I don't think it is a big deal. > The point (for RFC 2284bis at least) is just to describe the > situation in Section 2.4, Peer-to-peer operation. I think > that some changes may be required in the EAP SM to allow the > signals to be passed to the lower layer though. [Joe] Yes, I think we need to revisit the method interfaces in the state machines (for issue 203 as well). _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 13:33:21 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20815 for ; Wed, 26 Nov 2003 13:33:18 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ECB04580016; Wed, 26 Nov 2003 12:33:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B3F3758012B; Wed, 26 Nov 2003 12:33:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 65CDF58012B for ; Wed, 26 Nov 2003 12:32:35 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id AFB62580016 for ; Wed, 26 Nov 2003 12:32:33 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQIpum17178; Wed, 26 Nov 2003 10:51:57 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Issue 204: Peer-to-peer operation In-Reply-To: <001701c3b447$38738b80$0200000a@amer.cisco.com> Message-ID: References: <001701c3b447$38738b80$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 10:51:56 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] So the protected result is not just signaling that the > authentication was successful, but also that the peer has authorized the > opening of its port. If the Peer actually wanted to do bi-drection > authenticaiton perhaps using a different EAP method then it wouldn't > send a protected result indication of succss even if the first method > succeeded? I think those are orthogonal issues. The peer would send a protected result indication for the initial method. The authenticator would then assume that the peer was happy so that it would not ask the to authenticate to the peer (e.g. by sending an EAPOL-Start). But the peer could always send an EAP-Request if it wanted to do bi-drectional authentication for some reason. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 13:40:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20949 for ; Wed, 26 Nov 2003 13:40:01 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5ADFB580016; Wed, 26 Nov 2003 12:40:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F73A58012B; Wed, 26 Nov 2003 12:40:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C011458012B for ; Wed, 26 Nov 2003 12:39:32 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 37E67580016 for ; Wed, 26 Nov 2003 12:39:31 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQIwGO17508; Wed, 26 Nov 2003 10:58:27 -0800 From: Bernard Aboba To: Nick Petroni Cc: eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 10:58:16 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > based on this text, a proposed change to the state machine doc would > (roughly) look something like this: > > In Figure 5 "EAP Backend Authenticator State Machine", change the > METHOD_RESPONSE state to read > > m.process(aaaEapRespData) > if (m.isDone()) { > Policy.update(<...>) > aaaEapKeyData = m.getKey() > aaaEapPeerDecision = m.getPeerDecision() > methodState = END > } else > methodState = CONTINUE > > aaaEapPeerDecision would take values UNKNOWN, KNOWN_ACCEPT and > KNOWN_REJECT and be exported to the lower layer. > > thoughts? any other required changes? I think this is correct. The lower layer can then use this variable to decide whether to initiate EAP authentication in the other direction. On the peer side, there is also a need to make a decision (as Joe noted). However there I think that existing interfaces may be adequate because the peer knows whether it has been granted access and is willing to accept it; the only question is whether its policy requires an authentication in the other direction too. That doesn't seem like a decision that requires additional interfaces to the lower layer. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 14:02:14 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21772 for ; Wed, 26 Nov 2003 14:02:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 34F2E58012B; Wed, 26 Nov 2003 13:02:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1D1CE58012F; Wed, 26 Nov 2003 13:02:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0E24558012F for ; Wed, 26 Nov 2003 13:01:26 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 8114258012B for ; Wed, 26 Nov 2003 13:01:24 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAQJ134u003655; Wed, 26 Nov 2003 14:01:03 -0500 (EST) From: Nick Petroni To: Joseph Salowey Cc: Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine In-Reply-To: <007301c3afad$036b9110$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 14:01:03 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > 1. portEnabled > > portEnabled seems very .1x/PPP specific. EAP is being used in cases > such as IKE and PANA where this concept may a bit more abstract. > Perhaps we can change the name of the variable and/or expand its > definition to include other cases. > > Suggestion: > Perhaps "indicates that a lower layer communcation channel has been > established". [npetroni] this is fine for me. the name is not really of importance to me so I would just as soon leave it the same. If others think a name change is necessary it's fine. I like the definition change. > Suggestion: > Remove variable. We could explore this in an apppendix or a separate > document. [npetroni] previously disussed. I agree it should be removed. > 3. Interface to method > > The interface to the method seems too complicated. > > First I don't think that intCheck should be a different process. > Integrity checking is done as part of the method processing. Also > methods aren't required to ingore packets, some methods with ignore some > problems and return errors on others. I think this behavior should be > incorporated into m.process. [npetroni] intCheck is needed because SOMETIMES a method will decide not to use the packet at all. in this case, intCheck is the way the method tells the SM it will not be using that packet. Methods with other ways of dealing with this will just not set intCheck to be true. > On a separate but related note it seems that the method state and > decision is very complex. I don't really see the need for the > independent methodState and decision variables. M.process() should > return one of serverl possible results: IGNORE, CONTINUE, COND_SUCCESS, > SUCCESS, FAILURE. MethodState should be able to take on CONTINUE, > COND_SUCCESS, SUCCESS, FAILURE. I don't think a separate decision > variable is necessary. [npetroni] This is meant to show that a method really has its own state machine and that these states are separate from the final decision. I think it provides nice way of separating the two, but I am willing to discuss this alternative notation. > > 4. Idle timer > > It seems that there is a problem with the idle timer. It would be > possible for the peer to never time out if it keeps on receiving packets > that it discards. This is not so good. [npetroni] hmm, that seems like a trivial DoS, no? Send enough bad packets to the Peer and it goes away for a while? > 5. rxSuccess and rxFailure > > Shouldn't rxSuccess and rxFailure check to see if (reqId == lastReqID)? [npetroni] probably so. I think this should be added. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 14:25:26 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22744 for ; Wed, 26 Nov 2003 14:25:13 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 615AF580130; Wed, 26 Nov 2003 13:25:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B5DC580134; Wed, 26 Nov 2003 13:25:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8DD9580130 for ; Wed, 26 Nov 2003 13:24:27 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id A7FE4580141 for ; Wed, 26 Nov 2003 13:24:21 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAQJOF4u004275; Wed, 26 Nov 2003 14:24:15 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 196: Peer SM Issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 14:24:15 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > In Figure 3, it is not clear from the diagrams that SUCCESS and FAILURE This is stylistic I think. If there is a special notation for final states in Figure 3, there should be in all of them. I am open to other discussion, but I think the text descibing them as final is sufficient. Other votes? > are terminal states; perhaps a function call is necessary to cause > the packet to be sent. There are no packets to send- the Peer does not respond to success or failure. > Suggest adding a getIdentity() call in the IDENTITY state, > which can take into account the information that the peer > has available, in order to determine the appropriate > identity to put into the EAP-Response/Identity. This > could include, for example, "hints" in the EAP-Request/Identity, > default settings in the peer, etc. I think this is abstracted away in buildIdentity(). We could add information about these considerations in the function definition if the group thinks it is necessary. The remainder of this issue seems to be about tunnels, so I propose to reject the issue. We can make the style changes above as other issues or just as editiorial liberties if the group thinks they are good ideas. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 14:37:29 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23724 for ; Wed, 26 Nov 2003 14:37:24 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8E76580016; Wed, 26 Nov 2003 13:12:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 974D558012B; Wed, 26 Nov 2003 13:12:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80E2658012B for ; Wed, 26 Nov 2003 13:11:50 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id EC374580016 for ; Wed, 26 Nov 2003 13:11:48 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hAQJBk4u003934; Wed, 26 Nov 2003 14:11:46 -0500 (EST) From: Nick Petroni To: Bernard Aboba Cc: Subject: Re: [eap] Issue 195: Backend Authenticator SM review In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 14:11:46 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > pp. 21, Section 6 > > It's draft-ietf-eap-statemachine-01.pdf, not .ps, no? ok, that's no problem. I guess I thought either one could be official. just let me know which it should be. > > pp. 22, Figure 5 > > respMethod has the same value if it is a NAK or an expanded NAK. yeah, seems right. > > pp. 23 > > The definition of aaaMethodTimeout should make it clear that this > method-provided hint is not used to control the AAA timeout, only > the value of the Session-Timeout attribute sent by AAA. yes. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 15:55:13 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27927 for ; Wed, 26 Nov 2003 15:55:05 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 30E8C580138; Wed, 26 Nov 2003 14:55:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2A9DB58012B; Wed, 26 Nov 2003 14:55:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA65158012B for ; Wed, 26 Nov 2003 14:54:30 -0600 (CST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mail.frascone.com (Postfix) with ESMTP id 07F9B580016 for ; Wed, 26 Nov 2003 14:54:25 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAQKsJiN013900; Wed, 26 Nov 2003 12:54:20 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.113.48]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 12:59:30 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) Message-ID: <002401c3b45f$7625fe00$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Nov 2003 20:59:30.0676 (UTC) FILETIME=[2FB50B40:01C3B460] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 12:54:18 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Wednesday, November 26, 2003 9:48 AM > To: eap@frascone.com > Subject: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) > > > Issue 204 has been filed against the state machine document, > but it has been an open question as to what effect it would > have (if any) on RFC 2284bis. > > After looking at the revised section 2.4 "Peer to Peer > operation", the first four paragraphs of the section are > about limitations on peer-to-peer operation, which is > somewhat orthogonal to Issue 204. > > The next two paragraphs seem to be about a slightly different > subject -- whether an authentication is necessary in each > direction, which is the subject of Issue 204. > > My suggestion is that we replace the last two paragraphs in > Section 2.4, with the following text: > > "Lower layer considerations may dictate whether two EAP > authentications, (one in each direction) are required, rather > than a single EAP method supporting mutual authentication and > protected result indications. These include: > > [1] Support for bi-direction session key derivation. Lower > layers such as IEEE 802.11 only support uni-directional > derivation and transport of transient session keys. For > example, the group-key handshake defined in [IEEE-802.11i] is > uni-directional, since in IEEE 802.11 only the Access Point > (AP) sends multicast traffic. This means that in ad-hoc > operation where either peer may send multicast traffic, two > uni-directional group-key exchanges are required. Due to > constraints imposed by the 4-way unicast key handshake state > machine, this also implies two 4-way handshake and EAP method > exchanges. [Joe] Where is the use of multicast/broadcast defined in the case of an ad-hoc network? Is it defined in 802.11i? > > [2] Support for tie-breaking. Lower layers such as IEEE > 802.11 adhoc do not support "tie breaking" wherein two hosts > initiating authentication with each other will only go > forward with a single authentication. This implies that even > if 802.11 were to support a bi-directional group-key > handshake, then two authentications, one in each direction, > might still occur. > > [3] Support for protected result indications. When an EAP > method supporting mutual authentiation and protected result > indication is in use, the EAP peer and server will typically > be aware of each other's access decision, as well as their > own. For example, the EAP server will indicate to the peer > whether the peer has successfully authenticated to it, and > the peer will indicate to the EAP server whether the server > has successfully authenticated to the peer. As a result, the > EAP peer and server can determine whether an authentication > is required in the opposite direction. However, where the > authenticator operates as a pass-through, it will not be > aware whether the peer has accepted the access offered to it > by the EAP server unless this information is provided to it > via the AAA protocol. As a result, two authentications, one > in each direction, may still need to occur." [Joe] Here is a suggestion. It may need a little work, but I think it is more characteristic of the scenario. [3] Peer Policy is not satisfied. It is possible that the EAP Peer's access policy was not satisfied during the EAP-Method exchange, for example the peer may not have satisfactorily authenticated the authenticator. In this case the peer may wish to open another authentication exchange with the authenticator in the reverse direction. It is possible for an EAP mechanism to allow the Peer to return a protected result indicator to indicate that it successfully authenticated the authenticator. However, where the authenticator operates as a pass-through, it will not be aware whether the peer has accepted the credentials offered to it by the EAP server unless this information is provided to it via the AAA protocol. As a result, two authentications, one in each direction, may still need to occur. It is also possible for the peer to require additional authentication in the reverse direction even if the protected result indicator from the peer indicated success. > ______ _________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 17:37:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00960 for ; Wed, 26 Nov 2003 17:37:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AD4D580016; Wed, 26 Nov 2003 16:37:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCE8458012B; Wed, 26 Nov 2003 16:37:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 311E158012F for ; Wed, 26 Nov 2003 16:36:43 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id DE53E580016 for ; Wed, 26 Nov 2003 16:36:37 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAQMtvh31404; Wed, 26 Nov 2003 14:55:58 -0800 From: Bernard Aboba To: Joseph Salowey Cc: eap@frascone.com Subject: RE: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) In-Reply-To: <002401c3b45f$7625fe00$0200000a@amer.cisco.com> Message-ID: References: <002401c3b45f$7625fe00$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 14:55:57 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) How about this? [3] Peer Policy satisfaction. EAP methods may support protected result indications, enabling the peer to indicate to the EAP server that it successfully authenticated it. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered to it by the EAP server, unless this information is provided to the authenticator via the AAA protocol. As a result, two authentications, one in each direction, may still need to occur. It is also possible that the EAP peer's access policy was not satisfied during the EAP method exchange. For example, the authenticator may not have successfully authenticated to the peer, or may not have demonstrated sufficient authorization to act in multiple roles. For example, in EAP-TLS [RFC2716], the authenticator may have authenticated using a valid TLS server certificate, but not using a valid TLS client certificate. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided a protected result indication to the EAP server indicating that the server had successfully authenticated to it. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 18:03:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02030 for ; Wed, 26 Nov 2003 18:02:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAFD0580016; Wed, 26 Nov 2003 17:03:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 862F358012B; Wed, 26 Nov 2003 17:03:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF3EA58012B for ; Wed, 26 Nov 2003 17:02:41 -0600 (CST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail.frascone.com (Postfix) with ESMTP id C5739580016 for ; Wed, 26 Nov 2003 17:02:36 -0600 (CST) Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2003 15:02:32 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAQN2ViN018390; Wed, 26 Nov 2003 15:02:31 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.113.48]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 26 Nov 2003 15:07:42 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" Cc: Subject: RE: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) Message-ID: <002901c3b471$5eace880$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 26 Nov 2003 23:07:42.0223 (UTC) FILETIME=[1839F9F0:01C3B472] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 15:02:29 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks good. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, November 26, 2003 2:56 PM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) > > > How about this? > > [3] Peer Policy satisfaction. EAP methods may support > protected result indications, enabling the peer to indicate > to the EAP server that it successfully authenticated it. > However, a pass-through authenticator will not be aware that > the peer has accepted the credentials offered to it by the > EAP server, unless this information is provided to the > authenticator via the AAA protocol. As a result, two > authentications, one in each direction, may still need to occur. > > It is also possible that the EAP peer's access policy was not > satisfied during the EAP method exchange. For example, the > authenticator may not have successfully authenticated to the > peer, or may not have demonstrated sufficient authorization > to act in multiple roles. For example, in EAP-TLS [RFC2716], > the authenticator may have authenticated using a valid TLS > server certificate, but not using a valid TLS client > certificate. As a result, the peer may require an additional > authentication in the reverse direction, even if the peer > provided a protected result indication to the EAP server > indicating that the server had successfully authenticated to it. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 19:01:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05109 for ; Wed, 26 Nov 2003 19:01:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06912580016; Wed, 26 Nov 2003 18:01:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DEDD58012B; Wed, 26 Nov 2003 18:01:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 041A3580131 for ; Wed, 26 Nov 2003 18:00:11 -0600 (CST) Received: from chardonnay (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id E902C580016 for ; Wed, 26 Nov 2003 18:00:00 -0600 (CST) Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AP9ZW-0000HR-00; Thu, 27 Nov 2003 00:59:50 +0100 From: Henrik Levkowetz To: Bernard Aboba Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) Message-Id: <20031127005941.2556f51a.henrik@levkowetz.com> In-Reply-To: References: <002401c3b45f$7625fe00$0200000a@amer.cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 27 Nov 2003 00:59:41 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The first paragraph of the replacement text for the end of 2.4 still reads: "Lower layer considerations may dictate whether two EAP authentications, (one in each direction) are required, rather than a single EAP method supporting mutual authentication and protected result indications. These include:" However the list item 3 below seems to me not to really fall into the category of "Lower layer considerations"? Mayby the paragraph quoted above also needs a tweak? Wednesday 26 November 2003, Bernard wrote: > Peer Policy satisfaction. EAP methods may support > protected result indications, enabling the peer to indicate > to the EAP server that it successfully authenticated it. > However, a pass-through authenticator will not be aware that the peer > has accepted the credentials offered to it by the EAP server, unless > this information is provided to the authenticator via the AAA protocol. > As a result, two authentications, one in each direction, may still need > to occur. > > It is also possible that the EAP peer's access policy was not satisfied > during the EAP method exchange. For example, the authenticator may > not have successfully authenticated to the peer, or may not have > demonstrated sufficient authorization to act in multiple roles. > For example, in EAP-TLS [RFC2716], the authenticator may have > authenticated using a valid TLS server certificate, but not using > a valid TLS client certificate. As a result, the peer may require > an additional authentication in the reverse direction, even if > the peer provided a protected result indication to the EAP server > indicating that the server had successfully authenticated to it. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 19:09:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05415 for ; Wed, 26 Nov 2003 19:09:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B6CD580016; Wed, 26 Nov 2003 18:09:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E4FF7580131; Wed, 26 Nov 2003 18:09:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C1BE580131 for ; Wed, 26 Nov 2003 18:08:28 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 132B4580016 for ; Wed, 26 Nov 2003 18:08:23 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAR0RgH04352; Wed, 26 Nov 2003 16:27:43 -0800 From: Bernard Aboba To: Henrik Levkowetz Cc: Joseph Salowey , eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 204 (for RFC 2284bis) In-Reply-To: <20031127005941.2556f51a.henrik@levkowetz.com> Message-ID: References: <002401c3b45f$7625fe00$0200000a@amer.cisco.com> <20031127005941.2556f51a.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 16:27:42 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > "Lower layer considerations may dictate whether two EAP authentications, > (one in each direction) are required, rather than a single EAP > method supporting mutual authentication and protected result indications. > These include:" > > However the list item 3 below seems to me not to really fall into the > category of "Lower layer considerations"? Mayby the paragraph quoted above > also needs a tweak? Good catch! I've gone ahead and tweaked the resolution to address this. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Nov 26 20:58:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08669 for ; Wed, 26 Nov 2003 20:58:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79A0A580016; Wed, 26 Nov 2003 19:58:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3760A58012B; Wed, 26 Nov 2003 19:58:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 299D558012B for ; Wed, 26 Nov 2003 19:57:56 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 3ABB5580016 for ; Wed, 26 Nov 2003 19:57:49 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAR2HCd10900 for ; Wed, 26 Nov 2003 18:17:12 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 2284bis-07 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 26 Nov 2003 18:17:12 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) IETF WG last call has now completed on RFC 2284bis. The -07 version of the document, (incorporating resolutions to all submitted issues) is available here, prior to showing up on the IETF archive next week: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-rfc2284bis-07.txt Many thanks to Henrik Levkowetz for his excellent (and expeditious!) editorial work on -07. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 27 04:22:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01299 for ; Thu, 27 Nov 2003 04:22:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 68141580016; Thu, 27 Nov 2003 03:22:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 437F658012B; Thu, 27 Nov 2003 03:22:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22E0E580016 for ; Thu, 27 Nov 2003 03:21:59 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id B7F2958012B for ; Thu, 27 Nov 2003 03:21:56 -0600 (CST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAR9LsQ05776 for ; Thu, 27 Nov 2003 11:21:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Nov 2003 11:21:54 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 11:21:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C38B9@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 196: Peer SM Issues Thread-Index: AcOn4HW1ya7/i+9JSZKD2sqMEiN2GQM5zrEg From: To: , X-OriginalArrivalTime: 27 Nov 2003 09:21:54.0637 (UTC) FILETIME=[E5FA17D0:01C3B4C7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of Issue 196: Peer SM Issues Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 27 Nov 2003 11:21:53 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Here's my proposal for resolving issue 196: - Add "processIdentity(eapReqData)" to IDENTITY state (as first line) to show that the Identity Request may contain something=20 that needs to be processed. It seems that NOTIFICATION state needs something similar ("processNotify(eapReqData)"). We also need to describe these procedures in Section 4.4: processIdentity(): Process the contents of Identity Request. processNotify(): Process the contents of Notification Request (for instance, display it to the user or log it). - If Issue 198 removes the EapTunnelled variable, most of=20 the points below are solved. - No change for first point (in IEEE notation, terminal states are identified by having no outgoing transitions; and the=20 peer doesn't send any packets at this point). Best regards, Pasi > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Bernard Aboba > Sent: Tuesday, November 11, 2003 12:36 AM > To: eap@frascone.com > Subject: [eap] Issue 196: Peer SM Issues >=20 >=20 > Issue 196: Peer SM Issues > Submitter name: Ashwin Palekar > Submitter email address: ashwinp@microsoft.com > Date first submitted: Nov 10, 2003 > Reference: > Document: SM-01 > Comment type: T > Priority: S > Section: 4 > Rationale/Explanation of issue: >=20 > In Figure 3, it is not clear from the diagrams that SUCCESS > and FAILURE are terminal states; perhaps a function call is > necessary to cause the packet to be sent. > > EapTunnelled should probably be a function call rather than > a variable, so that there is no confusion that it is set > when the tunnelled method is selected and applies to either > cleartext or tunnelled packets. >=20 > The EapTunnelled variable does not describe the behavior > of current tunneled methods such as PEAP. For example > the state IDENTITY is reached from the RECEIVED state > if (selectedMethod =3D=3D NONE || EapTunnelled). However > inside PEAP, an Identity can't be sent when a method > has been selected and isn't complete. >=20 > Similarly, the transition from RECEIVED to GET_METHOD > seems to occur on EapTunnell =3D=3D TRUE even if a method > has previously been selected and is in progress. This seems=20 > wrong. > > Suggest adding a getIdentity() call in the IDENTITY state, > which can take into account the information that the peer > has available, in order to determine the appropriate > identity to put into the EAP-Response/Identity. This > could include, for example, "hints" in the EAP-Request/Identity, > default settings in the peer, etc. > > The state machine doesn't appear to suppport sequences > of authentication methods within tunnels. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 27 04:51:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01991 for ; Thu, 27 Nov 2003 04:51:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9D63580016; Thu, 27 Nov 2003 03:52:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7B1C558012B; Thu, 27 Nov 2003 03:52:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 56C9C58012B for ; Thu, 27 Nov 2003 03:51:11 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 65646580016 for ; Thu, 27 Nov 2003 03:51:09 -0600 (CST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAR9p8Q16595 for ; Thu, 27 Nov 2003 11:51:08 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 27 Nov 2003 11:51:07 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 27 Nov 2003 11:51:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612232F@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 195: Backend Authenticator SM review Thread-Index: AcOn4JIrhEx5EbEcTBqpSvGe3bYhaAM6Uagg From: To: , X-OriginalArrivalTime: 27 Nov 2003 09:51:07.0125 (UTC) FILETIME=[FA8A8A50:01C3B4CB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of Issue 195: Backend Authenticator SM review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 27 Nov 2003 11:51:06 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Here's my proposal for issue 195: - Change .ps to .pdf everywhere. - Section 4.3.1 already says the EAP type can be an expanded type, and that if it's an expanded type, it also contains "254" (that's why the variable type is "EAP Type" and not "integer").=20 So we can already tell Legacy and Expanded Naks apart... - In Section 7.1.1, change "aaaMethodTimeout (integer): Method-provided hint for suitable retransmission timeout, or NONE."=20 to =20 "aaaMethodTimeout (integer): Method-provided hint for suitable retransmission timeout, or NONE (note that this hint is for=20 the EAP retransmissions done by the passthrough authenticator, not retransmissions of AAA packets)." =20 Best regards, Pasi > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Bernard Aboba > Sent: Tuesday, November 11, 2003 12:37 AM > To: eap@frascone.com > Subject: [eap] Issue 195: Backend Authenticator SM review >=20 >=20 > Issue 195: Backend Authenticator SM review > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 8, 2003 > Reference: > Document: SM-01 > Comment type: T > Priority: S > Section: Multiple > Rationale/Explanation of issue: >=20 > pp. 21, Section 6 >=20 > It's draft-ietf-eap-statemachine-01.pdf, not .ps, no? >=20 > pp. 22, Figure 5 >=20 > respMethod has the same value if it is a NAK or an expanded NAK. >=20 > pp. 23 >=20 > The definition of aaaMethodTimeout should make it clear that this > method-provided hint is not used to control the AAA timeout, only > the value of the Session-Timeout attribute sent by AAA. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Nov 27 16:49:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19522 for ; Thu, 27 Nov 2003 16:49:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 83E5C58012F; Thu, 27 Nov 2003 15:49:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47598580017; Thu, 27 Nov 2003 15:49:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCBDA580016 for ; Thu, 27 Nov 2003 15:48:46 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5EF0B580017 for ; Thu, 27 Nov 2003 15:48:43 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 14D756A902; Thu, 27 Nov 2003 23:48:41 +0200 (EET) Message-ID: <3FC6702F.3020603@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" , Bernard Aboba , Margaret Wasserman , Thomas Narten Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] EAP WG Summary Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 27 Nov 2003 23:44:15 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The ADs have requested that a summary of the situation of each WG be posted after each meeting. The summary should include information about what decisions were taken in the meeting, what the action items exist, whether the WG milestones are up-to-date, if there's a need to update the charter, and so on. So this is the summary as Bernard and I see it. Please note your action items, and if you find something missing or wrong, let us know. --Jari EAP WG Summary, IETF-58 EVENTS o EAP Base Specification (2284bis) is in IETF Last Call ending on Nov 26 (Note: It has now ended. The -07 version of the document, incorporating resolutions to all submitted issues, is available here, prior to showing up on the IETF archive next week: http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-rfc2284bis-07.txt) o EAP State Machine document in in WG Last Call ending on Nov 19. (Note: it has now ended, 8 issues were raised: 193, 194, 195, 196, 197, 198, 199, and 203. For details, see: http://www.drizzle.com/~aboba/EAP/eapissues.html The issues were substantitive enough that once they are resolved and an -02 document is published, we will go through EAP WG last call again.) ONGOING WORK o EAP Keying Framework (draft-ietf-eap-keying-01.txt) is being worked on. A number of open issues exist against the document. o Several method definitions are being worked on by individual contributors. These documents have been held up in queue during the 2284bis work. The documents have been briefly discussed in EAP WG, but are for the most part intended as Individual submissions outside the WG, once the 2284bis IANA rules are in effect. DECISIONS o The EAP WG will look at the network selection problem. o Merge the contents of EMSK related issues from draft-salowey-eap-key-deriv-02.txt into the EAP Keying Framework draft. o ADs support the current 2284bis IANA rules i.e. that EAP codepoints should be allocated on the basis of expert review. INPUT TO THE WG o Stephen Hayes, 3GPP, told the WG that 3GPP's wishes for EAP include currently the base specifications, EAP-AKA, EAP-SIM, and some solution for network selection. There are no known other wishes. o IEEE's desires for new generally applicable EAP methods, as documented in their earlier liaison statements, are still in effect. ACTION ITEMS o Initiate a mailing list discussion to define the goals and constraints for network selection (Jari Arkko, Nov 30, 2003) o Produce solution proposal(s) for the network selection (Farid & others, Jan 2004) o Define which parts of IKEv2 can be used in EAP IKEv2 method (draft-tschofenig-eap-ikev2-02.txt). Possibly e.g. address configuration makes no sense within EAP. (Dirk Kroeselberg, Dec 30, 2003) o Review and hopefully approve the 2284bis document (IESG, Dec 15, 2003) o Correct the issues raised in the WG last call on the EAP State Machine document, and issue a new draft. (Pasi Eronen and Nick Petroni, Dec 5) o Issue a new WG Last Call on the EAP State Machine document. (Chairs, Dec 10) o Propose resolutions to the open issues in the EAP Keying Framework document. (Keying Design Team members, Dec 20) o Text suggestion for the additional EMSK-related content for EAP Keying Framework Draft (Joe Salowey, Dec 15, 2003) o Issue a WG Last Call on the EAP Keying Framework document (Chairs, Jan 20) o Charter update (Chairs and ADs, Dec 30) CHARTER MILESTONES o The keying problem document milestone needs to be changed: to say 'Feb 04' instead of the current 'Jun 03'. Does the WG feel that Feb 04 is realistic? CHARTER REVIEW o We expect that charter items 1-4 and 6-7 are going to be approved soon in the EAP Base Specification (2284bis). And item 5 is going to be approved relatively soon after that in the EAP State Machine specification. This leaves just the keying issues on the charter, as the rest should be removed as we move on. o It would be useful to add the EAP Binding Issues to the charter as well under its own item. It is expected that this work can complete in early 2004, though the lack of reviewers has been an issue. o In addition, the WG wishes network selection issues to be studied. A new charter item would be needed for that. o A number of methods have been proposed, but most of the authors desire an Individual submission route rather than a WG item and a Standards Track path. It is expected that future EAP methods and their authors are interested in Standards Track and WG charter items, but the charter can be changed later when this need arises. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 28 06:11:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23442 for ; Fri, 28 Nov 2003 06:10:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B579D580016; Fri, 28 Nov 2003 05:11:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9EDC580017; Fri, 28 Nov 2003 05:11:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CC604580017 for ; Fri, 28 Nov 2003 05:10:38 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id BF313580016 for ; Fri, 28 Nov 2003 05:10:36 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hASBAZM24414 for ; Fri, 28 Nov 2003 13:10:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 28 Nov 2003 13:10:29 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 13:10:29 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 28 Nov 2003 13:10:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C38BC@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 194: Standalone Authenticator SM review Thread-Index: AcOnjEquG0ze7i/USiCG0ydfbgyevgOE3wHg From: To: , X-OriginalArrivalTime: 28 Nov 2003 11:10:29.0568 (UTC) FILETIME=[3B976C00:01C3B5A0] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution of Issue 194: Standalone Authenticator SM review Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 28 Nov 2003 13:10:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, Here's my proposal for issue 194: - Move prototype of m.getTimeout as proposed. The other points don't IMHO need any changes: - The packet is handed over using variables (eapReq/eapReqData), so no function calls are needed. - As I mentioned in issue 195, respMethod is not a plain=20 integer, so the authenticator can already tell them apart. Best regards, Pasi > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Bernard Aboba > Sent: Monday, November 10, 2003 2:32 PM > To: eap@frascone.com > Subject: [eap] Issue 194: Standalone Authenticator SM review >=20 >=20 > Issue 194: Standalone Authenticator SM review > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: Nov 8, 2003 > Reference: > Document: SM-01 > Comment type: T > Priority: S > Section: 5, 5.1 > Rationale/Explanation of issue: > pp. 17, page 52 >=20 > m.getTimeout prototype should be after the paragraph > explaining what m.buildReq does, not before. >=20 > pp. 15, Figure 4 >=20 > Shouldn't there be a function in SEND_REQUEST state > to actually hand the packet over to the lower layer? >=20 > The Type code for NAK and EXPANDED_NAK > are the same, so that the definition of > respMethod should probably be modified. >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 28 08:35:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26982 for ; Fri, 28 Nov 2003 08:35:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E05DE580016; Fri, 28 Nov 2003 07:35:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7587558012B; Fri, 28 Nov 2003 07:35:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D8AB58012B for ; Fri, 28 Nov 2003 07:34:58 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 1E509580016 for ; Fri, 28 Nov 2003 07:34:57 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B0EBC6A903; Fri, 28 Nov 2003 15:34:55 +0200 (EET) Message-ID: <3FC74DF4.5040308@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aboba@internaut.com, eap@frascone.com Subject: Re: [eap] Proposed resolution of Issue 194: Standalone Authenticator SM review References: <052E0C61B69C3741AFA5FE88ACC775A6010C38BC@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38BC@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 28 Nov 2003 15:30:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Hi, > > Here's my proposal for issue 194: > > - Move prototype of m.getTimeout as proposed. > > The other points don't IMHO need any changes: > > - The packet is handed over using variables (eapReq/eapReqData), > so no function calls are needed. > > - As I mentioned in issue 195, respMethod is not a plain > integer, so the authenticator can already tell them apart. Agreed. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 28 12:12:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04016 for ; Fri, 28 Nov 2003 12:12:02 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91DB4580131; Fri, 28 Nov 2003 11:12:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1880958012B; Fri, 28 Nov 2003 11:12:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 29BBA580016 for ; Fri, 28 Nov 2003 11:11:41 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 34E9E58012B for ; Fri, 28 Nov 2003 11:11:39 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7AD726A901; Fri, 28 Nov 2003 19:11:38 +0200 (EET) Message-ID: <3FC780BF.1020808@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "eap@frascone.com" , "Adrangi, Farid" , Pasi Eronen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] network discovery & selection: problem definition Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 28 Nov 2003 19:07:11 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Folks, In IETF-58 we discussed network discovery and selection issues, and the straw poll indicated that the WG wants to work on this. I'd like initiate a discussion on the problem definition for this work before actually adopting it as something that the EAP WG intends to standardize. As a result of the discussion, we should know what the issue is, what functions are required, and what constraints should be placed on a potential solution. Here is the plan for the discussion: o All input should be received by December 15. The goal is to have also a common understanding of the problem by then. o Lets keep the actual solution discussion separate. In other words, lets not talk about the pros and cons of different approaches, or where this functionality should be placed in terms of the network or the protocol stack. o The results of the discussion will be summarized by the chairs. The need for documentation in the form of a draft will be determined during the process. o Next steps after this discussion has been concluded include another discussion & possible drafts in the solution space. At that time we also need to make a decision whether the work should stay in the EAP WG or be moved elsewhere. The following is my first cut at the problem definition. Comments appreciated -- I'd be happy if you can shoot my definition down. I have included a few questions within the definition -- if you have answers I'm sure the group would like to hear them. The primary network discovery and selection issue is routing within the AAA infrastructure, giving access to the user from the right home AAA and via the right AAA proxies. Currently, we have the NAI [RFC2486] functionality. NAIs allow users to specify their domain so that the AAA requests can be routed to the right home AAA servers. However, this does not provide support for the following: o Ability of the client to know which of his multiple home networks are available from a given access? Can I get to jari.arkko@ericsson.com, or only to jarkko@piuha.net? o Ability of the AAA requests to be routed correctly where there is no complete, global AAA routing table. Deployed AAA mechanisms use an essentially statically configured local routing tables, there is no e.g. link state routing protocols for AAA. Such local mechanisms are sufficient when there limited amout of branching in the AAA network. For instance, there is no need for a global routing table if all your clients are either locally authenticated or served by one other entity (such as a global ISP, teleoperator, or a roaming consortium). However, if the access network supports two different intermediaries, it becomes necessary to figure out which intermediary handles the domain given in a NAI. Question: what is the expected number of intermediaries per one network hop? Can you cite current numbers from existing networks, or projections of future network topologies? Question: Is it necessary to support multiple levels of selection, e.g. go first to intermediary 1, then to intermediary 2, etc? o For commercial reasons, intermediaries want to participate the AAA transaction. Question: Is there a need for someone else than the access network to control the routing to go via a special intermediary? This is not very clear to me. o For the purposes of choosing an intermediary with specific properties, users may wish to control network selection, or at least wish to be aware of the results. For instance, I can get to @ericsson.com either via piuha.net or commercialoperator.net, but since I want to go via piuha.net since it is free for me. Question: what are the security requirements for this? This is bordering on solution space, but as far as I know, none of the proposed mechanisms can support secure advertisements or secure selection indications. Is this acceptable? Question: what kind of information needs to be presented in protocols vs. provisioned in the clients vs. simply told to the user off-line? It seems that it would be possible to provide network name over protocols, but a standardized format for offered CoS of QoS would probably not be possible. An interesting twist in the AAA routing problem is that all the above has to work for requests, responses, as well as server-initiated messages. The network discovery and selection problem is closely related to the problem of access point discovery and selection in wireless networks. The two problems coincide when each access point offers exactly one network over one AAA route. However, the network discovery and selection problem may exist even where there is just one access point to attach to, if it offers multiple networks or multiple routes to these networks. During the discussion of solutions for these problems, it has become apparent that there are some additional constraints that may have to be placed on solutions. Some of the possible constraints are listed below: o Solution can be adopted for the whole network without requiring changes to the largest base of installed devices -- access points and clients. o Allow interoperability with clients, access networks, AAA proxies, and AAA servers that have not been modified to support network discovery and selection. o Works on all AAA protocols. o Does not prevent the introduction of new AAA or access network features, such as link-state AAA routing protocols (pretty far fetched) or fast handoffs. o Does not consume a significant amount of resources, such as bandwidth or network attachment time. o Does not cause a problem with limited packet sizes of current protocols. Further discussion can be found from http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt (including some solution space issues too). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 28 14:49:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08179 for ; Fri, 28 Nov 2003 14:49:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6470580016; Fri, 28 Nov 2003 13:49:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6792E580017; Fri, 28 Nov 2003 13:49:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79751580017 for ; Fri, 28 Nov 2003 13:48:36 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id C1A27580016 for ; Fri, 28 Nov 2003 13:48:34 -0600 (CST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hASJmWt01174 for ; Fri, 28 Nov 2003 14:48:32 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hASJprk10226 for ; Fri, 28 Nov 2003 14:51:53 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hASJcUpH013457 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 28 Nov 2003 14:38:31 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hASJcTED013453 for ; Fri, 28 Nov 2003 14:38:30 -0500 To: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: Your message of "Fri, 28 Nov 2003 19:07:11 +0200." <3FC780BF.1020808@piuha.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <13452.1070048309@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Fri, 28 Nov 2003 14:38:29 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- An additional area, maybe out of scope: how do I know that these intermediaries are legitimate, vs MITM? i.e. how do I avoid being tricked into selecting the wrong network? - -or- do I believe anything I've discovered? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8ekM4qHRg3pndX9AQF+4gQAhU3oIHbn9k6zgClcE4CFMHoEApiU/xZU 7LOz4VqBo5BR6Mwl+o8Q2bIcCLgfVtWpixA0B6Wa2ON+KH55cJSMtVz/bsTui0UI mQbY/nr3RCDmYv6MKGzFy2qrdRqN92Vq12I4s1dlqQUvZ74VbiEIMh8nEsX1hdeY ljMiGhoSDSs= =vQ1n -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Fri Nov 28 17:31:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13985 for ; Fri, 28 Nov 2003 17:31:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7DFB580016; Fri, 28 Nov 2003 16:31:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 13D5C580017; Fri, 28 Nov 2003 16:31:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A00D580016 for ; Fri, 28 Nov 2003 16:30:59 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 2BC66580017 for ; Fri, 28 Nov 2003 16:30:57 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A43D06A901; Sat, 29 Nov 2003 00:30:55 +0200 (EET) Message-ID: <3FC7CB94.4090501@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Cc: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition References: <13452.1070048309@marajade.sandelman.ottawa.on.ca> In-Reply-To: <13452.1070048309@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 29 Nov 2003 00:26:28 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Michael Richardson wrote: > An additional area, maybe out of scope: > how do I know that these intermediaries are legitimate, vs MITM? I suppose they still have to be legitimate AAA proxies. That is, an access network should not send your request to an unknown intermediary. If it has a business relationship with three intermediaries int1.com, int2.com, and int3.com, it will route your request through one of them, even if you tried to request routing through mitm.org. Its good that you brought this up! This is a requirement. And if we don't write it down, an implementation might actually forget to check this. An additional issue is that even if the intermediaries are legitimate, they could be switched. For instance, an access network could advertise that it has a deal with elcheapointermediary.net, and then switch the user's selection to pricey.com instead. To make this relevant, the pricing would have to be based on the intermediary. Furthermore, even if were to secure the selection, we would be unable to guarantee that the QoS or other properties claimed by the network were indeed provided. This leads me to think that at the moment, the advertisements and selections cannot be more than hints, and everyone should be made aware of that. Typically, non-protocol means are used to detect problems like that. [Solution space: Independent of the network selection issue, some of us have talked about ways to authenticate claims made by access points and service selections picked by the client. It looks like we could do it as a backwards compatible extension of popular EAP methods such as EAP-TLS or EAP-SIM. I would rather design a general feature for such protection rather than somethign specific for network selection.] --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sat Nov 29 20:40:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04922 for ; Sat, 29 Nov 2003 20:40:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D230580132; Sat, 29 Nov 2003 19:40:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C15958012F; Sat, 29 Nov 2003 19:40:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C2E058012F for ; Sat, 29 Nov 2003 19:39:02 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id CB720580017 for ; Sat, 29 Nov 2003 19:38:59 -0600 (CST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAU1cet07265 for ; Sat, 29 Nov 2003 20:38:40 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAU1g2H20657 for ; Sat, 29 Nov 2003 20:42:02 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hATNYcpH015127 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 29 Nov 2003 18:34:39 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hATNYZXc015123 for ; Sat, 29 Nov 2003 18:34:38 -0500 To: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: Your message of "Sat, 29 Nov 2003 00:26:28 +0200." <3FC7CB94.4090501@piuha.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <15122.1070148875@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sat, 29 Nov 2003 18:34:35 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> Michael Richardson wrote: >> An additional area, maybe out of scope: >> how do I know that these intermediaries are legitimate, vs MITM? Jari> I suppose they still have to be legitimate AAA proxies. Jari> That is, an access network should not send your request to Jari> an unknown intermediary. If it has a business relationship Jari> with three intermediaries int1.com, int2.com, and int3.com, Jari> it will route your request through one of them, even if you Jari> tried to request routing through mitm.org. It is more immediate than that. Let's assume that there are two competing hotspots, physically adjacent to each other. The signal is available in both locations. Both are using NAT. Call the two operators DeltaCoffee and GammaCoffee. They are using ESSID "delta" and "gamma". Both make deals with arkohotspotproxy.com, the most popular clearing house for EAP-AKA based payments. However, GammaCoffee has found a way to make money without spending much. They set their ESSID to "delta", and respond to EAP. As a supplicant, one could get a EAP Request from either one. Let's say that I get one from GammaCoffee's AP. It takes my request, goes back on the wireless, authenticates against arkohotspotproxy.com using radius. Yes, passing the packets to DeltaCoffee's AP, to which it has already authenticated *itself* with. The supplicant and authenticator do their thing, and then the supplicant gets an IP address from GammaCoffee's AP. supplicant's packets are NAT'ed by Gamma, and sent to Delta (who NATs them again). The result: Gamma gets a revenue stream from arkohotspotproxy.com Delta pays for the bandwidth If the charges are based upon per-byte, then maybe Gamma has to pay Delta as much as it takes in. If they are based upon time, then Gamma wins. (Best is if Gamma manages to steal a username/password along the way, from some user that is willing to do username/password instead of something that is secure) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8ktCYqHRg3pndX9AQEYsAP+JIaS2/99nwcOgyAdzu/hhJ8RRbmD5DPn MxKKWmxvnDKwCZL35AEH7eIxZT+y4hgKPas43+HA77eIudbQcTiu30mXhq2pfsCl g47PhyzbBtiPH19KHDOpK2eqnM4GG5zyqUf8++X50dgNfefqwp0Io/+w9kINJleC NGlSKptV0BI= =vT5n -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 30 05:07:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26906 for ; Sun, 30 Nov 2003 05:07:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B655580017; Sun, 30 Nov 2003 04:07:11 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2593A580023; Sun, 30 Nov 2003 04:07:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 958F8580023 for ; Sun, 30 Nov 2003 04:06:03 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id CDB52580017 for ; Sun, 30 Nov 2003 04:06:01 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E54F46A902; Sun, 30 Nov 2003 12:05:59 +0200 (EET) Message-ID: <3FC9BFFC.3070808@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Cc: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition References: <15122.1070148875@marajade.sandelman.ottawa.on.ca> In-Reply-To: <15122.1070148875@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 30 Nov 2003 12:01:32 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>>>"Jari" == Jari Arkko writes: > > Jari> Michael Richardson wrote: > > >> An additional area, maybe out of scope: > >> how do I know that these intermediaries are legitimate, vs MITM? > > Jari> I suppose they still have to be legitimate AAA proxies. > Jari> That is, an access network should not send your request to > Jari> an unknown intermediary. If it has a business relationship > Jari> with three intermediaries int1.com, int2.com, and int3.com, > Jari> it will route your request through one of them, even if you > Jari> tried to request routing through mitm.org. > > It is more immediate than that. Ok, reading on... > Let's assume that there are two competing hotspots, physically adjacent > to each other. The signal is available in both locations. Both are using > NAT. > > Call the two operators DeltaCoffee and GammaCoffee. They are using ESSID > "delta" and "gamma". Both make deals with arkohotspotproxy.com, the most > popular clearing house for EAP-AKA based payments. > > However, GammaCoffee has found a way to make money without spending much. > They set their ESSID to "delta", and respond to EAP. This could happen, yes. > As a supplicant, one could get a EAP Request from either one. Let's say > that I get one from GammaCoffee's AP. It takes my request, goes back on the > wireless, authenticates against arkohotspotproxy.com using radius. Yes, > passing the packets to DeltaCoffee's AP, to which it has already > authenticated *itself* with. Are you thinking that the GammaCoffee's AP simply has its own userid for access to DeltaCoffee, or some sort of a mitm authentication attack? I am assuming the former, because I do not see the mitm authentication attack here. Only one of the access points gets the session keys from the home AAA. The other AP would not, and hence one of the AP could not complete the 4-way handshake or send/receive packets. > The supplicant and authenticator do their thing, and then the supplicant > gets an IP address from GammaCoffee's AP. supplicant's packets are NAT'ed by > Gamma, and sent to Delta (who NATs them again). > > The result: > Gamma gets a revenue stream from arkohotspotproxy.com > Delta pays for the bandwidth > > If the charges are based upon per-byte, then maybe Gamma has to pay Delta > as much as it takes in. If they are based upon time, then Gamma wins. > (Best is if Gamma manages to steal a username/password along the way, > from some user that is willing to do username/password instead of something > that is secure) I think I see your attack (if my assumption above was correct). Its an interesting attack, though I'm not sure how specific it is to network selection or even to authentication mechanisms such as EAP. Here's why: the current network access mechanisms enable us to have authentication, and link layer protection. They do not, however, guarantee anything about the delivery of the actual payload packets. In particular, there is no guarantee that the payload packets are delivered through a right route, or NATed only up to some specific number of times. We could call this the "payload route binding problem". In this problem, authentication and l2 support do not guarantee that the packets are actually routed through the path that appears to have been offered. Basically, if I have a flat fee account *and* a deal with a clearing house, I can offer access to anyone with a per-byte account, NAT their packets, and send the traffic forward on my account, and get a lot of money. The local ISP would not be any wiser, as I could tunnel my AAA packets through him encrypted. The user would not be any wiser either, because there's nothing in 802.11i or EAP that binds the SSID to the authentication. And even if there were, the user wouldn't care about the SSID enough to look at it. You would probably be breaking the contract with your provider, often they have just-one-machine clauses. But it would be hard for them to detect this. In conclusion this looks like an interesting attack. It appears to exist without any network selection functionality, so its a general issue. What would you like to do with this issue - solve or document it? I am not sure if we talk about something like this already in the keying document. Or maybe we should go into business together and start selling software that does this on the background on everyone's PC ;-) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 30 08:17:04 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00497 for ; Sun, 30 Nov 2003 08:17:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA5B6580127; Sun, 30 Nov 2003 07:17:12 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D380580063; Sun, 30 Nov 2003 07:17:08 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3CE0580023 for ; Sun, 30 Nov 2003 07:16:05 -0600 (CST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by mail.frascone.com (Postfix) with ESMTP id 6391D580063 for ; Sun, 30 Nov 2003 07:16:02 -0600 (CST) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hAUDGTv5008279 for ; Sun, 30 Nov 2003 13:16:29 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hAUD5Y616406 for ; Sun, 30 Nov 2003 13:05:34 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003113005155928142 ; Sun, 30 Nov 2003 05:15:59 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 30 Nov 2003 05:15:59 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] network discovery & selection: problem definition Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC207@orsmsx410.jf.intel.com> Thread-Topic: [eap] network discovery & selection: problem definition Thread-Index: AcO24utGqu2CfDrLTCia+6F0NV73vgAWtp+Q From: "Adrangi, Farid" To: "Michael Richardson" , X-OriginalArrivalTime: 30 Nov 2003 13:15:59.0741 (UTC) FILETIME=[18C022D0:01C3B744] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 30 Nov 2003 05:15:59 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Michael, Please see my reply inline (marked by Farid>). BR, Farid -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Michael Richardson Sent: Saturday, November 29, 2003 3:35 PM To: eap@frascone.com Subject: Re: [eap] network discovery & selection: problem definition=20 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" =3D=3D Jari Arkko writes: Jari> Michael Richardson wrote: >> An additional area, maybe out of scope: >> how do I know that these intermediaries are legitimate, vs MITM? Jari> I suppose they still have to be legitimate AAA proxies. Jari> That is, an access network should not send your request to Jari> an unknown intermediary. If it has a business relationship Jari> with three intermediaries int1.com, int2.com, and int3.com, Jari> it will route your request through one of them, even if you Jari> tried to request routing through mitm.org. It is more immediate than that. Let's assume that there are two competing hotspots, physically adjacent to each other. The signal is available in both locations. Both are using NAT.=20 Call the two operators DeltaCoffee and GammaCoffee. They are using ESSID "delta" and "gamma". Both make deals with arkohotspotproxy.com, the most popular clearing house for EAP-AKA based payments. However, GammaCoffee has found a way to make money without spending much. They set their ESSID to "delta", and respond to EAP. Farid> Is this a legal thing to do? That is, having two overlapping hotspots whose ESSID values are the same. It seems that this will create other problems ...! But, let's go on with this assumption. As a supplicant, one could get a EAP Request from either one. Let's say that I get one from GammaCoffee's AP. It takes my request, goes back on the wireless, authenticates against arkohotspotproxy.com using radius. Farid> Okay - here is my interpretation of the above paragraph: the GammaCoffee's AP takes the EAP-Response from the supplicant and puts into an Access-Request and sends it arkohoptsportproxy.com (assuming that there is a business relationship between the two). After a few EAP and EAP-over-RADIUS exchanges, the supplicant authenticates itself to its home service network through GammaCoffee's AP and the arkohotsportproxy.com (the intermediary proxy). Yes, passing the packets to DeltaCoffee's AP, to which it has already authenticated *itself* with. Farid> Here you losing me! Are we still talking about authentication packets here? Who is passing the packets to DeltaCoffee's AP? The supplicant and authenticator do their thing, and then the supplicant gets an IP address from GammaCoffee's AP. supplicant's packets are NAT'ed by Gamma, and sent to Delta (who NATs them again). Farid> How do supplicant's IP packets get sent to Delta hotspot? If it double NATed, I assume that the packets are forwarded by some Access Router within Gamma to Delta. That means that there has to be some business agreement between Gamma and Delta, otherwise Delta can simply drop the packets. =20 The result: Gamma gets a revenue stream from arkohotspotproxy.com Delta pays for the bandwidth If the charges are based upon per-byte, then maybe Gamma has to pay Delta as much as it takes in. If they are based upon time, then Gamma wins.=20 (Best is if Gamma manages to steal a username/password along the way, from some user that is willing to do username/password instead of something that is secure) ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ =20 =20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8ktCYqHRg3pndX9AQEYsAP+JIaS2/99nwcOgyAdzu/hhJ8RRbmD5DPn MxKKWmxvnDKwCZL35AEH7eIxZT+y4hgKPas43+HA77eIudbQcTiu30mXhq2pfsCl g47PhyzbBtiPH19KHDOpK2eqnM4GG5zyqUf8++X50dgNfefqwp0Io/+w9kINJleC NGlSKptV0BI=3D =3DvT5n -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 30 10:42:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03788 for ; Sun, 30 Nov 2003 10:41:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E295F580017; Sun, 30 Nov 2003 09:42:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C4E2580023; Sun, 30 Nov 2003 09:42:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A9022580023 for ; Sun, 30 Nov 2003 09:41:48 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 58977580017 for ; Sun, 30 Nov 2003 09:41:46 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAUG0Qp19039 for ; Sun, 30 Nov 2003 08:00:42 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: network discovery & selection: problem definition Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 30 Nov 2003 08:00:26 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I'd suggest that there are three somewhat orthogonal problems being discussed under the rubric of "network selection". First, there is the problem of "Network discovery". This is the problem of discovering access networks available in the vicinity, and the points of presence (POPs) associated with those networks. Second, there is the problem of "Identifier selection". This is the problem of selecting which identity (and credentials) to use to authenticate to a given POP. Thirdly, there is the problem of "Access routing" which involves figuring out how to route the authentication conversation originating from the selected identity back to the home realm. Network Discovery ----------------- Traditionally, the problem of discovering available networks has been handled out-of-band of EAP. RFC 2194 describes the pre-provisioning of dialup roaming clients, which typically included a list of potential phone numbers, updated by the provider(s) with which the client had a contractual relationship. RFC 3017 describes the IETF Proposed Standard for the Roaming Access XML DTD. This covers not only the attributes of the Points of Presence (POPs) and Internet Service Providers (ISPs), but also hints on the appropriate NAI to be used with a particular POP. In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism provides a way for Stations to discover Access Points (APs), as well as the capabilities of those APs. Among the Information Elements (IEs) included within the Beacon and Probe Response is the SSID, a non-unique identifier of the network to which an Access Point is attached. By combining network identification along with capabilities discovery, the Beacon/Probe facility provides the information required for both network discovery and roaming decisions within a single mechanism. As noted in [Velayos], the Beacon mechanism does not scale well; with a Beacon interval of 100ms, and 10 APs in the vicinity, approximately 32 percent of an 802.11b AP's capacity is used for beacon transmission. In addition, since Beacon/Probe Response frames are sent by each AP over the wireless medium, stations can only discover APs within range, which implies substantial coverage overlap for roaming to occur without interruption. A number of enhancements have been proposed to the Beacon/Probe Response mechanism in order to improve scalability and roaming performance. These include allowing APs to announce capabilities of neighbor APs as well as their own, as proposed in IEEE 802.11k; propagation of discovery information over IP, as handled in the CARD protocol developed within the IETF SEAMOBY WG, etc. Typically scalability enhancement mechanisms attempt to get around Beacon/Probe Response restrictions by sending advertisements at the higher rates which are enabled one the station has associated with an AP. Since these mechanisms run over IP, they can utilize IP facilities such as fragmentation, which the Beacon/Probe Response mechanism cannot. Identity selection ------------------ As networks proliferate, it becomes more and more likely that a given EAP peer may have multiple identities and credential sets, available for use in different situations. For example, the EAP peer may have an account with one or more Public WLAN providers; a corporate WLAN; one or more wireless WAN providers. As a result, the EAP peer has to decide which credential set to use when presented with a given set of potential EAP authenticators. Traditionally, hints useful in identity selection have also been provided out-of-band. For example, via the IETF Proposed Standard Roaming Access XML DTD, a client can select between potential POPs, and then based on information provided in the DTD, determine the appropriate NAI to use with the selected POP. However, it is also possible for hints to be embedded within credentials. In [Housley], usage hints are provided within certificates used for wireless authentication. This involves extending the certificate to include the SSIDs with which the certificate can be used. Access routing -------------- Once the identity has been selected, it is necessary for the authentication conversation to be routed back to the home realm. Within the IETF ROAMOPS WG, a number of approaches were considered for this, including source routing techniques based on the NAI [RFC2486], and techniques relying on the AAA infrastructure. Given the relative simplicity of the roaming implementations described in RFC 2194, static routing mechanisms appeared adequate for the task and it was not deemed necessary to develop dynamic routing protocols. As noted in RFC 2607, RADIUS proxies are deployed not only for routing purposes, but also to mask a number of inadequacies in the RADIUS protocol design, such as the lack of standarized retransmission behavior and the need for shared secret provisioning. By removing many of the protocol inadequacies, introducing new AAA agent types such as Redirects, providing support for certificate-based authentication as well as inter and intra-domain service discovery, Diameter allows a NAS to directly open a Diameter connection to the home realm without having to utilize a network of proxies. This is somewhat analagous to the evolution of email delivery. Prior to the widespread proliferation of the Internet, it was necessary to gateway between SMTP-based mail systems and alternative delivery technologies, such as UUCP and FidoNet, and email-address based source-routing was used to handle this. However, as mail could increasingly be delivered directly, the use of source routing disappeared. As with the selection of certificates by stations, a Diameter client wishing to authenticate with a Diameter server may have a choice of available certificates, and therefore it may need to choose between them. References ---------- [Housley] Housley, R., and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in PPP and Wireless LAN", draft-ietf-pkix-wlan-extns-04.txt, Internet Draft (work in progress), June 2003. [Mishra] Mishra, A., Shin, M. and W. Arbaugh, "An empirical analysis of the IEEE 802.11 MAC layer handoff process", University of Maryland Technical Report, UMIACS-TR-2002-75, 2002. [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 30 11:20:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04299 for ; Sun, 30 Nov 2003 11:20:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82A8B58012D; Sun, 30 Nov 2003 10:21:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86B08580109; Sun, 30 Nov 2003 10:21:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2CE1A580063 for ; Sun, 30 Nov 2003 10:20:54 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 5E27C580017 for ; Sun, 30 Nov 2003 10:20:52 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hAUGdvf21237 for ; Sun, 30 Nov 2003 08:39:57 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Re: [Issue 200] channel binding threats Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 30 Nov 2003 08:39:57 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) It seems to me that the "false SSID" attack brought up by Michael Richardson as part of the "network selection" thread is another variation on the "channel binding" attack that is discussed in Issue 200. That is, the AP advertises an SSID to the user, but presumably does not include this SSID in the Called-Station-Id sent to the AAA server. Can someone take a look at the proposed resolution of Issue 200 and determine whether the issue is being adequately handled? My understanding is that including an exchange of SSIDs within the EAP method would allow the station and AAA server to determine that the AP had launched this attack. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 30 16:20:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13549 for ; Sun, 30 Nov 2003 16:20:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEB6758012D; Sun, 30 Nov 2003 15:20:14 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BEC8580126; Sun, 30 Nov 2003 15:20:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BBA8580063 for ; Sun, 30 Nov 2003 15:19:32 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 427EB580017 for ; Sun, 30 Nov 2003 15:19:30 -0600 (CST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAULIet11123 for ; Sun, 30 Nov 2003 16:18:40 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAULM3V27139 for ; Sun, 30 Nov 2003 16:22:03 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAULGmpH014871 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 Nov 2003 16:16:49 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAULGmkh014867 for ; Sun, 30 Nov 2003 16:16:48 -0500 To: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: Your message of "Sun, 30 Nov 2003 12:01:32 +0200." <3FC9BFFC.3070808@piuha.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <14866.1070227007@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 30 Nov 2003 16:16:47 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> Are you thinking that the GammaCoffee's AP simply has its own Jari> userid for Jari> access to DeltaCoffee, or some sort of a mitm authentication attack? Either way. If DeltaCoffee regularly uses username/password to get online (such as, for instance, for regular customers, or for the "staff" machines), then it is trivial for GammaCoffee to steal such an ID. But, we agree that those methods are inheirently insecure. Jari> I think I see your attack (if my assumption above was correct). Its Jari> an Jari> interesting attack, though I'm not sure how specific it is to Jari> network selection If the customer can figure out which AP belongs to DeltaCoffee and which ones does not, then they customer can input this to their selection algorithm. Btw, this was essentially the situation that we had at the last IETF, except that the "rogue APs" weren't so cooperative as to route our packets. Jari> network access mechanisms enable us to have authentication, and Jari> link layer Jari> protection. They do not, however, guarantee anything about the Jari> delivery of Jari> the actual payload packets. In particular, there is no guarantee Jari> that the Right, so this opens up the whole system up to disputes that one was charged for service that was not received. You included QoS and pricing in your "selection" algorithm. (No service is a QoS) Jari> We could call this the "payload route binding problem". In this Jari> problem, authentication and l2 support do not guarantee that Jari> the packets are actually routed through the path that appears to have Jari> been offered. Basically, if I have a flat fee account *and* a deal If I took a shared key from the EAP EMSK somewhere, and used that to authenticate the DHCP server (3118), it might have a serious positive benefit. In v6 land, we could use the channel created by EAP to provide the certificates for the SEND secured RA. Both ways, that means that we are sure we are speaking at layer 3 to the services that we authenticated at layer two. Jari> a lot of money. The local ISP would not be any wiser, as I could Jari> tunnel Jari> my AAA packets through him encrypted. The user would not be any wiser Jari> either, because there's nothing in 802.11i or EAP that binds the SSID Jari> to the authentication. And even if there were, the user wouldn't care Jari> about the SSID enough to look at it. You would probably be breaking Jari> the contract with your provider, often they have just-one-machine Jari> clauses. But it would be hard for them to detect this. The one-machine clause has effectively died around here, with pretty much all the ISPs selling "network sharing" NAT boxes themselves. Jari> In conclusion this looks like an interesting attack. It appears Jari> to exist without any network selection functionality, so its a Jari> general issue. What would you like to do with this issue - solve Jari> or document it? I am not sure if we talk about something like this Jari> already in the keying document. Or maybe we should go into business Jari> together and start selling software that does this on the background Jari> on everyone's PC ;-) I'd like a way to avoid the attack by careful network selection. If you think it is out of scope - that's fine. But it is, in my opinion one of the major things that has fallen through the cracks between IETF and IEEE. cf. my comment last summer about "subipSEC" ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8pePoqHRg3pndX9AQEjsgQA6FRqTHOIK7K1Y/uzbBhU6nM/wuEsJ+Rd mJ6sUFdq66IX8YoOEUkqpsWj2br2vZeBg8+PAQzWf8wXDLhOHW2c5XM2LyOXKVhw VWOe0kabxKGdH9Lg9bYoKgdGERPMKJQ3zDt4rP9MsBGzZuELgpzcetza/F1398XV 7lMrWcrTZoA= =J4vk -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Sun Nov 30 16:29:18 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13671 for ; Sun, 30 Nov 2003 16:29:12 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59912580127; Sun, 30 Nov 2003 15:29:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5AB5E580063; Sun, 30 Nov 2003 15:29:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9FECC580063 for ; Sun, 30 Nov 2003 15:28:47 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id D8E00580017 for ; Sun, 30 Nov 2003 15:28:45 -0600 (CST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAULSjt11169 for ; Sun, 30 Nov 2003 16:28:45 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hAULW8V27753 for ; Sun, 30 Nov 2003 16:32:08 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAULN1pH015039 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 30 Nov 2003 16:23:02 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hAULN1AU015033 for ; Sun, 30 Nov 2003 16:23:01 -0500 To: eap@frascone.com Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: Your message of "Sun, 30 Nov 2003 05:15:59 PST." <96D13222E704DC4D868F0009F0EE53E10AC207@orsmsx410.jf.intel.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <15032.1070227381@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Sun, 30 Nov 2003 16:23:01 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- mcr> However, GammaCoffee has found a way to make money without spending mcr> much. mcr> They set their ESSID to "delta", and respond to EAP. Farid> Is this a legal thing to do? That is, having two overlapping Farid> hotspots whose ESSID values are the same. It seems that this will Farid> create other problems ...! But, let's go on with this assumption. It is unlicensed space. Everything is legal, as long as you don't exceed the transmit power. Further, multiple APs on the same ESSID - well, that's how we arrange to cover more space. This is a feature of 802.11. At this point, Farid's choice of non-Usenet anti-quoting loses me completely, so he'll have to ask his question again. (see http://www.lemis.com/email/fixing-outlook.html) Farid> Here you losing me! Are we still talking about authentication Farid> packets here? Who is passing the packets to DeltaCoffee's AP? GammaCoffee's AP takes the packets from the client machine, NATs them, and then *retransmits* them to Delta. Farid> How do supplicant's IP packets get sent to Delta hotspot? If it Farid> double NATed, I assume that the packets are forwarded by some Farid> Access Router within Gamma to Delta. That means that there has to Farid> be some business agreement between Gamma and Delta, otherwise Farid> Delta can simply drop the packets. Delta thinks that Gamma is just another flat-rate customer. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8pfs4qHRg3pndX9AQFP/gP/ef/adXhP5xl7nS2jMUCuhkLA0oXpjKRk uXnAkZNgGNb+Kho0j86dftJbbnOeUfH77H7wcxvx4PYp/fNLfTqLDlLbbg5uxf3o 0QjTqmMgCl6AMxexJBCpLROgNOo+ubxA6ARIzaDrBu9Xna/Wz5xTXDTLzfUGj47U Ag8uaHMDiWk= =p8ZX -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap