From tobias.gondrom@gondrom.org Tue Jan 1 01:01:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D3321F8A67 for ; Tue, 1 Jan 2013 01:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.113 X-Spam-Level: X-Spam-Status: No, score=-95.113 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slxJv4JWbeiQ for ; Tue, 1 Jan 2013 01:01:37 -0800 (PST) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 811EE21F8A6B for ; Tue, 1 Jan 2013 01:01:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=B/xewOiSEDzr/CLjym7MxGu2adzgiOQcWZjbI6je+VL8JKTW681elVU2Z3iQdi+xJvyjUujGe/wk3OSXQAMu0OUbt1DI5rVovcMumPR48VjfMPqZ4xk9Oa+At6QBYxgl; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Received: (qmail 21520 invoked from network); 1 Jan 2013 10:01:34 +0100 Received: from 059148230045.ctinets.com (HELO ?10.56.78.172?) (59.148.230.45) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Jan 2013 10:01:34 +0100 Message-ID: <50E2A5EB.7040706@gondrom.org> Date: Tue, 01 Jan 2013 17:01:31 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-trill-oam-req.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------030609060906060507010902" Subject: [secdir] secdir review of draft-ietf-trill-oam-req X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 09:01:37 -0000 This is a multi-part message in MIME format. --------------030609060906060507010902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments. This ID is informational and specifies requirements for operations, administration and maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links). The document lists requirements from an operational perspective. And less from a security perspective. Section "4.8. Security and Operational considerations" is very brief. And although I like the basic attitude of the first sentence there "Methods MUST be provided to protect against exploitation of OAM framework for security and denial of service attacks." The section is not clear about which requirements might derive from the "protect against exploitation of OAM ...for security...". The draft could benefit from deriving from this security consideration statement a set of clear and specific requirements for OAM for TRILL and/or linking them to the operational requirements listed in the previous sections. Section 5 is just a pointer to section 4.8 and could be merged with section 4.8 and/or removed. It is reasonable to refer to the basic security considerations for TRILL in RFC6325, but it would be good to add/think about requirement implications from security requirements for OAM. Best regards, Tobias --------------030609060906060507010902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments.

This ID is informational and specifies requirements for operations, administration and maintenance (OAM) in TRILL (Transparent Interconnection of Lots of Links).

The document lists requirements from an operational perspective. And less from a security perspective.
Section "4.8. Security and Operational considerations" is very brief.
And although I like the basic attitude of the first sentence there "Methods MUST be provided to protect against exploitation of OAM framework for security and denial of service attacks."
The section is not clear about which requirements might derive from the "protect against exploitation of OAM ...for security...". The draft could benefit from deriving from this security consideration statement a set of clear and specific requirements for OAM for TRILL and/or linking them to the operational requirements listed in the previous sections.

Section 5 is just a pointer to section 4.8 and could be merged with section 4.8 and/or removed.
It is reasonable to refer to the basic security considerations for TRILL in RFC6325, but it would be good to add/think about requirement implications from security requirements for OAM.

Best regards, Tobias


 --------------030609060906060507010902-- From mnot@mnot.net Tue Jan 1 20:12:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86A521F8E1F; Tue, 1 Jan 2013 20:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.783 X-Spam-Level: X-Spam-Status: No, score=-103.783 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sREKAOqNRg3Q; Tue, 1 Jan 2013 20:12:42 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBDC21F8E1E; Tue, 1 Jan 2013 20:12:42 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.74.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BFCE8509B5; Tue, 1 Jan 2013 23:12:39 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 2 Jan 2013 15:12:35 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Donald Eastlake X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-appsawg-json-pointer.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 04:12:43 -0000 Thanks for the review; replies below. On 31/12/2012, at 2:11 PM, Donald Eastlake wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. >=20 > This draft describes two closely related syntaxes for pointers to > objects within a JSON (JavaScript Object Notation) document. One is a > JSON string syntax, the other is a URI fragment identifier for URIs > defined to take such a fragment identifier. >=20 > Security: >=20 > I do not see any security problems with this document. The syntax > appears to be unambiguously specified, including ABNF, and the > Security Considerations Section is adequate and touches on the > potential pit-falls that JSON pointers can contain NULs. >=20 > Miscellaneous: >=20 > I found significant ambiguity in the semantics of a JSON pointer > string. Is the result of the successful evaluation ("evaluation" is a > term used in the draft) of such a pointer string a structure that > points into a JSON document or is it the objection pointed to? It > mostly seems to be an object but it is specifically provided that > array references could point beyond the end of an array and at least > in that case perhaps some sort of pointer structure would be returned > with the error condition. It probably doesn't matter, because these > syntaxes are intended to be used in a variety of applications and it > will be up to the application to clarify the semantics. I think it's purposefully ambiguous, to accommodate a variety of = applications. > Minor: >=20 > The expansion for the acronym JSON should be given in the title and = abstract. In SVN. > In the first line of the second paragraph of Section 6, I found the > word "nominate" kind of odd. Why not "specify" or "select" or "use"? In SVN. > None of the Authors Addresses given includes a postal address. Yes. -- Mark Nottingham http://www.mnot.net/ From d3e3e3@gmail.com Tue Jan 1 21:18:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FE021E8049; Tue, 1 Jan 2013 21:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeMD9OQ+9MRb; Tue, 1 Jan 2013 21:18:40 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F79921E8042; Tue, 1 Jan 2013 21:18:39 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so12543059obc.17 for ; Tue, 01 Jan 2013 21:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iW7C9D08kI8u+BF5dQJkhF226hMG9ilm1JJHrOjvpKg=; b=BkXUBdLcSMHxwIJj+llhEukVgdAiNJzEdCdc41gLqM3NTngewzZFuccs/Hff3BbwmL 7Jl1nHQbKVSv4t6kmp3x47Eyaygj2AQtpCg40k7WWQkmlWplLGcw7Yj9gGhRL114AHdB vxK2xj82LpZM5iz+lbqSctJGNWUDs8QNdEVuuxEHPia2VpwyqO0qAp0291fwT+8B/Xz2 V5Xum85Hkf2K+iUK4ERXBxgPZ4NvMzqIuG/cwFM9G81RmF3e8hc/RKb44J6uAV0/SuOw yPcvV9zq4bg3sHiFPkcKb5c66c9SdGzASr45ypsCX52QwWCx992987Q8TpP4RVEh1hhP 9yNw== Received: by 10.182.185.12 with SMTP id ey12mr37503480obc.7.1357103919354; Tue, 01 Jan 2013 21:18:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.144.105 with HTTP; Tue, 1 Jan 2013 21:18:19 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Wed, 2 Jan 2013 00:18:19 -0500 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-appsawg-json-pointer.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 05:18:41 -0000 Hi Mark, On Tue, Jan 1, 2013 at 11:12 PM, Mark Nottingham wrote: > Thanks for the review; replies below. > > On 31/12/2012, at 2:11 PM, Donald Eastlake wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. Document editors and WG chairs should treat these comments just >> like any other last call comments. >> >> This draft describes two closely related syntaxes for pointers to >> objects within a JSON (JavaScript Object Notation) document. One is a >> JSON string syntax, the other is a URI fragment identifier for URIs >> defined to take such a fragment identifier. >> >> Security: >> >> I do not see any security problems with this document. The syntax >> appears to be unambiguously specified, including ABNF, and the >> Security Considerations Section is adequate and touches on the >> potential pit-falls that JSON pointers can contain NULs. >> >> Miscellaneous: >> >> I found significant ambiguity in the semantics of a JSON pointer >> string. Is the result of the successful evaluation ("evaluation" is a >> term used in the draft) of such a pointer string a structure that >> points into a JSON document or is it the objection pointed to? It >> mostly seems to be an object but it is specifically provided that >> array references could point beyond the end of an array and at least >> in that case perhaps some sort of pointer structure would be returned >> with the error condition. It probably doesn't matter, because these >> syntaxes are intended to be used in a variety of applications and it >> will be up to the application to clarify the semantics. > > I think it's purposefully ambiguous, to accommodate a variety of applications. OK. >> Minor: >> >> The expansion for the acronym JSON should be given in the title and abstract. > > In SVN. What does that mean? If you mean to say that you agree with the change suggested and that it will be in the next version posted, you should say that. >> In the first line of the second paragraph of Section 6, I found the >> word "nominate" kind of odd. Why not "specify" or "select" or "use"? > > In SVN. Same response as above. >> None of the Authors Addresses given includes a postal address. > > Yes. I think they should. I find that such corner cutting typically goes with other sloppiness. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > -- > Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jan 1 21:20:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA61321E8049; Tue, 1 Jan 2013 21:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.765 X-Spam-Level: X-Spam-Status: No, score=-103.765 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnrP5JCzJVxN; Tue, 1 Jan 2013 21:20:32 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B821E8042; Tue, 1 Jan 2013 21:20:31 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.74.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 75034509B5; Wed, 2 Jan 2013 00:20:29 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: Date: Wed, 2 Jan 2013 16:20:25 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <96188DBD-355B-4363-B8EA-C969EE6F6B77@mnot.net> References: To: Donald Eastlake X-Mailer: Apple Mail (2.1499) Cc: draft-ietf-appsawg-json-pointer.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 05:20:46 -0000 On 02/01/2013, at 4:18 PM, Donald Eastlake wrote: > Hi Mark, >=20 > On Tue, Jan 1, 2013 at 11:12 PM, Mark Nottingham = wrote: >> Thanks for the review; replies below. >>=20 >> On 31/12/2012, at 2:11 PM, Donald Eastlake wrote: >>=20 >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. Document editors and WG chairs should treat these comments = just >>> like any other last call comments. >>>=20 >>> This draft describes two closely related syntaxes for pointers to >>> objects within a JSON (JavaScript Object Notation) document. One is = a >>> JSON string syntax, the other is a URI fragment identifier for URIs >>> defined to take such a fragment identifier. >>>=20 >>> Security: >>>=20 >>> I do not see any security problems with this document. The syntax >>> appears to be unambiguously specified, including ABNF, and the >>> Security Considerations Section is adequate and touches on the >>> potential pit-falls that JSON pointers can contain NULs. >>>=20 >>> Miscellaneous: >>>=20 >>> I found significant ambiguity in the semantics of a JSON pointer >>> string. Is the result of the successful evaluation ("evaluation" is = a >>> term used in the draft) of such a pointer string a structure that >>> points into a JSON document or is it the objection pointed to? It >>> mostly seems to be an object but it is specifically provided that >>> array references could point beyond the end of an array and at least >>> in that case perhaps some sort of pointer structure would be = returned >>> with the error condition. It probably doesn't matter, because these >>> syntaxes are intended to be used in a variety of applications and it >>> will be up to the application to clarify the semantics. >>=20 >> I think it's purposefully ambiguous, to accommodate a variety of = applications. >=20 > OK. >=20 >>> Minor: >>>=20 >>> The expansion for the acronym JSON should be given in the title and = abstract. >>=20 >> In SVN. >=20 > What does that mean? If you mean to say that you agree with the change > suggested and that it will be in the next version posted, you should > say that. It does. Could it mean something else, I wonder? >>> In the first line of the second paragraph of Section 6, I found the >>> word "nominate" kind of odd. Why not "specify" or "select" or "use"? >>=20 >> In SVN. >=20 > Same response as above. >=20 >>> None of the Authors Addresses given includes a postal address. >>=20 >> Yes. >=20 > I think they should. I find that such corner cutting typically goes > with other sloppiness. Alternatively, it could mean that the authors don't wish to expose their = postal addresses. Or, that they believe that their electronic addresses = will be more stable than physical ones. -- Mark Nottingham http://www.mnot.net/ From barryleiba@gmail.com Wed Jan 2 06:33:09 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F70521F8510; Wed, 2 Jan 2013 06:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McZ4BXwI073O; Wed, 2 Jan 2013 06:33:08 -0800 (PST) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id 748F221F84E8; Wed, 2 Jan 2013 06:33:07 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fk20so6019698lab.22 for ; Wed, 02 Jan 2013 06:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FPQ6OFoAsDQx7VYaa3EJXoVJaBSu+i9+Rc+sJ2nNSUQ=; b=WvrmigfdMhhppT9h1iSsmLZ1Qa9Wugnl5VcKKSrcL4ylWXaIC2XzRoy8epKA2gyQzs ylZIxBiJQbAb7pM/qyC7rLzSCdB/2p+2saJJIn94sikGfvTbDGd9IOSx/ozXQAlcJ7RB vbyTYHgrnw2gTkuC3qR6b+OEQ2LohWHaPD33+Ip+TNwI75L4GzEHTEp8gjhBuaqpkIWH P7iSCYS0GAZjcW96wp9ORLwPAowN++VrHZBJRsRnzEoVpVQUDomvom7ie/Xp8J4nmKmT M2wyOb7ouf9alNhGwSZTNeNWyUYSMaGcPw1LGHnfy2NLUGKQXX2HUiqE2cOMLZHX3WT3 HRgw== MIME-Version: 1.0 Received: by 10.152.45.174 with SMTP id o14mr33618759lam.12.1357137186464; Wed, 02 Jan 2013 06:33:06 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.81.194 with HTTP; Wed, 2 Jan 2013 06:33:06 -0800 (PST) In-Reply-To: <96188DBD-355B-4363-B8EA-C969EE6F6B77@mnot.net> References: <96188DBD-355B-4363-B8EA-C969EE6F6B77@mnot.net> Date: Wed, 2 Jan 2013 09:33:06 -0500 X-Google-Sender-Auth: o9QJcd7ttJh1hYl0GZr0lwVEx44 Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-appsawg-json-pointer.all@tools.ietf.org, IESG , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 14:33:09 -0000 >>>> None of the Authors Addresses given includes a postal address. >>> >>> Yes. >> >> I think they should. I find that such corner cutting typically goes >> with other sloppiness. > > Alternatively, it could mean that the authors don't wish to expose their postal > addresses. Or, that they believe that their electronic addresses will be more > stable than physical ones. I agree; we should drop this item from any discussion. The custom of putting at least one postal address is an old one, and might be considered "quaint" by some now. It's rare, indeed, for anyone to try to contact an author by postal mail. (The same, by the way, goes for phone numbers: in this case there are phone numbers for some authors, but I have no issue with having none.) Barry, responsible AD From kivinen@iki.fi Thu Jan 3 02:03:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2371021F8B45 for ; Thu, 3 Jan 2013 02:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH1fui+YLY8P for ; Thu, 3 Jan 2013 02:03:36 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E121F8B37 for ; Thu, 3 Jan 2013 02:03:35 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r03A3SlA023242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 Jan 2013 12:03:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r03A3QR5012129; Thu, 3 Jan 2013 12:03:26 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20709.22382.138778.97995@fireball.kivinen.iki.fi> Date: Thu, 3 Jan 2013 12:03:26 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 10:03:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2013-01-10 Reviewer LC end Draft Rob Austein T 2012-12-19 draft-ietf-mboned-auto-multicast-14 Alan DeKok T 2012-12-25 draft-ietf-appsawg-json-patch-08 Julien Laganier T 2012-11-19 draft-ietf-karp-routing-tcp-analysis-06 Yaron Sheffer TR2012-12-12 draft-ietf-6renum-enterprise-05 Sam Weiler T 2012-12-26 draft-salgueiro-vcarddav-kind-device-06 Nico Williams T - draft-bonica-special-purpose-04 Glen Zorn T 2012-12-20 draft-ietf-v6ops-icp-guidance-04 For telechat 2013-01-24 Dave Cridland T 2013-01-02 draft-schaad-pkix-rfc2875-bis-05 Charlie Kaufman T 2013-01-17 draft-higgs-oipf-urn-00 Last calls and special requests: Phillip Hallam-Baker 2013-01-03 draft-ietf-roll-p2p-rpl-15 Dan Harkins 2013-01-04 draft-ietf-mpls-tp-itu-t-identifiers-06 Sam Hartman 2013-01-07 draft-ietf-sipcore-priority-00 Paul Hoffman 2013-01-14 draft-ietf-sidr-rpki-rtr-protocol-mib-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2013-01-24 draft-laurie-pki-sunlight-05 Leif Johansson 2013-01-16 draft-ietf-nea-pt-eap-06 Simon Josefsson 2013-01-16 draft-ietf-6man-ipv6-atomic-fragments-03 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Jan 3 02:43:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7941621F8518 for ; Thu, 3 Jan 2013 02:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScjiYoaWRsHO for ; Thu, 3 Jan 2013 02:43:48 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9146421F8B0F for ; Thu, 3 Jan 2013 02:43:47 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so7667429lab.1 for ; Thu, 03 Jan 2013 02:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YE5M5gBF9mIKqnLBEdDfo1tytazqIictLBdM3HwY194=; b=tu7ptsKHWzsD4NjgXRmQsZs44eqnVmPYrhRQqs4oOHvbjGfeP/5U7A6xRQNs90I0jV 5ZJ4rditNdeHGmBXg9b1e7mGT0ESdb2AvogvWcXU2q+DEgCCG+nsQGsPM+xaF/jQKytZ UG66Crm6sQIJQuoMIvx2oyU7FBVuM9Ley0j0KzcxTzE+1OdmQN9+gDMWjFm4aLxrObXi mXheN4Onir/7abms6OHd2R92PmZ+YLfY8hn1PVeLSnr8mEE4kRjclXxw/RI7e3nQgiK3 rBcj7HNfoJOktlSN0o7v/m/L5jOZ68OFhzJzGAVdv7AC2XYm6pHLUmlOtikF6IuN6E3T +i7g== X-Received: by 10.112.51.175 with SMTP id l15mr19204613lbo.5.1357209826378; Thu, 03 Jan 2013 02:43:46 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id sj3sm18259074lab.2.2013.01.03.02.43.43 (version=SSLv3 cipher=OTHER); Thu, 03 Jan 2013 02:43:44 -0800 (PST) Message-ID: <50E560DD.8050506@gmail.com> Date: Thu, 03 Jan 2013 12:43:41 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "secdir@ietf.org" , draft-ietf-6renum-enterprise.all@tools.ietf.org References: <4FBFAE5F.8010305@gmail.com> <50CB009A.80908@gmail.com> In-Reply-To: <50CB009A.80908@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir repeat review of draft-ietf-6renum-enterprise-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 10:43:48 -0000 Hi, version -05 of the draft responds to all the concerns I had with -04. I have no additional comments. Thanks, Yaron On 12/14/2012 12:34 PM, Yaron Sheffer wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document reviews best practices in renumbering IPv6 enterprise > networks. > > I apologize for my belated review, and hope it is still useful to the > authors and document reviewers. > > Summary > > The Security Considerations section appears appropriate for this type of > document. I do not see any issues that should block the document from > advancing. > > Details > > - Usage of FQDN: I don't understand why RFC 5996 (IKEv2) is cited, I > suspect this is a typo. Otherwise, please clarify. > - The "Security" subsection of 4.1 overlaps with the Security > Considerations section, and I would recommend to consolidate them. > - 4.1, "Miscellaneous": I accept the recommendation to use FQDNs instead > of IP addresses. But saying "connections can survive" implies to me that > live TCP connections will survive an IP renumbering event, which is not > the case. I would say "connectivity to the remote side can survive" > instead. > - 4.3: RFC 2230 is mentioned as a way to deal with naming of IPsec > endpoints. I am not aware of current implementations of this RFC (in > fact it is not even mentioned in the current IPsec Roadmap document, RFC > 6071). Moreover, there is community consensus that IPsec should not be > used in the absence of a key management protocol. And IKE/IKEv2 > certainly supports naming/identifying endpoints by FQDN. > - The Security Considerations are sufficient IMO. The first point (using > renumbering to escape blacklisting) is appropriate in the context, even > if per Martin Stiemerling's comment, this strategy may not be very > effective. This is not a recommendation on how to bypass blacklisting, > just a description of a potential vulnerability. > > Thanks, > Yaron > From dharkins@lounge.org Thu Jan 3 11:04:56 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE96421F8D12; Thu, 3 Jan 2013 11:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqVOK15mwllL; Thu, 3 Jan 2013 11:04:56 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 95BDE21F85AB; Thu, 3 Jan 2013 11:04:51 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6978610224052; Thu, 3 Jan 2013 11:04:51 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 3 Jan 2013 11:04:51 -0800 (PST) Message-ID: <6398d2a9aea631a9b8b7224b48cdaa00.squirrel@www.trepanning.net> Date: Thu, 3 Jan 2013 11:04:51 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-ietf-mpls-tp-itu-t-identifiers X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 19:04:57 -0000 Hello, and happy new year, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft creates a new globally unique identifier for the Transport Profile of MPLS. RFC 6370, which created identifiers for MPLS-TP, uses the operator's AS as a globally unique identifier but this draft proposes an alternative: use the ITU-T Carrier Codes. It then goes about changing the identifiers created by RFC 6370 by substituting the ITU-T Carrier Code for the AS. The security considerations state that the draft merely extends an information model and does not propose any protocol changes and therefore it does not introduce any new security concerns. This seems acceptable except that this extension relies on the global uniqueness of the ITU-T Carrier Codes (as RFC 6370 relies on the AS to be globally unique). Apparently "national regulatory authorities" ensure that they are unique in their regulatory domain (which is an ISO 3166-1 identified code) so as long as they don't screw up anything all is well. I think it might be worth mentioning the assumption that the "national regulatory authorities" will not make a mistake and what happens if they do. RFC 6370 relied on IANA to not make a mistake; this draft relies on all 249 entities that have an official code in ISO 3166-1 to not make a mistake. Also, there is a normative reference to a "Corrigendum" of an ITU-T recommendation on "OAM functions and mechanisms for Ethernet based networks". I have never encountered such a document. Is it a stable reference? regards, Dan. From charliek@microsoft.com Thu Jan 3 12:54:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9664E21F8D20; Thu, 3 Jan 2013 12:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.534 X-Spam-Level: ** X-Spam-Status: No, score=2.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbvO73SkSrUE; Thu, 3 Jan 2013 12:54:09 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8891C21F867D; Thu, 3 Jan 2013 12:54:09 -0800 (PST) Received: from BL2FFO11FD007.protection.gbl (10.173.161.202) by BL2FFO11HUB017.protection.gbl (10.173.160.109) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 3 Jan 2013 20:54:01 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 3 Jan 2013 20:54:01 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 3 Jan 2013 20:53:26 +0000 Received: from mail81-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 Jan 2013 20:51:55 +0000 Received: from mail81-va3 (localhost [127.0.0.1]) by mail81-va3-R.bigfish.com (Postfix) with ESMTP id BB4A6300242; Thu, 3 Jan 2013 20:51:55 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zzc85fhzz1de0h1202h1e76h1d1ah1d2ahzz8275bh8275dh18c673h17326ahz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h) Received-SPF: softfail (mail81-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2PR03MB593; LANG:en; Received: from mail81-va3 (localhost.localdomain [127.0.0.1]) by mail81-va3 (MessageSwitch) id 1357246313574297_28782; Thu, 3 Jan 2013 20:51:53 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.237]) by mail81-va3.bigfish.com (Postfix) with ESMTP id 858D92600A4; Thu, 3 Jan 2013 20:51:53 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 3 Jan 2013 20:51:51 +0000 Received: from BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 3 Jan 2013 20:51:51 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB593.namprd03.prod.outlook.com (10.255.109.36) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 3 Jan 2013 20:51:50 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.3.178]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.3.178]) with mapi id 15.00.0586.000; Thu, 3 Jan 2013 20:51:50 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-higgs-oipf-urn.all@tools.ietf.org" Thread-Topic: Secdir review of draft-higgs-oipf-urn-00 Thread-Index: Ac3p8xQ/AvnQn/XVTxycgpKZd3NuYw== Date: Thu, 3 Jan 2013 20:51:50 +0000 Message-ID: <62881648643b4f8cafe101093e950ad4@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.156.132] Content-Type: multipart/alternative; boundary="_000_62881648643b4f8cafe101093e950ad4BL2PR03MB592namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(33646001)(47736001)(51856001)(56776001)(47976001)(46102001)(59766001)(56816002)(77982001)(5343635001)(31966008)(44976002)(6806001)(53806001)(54356001)(74662001)(4396001)(76482001)(16676001)(54316002)(49866001)(16236675001)(47446002)(512954001)(15202345001)(5343655001)(74502001)(50986001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB017; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 071518EF63 Subject: [secdir] Secdir review of draft-higgs-oipf-urn-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:54:10 -0000 --_000_62881648643b4f8cafe101093e950ad4BL2PR03MB592namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. Document= editors and WG chairs should treat these comments just like any other last= call comments. This document (intended to become an informational RFC) reserves the URN Na= mespace Identifier "OIPF" for use by the Open IPTV Forum so that organizati= on can assign globally unique URNs beginning with "urn:oipf:". The security= considerations section correctly states that there are no security conside= rations beyond those normally associated with the use and resolution of URN= s in general. This one does not require a lot of thought (at least with respect to securi= ty). --Charlie --_000_62881648643b4f8cafe101093e950ad4BL2PR03MB592namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.  Document editors and WG chairs should treat these co= mments just like any other last call comments.

 

This document (intended to become an informational R= FC) reserves the URN Namespace Identifier “OIPF” for use by the= Open IPTV Forum so that organization can assign globally unique URNs begin= ning with “urn:oipf:”. The security considerations section correctly states that there are no security considerations beyond = those normally associated with the use and resolution of URNs in general.

 

This one does not require a lot of thought (at least= with respect to security).

 

        &nbs= p;       --Charlie

--_000_62881648643b4f8cafe101093e950ad4BL2PR03MB592namprd03pro_-- From new-work-bounces@ietf.org Thu Jan 3 12:56:54 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA8421F8586; Thu, 3 Jan 2013 12:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1357246614; bh=TAEbQDtJkEnh5vu956sr7D3fic6CLBdqwQymd/leBsA=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=Jm8xXsEeZTJzs6e5zZIhFwsdxwSBKohQwKD6AoyJaHhPU3zYRXgjnA2+AwIbLoCRJ rMfWmGwFGT8VsMGsDSmJLjQpbssB5BjPKp0lEbgmEN+qc4NQFasoPuf1kXpRBzO6rw a9NyPq+ArFxMR3JWkNjyLmEHWKjkOUTNE6ZOaWs8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6253121F81FE for ; Thu, 3 Jan 2013 12:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.109 X-Spam-Level: X-Spam-Status: No, score=-109.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZEX5NMWUtgK for ; Thu, 3 Jan 2013 12:56:51 -0800 (PST) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by ietfa.amsl.com (Postfix) with ESMTP id AE0B421F857A for ; Thu, 3 Jan 2013 12:56:51 -0800 (PST) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos; i="4.84,405,1355119200"; d="scan'208,217"; a="48501352" From: To: Date: Thu, 3 Jan 2013 14:48:13 -0600 Thread-Topic: Status of Study Groups per November 2012 IEEE 802 Plenary Thread-Index: Ac3Si6HM/8ouEf1+RNWVX/PbOfDvRQXaSLzg Message-ID: <93720FE55DA3044C9F74B2962338F7DE8A4E815380@AUSX7MCPC109.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============1436312681837607686==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 04 Jan 2013 08:31:00 -0800 Subject: [secdir] [new-work] Status of Study Groups per November 2012 IEEE 802 Plenary X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:56:54 -0000 --===============1436312681837607686== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_93720FE55DA3044C9F74B2962338F7DE8A4E815380AUSX7MCPC109A_" --_000_93720FE55DA3044C9F74B2962338F7DE8A4E815380AUSX7MCPC109A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Colleagues, The following Study Groups were approved at the November 2012 IEEE 802 Plen= ary - 1. IEEE 802, "OmniRAN" EC Study Group 2. IEEE 802.1 "802.11 Bridging" Study Group 3. IEEE 802.3 "Reduced Twisted Pair Gigabit Ethernet" Study Group 4. IEEE 802.3 "Next Generation BASE-T" Study Group 5. IEEE 802.3 "Distinguished Minimum Latency Traffic in a Converged Traff= ic Environment" Study Group 6. IEEE 802.11 "Pre-association Discovery (PAD)" Study Group 7. IEEE 802.11 "General Link (GLK)" Study Group 8. IEEE 802.15 "Ultra Low Power" Study Group 9. IEEE 802.15 "Layer 2 Routing" Study Group Please note, per the IEEE 802 LMSC Policies and Procedures that a Study Gro= up is chartered plenary session-to-plenary session. Therefore, the Study G= roups, listed above and found at http://www.ieee802.org/StudyGroups.shtml, = are chartered until the IEEE 802 March 2013 Plenary Session. Please note that IEEE meetings are open and may be attended by any individu= als who register and fulfill any registration fees. Details regarding futu= re IEEE 802 plenary meeting schedules may be found at http://www.ieee802.or= g/PARs.shtml. Please refer to individual working groups for their interim = meeting schedules. A listing of all working groups may be found at http://= www.ieee802.org/. Best Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary Note - This email solely represents the views of the IEEE 802 LMSC and do= es not necessarily represent a position of the IEEE or the IEEE Standards A= ssociation. --_000_93720FE55DA3044C9F74B2962338F7DE8A4E815380AUSX7MCPC109A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

The following Study Groups were approved at the No= vember 2012 IEEE 802 Plenary –

  1. IEEE 802, "OmniRAN" EC Study Group<= /span> =
  2. IEEE 802.1 "802.11 Bridgin= g" Study Group
  3. IEEE 802.3 = "Reduced Twisted Pair Gigabit Ethernet" Study Group
  4. IEEE 802.3 "Next Generation BASE-T"= ; Study Group
  5. IEEE 802.3 "= Distinguished Minimum Latency Traffic in a Converged Traffic Environment&qu= ot; Study Group
  6. IEEE 802.11 &qu= ot;Pre-association Discovery (PAD)" Study Group
    7. <= li class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt= :auto;mso-list:l0 level1 lfo3'>IEEE 802.11  "General Link (GLK)" Stud= y Group
  7. IEEE 802.15  "= ;Ultra Low Power" Study Group
  8. IEEE 802.15  "Layer 2 Routing" Study Group

Please note, per the IEEE 802 LMSC Policies and P= rocedures that a Study Group is chartered plenary session-to-plenary sessio= n.  Therefore, the Study Groups, listed above and found at http://www.ieee802.org/StudyGroup= s.shtml, are chartered until the IEEE 802 March 2013 Plenary Session.

 

Please note that IEEE meetings are open and may be attended by= any individuals who register and fulfill any registration fees.  Deta= ils regarding future IEEE 802 plenary meeting schedules may be found at http://www.ieee802.org/PARs.shtm= l.  Please refer to individual working groups for their interim me= eting schedules.  A listing of all working groups may be found at http://www.ieee802.org/.

 

Best Regards,

John D’Ambrosia

=

IEEE 802 LMSC Recording Secretary

 

Note -   This email solely represents the views of the I= EEE 802 LMSC and does not necessarily represent a position of the IEEE or t= he IEEE Standards Association. 

 

= --_000_93720FE55DA3044C9F74B2962338F7DE8A4E815380AUSX7MCPC109A_-- --===============1436312681837607686== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============1436312681837607686==-- From new-work-bounces@ietf.org Thu Jan 3 13:21:09 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BCF21F8C74; Thu, 3 Jan 2013 13:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1357248068; bh=ZOpVUiqSYzZKcczZmmk4A98FIRyuBZkvIopz3na8Prs=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=dZjM81GtsL5U+5otPmulhYe3jzSCArtFJ+fdGvD3UXGctP3Ah4tfAh/6h6ti+QebG /tZzSUvP0pLT1dy1LF4blVtIolaD3cEvOF3rutkOIByg00uMC+OpwOQdQTkWJaXNH3 WI0FNZFS6tolSxtEIAJlCmgu2xqLIUrNZ16Atg2w= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BEF21F8BCE for ; Thu, 3 Jan 2013 13:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.853 X-Spam-Level: X-Spam-Status: No, score=-109.853 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0M5AdZvs9a0 for ; Thu, 3 Jan 2013 13:21:03 -0800 (PST) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id C3A6121F8BED for ; Thu, 3 Jan 2013 13:20:58 -0800 (PST) X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos; i="4.84,405,1355119200"; d="scan'208,217"; a="47014860" From: To: Date: Thu, 3 Jan 2013 14:47:31 -0600 Thread-Topic: For Your Consideration - IEEE 802.3 HSE Consensus Ad Hoc - Next Speed of Ethernet Thread-Index: Ac3p9GThzXp0OtgBSUOoLa+QTDL2qA== Message-ID: <93720FE55DA3044C9F74B2962338F7DE8A4E815374@AUSX7MCPC109.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============3946577455795734043==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 04 Jan 2013 08:31:00 -0800 Subject: [secdir] [new-work] For Your Consideration - IEEE 802.3 HSE Consensus Ad Hoc - Next Speed of Ethernet X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:21:09 -0000 --===============3946577455795734043== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_93720FE55DA3044C9F74B2962338F7DE8A4E815374AUSX7MCPC109A_" --_000_93720FE55DA3044C9F74B2962338F7DE8A4E815374AUSX7MCPC109A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please note that the following message was sent previously, but was not for= warded to the "New Work" reflector. Dear Colleagues, The IEEE 802.3 Industry Connections Ethernet Bandwidth Assessment Ad hoc co= mpleted its charter at the IEEE 802 July Plenary, as its assessment report = was approved by the IEEE 802.3 Working Group. The assessment is publicly a= vailable for download at http://www.ieee802.org/3/ad_hoc/bwa/BWA_Report.pdf= . Please note that a supporting tutorial presentation was given during the= week of the IEEE 802 July Plenary, and is available for download at http:/= /www.ieee802.org/802_tutorials/2012-07/BWATutorial_D1_12_0716.pdf. Based on the findings, a new Industry Connections Higher Speed Ethernet Con= sensus Ad Hoc has been formed The purpose of the IEEE 802.3 Industry Con= nections Higher Speed Ethernet Consensus activity will be to build consensu= s for initiating a new effort targeting the next speed of Ethernet for wire= line applications. This consensus will be used for the evaluation and possi= ble development of a Call-For-Interest for the next IEEE 802.3 Higher Speed= Study Group. The group's first meeting was held on September 23, 2012 at t= he IEEE 802.3 Interim meeting in Geneva, CH. Further information about thi= s meeting and the ad hoc can be found at http://www.ieee802.org/3/ad_hoc/hs= e/public/index.html. Participation in the ad hoc is open to all. To subscribe to the ad hoc's r= eflector, please see http://www.ieee802.org/3/ad_hoc/bwa/reflector.html. Best Regards, John D'Ambrosia Chair, IEEE 802.3 HSE Consensus Ad Hoc Note - This email solely represents the views of the IEEE 802.3 Industr= y Connections Higher Speed Ethernet Consensus Ad Hoc and does not necessari= ly represent a position of the IEEE, the IEEE Standards Association, IEEE 8= 02, or IEEE 802.3. --_000_93720FE55DA3044C9F74B2962338F7DE8A4E815374AUSX7MCPC109A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please note that the following message was se= nt previously, but was not forwarded to the “New Work” reflecto= r. 

 

Dear Colleagues,

<= o:p> 

The IEEE 80= 2.3 Industry Connections Ethernet Bandwidth Assessment= Ad hoc completed its charter at the IEEE 802 July Plenary, as its assessme= nt report was approved by the IEEE 802.3 Working Group.  The assessmen= t is publicly available for download at http://www.ieee802.org/3/ad_hoc/bwa/BWA_Report.pd= f.  Please note that a supporting tutorial presentation was given du= ring the week of the IEEE 802 July Plenary, and is available for download a= t http://www.ieee802.org/802_tutorials/2012-07/BWATutorial_D1_12_071= 6.pdf.

 

Based on the findings, a new Industry Connections Higher Speed Ethe= rnet Consensus Ad Hoc has been formed    The purpose of the = IEEE 802.3 Industry Connections Higher Speed Ethernet Consensus activity wi= ll be to build consensus for initiating a new effort targeting the next spe= ed of Ethernet for wireline applications. This consensus will be used for t= he evaluation and possible development of a Call-For-Interest for the next = IEEE 802.3 Higher Speed Study Group. The group’s first meeting was he= ld on September 23, 2012 at the IEEE 802.3 Interim meeting in Geneva, CH.&n= bsp; Further information about this meeting and the ad hoc can be found at = http://www.= ieee802.org/3/ad_hoc/hse/public/index.html.

 

Participation in the ad hoc is= open to all.  To subscribe to the ad hoc’s reflector, please se= e http://www.i= eee802.org/3/ad_hoc/bwa/reflector.html. 

 

Best Regards,

 

John D’Amb= rosia

Chair, IEEE 802.3 HSE Consensus Ad H= oc

 

=  

Note -     This email solely = represents the views of the IEEE 802.3 Industry Connections Higher Speed Et= hernet Consensus Ad Hoc and does not necessarily represent a position of th= e IEEE, the IEEE Standards Association, IEEE 802, or IEEE 802.3.

 

= --_000_93720FE55DA3044C9F74B2962338F7DE8A4E815374AUSX7MCPC109A_-- --===============3946577455795734043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============3946577455795734043==-- From new-work-bounces@ietf.org Fri Jan 4 11:48:41 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31B521F8906; Fri, 4 Jan 2013 11:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1357328921; bh=tzw9irKvyBwqjAl/VhPUHv1+wo8/WpCTc3J7eOKXRnM=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NJdTCazg//dZX6+Jf1Yk2SkvVi/uMt4DcownDOSiYXCIv/IlSe3V6Ls39Vyh6v2PS SBWrVdf5l0GQiBC+e6g5Qhn0DYHqxsdtA2fxFt2rvIzEkpZveKkzQ7sJMaAJQaZdr8 /DxsJCuTsNXG7YC3NpjBer693696lhXJEfoxoqj0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E26A21F871C; Fri, 4 Jan 2013 11:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.128 X-Spam-Level: X-Spam-Status: No, score=-102.128 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eFCzAHm8Q8e; Fri, 4 Jan 2013 11:48:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC4121F88EA; Fri, 4 Jan 2013 11:48:35 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130104194835.15687.97721.idtracker@ietfa.amsl.com> Date: Fri, 04 Jan 2013 11:48:35 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 04 Jan 2013 15:54:28 -0800 Subject: [secdir] [new-work] WG Review: Sunsetting IPv4 (sunset4) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 19:48:42 -0000 The Sunsetting IPv4 (sunset4) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-01-11. Sunsetting IPv4 (sunset4) ------------------------------------------------ Current Status: Active Working Group Chairs: Marc Blanchet Wesley George Technical advisors: Martin Stiemerling Stewart Bryant Fred Baker Assigned Area Director: Ralph Droms Mailing list Address: sunset4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sunset4 Archive: http://www.ietf.org/mail-archive/web/sunset4/ Charter of Working Group: Global IPv4 addresses, once considered plentiful, are an increasingly scarce resource for many who wish to connect to the Internet today. IPv6 provides an abundance of freely available addresses, and while deployment alongside IPv4 has begun in earnest, much work remains. In order to fully transition the Internet to IPv6, individual applications, hosts, and networks that have enabled IPv6 must also be able to operate fully in the absence of IPv4. The Working Group will point out specific areas of concern, provide recommendations, and standardize protocols that facilitate the graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has been deployed. This includes the act of shutting down IPv4 itself, as well as the ability of IPv6-only portions of the Internet to continue to connect with portions of the Internet that remain IPv4-only. While this work obviously spans multiple IETF areas including Internet, Operations, Transport, Applications, and Routing, this working group provides a single venue for the consideration of IPv4 sunsetting. Work in this group shall never impede the deployment of IPv6, will not duplicate functions and capabilities already available in existing technologies, and should demonstrate widespread operational need. Cross- area coordination and support is essential. Disabling IPv4 in applications, hosts, and networks is new territory for much of the Internet today, and it is expected that problems will be uncovered including those related to basic IPv4 functionality, interoperability, as well as potential security concerns. The working group will report on common issues, provide recommendations, and, when necessary, protocol extensions in order to facilitate disabling IPv4 in networks where IPv6 has been deployed. As a rule, deployment scenarios considered by the working group shall include IPv6-only nodes and networks. Work on technologies that involve increased sharing of global IPv4 addresses should be limited to what is necessary for communicating with endpoints or over networks that are IPv6-only. The initial work items are: * NAT64 port allocation and address sharing methods involving scenarios where an IPv6-only node is present (and NAT44, as it overlaps NAT64 address sharing and port use). This may require a description of the use of an existing protocol, the development of extensions to an existing protocol, or the definition of an entirely new protocol. * Gap analysis of IPv4/IPv6 features to facilitate IPv4 sunsetting * Provisioning methods to signal a dual-stack host to disable or depreference the use of IPv4 Goals and Milestones: Mar 2013 - Submit gap analysis on IPv4 sunsetting to IESG for consideration as an Informational RFC Jun 2013 - Submit NAT64 port allocation and address sharing methods to IESG for consideration as an Informational RFC Sep 2013 - Submit provisioning methods to signal a dual-stack host to disable the use of IPv4 to IESG for consideration as Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From afarrel@juniper.net Sat Jan 5 07:38:04 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5127D21F858A; Sat, 5 Jan 2013 07:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG1EECR0mlx0; Sat, 5 Jan 2013 07:38:03 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id C00A321F8584; Sat, 5 Jan 2013 07:38:02 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r05Fc0H7010505; Sat, 5 Jan 2013 15:38:01 GMT Received: from 950129200 (089144192189.atnat0001.highway.a1.net [89.144.192.189]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r05Fbw0a010477; Sat, 5 Jan 2013 15:38:00 GMT From: "Adrian Farrel" To: "'Dan Harkins'" References: <6398d2a9aea631a9b8b7224b48cdaa00.squirrel@www.trepanning.net> In-Reply-To: <6398d2a9aea631a9b8b7224b48cdaa00.squirrel@www.trepanning.net> Date: Sat, 5 Jan 2013 15:37:58 -0000 Message-ID: <00a001cdeb5a$a4efb7d0$eecf2770$@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFj7XcJdDDL9XvJlrKu9AYvnToDKpkO2N5A Content-Language: en-gb Cc: draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-itu-t-identifiers X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: afarrel@juniper.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 15:38:04 -0000 Hi Dan, The authors may care to comment further, but I think there are two points... The regulatory codes are centrally allocated so the "screw-ups" that you refer to are within those domains. That reduces the scope of the problem and also reduces its impact. But maybe the document would benefit from a note on the "risks of misconfiguration". I am not sure that that would belong in the Security Considerations section, but space could certainly be found in the document. Yes, Corrigenda are stable ITU-T references. They are found on the same web page that gives download pointers for the Recommendations they correct. Cheers, Adrian > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Dan > Harkins > Sent: 03 January 2013 19:05 > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mpls-tp-itu-t- > identifiers.all@tools.ietf.org > Subject: secdir review of draft-ietf-mpls-tp-itu-t-identifiers > > > Hello, and happy new year, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft creates a new globally unique identifier for the Transport > Profile of MPLS. RFC 6370, which created identifiers for MPLS-TP, > uses the operator's AS as a globally unique identifier but this draft > proposes an alternative: use the ITU-T Carrier Codes. It then goes > about changing the identifiers created by RFC 6370 by substituting > the ITU-T Carrier Code for the AS. > > The security considerations state that the draft merely extends an > information model and does not propose any protocol changes and > therefore it does not introduce any new security concerns. This seems > acceptable except that this extension relies on the global uniqueness > of the ITU-T Carrier Codes (as RFC 6370 relies on the AS to be > globally unique). Apparently "national regulatory authorities" > ensure that they are unique in their regulatory domain (which is an > ISO 3166-1 identified code) so as long as they don't screw up > anything all is well. I think it might be worth mentioning the > assumption that the "national regulatory authorities" will not make a > mistake and what happens if they do. RFC 6370 relied on IANA to > not make a mistake; this draft relies on all 249 entities that have an > official code in ISO 3166-1 to not make a mistake. > > Also, there is a normative reference to a "Corrigendum" of an ITU-T > recommendation on "OAM functions and mechanisms for Ethernet > based networks". I have never encountered such a document. Is it > a stable reference? > > regards, > > Dan. From leifj@sunet.se Mon Jan 7 04:43:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3921F875A; Mon, 7 Jan 2013 04:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvpbV01-vh7H; Mon, 7 Jan 2013 04:43:14 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D27C221F881A; Mon, 7 Jan 2013 04:42:40 -0800 (PST) Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com [62.102.145.131]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id r07CgXDY012465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 13:42:36 +0100 (CET) Message-ID: <50EAC2B8.3080908@sunet.se> Date: Mon, 07 Jan 2013 13:42:32 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "secdir@ietf.org" , draft-ietf-nea-pt-eap.all@tools.ietf.org, "iesg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-nea-pt-eap-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 12:43:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a posture transport protocol for EAP tunnel methods. I found the document clearly written and easy to follow. The only suggestion I have is that in section 3.4 (or 4.2.5) on the Asokan Attack the document should clearly state that the verification of the channel token MUST be performed before any other attestations are evaluated. Cheers Leif From huub.van.helvoort@huawei.com Mon Jan 7 05:58:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EE921F86F7; Mon, 7 Jan 2013 05:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeTssiQ1NogC; Mon, 7 Jan 2013 05:58:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A77A621F86D4; Mon, 7 Jan 2013 05:58:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANG82104; Mon, 07 Jan 2013 13:58:42 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 7 Jan 2013 13:57:35 +0000 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.01.0323.003; Mon, 7 Jan 2013 13:58:38 +0000 From: Huub helvoort To: "afarrel@juniper.net" , "'Dan Harkins'" Thread-Topic: secdir review of draft-ietf-mpls-tp-itu-t-identifiers Thread-Index: AQHN6eU/uyehI2LrqU+v9clAyT9105g64XsAgAME2gs= Date: Mon, 7 Jan 2013 13:58:37 +0000 Message-ID: <73E555AA235F3846B8051DB38C8776272E57FA00@lhreml509-mbx> References: <6398d2a9aea631a9b8b7224b48cdaa00.squirrel@www.trepanning.net>, <00a001cdeb5a$a4efb7d0$eecf2770$@juniper.net> In-Reply-To: <00a001cdeb5a$a4efb7d0$eecf2770$@juniper.net> Accept-Language: en-GB, en-US, zh-CN Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.112.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 07 Jan 2013 06:02:43 -0800 Cc: "draft-ietf-mpls-tp-itu-t-identifiers.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-mpls-tp-itu-t-identifiers X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 13:58:45 -0000 Hello Dan, Thank you for the review. Adrian already addressed your concerns, I would like to provide soem extra = information. See my comments in-line [Huub] ________________________________________ From: Adrian Farrel [afarrel@juniper.net] Sent: 05 January 2013 16:37 To: 'Dan Harkins' Cc: iesg@ietf.org; secdir@ietf.org; draft-ietf-mpls-tp-itu-t-identifiers.al= l@tools.ietf.org Subject: RE: secdir review of draft-ietf-mpls-tp-itu-t-identifiers Hi Dan, The authors may care to comment further, but I think there are two points..= . The regulatory codes are centrally allocated so the "screw-ups" that you re= fer to are within those domains. That reduces the scope of the problem and also reduces its impact. [Huub] correct, each country is responsible for allocating and using unique= operator identification codes: the ICC. This is explained on this page: http://www.itu.int/oth/T0201 To make them globally unique the CC has to be added. But maybe the document would benefit from a note on the "risks of misconfiguration". I am not sure that that would belong in the Security Considerations section, but space could certainly be found in the document. [Huub] would a reference to http://www.itu.int/oth/T0201 be enough? Yes, Corrigenda are stable ITU-T references. They are found on the same web= page that gives download pointers for the Recommendations they correct. [Huub] see http://www.itu.int/ITU-T/recommendations/rec.aspx?id=3D11136&lan= g=3Den Best regards, Huub. -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Always remember that you are unique...just like everyone else... > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of D= an > Harkins > Sent: 03 January 2013 19:05 > To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mpls-tp-itu-t- > identifiers.all@tools.ietf.org > Subject: secdir review of draft-ietf-mpls-tp-itu-t-identifiers > > > Hello, and happy new year, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft creates a new globally unique identifier for the Transport > Profile of MPLS. RFC 6370, which created identifiers for MPLS-TP, > uses the operator's AS as a globally unique identifier but this draft > proposes an alternative: use the ITU-T Carrier Codes. It then goes > about changing the identifiers created by RFC 6370 by substituting > the ITU-T Carrier Code for the AS. > > The security considerations state that the draft merely extends an > information model and does not propose any protocol changes and > therefore it does not introduce any new security concerns. This seems > acceptable except that this extension relies on the global uniqueness > of the ITU-T Carrier Codes (as RFC 6370 relies on the AS to be > globally unique). Apparently "national regulatory authorities" > ensure that they are unique in their regulatory domain (which is an > ISO 3166-1 identified code) so as long as they don't screw up > anything all is well. I think it might be worth mentioning the > assumption that the "national regulatory authorities" will not make a > mistake and what happens if they do. RFC 6370 relied on IANA to > not make a mistake; this draft relies on all 249 entities that have an > official code in ISO 3166-1 to not make a mistake. > > Also, there is a normative reference to a "Corrigendum" of an ITU-T > recommendation on "OAM functions and mechanisms for Ethernet > based networks". I have never encountered such a document. Is it > a stable reference? > > regards, > > Dan.= From weiler@watson.org Tue Jan 8 08:02:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBD021F8906; Tue, 8 Jan 2013 08:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmUTlBpVlv7n; Tue, 8 Jan 2013 08:02:36 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id D148421F84EA; Tue, 8 Jan 2013 08:02:35 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.5/8.14.5) with ESMTP id r08G2YnF081693; Tue, 8 Jan 2013 11:02:34 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.5/8.14.5/Submit) with ESMTP id r08G2XXP081683; Tue, 8 Jan 2013 11:02:33 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 8 Jan 2013 11:02:33 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, draft-salgueiro-vcarddav-kind-device@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 08 Jan 2013 11:02:34 -0500 (EST) Subject: [secdir] secdir review of draft-salgueiro-vcarddav-kind-device-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 16:02:36 -0000 Summary: no objections. There are very real security concerns, but the only surprise is that they're discussed only by reference. The draft refers to the general vCard spec (RFC6350). RFC6350 does an adequate job. One might argue that vCards more devices are more likely to be used in automated and perhaps unfamiliar ways, so the ricks are greater than with vCards for humans. But we let a similar doc (RFC6473) be published a year ago with this same sort of referral, so it's hard to make a case than anything needs to change here. Thanks to the editors for the very readable doc. -- Sam From sgundave@cisco.com Tue Jan 8 21:37:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F971F0CFA; Tue, 8 Jan 2013 21:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5wEn8YYd+2p; Tue, 8 Jan 2013 21:37:46 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E372D1F0CF8; Tue, 8 Jan 2013 21:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1818; q=dns/txt; s=iport; t=1357709861; x=1358919461; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SViUtAElm0oenmbMDtSHNTMp/+FGPSFIOhjOcLCbPgY=; b=B74CtjCr701DBGJCT/4OqfSXOOaHF43JKXvBqbRHcPWX69YQd/3AlRpc bkevEKOE2T9yXm27pQzCsCG9eZThAssNggkGXK231cCvXLSXgeZTZY+Lx /zSKuC7mGMqzoLyV367YewZXstetM5ORAqxlo1iPlbMoBDDvjTpTda4SV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOwA7VCtJXHB/2dsb2JhbABFvV4Wc4IgAQQ6LRISAQgiFEIlAgQBDQUIiA+3IZA0YQOmVYJ0giY X-IronPort-AV: E=Sophos;i="4.84,435,1355097600"; d="scan'208";a="160404050" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jan 2013 05:37:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r095bdFo008948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Jan 2013 05:37:39 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.233]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 8 Jan 2013 23:37:39 -0600 From: "Sri Gundavelli (sgundave)" To: Vincent Roca , IESG IESG , "secdir@ietf.org" , "draft-ietf-netext-pmipv6-sipto-option.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-netext-pmipv6-sipto-option-07 Thread-Index: AQHN7itvCHxP1JDz2ke5MpS4VCM/aQ== Date: Wed, 9 Jan 2013 05:37:38 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8100E717B@xmb-aln-x03.cisco.com> In-Reply-To: <6AF80A4F-EA0A-4E09-B304-043066124E4E@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.121.244] Content-Type: text/plain; charset="us-ascii" Content-ID: <316B243D60321B44BE4AF247918E346B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 09 Jan 2013 08:03:24 -0800 Cc: Brian Haberman , Basavaraj Patil Subject: Re: [secdir] Secdir review of draft-ietf-netext-pmipv6-sipto-option-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 05:37:54 -0000 Hi Vincent, Thanks for the review. Please see inline. On 11/28/12 6:34 AM, "Vincent Roca" wrote: >Hello, > >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >-- > >This is a small document that describes PMIPv6 options to handle >traffic offloading. Taken alone, the "security considerations" section >would not be sufficient. However the RFC5213 (PMIPv6) provides >the required security guidelines. In particular it clarifies that the use >of IPsec is recommended between the MAG and LMA for signaling >messages. The present document therefore inherits from these >recommendations. I therefore agree with the authors. [Sri] Ack. > >A remark. It is said: > "This option is carried like any other > mobility header option as specified in [RFC5213] and does not require > any special security considerations." > >It's misleading IMHO. This option does require security considerations >since an attacker, by sending fake signaling messages, may prevent >a mobile network from offloading traffic which may lead to a DoS. >You'd better say something like: > > "This option is carried like any other > mobility header option as specified in [RFC5213]. > Therefore it inherits from [RFC5213] its security guidelines > and does not require any additional security considerations." [Sri] Ok. Makes sense. > >Typos:=20 >Section 1: >s/its only about IPv4/it is only about IPv4/ [Sri] Ok Regards Sri > > >Cheers, > > Vincent From kivinen@iki.fi Thu Jan 10 02:12:19 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2412421F847F for ; Thu, 10 Jan 2013 02:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZB8jxzGe7Qs for ; Thu, 10 Jan 2013 02:12:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6F21F8497 for ; Thu, 10 Jan 2013 02:12:11 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0AAC82r003221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Jan 2013 12:12:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0AAC7LI022203; Thu, 10 Jan 2013 12:12:07 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20718.37878.895554.303648@fireball.kivinen.iki.fi> Date: Thu, 10 Jan 2013 12:12:06 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 10:12:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Kathleen Moriarty is next in the rotation. For telechat 2013-01-10 Reviewer LC end Draft Rob Austein T 2012-12-19 draft-ietf-mboned-auto-multicast-14 Alan DeKok T 2012-12-25 draft-ietf-appsawg-json-patch-09 Sam Hartman T 2013-01-07 draft-ietf-sipcore-priority-00 Julien Laganier T 2012-11-19 draft-ietf-karp-routing-tcp-analysis-06 Nico Williams T - draft-bonica-special-purpose-05 Glen Zorn T 2012-12-20 draft-ietf-v6ops-icp-guidance-04 For telechat 2013-01-24 Dave Cridland T 2013-01-02 draft-schaad-pkix-rfc2875-bis-06 Phillip Hallam-Baker T 2013-01-03 draft-ietf-roll-p2p-rpl-15 Dan Harkins TR2013-01-04 draft-ietf-mpls-tp-itu-t-identifiers-07 Tero Kivinen T 2013-01-22 draft-ietf-tsvwg-sctp-udp-encaps-07 Chris Lonvick T 2013-01-22 draft-ietf-rmt-fcast-07 Catherine Meadows T 2013-01-22 draft-ietf-rmt-flute-sdp-03 Vincent Roca TR2012-09-24 draft-ietf-dime-erp-16 Last calls and special requests: Paul Hoffman 2013-01-14 draft-ietf-sidr-rpki-rtr-protocol-mib-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2013-01-24 draft-laurie-pki-sunlight-05 Simon Josefsson 2013-01-16 draft-ietf-6man-ipv6-atomic-fragments-03 Scott Kelly 2013-01-17 draft-ietf-avtcore-srtp-encrypted-header-ext-04 Stephen Kent 2013-01-21 draft-ietf-roll-security-threats-00 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-08 Julien Laganier 2013-01-21 draft-ietf-ccamp-lmp-behavior-negotiation-09 Ben Laurie 2013-01-23 draft-ietf-ipfix-information-model-rfc5102bis-09 Matt Lepinski 2013-01-18 draft-ietf-radext-radius-extensions-08 Alexey Melnikov 2013-01-21 draft-ietf-roll-p2p-measurement-07 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-10 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 -- kivinen@iki.fi From benl@google.com Thu Jan 10 03:55:19 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276BC21F88C4 for ; Thu, 10 Jan 2013 03:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZS5zXlYGQ1p for ; Thu, 10 Jan 2013 03:55:18 -0800 (PST) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7165821F88AE for ; Thu, 10 Jan 2013 03:55:17 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t49so218059wey.28 for ; Thu, 10 Jan 2013 03:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=1BwLxG1Ijyq0UZgMZhk7cx7O11T2sQ4S+UBGr26CXyM=; b=bLO556UKfQH+cLN1OwuRtHl0ZhSimNC27Hv0UHVtKPw/eJUQl6hRXhLoEvy2oz4CwA wrJF10rsKCQ0+k9X39c+j0LIxoq+551bf1Sf9fmmREd5fXEd9Y5YOadfFr5cy09c33ys fne1DU2N/7ekKZmtGFjdaTsVdxCmLc2e5xj8Ll6RtCLcrYJfe9Y/aE2cnDSPxUL7h3YO SbcS/HwPjE4oVysMj3LiVXdRglJAH5aJgGIzRdOkXPXwT4I0o6iOKTsB5x/DnSuVr+fO HJreln0vWdt8CWZOpPQxxZ30L+NiAprGDMoDzVwGBdXt6EiJ3WKSWY93APaOTzCofk6G HDCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=1BwLxG1Ijyq0UZgMZhk7cx7O11T2sQ4S+UBGr26CXyM=; b=nDSvxgByuOE0oq0W1hlPIHY69HqdKHxnlxSrcA8UDaLpYxXQdOfTGgneuGCMF1jtv+ SEKe4il3t5bMfAHSDQqLATH2W1AhcRZrhxpfJQjXx7ecAMB/hZ3SG3RN8Q2vqpEIZOAL Z0yIhHf/5nVkeEOQUjCstz8KHqF7xc/z0YedqmrosPMJBTab2VpaCQ4QHWc9PPsSON93 Pep24yNLhaWtBjBgBNtnKu68ab7MVBgJ7w2MpqBVJc0PeyUA7n3GkMsIETdn6VMBbxk4 uSF5caeNZJ7SuibE3SnKY8y6rkC+T8rLWSC/YuOmyssmW0ndMkIBKEbCCA2v5tBKsVm+ qC7A== MIME-Version: 1.0 X-Received: by 10.180.84.193 with SMTP id b1mr8670858wiz.26.1357818916276; Thu, 10 Jan 2013 03:55:16 -0800 (PST) Received: by 10.194.234.134 with HTTP; Thu, 10 Jan 2013 03:55:16 -0800 (PST) Date: Thu, 10 Jan 2013 11:55:16 +0000 Message-ID: From: Ben Laurie To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmpR2A3AbyYVYC+guQur0cUuOCgfzGMkjYqAOaY5e/oibbHHvtiEUNflzIj8wAggqMV5sYKE7IaaMIwnSkFk/OF/HnHFnhtZLmqRPgO7T2xLavtUb9f50LMEozNAtKwPA/oEtd5EFG3j4iZyWeK3H6Ud9SzmW02oyUlD4eRaN2xg9r2b2C75435yZDkfx3M/EQbzTW Subject: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 11:55:19 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: this document is part of a series of documents describing the protocol, and only deals with data elements. As such, most security considerations are dealt with elsewhere. However, I note that whilst a good deal of attention is paid to integrity and authentication of the data in those other documents, as far as I can see nothing is said about authentication of the requester, nor about access control. Given that flow information is potentially quite sensitive, this is surprising. The document itself seems OK, with nits. Nits: "3.1.14. string The type "string" represents a finite-length string of valid characters from the Unicode character encoding set [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many other international character sets to be used." RFC 5610 says this is encoded using UTF-8. UTF-8 can have security issues, e.g. sending a string with an incomplete UTF-8 encoded character, which then swallows part of a following string, or causes errors in parsers. Although this document may not be the right place for it, it is unfortunate this potential problem is not mentioned. From kivinen@iki.fi Thu Jan 10 06:43:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBA321F8798; Thu, 10 Jan 2013 06:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMaeI33Y-q-D; Thu, 10 Jan 2013 06:43:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5735F21F84B2; Thu, 10 Jan 2013 06:43:32 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0AEhSqf014295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 16:43:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0AEhRpR024615; Thu, 10 Jan 2013 16:43:27 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20718.54159.713629.567812@fireball.kivinen.iki.fi> Date: Thu, 10 Jan 2013 16:43:27 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 46 min X-Total-Time: 51 min Subject: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 14:43:35 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the UDP encapsulation for the SCTP packets. It seems to be quite similar to other UDP encapsulation documents (for example RFC3948 for IPsec). The security considerations section points to the RFC4960 and RFC5061 and says there is no additional security considerations. I belive this is not true. The RFC4960 section 11.3 talks about the SCTP Interactions with firewalls, i.e. how firewalls can do SCTP filtering and how to find the INIT chunks. This UDP encapsulation can be used to bypass those checks, by encapsulating the initial INIT chunks with UDP encapsulated SCTP packets and then after that move to normal SCTP flow (or just stay in the UDP encapsulated SCTP). This might allow bypassing the firewall rules set by the site adminstrator. This also might allow attacks to the hosts inside the firewall protected domain by bypassing the firewall, which was supposed to be protecting the hosts. The document should note that firewalls needs to be updated to specifically inspect / filter also UDP encapsulated SCTP if they do normal SCTP inspection / filtering. Also some other issues. It is not clear for me how the initiator host finds the port where to connect, when it is doing initial connection. I.e. if a host A wants to connect to host B, which port it should use if it needs to use UDP encapsulated SCTP? Is it assumed that 9899 will be used always? What about connecting to the hosts which are behind NAT, i.e. if host B is behind NAT, how does host A find the port number to use (which host B hopefully somehow already configred to the NAT to be passed to him)? Also what if host A and B already have one SCTP connection, and now host B wants to create another, do host B reuse the same UDP destination port number for host A that was used for the already existing SCTP connection between them? The section 4.1 says that UDP port numbers are stored per destination address per SCTP association, so that would indicate no. The draft seems to be doing dynamic port number updating based on finding SCTP association (which includes checking the very weak verification tag). The current section 4.4 only mentions that port number is updated. In some cases also the IP-address might change, i.e. if the NAT box is rebooted or its connection table is cleared, and the NAT box have multiple IP-addresses, it is completly possible that the NAT mapping changes so that IP-address and UDP port number both change. I am not familiar enough with SCTP to know whether this causes problem with SCTP, i.e. whether it is default SCTP rules to use the last seen IP-address when sending reply or what. The section 3.2 do say that if multiple addresses are used, then RFC5061 (SCTP Dynamic Address Reconfiguration) with RFC4895 (Authentication Chunks for SCTP) MUST be used. With dynamic update for the UDP port number, the similar hijacking attack described in the RFC5061 security considerations section is applicable here too. The RFC5061 requires (without using RFC2119 language) using of authentication chunks to prevent that attack, so should we require authentication chunks here too to prevent same attacks even when using only one IP-address, as we do update the UDP ports based on the received packets? Also perhaps the requirement of using authentication chunks should be also mentioned in the security considerations section, as it is very important for the security point of view of the protocol. The section 4.1 "Architectural Considerations" says correctly that implementations needs to store remote UDP port per destination address for each SCTP association, i.e. different SCTP associations can have different port numbers for same destination address. This is required, because there might be multiple SCTP clients behind the same NAT box (having same IP-address), just using different ports. Unfortunately, section 4.3 "Encapsulation Procedure" does not have the "for each SCTP association" part, so it would be better to clarify this also in 4.3 that the UDP port number is per destination address per SCTP association. The current draft also does not comment anything about NAT keepalives. For example the RFC3948 (UDP encapsulation for IPsec) does specify special NAT keepalive packets which are sent by the host behind the NAT to keep the NAT mapping alive, as quite often NAT boxes remove mappings after certain time. If the NAT mapping disappears, then packets might not pass NAT box anymore depending on the direction of packets and type of NAT box (see RFC2663 for different types of NATs). The current draft does not seem to answer any of the UNSAF (IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation, RFC3424) questions. -- kivinen@iki.fi From benl@google.com Fri Jan 11 02:33:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888D621F88C7 for ; Fri, 11 Jan 2013 02:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyV56XksqaHq for ; Fri, 11 Jan 2013 02:33:36 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7BD21F88D6 for ; Fri, 11 Jan 2013 02:33:32 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hn3so926810wib.5 for ; Fri, 11 Jan 2013 02:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PzisIdnmyfKCd0xSPFSM8/C8RaB1ljnvtrgdAr0CgEY=; b=lAW4Px7hIL26skOkHg9DHzhGH1bUR5IHK6IGr0yqA1I2+fHHL7T36OhvtLv8CM2NoT aLJs7r/MSEX0E1/hyae1d39wGKLq3LDe5zgOTmoRZ1iu9LEDMsswkKqSGMfx0XlFakQW qE9m4XHAN1RwLR0p+ftVEp96K4A3kig7f+AQXyHVkH5I9pbYa5QBz/nZnUVYTx/20cCj fM3u6s+rDwDuIEvHGa3Ija71w0VD4yv81rWfZWzyPnT9CpQGSCuhf+R/XhnBy3UcYNiU OEyQSkrYf74MlyMqolkJP4eNVSZ2SHorYwj5//vSRA0b30v1QAbZNJM6D0CiGVpYuJJ9 6PQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=PzisIdnmyfKCd0xSPFSM8/C8RaB1ljnvtrgdAr0CgEY=; b=JAxbGB7Xz/BKmZzngb6hOS9+qX8NVbF4wdvPFAzX3bSfPxL0Wik7nStnbChY6RanXT jNrKWCnqFeYiKpZ6jfzh8IVEv2KaQ48mA/C+ucSyX9317T+GuJPvijzbUixrCLR53JWi wGIX4e4zpufeJvnQX/whFj543a82YEqdnlZ1TtY/8KVNeg4swSN2qDt+yFOMAfBsqtKd 1EoWcgJRX98EBDTgNvYtObjvA6Q7EygJ/V/Sggs0/KB3Hh6Zy+BDZxDF3Fve7/lgICcn GOUUmtOsg1S7K79zvSnacYCEOEap/YGUn3kQhnxrjzKC7mat4HiCD0HRSA63Ejl1i+Nk 5BLQ== MIME-Version: 1.0 Received: by 10.180.77.68 with SMTP id q4mr14470656wiw.10.1357900411497; Fri, 11 Jan 2013 02:33:31 -0800 (PST) Received: by 10.194.234.134 with HTTP; Fri, 11 Jan 2013 02:33:31 -0800 (PST) In-Reply-To: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch> References: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch> Date: Fri, 11 Jan 2013 10:33:31 +0000 Message-ID: From: Ben Laurie To: Brian Trammell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl4e1iSxsn92mklJ1/H+I70LX9qf4tTxoiGuLAP/kWh/xm6QhBrH5Vr9ei8J1xJoqm0htvLZudyaKoyEEsaIi9TGONACPzHJhYve9Z/r/2p/WAyhcOHhtQgGq0O5xZ0/OaKYCRLpeJlMb2+1oJ4aU045JCcSLn6O+0LCmxhXJ6ubHo8TP9DE7h8jw2WciiQYZ8JBWzN Cc: draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org, The IESG , "ipfix@ietf.org Working Group" , secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:33:37 -0000 On 11 January 2013 09:24, Brian Trammell wrote: > Hi, Ben, > > Many thanks for the review. Comments/questions thereon inline. > > On Jan 10, 2013, at 12:55 PM, Ben Laurie wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Summary: this document is part of a series of documents describing the >> protocol, and only deals with data elements. As such, most security >> considerations are dealt with elsewhere. > > (I'll address the following as comments on 5101 / 5101bis, specifically s= ection 11, which I assume you're referring to...) Right. > >> However, I note that whilst a >> good deal of attention is paid to integrity and authentication of the >> data in those other documents, as far as I can see nothing is said >> about authentication of the requester, > > As IPFIX is a push protocol designed for operation within a network manag= ement infrastructure there is no "requester" per se. There are only exporte= rs and collectors, the former configured (out of band) to send information = to the latter, the latter to accept information from the former. Section 11= .3 of rfc5101(-bis) addresses authentication of exporters and collectors...= . Ah, that was not clear to me, thanks for the explanation. It might be nice to at least mention that the out of band configuration is also security sensitive (and perhaps mention the push nature of the protocol in the security considerations to make it clearer for the non-expert). > >> nor about access control. > > ...however, while the intention of section 11.3 of RFC5101(-bis) was to s= tate that collectors/exporters should only establish sessions with peers th= at they could authenticate using TLS mutual authentication, on rereading I = see that this isn't explicitly stated in that section. We should fix that. > > Section 11 is also a little outdated (at least with respect to terminolog= y for doing DNS-ID lookups) and appears to be needlessly restrictive (e.g.,= TLS-PSK is not allowed although it would be useful in this case). We shoul= d review this as well. I didn;t intend to review 5101 as well, but anyway re-reading this section raises some questions 1. What is meant by "Each of the IPFIX Exporting and Collecting Processes MUST verify the identity of its peer against its authorized certificates" is a little unclear - does it mean the cert must match an authorized cert, or that it must chain from one? 2. There's a requirement to match the DNS name - but the server end of the connection may not have access to the client's (relevant) DNS name. Presumably there's some more complex process involving DNS lookups you have in mind here? (And if you introduce PSK, there's no cert). 3. As it stands it would be perfectly OK for an exporter to connect to a collector and then send it data for flows it is not configured to send (but are expected from another exporter). > > >> Given >> that flow information is potentially quite sensitive, this is >> surprising. The document itself seems OK, with nits. > >> Nits: >> >> "3.1.14. string >> >> The type "string" represents a finite-length string of valid >> characters from the Unicode character encoding set >> [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and many >> other international character sets to be used." >> >> RFC 5610 says this is encoded using UTF-8. UTF-8 can have security >> issues, e.g. sending a string with an incomplete UTF-8 encoded >> character, which then swallows part of a following string, or causes >> errors in parsers. Although this document may not be the right place >> for it, it is unfortunate this potential problem is not mentioned. > > This is good point. Would you know of an existing description of this pro= blem, ideally with mitigation strategies at the receiver, that we could ref= erence here? Again, I think this would be something to address in 5101bis, = as 5102bis is concerned with _abstract_ data types, and 5101bis presents th= e IPFIX-compatible encoding of those data types. "Unicode Security Considerations" (http://www.unicode.org/reports/tr36/#UTF-8_Exploit) has a good discussion. From dhanes@cisco.com Thu Jan 10 19:31:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D7321F8809; Thu, 10 Jan 2013 19:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z7P+mHT+C5f; Thu, 10 Jan 2013 19:31:53 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id E350C21F87DC; Thu, 10 Jan 2013 19:31:52 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0B3VoMU011273; Thu, 10 Jan 2013 22:31:50 -0500 (EST) Received: from rtp-dhanes-8917.cisco.com (rtp-dhanes-8917.cisco.com [10.117.39.200]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0B3VnEE013828; Thu, 10 Jan 2013 22:31:49 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: David Hanes In-Reply-To: Date: Thu, 10 Jan 2013 22:31:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Yu X-Mailer: Apple Mail (2.1085) X-Mailman-Approved-At: Fri, 11 Jan 2013 03:24:12 -0800 Cc: secdir@ietf.org, Kevin Fleming , Gonzalo Camarillo , Gonzalo Salgueiro , iesg@ietf.org, draft-hanes-dispatch-fax-capability.all@tools.ietf.org Subject: Re: [secdir] secdir review of draft-hanes-dispatch-fax-capability-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 03:31:54 -0000 Hi Tom, Sorry for the delayed response but thanks for your review and feedback = on the document. This media feature tag has the effect of explicitly = indicating a call *preference* to be fax; but there is no guarantee that = it will end up that way (the re-INVITE SIP message later in the call = flow is a much more accurate predictor that a call is of type fax). = Your question is reasonable since that simple fact could still seemingly = simplify targeted attacks because chances are improved that the = resultant call is indeed fax. The truth is that SIP and SDP have = various such media identification features so this is a persistent = issue. Secondly, the reason for the umbrella reference to RCFC 3840 is = that ANY media feature tag will be an explicitly indication of = preference for a particular media type (speech, text, etc.). This draft = merely registers a new value in a long list of other media feature tags = but doesn't introduce any new Security Considerations that those others = wouldn't have to address through the standard recommended privacy = mechanisms (e.g., encryption, obfuscation, etc.).=20 Regards, David On Dec 26, 2012, at 11:37 PM, Tom Yu wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document describes a SIP media feature tag for indicating support > for fax calls. >=20 > The Security Considerations section of this document refers to the > Security Considerations documented in Section 11.1 of RFC 3840. This > seems mostly adequate. One additional question (which might be > irrelevant because of my unfamiliarity with SIP) is whether an > explicit indication of fax content would make it easier for an > eavesdropper to target fax image data (which might contain sensitive > information such as credit card numbers). From trammell@tik.ee.ethz.ch Fri Jan 11 01:24:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6773221F873E; Fri, 11 Jan 2013 01:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E-FlJprZzUE; Fri, 11 Jan 2013 01:24:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9526C21F8629; Fri, 11 Jan 2013 01:24:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5B97FD930A; Fri, 11 Jan 2013 10:24:06 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IFp6uvcpHGFP; Fri, 11 Jan 2013 10:24:06 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 14CF8D9307; Fri, 11 Jan 2013 10:24:06 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: Date: Fri, 11 Jan 2013 10:24:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DCB34ED-F075-47C6-BE07-4B40B1A242F9@tik.ee.ethz.ch> References: To: Ben Laurie X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Fri, 11 Jan 2013 03:24:12 -0800 Cc: draft-ietf-ipfix-information-model-rfc5102bis.all@tools.ietf.org, The IESG , "ipfix@ietf.org Working Group" , secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-ipfix-information-model-rfc5102bis-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 09:24:14 -0000 Hi, Ben, Many thanks for the review. Comments/questions thereon inline. On Jan 10, 2013, at 12:55 PM, Ben Laurie wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Summary: this document is part of a series of documents describing the > protocol, and only deals with data elements. As such, most security > considerations are dealt with elsewhere. (I'll address the following as comments on 5101 / 5101bis, specifically = section 11, which I assume you're referring to...) > However, I note that whilst a > good deal of attention is paid to integrity and authentication of the > data in those other documents, as far as I can see nothing is said > about authentication of the requester, As IPFIX is a push protocol designed for operation within a network = management infrastructure there is no "requester" per se. There are only = exporters and collectors, the former configured (out of band) to send = information to the latter, the latter to accept information from the = former. Section 11.3 of rfc5101(-bis) addresses authentication of = exporters and collectors.... > nor about access control. ...however, while the intention of section 11.3 of RFC5101(-bis) was to = state that collectors/exporters should only establish sessions with = peers that they could authenticate using TLS mutual authentication, on = rereading I see that this isn't explicitly stated in that section. We = should fix that. Section 11 is also a little outdated (at least with respect to = terminology for doing DNS-ID lookups) and appears to be needlessly = restrictive (e.g., TLS-PSK is not allowed although it would be useful in = this case). We should review this as well. > Given > that flow information is potentially quite sensitive, this is > surprising. The document itself seems OK, with nits. > Nits: >=20 > "3.1.14. string >=20 > The type "string" represents a finite-length string of valid > characters from the Unicode character encoding set > [ISO.10646-1.1993]. Unicode allows for ASCII [ISO.646.1991] and = many > other international character sets to be used." >=20 > RFC 5610 says this is encoded using UTF-8. UTF-8 can have security > issues, e.g. sending a string with an incomplete UTF-8 encoded > character, which then swallows part of a following string, or causes > errors in parsers. Although this document may not be the right place > for it, it is unfortunate this potential problem is not mentioned. This is good point. Would you know of an existing description of this = problem, ideally with mitigation strategies at the receiver, that we = could reference here? Again, I think this would be something to address = in 5101bis, as 5102bis is concerned with _abstract_ data types, and = 5101bis presents the IPFIX-compatible encoding of those data types. Best regards, Brian= From bclaise@cisco.com Fri Jan 11 03:25:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5539C21F88EA; Fri, 11 Jan 2013 03:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7UPygxm8HTD; Fri, 11 Jan 2013 03:25:44 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 645C721F8873; Fri, 11 Jan 2013 03:25:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BBPYC4020686; Fri, 11 Jan 2013 12:25:34 +0100 (CET) Received: from [10.60.67.89] (ams-bclaise-8918.cisco.com [10.60.67.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0BBPXIo023756; Fri, 11 Jan 2013 12:25:33 +0100 (CET) Message-ID: <50EFF6AD.1040808@cisco.com> Date: Fri, 11 Jan 2013 12:25:33 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "draft-ietf-radext-ipv6-access.all@tools.ietf.org" References: <20550.1861.349381.646147@fireball.kivinen.iki.fi> <4613980CFC78314ABFD7F85CC30277210152E3@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277210152E3@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Wojciech Dec \(wdec\)" , "iesg@ietf.org IESG" , "radext-chairs@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-radext-ipv6-access-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 11:25:45 -0000 draft-ietf-radext-ipv6-access authors, Can you please address Yoav' point. Regards, Benoit > Hi > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > The draft adds IPv6 RADIUS attributes for information received using DHCP. The attributes include IPv6 address, DNS server address, IPv6 route information, delegated IPv6 prefix, and stateful IPv6 address pool. > > The security considerations section covers general vulnerabilities in RADIUS just to say that those apply here as well. It also makes a reference to IPsec as "natively defined for IPv6". This can IMO be omitted, as pretty much every platform that has IPsec for IPv6 has it for IPv4 as well, and IPsec is not longer required for compliance with IPv6, otherwise all those smart objects would be non-compliant. > > There is no treatment of the issue of a rogue RADIUS server supplying bad routes to the NAS. This can be explained away by saying that a trust relationship exists between RADIUS server and NAS, but I think this should be mentioned. > > Yoav > > > > > From wdec@cisco.com Fri Jan 11 03:48:46 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C900321F87B3; Fri, 11 Jan 2013 03:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9BfwraQyC4c; Fri, 11 Jan 2013 03:48:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A4C3521F87AD; Fri, 11 Jan 2013 03:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1534; q=dns/txt; s=iport; t=1357904925; x=1359114525; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QrRSzJoRJAlxsERLyS2AcHPY4DTNAguuorP25WTcujg=; b=Gym4h9nnOGK8FI3iGutvnlkLohmJn/LJBMCAGcPXAsDaUymAdFyWvpfN W3uHoudUE7q1c7ttdK+laKx8S8lDb0ZaAfI3CtK9rHlpsE+pqzl0Ujefr KSNmGU3Qg2WBmtMVueFDchWbJeIU7jDgIhKprn3wBMpoIsEpgzOipRSd4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHb771CtJXHA/2dsb2JhbABEvXkWc4IgAQQ6OAcSAQgiFEIlAgQBDQUIiBG1PZA+YQOmU4J1giQ X-IronPort-AV: E=Sophos;i="4.84,451,1355097600"; d="scan'208";a="161374288" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 11 Jan 2013 11:48:45 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0BBmiVh027400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jan 2013 11:48:45 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.135]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 11 Jan 2013 05:48:44 -0600 From: "Wojciech Dec (wdec)" To: "Benoit Claise (bclaise)" , "draft-ietf-radext-ipv6-access.all@tools.ietf.org" Thread-Topic: SecDir review of draft-ietf-radext-ipv6-access-13 Thread-Index: AQHN7+5hTcFX1L/h0Em0c0QGTPnw2phEeK2A Date: Fri, 11 Jan 2013 11:48:43 +0000 Message-ID: <19F346EB777BEE4CB77DA1A2C56F20B31D5932@xmb-aln-x05.cisco.com> In-Reply-To: <50EFF6AD.1040808@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.61.104.83] Content-Type: text/plain; charset="us-ascii" Content-ID: <905D47184D70E546BE5E6EFF457483C6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 11 Jan 2013 08:09:19 -0800 Cc: "iesg@ietf.org IESG" , "radext-chairs@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-radext-ipv6-access-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 11:48:47 -0000 Thanks. Comment is addressed in draft 15. Rgds Woj.. On 11/01/2013 12:25, "Benoit Claise (bclaise)" wrote: >draft-ietf-radext-ipv6-access authors, > >Can you please address Yoav' point. > >Regards, Benoit >> Hi >> >> I have reviewed this document as part of the security directorate's >>ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >>area directors. Document editors and WG chairs should treat these >>comments just like any other last call comments. >> >> The draft adds IPv6 RADIUS attributes for information received using >>DHCP. The attributes include IPv6 address, DNS server address, IPv6 >>route information, delegated IPv6 prefix, and stateful IPv6 address pool. >> >> The security considerations section covers general vulnerabilities in >>RADIUS just to say that those apply here as well. It also makes a >>reference to IPsec as "natively defined for IPv6". This can IMO be >>omitted, as pretty much every platform that has IPsec for IPv6 has it >>for IPv4 as well, and IPsec is not longer required for compliance with >>IPv6, otherwise all those smart objects would be non-compliant. >> >> There is no treatment of the issue of a rogue RADIUS server supplying >>bad routes to the NAS. This can be explained away by saying that a trust >>relationship exists between RADIUS server and NAS, but I think this >>should be mentioned. >> >> Yoav >> >> >> >> >> > From tuexen@fh-muenster.de Fri Jan 11 13:23:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D74221F8797; Fri, 11 Jan 2013 13:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHemwXS8RUVr; Fri, 11 Jan 2013 13:23:19 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF621F886A; Fri, 11 Jan 2013 13:23:15 -0800 (PST) Received: from [192.168.1.101] (p5481A117.dip.t-dialin.net [84.129.161.23]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A49F41C0C069D; Fri, 11 Jan 2013 22:23:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20718.54159.713629.567812@fireball.kivinen.iki.fi> Date: Fri, 11 Jan 2013 22:23:15 +0100 Content-Transfer-Encoding: 7bit Message-Id: <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:23:28 -0000 On Jan 10, 2013, at 3:43 PM, Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Hi Tero, thank you very much for your comments. See my answers inline. > > This document describes the UDP encapsulation for the SCTP packets. > It seems to be quite similar to other UDP encapsulation documents (for > example RFC3948 for IPsec). The security considerations section points > to the RFC4960 and RFC5061 and says there is no additional security > considerations. I belive this is not true. > > The RFC4960 section 11.3 talks about the SCTP Interactions with > firewalls, i.e. how firewalls can do SCTP filtering and how to find > the INIT chunks. This UDP encapsulation can be used to bypass those > checks, by encapsulating the initial INIT chunks with UDP encapsulated > SCTP packets and then after that move to normal SCTP flow (or just > stay in the UDP encapsulated SCTP). > > This might allow bypassing the firewall rules set by the site > adminstrator. This also might allow attacks to the hosts inside the > firewall protected domain by bypassing the firewall, which was > supposed to be protecting the hosts. > > The document should note that firewalls needs to be updated to > specifically inspect / filter also UDP encapsulated SCTP if they do > normal SCTP inspection / filtering. I agree. What about adding the following to the Security Considerations: Firewalls inspecting SCTP packets must also be aware of the encapsulation and apply corresponding rules to the encapsulated packets. > > Also some other issues. > > It is not clear for me how the initiator host finds the port where to > connect, when it is doing initial connection. I.e. if a host A wants > to connect to host B, which port it should use if it needs to use UDP > encapsulated SCTP? Is it assumed that 9899 will be used always? What > about connecting to the hosts which are behind NAT, i.e. if host B is > behind NAT, how does host A find the port number to use (which host B > hopefully somehow already configred to the NAT to be passed to him)? The method for finding the remote port number for the initial packets is not in the scope of this document. This is something you would do outside of the SCTP stack. The described API provides the required interface for the application to set the remote encapsulation port. > > Also what if host A and B already have one SCTP connection, and now > host B wants to create another, do host B reuse the same UDP > destination port number for host A that was used for the already > existing SCTP connection between them? The section 4.1 says that UDP > port numbers are stored per destination address per SCTP association, > so that would indicate no. As stated in the document, each stack uses a single port number as the destination address of all incoming packets. > > The draft seems to be doing dynamic port number updating based on > finding SCTP association (which includes checking the very weak > verification tag). The current section 4.4 only mentions that port > number is updated. In some cases also the IP-address might change, Correct. > i.e. if the NAT box is rebooted or its connection table is cleared, > and the NAT box have multiple IP-addresses, it is completly possible > that the NAT mapping changes so that IP-address and UDP port number > both change. I am not familiar enough with SCTP to know whether this > causes problem with SCTP, i.e. whether it is default SCTP rules to use > the last seen IP-address when sending reply or what. The method described in the document does NOT cover changing the address. If you want to handle that, you need to use the address reconfiguration extension (RFC 5061). > > The section 3.2 do say that if multiple addresses are used, then > RFC5061 (SCTP Dynamic Address Reconfiguration) with RFC4895 > (Authentication Chunks for SCTP) MUST be used. With dynamic update for > the UDP port number, the similar hijacking attack described in the > RFC5061 security considerations section is applicable here too. The > RFC5061 requires (without using RFC2119 language) using of > authentication chunks to prevent that attack, so should we require > authentication chunks here too to prevent same attacks even when using > only one IP-address, as we do update the UDP ports based on the > received packets? Also perhaps the requirement of using authentication I don't think so. The reasoning is the SCTP/UDP/IP does not need to be more secure than SCTP/IP. SCTP/IP is protected against blind attackers by the V-tag mechanism. The same applies to SCTP/UDP/IP. This is described in the second paragraph of the Security Considerations. The situation is different from changing the IP address. Assume that there is an association between endpoints A and B. If A owns IP.A while establishing the association, then looses it and a node C gets it, B sends packets to C. So C could take over the association. > chunks should be also mentioned in the security considerations > section, as it is very important for the security point of view of the > protocol. > > The section 4.1 "Architectural Considerations" says correctly that > implementations needs to store remote UDP port per destination address > for each SCTP association, i.e. different SCTP associations can have > different port numbers for same destination address. This is required, > because there might be multiple SCTP clients behind the same NAT box > (having same IP-address), just using different ports. Unfortunately, And there might be multiple peer addresses and the port might be different. It is even possible that some peer addresses need encapsulation and some don't. > section 4.3 "Encapsulation Procedure" does not have the "for each SCTP > association" part, so it would be better to clarify this also in 4.3 > that the UDP port number is per destination address per SCTP > association. What about: When inserting the UDP header, the source port MUST be the local UDP encapsulation port number of the SCTP stack, the destination port MUST be the remote UDP encapsulation port number stored for the association and the destination address to which the packet is sent (see ). > > The current draft also does not comment anything about NAT keepalives. > For example the RFC3948 (UDP encapsulation for IPsec) does specify > special NAT keepalive packets which are sent by the host behind the > NAT to keep the NAT mapping alive, as quite often NAT boxes remove > mappings after certain time. If the NAT mapping disappears, then > packets might not pass NAT box anymore depending on the direction of > packets and type of NAT box (see RFC2663 for different types of NATs). SCTP sends on each idle path HEARTBEAT messages which would keep the NAT state alive. What about adding the following to section 3.2: SCTP sends periodically HEARTBEAT chunks on all idle paths. These can be used to keep the NAT state alive. > > The current draft does not seem to answer any of the UNSAF (IAB > Considerations for UNilateral Self-Address Fixing (UNSAF) Across > Network Address Translation, RFC3424) questions. That is correct. However, the document describes how you encapsulate SCTP in UDP, not how you build a complete NAT traversal solution where both ends might be behind NATs. So finding the remote encapsulation port is not within the scope of the document. > -- > kivinen@iki.fi > From ncamwing@cisco.com Sat Jan 12 07:23:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED94F21F870A; Sat, 12 Jan 2013 07:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09UYCLfUbnwc; Sat, 12 Jan 2013 07:23:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E2C1021F8707; Sat, 12 Jan 2013 07:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=972; q=dns/txt; s=iport; t=1358004222; x=1359213822; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=gmU7maBtATuVB2AbqwWzmmVaOoH3jvKyn8fnZj3uAfE=; b=j21Yehd8Pz2YVsa7h8eVpSIW7kRjo9nT+NHhxlLZOsOxixkx3yZbRngK 3OE/EpfvUqF75HppEWOArBNC+6Q7w7BYE8z48+N0qRHrERcBBwO2g/OMG YSeHJYEKPS7WA51Slc02B+KNHyj7hvBJNtMR7ZpUX7FzeAyE6/a0VwHIX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEx/8VCtJXG9/2dsb2JhbABFvg8Wc4IgAQQ6UQEIIhRCJQIEARIIiBG1OpBNYQOmVIJ1giQ X-IronPort-AV: E=Sophos;i="4.84,458,1355097600"; d="scan'208";a="161704407" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 12 Jan 2013 15:23:41 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0CFNfdg023818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 12 Jan 2013 15:23:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Sat, 12 Jan 2013 09:23:41 -0600 From: "Nancy Cam-Winget (ncamwing)" To: Leif Johansson , "secdir@ietf.org" , "draft-ietf-nea-pt-eap.all@tools.ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-nea-pt-eap-06 Thread-Index: AQHN7NSAhWJul+LVc0GKYm4QR11Ah5hFtmeA Date: Sat, 12 Jan 2013 15:23:41 +0000 Message-ID: In-Reply-To: <50EAC2B8.3080908@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.117.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 13 Jan 2013 08:02:37 -0800 Subject: Re: [secdir] secdir review of draft-ietf-nea-pt-eap-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 15:23:44 -0000 Hi Leif, Thanks for your review. I can make that update to the PT-EAP draft as it looks like a few more comments are trickling in as well. Thanks! Nancy. On 1/7/13 4:42 AM, "Leif Johansson" wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written primarily for the benefit of the security >area directors. Document editors and WG chairs should treat these >comments just like any other last call comments. > >This document describes a posture transport protocol for EAP tunnel >methods. > >I found the document clearly written and easy to follow. > >The only suggestion I have is that in section 3.4 (or 4.2.5) on the Asokan >Attack the document should clearly state that the verification of the >channel >token MUST be performed before any other attestations are evaluated. > > Cheers Leif From paul.hoffman@vpnc.org Mon Jan 14 11:05:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDBF21F8ABA for ; Mon, 14 Jan 2013 11:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdctmM9Fuo68 for ; Mon, 14 Jan 2013 11:05:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D1FE121F89EE for ; Mon, 14 Jan 2013 11:05:37 -0800 (PST) Received: from [172.19.131.164] ([12.130.118.13]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0EJ5VjZ099084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Jan 2013 12:05:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 14 Jan 2013 11:05:32 -0800 To: secdir Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [secdir] Secdir review of draft-ietf-sidr-rpki-rtr-protocol-mib X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 19:05:40 -0000 This document is a MIB for the RPKI-Router protocol from the SIDR WG. It = is a bunch of MIBish boilerplate, followed by a MIB, followed by a = boilerplate security considerations section. It all seems fine. = RPKI-Router is itself a security protocol, so the MIB for it might be = considered more security-sensitive than for "regular" protocols, but the = boilerplate here seems to cover any sort of protocol well. --Paul Hoffman= From new-work-bounces@ietf.org Tue Jan 15 08:43:33 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5F621F8555; Tue, 15 Jan 2013 08:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1358268213; bh=L1EEeQxM3Ux5eE9+OULcze2/5rq8k3QZWCQ/c1l5j/I=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=FpyJfFQ6xo58mh2CRa4pqmjHs0+1AudFDQCLxAa7bYbWqjuwzYAtPAuAE9eJKaFYE LcHwaReVr7wbTJbzGWWKufCpM/LgDpuJKGD5q1WgHGi+SQSFZZRsKFAplou8PrvBwI 1WKcZ+slElkMf8D1r0f47qh+waJLY8TCumvUToWg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A20B21F8870; Tue, 15 Jan 2013 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnOxTEH8XbA0; Tue, 15 Jan 2013 08:43:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389D421F8859; Tue, 15 Jan 2013 08:43:29 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115164329.2283.5040.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 08:43:29 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 15 Jan 2013 08:44:13 -0800 Subject: [secdir] [new-work] WG Review: Interface to the Routing System (i2rs) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 16:43:33 -0000 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-01-22. Interface to the Routing System (i2rs) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Adrian Farrel Mailing list Address: i2rs@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2rs Archive: http://www.ietf.org/mail-archive/web/i2rs/current/maillist.html Charter of Working Group: Working Group Name: Interfaces to the Routing System (I2RS) IETF Area: Routing Area Chair(s): TBD Routing Area Director(s): Adrian Farrel Routing Area Advisor: Adrian Farrel Operations Area Advisor: TBD Mailing Lists: General Discussion: i2rs@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/i2rs Archive: http://www.ietf.org/mail-archive/web/i2rs/current/maillist.html Description of Working Group: In an IP routed network, the routing system: - Distributes topology and other state (network metadata) - Uses this network metadata to determine the best path to each given reachable destination attached to the network - Communicates these decisions to the forwarding plane of each forwarding device in the network. That is, the routing system is the collection of entities, protocols and processes that collectively build the forwarding tables that are exported into the entities that constitute the network's fowarding plane. While processes participating in the routing system are often colocated with the local forwarding elements, this isn't a necessary condition. Thus, the routing system includes control plane protocols that compute routes and paths for data packets, wherever the processes implementing those protocols may be running. I2RS facilitates real-time or event driven interaction with the routing system through a collection of protocol-based control or management interfaces. These allow information, policies, and operational parameters to be injected into and retrieved (as read or by notification) from the routing system while retaining data consistency and coherency across the routers and routing infrastructure, and among multiple interactions with the routing system. The I2RS interfaces will co-exist with existing configuration and management systems and interfaces. It is envisioned that users of the I2RS interfaces will be management applications, network controllers, and user applications that make specific demands on the network. The I2RS working group works to develop a high-level framework and architecture that describes the basic building-blocks necessary to enable the specific use cases, and that will lead to an understanding of the abstract informational models and requirements for encodings and protocols for the I2RS interfaces. Small and well-scoped use cases are critical to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. Initial work within the working group will be limited to a single administrative domain. The working group is chartered to work on the following items: - High-level architecture and framework for I2RS including considerations of policy and security. - Tightly scoped key use cases for operational use of I2RS as follows: o Interactions with the Routing Information Base (RIB). Allowing read and write access to the RIB, but no direct access to the Forwarding Information Base (FIB). o Control and analysis of the operation of the Border gateway Protocol (BGP) including the setting and activation of policies related to the protocol. o Control, optimization, and choice of traffic exit points from networks based on more information than provided by the dynamic control plane. o Distributed reaction to network-based attacks through quickly modification of the control plane behavior to reroute traffic for one destination while leaving a standard mechanisms (filters, metrics, and policy) in place for other routes. o Service layer routing to improve on existing hub-and-spoke traffic. o The ability to extract information about topology from the network. Injection and creation of topology will not be considered as an initial work item. Other use cases may be adopted by the working group only through rechartering. - Abstract information models consistent with the use cases. - Requirements for I2RS protocols and encoding languages. - An analysis of existing IETF and other protocols and encoding languages against the requirements. The working group is not currently chartered to develop protocols, encoding languages, or data models. The objective of this work effort is to arrive at common standards for these items, but these items are dependent on the progress of the topics listed above. Work for these items will be conducted in this working group only after a re-charter, and/or may be carried out in another working group with specific responsibility for the protocol or encoding language. Goals and Milestones: Jul 2013: Request publication of an Informational document defining the problem statement Jul 2013: Request publication of an Informational document defining the highlevel architecture and framework Aug 2013: Request publication of Informational documents describing use cases Sep 2013: Request publication of an Informational document defining the protocol requirements Sep 2013: Request publication of an Informational document defining encoding language requirements Nov 2013: Request publication of Standards Track documents specifying information models Nov 2013: Request publication of an Informational document providing an analysis of existing IETF and other protocols and encoding languages against the requirements Dec 2013: Consider re-chartering _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From simon@josefsson.org Wed Jan 16 07:26:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3A21F8A2F; Wed, 16 Jan 2013 07:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRaMuRd053GZ; Wed, 16 Jan 2013 07:26:06 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 887C021F8A25; Wed, 16 Jan 2013 07:26:04 -0800 (PST) Received: from [192.168.10.183] (229.Red-80-59-64.staticIP.rima-tde.net [80.59.64.229]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r0GFPdXF026980 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 16 Jan 2013 16:25:50 +0100 Message-ID: <1358349927.4463.5.camel@latte.josefsson.org> From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6man-ipv6-atomic-fragments.all@ietf.org Date: Wed, 16 Jan 2013 16:25:27 +0100 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: [secdir] Review of draft-ietf-6man-ipv6-atomic-fragments-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 15:26:06 -0000 I've reviewed draft-ietf-6man-ipv6-atomic-fragments-03.txt and believe the document is "Ready with nits". From a security perspective, one could desire more discussion in the document but I do not believe significant attention is required. Document summary: The document is about special kind of IPv6 fragment; a fragment that claim to be offset 0 of the payload and also to be the last fragment. The document says that those fragments can be reassembled without waiting for any other fragment. The document is another tweak for the IPv6 fragmentation rules. /Simon Caveat: I'm not an IPv6 expert so the issues below may just be due to my misunderstanding of how things work. A sufficient response to some of the issues below may just be that I got it all wrong, although if that is the case, some explanation for my education would be appreciated. MINOR ISSUES: 1) The document does a good job describing how attackers can trigger atomic fragments, which makes it possible to apply fragmention-based attacks to normal traffic. But there is no details about fragmentation-based attacks, neither what is gained nor how they are mounted. It refers to informational documents [I-D.gont-6man-predictable-fragment-id] and [CPNI-IPv6] for the attacks, which I have not reviewed. Thus the abstract's claim that "the document discuss [...] the corresponding security implications" seems erradic since the discussion does not happen in this document. The Security Considerations does not describe any complete attack either. It is possible, perhaps likely, that fragmentation-based attacks are well-known to anyone working with IPv6 that they do not need to be explained in this document. As an out-sider, though, I was left with the feeling that the attack this document attempts to protect against is not actually described. If a short description of one complete attack could be added, that would have helped me. 2) This is actually more of a question about the new rule text. I'm having trouble understanding what should happen in the following situation: * A host has a fragment with fragment identification X in its cache, with fragment offset 42 and M=1 indicating there are other outstanding fragments. * A host has received an atomic fragment (i.e, fragment offset 0 and M=0) with the same fragment identification X. * A host never receives any more fragments with the fragment identification X. RFC 2460 says: If insufficient fragments are received to complete reassembly of a packet within 60 seconds of the reception of the first-arriving fragment of that packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded. If the first fragment (i.e., the one with a Fragment Offset of zero) has been received, an ICMP Time Exceeded -- Fragment Reassembly Time Exceeded message should be sent to the source of that fragment. Now given the following updated text in section 4: A host that receives an IPv6 packet which includes a Fragment Header with the "Fragment Offset" equal to 0 and the "M" bit equal to 0 MUST process such packet in isolation from any other packets/ fragments, even if such packets/fragments contain the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. The atomic fragment should be dealt with in isolation, so it is reassembled immediately. Now, after 60 seconds, what should the host do? Should it send an ICMP Time Exceeded or not? It has already completed assembly but it is also waiting for more fragments. 3) As a consequence of the previous point, I'm left uncertain about how the updated rule interacts with the requirements in RFC 5722 about overlapping fragments. If overlapping payloads should cause packets to be dropped, this is no longer the case if atomic fragments are "let through" the fragmentation logic. 4) Section 2: Offset set to 0 and the M bit set to 0. ^^^ RFC 2460 uses the term "M flag", not "M bit". 5) o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big" error messages, the Destinations Cache is usually updated to ^^^^^^^^^^^^^^^^^^ reflect that any subsequent packets to such destination should include a Fragment Header. This means that a single ICMPv6 Where is "Destinations Cache" defined? The phrase does not have any specific meaning to me, and I cannot find it in any of the normative references. The use of upper case suggests to me that some well defined meaning is intended. Without understanding that term, I don't follow the rest of the paragraph. 6) Additionally, if any fragments with the same set {IPV6 Source ^ Typo, 'v'. From kivinen@iki.fi Wed Jan 16 23:39:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2586221F88CB for ; Wed, 16 Jan 2013 23:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW8lRO0DssLH for ; Wed, 16 Jan 2013 23:39:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D94121F88C8 for ; Wed, 16 Jan 2013 23:39:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0H7daYa019770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jan 2013 09:39:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0H7dYmH024945; Thu, 17 Jan 2013 09:39:34 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20727.43702.770479.139307@fireball.kivinen.iki.fi> Date: Thu, 17 Jan 2013 09:39:34 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 07:39:53 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2013-01-24 Reviewer LC end Draft Dave Cridland T 2013-01-02 draft-schaad-pkix-rfc2875-bis-06 Phillip Hallam-Baker T 2013-01-03 draft-ietf-roll-p2p-rpl-15 Chris Lonvick T 2013-01-22 draft-ietf-rmt-fcast-07 Catherine Meadows T 2013-01-22 draft-ietf-rmt-flute-sdp-03 Vincent Roca TR2012-09-24 draft-ietf-dime-erp-16 For telechat 2013-02-21 Hilarie Orman T 2013-02-11 draft-leiba-urnbis-ietf-namespace-01 Last calls and special requests: Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Jeffrey Hutzelman 2013-01-24 draft-laurie-pki-sunlight-05 Scott Kelly 2013-01-17 draft-ietf-avtcore-srtp-encrypted-header-ext-04 Stephen Kent 2013-01-21 draft-ietf-roll-security-threats-00 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-08 Julien Laganier 2013-01-21 draft-ietf-ccamp-lmp-behavior-negotiation-09 Matt Lepinski 2013-01-25 draft-ietf-radext-radius-extensions-08 Alexey Melnikov 2013-01-21 draft-ietf-roll-p2p-measurement-07 Kathleen Moriarty 2013-02-08 draft-farrell-ft-03 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Sandy Murphy 2013-01-29 draft-ietf-6man-nd-extension-headers-03 Yoav Nir 2013-01-30 draft-ietf-bmwg-sip-bench-term-08 Magnus Nystrom 2013-01-25 draft-ietf-eman-requirements-10 Radia Perlman 2013-01-24 draft-ietf-idr-deprecate-dpa-etal-00 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-00 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Vincent Roca 2013-01-25 draft-ietf-eman-rfc4133bis-05 Joe Salowey 2013-01-28 draft-ietf-storm-iscsimib-03 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 -- kivinen@iki.fi From kent@bbn.com Thu Jan 17 09:08:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F5A21F849A for ; Thu, 17 Jan 2013 09:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.289 X-Spam-Level: X-Spam-Status: No, score=-105.289 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySXQzbRZhs20 for ; Thu, 17 Jan 2013 09:08:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B983821F8476 for ; Thu, 17 Jan 2013 09:08:47 -0800 (PST) Received: from [128.89.89.145] (port=52445 helo=bud-d360.bbn.com) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TvsxG-000ECt-CC; Thu, 17 Jan 2013 12:08:42 -0500 Message-ID: <50F8301A.2060508@bbn.com> Date: Thu, 17 Jan 2013 12:08:42 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: secdir , angel.lozano@upf.edu, vanesa.daza@upf.edu, mischa.dohler@cttc.es, roger.alexander@cooperindustries.com, tzeta.tsao@cooperindustries.com, mcr+ietf@sandelman.ca, jpv@cisco.com, adrian@olddog.co.uk Content-Type: multipart/alternative; boundary="------------020504040209010307090606" Subject: [secdir] SECDIR review of draft-ietf-roll-security-threats-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 17:08:54 -0000 This is a multi-part message in MIME format. --------------020504040209010307090606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-ietf-roll-security-threats-00 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This is a long document moderate, 47 densely-written pages. It is characterized as a threat analysis for a routing technology for use in low power and lossy networks (ROLL). The abstract says that it builds on other routing security documents, and adapts them to this specific environment. Looking ahead, I see that he references section cites RFC 4593, probably the most relevant threat document for routing, at this time, RFC 4949 the security glossary). These were good omens. Unfortunately, there are a number of problems with the text, as noted below. Given that this is a 00 doc, I'm guessing that the ROLL WG has not been so interested as to provide feedback. Pity. Section 3 gets off to a poor start. The definition of "security" introduced here is too generic, and quickly needs to be qualified to add notions of authorization, authentication, confidentiality, and timeliness. There are references to various academia papers, which may be appropriate. I note, however, that other such papers that characterize routing security in terms of "correct" operation of a routing protocol, e.g., in the BGP context, have not been cited, and do not appear to be part of the methodology here. 3.1 -- Much of the model presented in this section seems to be unnecessarily abstract, but maybe it gets better, later. 3.2 -- One shortcoming of the "CIA" model is that it fails to differentiate authentication from integrity, and it also does not explicitly include authorization. This shortcoming shows up in the discussion on page 9. Use of the IS0 7498-2 security service terms might have yielded a better outcome, although that list also is not perfect. The introduction of the term "misuse" under the heading of integrity strikes me as inappropriate. I disagree thatnon-repudiation might be relevant here. This security service (defined in ISO 6498-2) applies to people and organizations, not to devices. 3.3 -- The phrase "sleepy node" is introduced, but was not defined in the terminology section. 3.4 -- The use of the term "misappropriated" is odd, at best. Are the authors referring to unauthorized use? The term "legitimacy," applied to participants is not helpful. Do the authors mean 'authorized" here? The term "truthfulness" appears here, and is equally unhelpful. How about "accurate?" I'm beginning to wonder how carefully the authors read 4593! 4.1- the authors should use technical terminology from 4949, since they went to the trouble to cite in various places, e.g., replace "sniffing" with "passive wiretapping," both here and throughput the document. Also, the term "traffic analysis" is much broader than what the authors suggest here. Even without access to headers per se, one can examine the size of messages and the frequency of transmission, and both of these are examples of traffic analysis. 4.2 -- here too, addressing integrity and authentication separately might result in a clearer discussion. For example, "identity misappropriation" is really a violation of an authentication guarantee. The terms "overclaiming" and "misclaiming" are introduced here (4.4.1), without being defined earlier. There is mention of "freshness" which might have been addressed by using the 7498-2 terminology "connection-orietned integrity." 4.3- "Selective forwarding," "wormhole," and "sinkhole" attacks are mentioned, without definition. Using a diagram to illustrate these attacks is not a substitute for concise definitions. In 4.3.4 "overload" attacks are noted, but not defined. Also, selective forwarding isn't a routing attack, so why is it included here? 5. -- Use of encryption does not counter deliberate exposure attacks. Use of encryption, and authentication, is a counter to exposure of routing data via passive wiretapping. 5.1.2 - Passive wiretapping ("sniffing" to the authors) does not include device compromise. The discussion of what constitutes a suitable key length is not a good topic for this document. First, the authors fail to note, at the beginning of the relevant paragraph, that the key length comments are applicable to symmetric cryptographic algorithms. Second, absent a mention of the granularity of key distribution, this discussion is premature, at best. 5.1.3 - TA is always a passive attack, so the description here "... may be passive..." is wrong. Also, TA is broader in scope than the authors stated earlier, and thus the proposed countermeasures are a subset of what might be considered.The discussion here seems to diverge from the routing security focus of the document, when the authors discuss TA issues relevant to end-user traffic flows. 5.1.4 -- Discussions of anti-tamper are rarely appropriate for IETF documents. There is no reason to believe that these authors are especially knowledgeable about such technology. I suggest this section be deleted. 5.2 -- Again, distinguishing among integrity, authentication, and authorization might make for a clearer discussion. Adherence to the "CAI" model is causing these problems. 5.2.1 -- the discussionhere is very superficial, not as thorough as the subsections in 5.1. 5.2.2 -- This discussion is very superficial as well. 5.2.3 -- "liveliness" -> "liveness" The discussion of theuse of public key technology vs. symmetric cryptographic mechanisms for authentication is vastly oversimplified, and thus not very useful. Also, the work cited here [Wander2005] is not bad, but "NanoECC: testing the limits of elliptic curve cryptography in sensor networks, 2008" is more up to date. 5.2.4 - this discussion seems to overemphasize timestamps as a alternative to counters, without considering the vulnerabilities associated with transitively-relayed timestamp info. 5.3.1 -- Unlike previous sections, the focus here seems to be protocol-specific. I'd feel more comfortable that this was not simply an ad hocdiscussion if it were posed in a more general form. On the other hand, if ROLL has already selected a specific routing paradigm, the preceding section should be specific to that model. 5.3.2 -- "Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy store quicker" -> "Overload attacks are a form of DoS attack in which a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy store _more quickly_." This sort of attack is not one against routing, unless the overload is the result of processing routing traffic? 5.3.3 -- "Selective forwarding" is not a routing attack. 5.3.4 -- "..., if geographic positions of nodes are available, then the network can assure that data is actually routed towards the intended destination and not elsewhere." This is not always true, since a node might have an onward connection that provides faster or higher bandwidth service towards the destination. 5.3.5 -- "In wormhole attacks at least two malicious nodes shortcut or divert the usual routing path by means of a low-latency out-of-band channel." This seems to be a narrow characterization of such attacks. One might also say that two nodes that _claim_ to have a short path between themselves are effecting such an attack. If two nodes really do have a short, low latency path between themselves then, from a routing perspective, what's the problem? 6 -- I find the opening sentence to be very confusing: "The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing." 6.1 - "... and improve vulnerability against other more direct attacks ..." -> "... and reduce vulnerabilities relative to other attacks ..." What does "privacy" mean here? This is the first use of the term in this document. Also, the cite to Geopriv is not helpful, as the context for most Geopriv work does not match the ROLL environment. 6.2 -- Did you really mean to say " ... integrity of the encrypted message ..."? Generally one applies integrity mechanisms to the plaintext message, prior to encryption. The requirement to verify "message sequence" is grammatically incorrect and ambiguous. Routing protocols may not require delivery of every routing message. If the requirement here is anti-replay, say so. Also, the phrase "unintentional Byzantine" seems odd to me. It does not appear earlier, in the discussion of Byzantine threats. The common notion of a Byzantine attack is that the actors are doing so with intent. There is a very worrisome sentence in this section: In the most basic form, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated through the concatenation of trust established at each individual routing peer exchange." This sentence seems to endorse the notion of transitive trust for routing security, a bad idea. 6.4 -- A more appropriate title would be "Cryptographic Key Management." The endorsement of TPMs here seems inappropriately-specific. " ... a LLN is also encouraged to have automatic ..." I don't think you want to try to encourage a network, vs. a network operator. More to the point, we usually establish standards for security features for protocols, which seems to be the focus of this document. This is a directive directed to a network operator, and thus is out of place here. The reference to RFC 3029 is old, and refers to an experimental protocol. I'd suggest RFC 5055, which is much more recent, and is a proposed standard. " ... which supports several alternative private, public, or Diffie-Hellman ..." Diffie-Hellman is a public-key scheme! 6.5 -- " ... diversified needs ..." -> "... diverse needs..." 8 -- Although the text says that " ... design guidelines with a scope limited to ROLL." there are a few instances where the discussion is not limited to routing. I wish the document used standard terms for security services, and employed these for the requirements, e.g., from ISO 7498-2. The security service terminology used in this document is often ad hoc. "...mechanisms to be used to deal with each threat is specified ..." -> "...mechanisms to be used to deal with each threat _are_ specified ..." --------------020504040209010307090606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SECDIR review of draft-ietf-roll-security-threats-00

 

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

 

This is a long document moderate, 47 densely-written pages. It is characterized as a threat analysis for a routing technology for use in low power and lossy networks (ROLL). The abstract says that it builds on other routing security documents, and adapts them to this specific environment. Looking ahead, I see that he references section cites RFC 4593, probably the most relevant threat document for routing, at this time, RFC 4949 the security glossary). These were good omens. Unfortunately, there are a number of problems with the text, as noted below. Given that this is a 00 doc, I'm guessing that the ROLL WG has not been so interested as to provide feedback. Pity.

 

Section 3 gets off to a poor start. The definition of “security” introduced here is too generic, and quickly needs to be qualified to add notions of authorization, authentication, confidentiality, and timeliness. There are references to various academia papers, which may be appropriate. I note, however, that other such papers that characterize routing security in terms of “correct” operation of a routing protocol, e.g., in the BGP context, have not been cited, and do not appear to be part of the methodology here.

 

3.1 – Much of the model presented in this section seems to be unnecessarily abstract, but maybe it gets better, later.

 

3.2 – One shortcoming of the “CIA” model is that it fails to differentiate authentication from integrity, and it also does not explicitly include authorization. This shortcoming shows up in the discussion on page 9. Use of the IS0 7498-2 security service terms might have yielded a better outcome,

although that list also is not perfect. The introduction of the term “misuse” under the heading of integrity strikes me as inappropriate. I disagree that  non-repudiation might be relevant here. This security service (defined in ISO 6498-2) applies to people and organizations, not to devices.

 

3.3 – The phrase “sleepy node” is introduced, but was not defined in the terminology section.

 

3.4 – The use of the term “misappropriated” is odd, at best. Are the authors referring to unauthorized use? The term “legitimacy,” applied to participants is not helpful. Do the authors mean ‘authorized” here? The term “truthfulness” appears here, and is equally unhelpful. How about “accurate?” I’m beginning to wonder how carefully the authors read 4593!

 

4.1- the authors should use technical terminology from 4949, since they went to the trouble to cite in various places, e.g., replace “sniffing” with “passive wiretapping,” both here and throughput the document. Also, the term “traffic analysis” is much broader than what the authors suggest here. Even without access to headers per se, one can examine the size of messages and the frequency of transmission, and both of these are examples of traffic analysis.

 

4.2 – here too, addressing integrity and authentication separately might result in a clearer discussion. For example, “identity misappropriation” is really a violation of an authentication guarantee. The terms “overclaiming” and “misclaiming” are introduced here (4.4.1), without being defined earlier. There is mention of “freshness” which might have been addressed by using the 7498-2 terminology “connection-orietned integrity.”

 

4.3- “Selective forwarding,” “wormhole,” and “sinkhole” attacks are mentioned, without definition. Using a diagram to illustrate these attacks is not a substitute for concise definitions. In 4.3.4 “overload” attacks are noted, but not defined.  Also, selective forwarding isn’t a routing attack, so why is it included here?

 

5. – Use of encryption does not counter deliberate exposure attacks. Use of encryption, and authentication, is a counter to exposure of routing data via passive wiretapping.

 

5.1.2 - Passive wiretapping (“sniffing” to the authors) does not include device compromise. The discussion of what constitutes a suitable key length is not a good topic for this document. First, the authors fail to note, at the beginning of the relevant paragraph, that the key length comments are applicable to symmetric cryptographic algorithms. Second, absent a mention of the granularity of key distribution, this discussion is premature, at best.

 

5.1.3 - TA is always a passive attack, so the description here “… may be passive…” is wrong. Also,  TA is broader in scope than the authors stated earlier, and thus the proposed countermeasures are a subset of what might be considered.  The discussion here seems to diverge from the routing security focus of the document, when the authors discuss TA issues relevant to end-user traffic flows.

 

5.1.4 – Discussions of anti-tamper are rarely appropriate for IETF documents. There is no reason to believe that these authors are especially knowledgeable about such technology. I suggest this section be deleted.

 

5.2 – Again, distinguishing among integrity, authentication, and authorization might make for a clearer discussion. Adherence to the “CAI” model is causing these problems.

 

5.2.1 – the discussion  here is very superficial, not as thorough as the subsections in 5.1.

 

5.2.2 – This discussion is very superficial as well.

 

5.2.3 – “liveliness” -> “liveness” The discussion of the  use of public key technology vs. symmetric cryptographic mechanisms for authentication is vastly oversimplified, and thus not very useful. Also, the work cited here [Wander2005] is not bad, but “NanoECC: testing the limits of elliptic curve cryptography in sensor networks, 2008” is more up to date.

 

5.2.4 -  this discussion seems to overemphasize timestamps as a alternative to counters, without considering the vulnerabilities associated with transitively-relayed timestamp info.

 

5.3.1 – Unlike previous sections, the focus here seems to be protocol-specific. I’d feel more comfortable that this was not simply an ad hoc  discussion if it were posed in a more general form. On the other hand, if ROLL has already selected a specific routing paradigm, the preceding section should be specific to that model.

 

5.3.2 – “Overload attacks are a form of DoS attack in that a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy store quicker” -> “Overload attacks are a form of DoS attack in which a malicious node overloads the network with irrelevant traffic, thereby draining the nodes' energy store more quickly.” This sort of attack is not one against routing, unless the overload is the result of processing routing traffic?

 

5.3.3 – “Selective forwarding” is not a routing attack.

 

5.3.4 – “…, if geographic positions of nodes are available, then the

network can assure that data is actually routed towards the intended

destination and not elsewhere.” This is not always true, since a node might have an onward connection that provides faster or higher bandwidth service towards the destination.

 

5.3.5 – “In wormhole attacks at least two malicious nodes shortcut or divert the usual routing path by means of a low-latency out-of-band channel.” This seems to be a narrow characterization of such attacks. One might also say that two nodes that claim to have a short path between themselves are effecting such an attack. If two nodes really do have a short, low latency path between themselves then, from a routing perspective, what’s the problem?

 

6 – I find the opening sentence to be very confusing: “The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing.”

 

6.1 - “… and improve vulnerability against other more direct attacks …” -> “… and reduce vulnerabilities relative to other attacks …” What does “privacy” mean here? This is the first use of the term in this document. Also, the cite to Geopriv is not helpful, as the context for most Geopriv work does not match the ROLL environment.

 

6.2 – Did you really mean to say “ … integrity of the encrypted message …”? Generally one applies integrity mechanisms to the plaintext message, prior to encryption. The requirement to verify “message sequence” is grammatically incorrect and ambiguous. Routing protocols may not require delivery of every routing message. If the requirement here is anti-replay, say so. Also, the phrase “unintentional Byzantine” seems odd to me. It does not appear earlier, in the discussion of Byzantine threats. The common notion of a Byzantine attack is that the actors are doing so with intent. There is a very worrisome sentence in this section: In the most basic form, verification of routing peer authenticity and liveliness can be used to build a "chain of trust" along the path the routing information flows, such that network-wide information is validated through the concatenation of trust established at each individual routing peer exchange.” This sentence seems to endorse the notion of transitive trust for routing security, a bad idea.

 

6.4 – A more appropriate title would be “Cryptographic Key Management.” The endorsement of TPMs here seems inappropriately-specific. “ … a LLN is also encouraged to have automatic …” I don’t think you want to try to encourage a network, vs. a network operator. More to the point, we usually establish standards for security features for protocols, which seems to be the focus of this document. This is a directive directed to a network operator, and thus is out of place here. The reference to RFC 3029 is old, and refers to an experimental protocol. I'd suggest RFC 5055, which is much more recent, and is a proposed standard. “ … which supports several alternative private, public, or Diffie-Hellman …” Diffie-Hellman is a public-key scheme!

 

6.5 – “ … diversified needs …” -> “… diverse needs…”

 

8 – Although the text says that “ … design guidelines with a scope limited to ROLL.” there are a few instances where the discussion is not limited to routing. I wish the document used standard terms for security services, and employed these for the requirements, e.g., from ISO 7498-2. The security service terminology used in this document is often ad hoc.

 “…mechanisms to be used to deal with each threat is specified …” -> “…mechanisms to be used to deal with each threat are specified …”

 

 

--------------020504040209010307090606-- From scott@hyperthought.com Thu Jan 17 10:14:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B424521F87D4 for ; Thu, 17 Jan 2013 10:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZPF+KV11nrx for ; Thu, 17 Jan 2013 10:14:45 -0800 (PST) Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1955921F85C8 for ; Thu, 17 Jan 2013 10:14:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8D6FE20735; Thu, 17 Jan 2013 13:14:44 -0500 (EST) X-Virus-Scanned: OK Received: from legacy14.wa-web.iad1a (legacy14.wa-web.iad1a.rsapps.net [192.168.4.100]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 9521E2069D; Thu, 17 Jan 2013 13:14:42 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by legacy14.wa-web.iad1a (Postfix) with ESMTP id 70C392630001; Thu, 17 Jan 2013 13:14:42 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 17 Jan 2013 10:14:42 -0800 (PST) Date: Thu, 17 Jan 2013 10:14:42 -0800 (PST) From: "Scott G. Kelly" To: draft-ietf-avtcore-srtp-encrypted-header-ext.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1358446482.458815115@apps.rackspace.com> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-avtcore-srtp-encrypted-header-ext-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 18:14:45 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThis document describes a modification to = the SRTP protocol, wherein header fields which have previously only been pr= otected with authentication may now also be protected with (authenticated) = encryption. The document is detailed and well-written, and the document tex= t, together with the security considerations section, seems to address all = relevant concerns.=0A=0AI want to qualify my comments: I had relatively sho= rt notice for this document review, I have no prior experience with SRTP, a= nd I have been very busy with post-Holiday catch-up, so I have to apologize= for not giving this document more attention. On the other hand, there are = a number of highly respected reviewers mentioned in the acknowledgements se= ction, so I think odds are good that this document raises no serious concer= ns.=0A=0A--Scott From catherine.meadows@nrl.navy.mil Thu Jan 17 15:56:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AA021F8960; Thu, 17 Jan 2013 15:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOAVmCE-GhiR; Thu, 17 Jan 2013 15:56:21 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 29FF521F8953; Thu, 17 Jan 2013 15:56:20 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.14.4/8.13.6) with ESMTP id r0HNuIfa014643; Thu, 17 Jan 2013 18:56:19 -0500 Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id r0HNuGUm015094; Thu, 17 Jan 2013 18:56:16 -0500 (EST) Received: from ashurbanipal.fw5540.net ([10.0.3.109]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2013011718561603008 ; Thu, 17 Jan 2013 18:56:16 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_28E3162C-D08D-42E5-9E1A-AFB6959BC2EF" Date: Thu, 17 Jan 2013 18:56:16 -0500 Message-Id: <2C7CDF5F-686D-46F8-A496-AC0E89E4ABF7@nrl.navy.mil> To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-rmt-flute-sdp.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [secdir] SecDir Review of draft-ietf-rmt-flute-sdp-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 23:56:21 -0000 --Apple-Mail=_28E3162C-D08D-42E5-9E1A-AFB6959BC2EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The Session Description Protocol (SDP) provides a general-purpose format for describing multimedia sessions in announcements or = invitations. This ID defines two new protocol identifiers for the File Delivery over = Unidirectional Transport (FLUTE) protocol and other required SDP attributes for initiation of a = FLUTE session. No security considerations are introduced other than those already = pertaining to SDP or FLUTE. So I do not believe that this ID needs any further = attention from a security point of view. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil --Apple-Mail=_28E3162C-D08D-42E5-9E1A-AFB6959BC2EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Catherine Meadows
Naval = Research Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: 202-767-3490
fax: = 202-404-7942
email: catherine.meadows@nrl.navy.= mil
= --Apple-Mail=_28E3162C-D08D-42E5-9E1A-AFB6959BC2EF-- From mcr@sandelman.ca Fri Jan 18 10:18:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E70E21F84C9 for ; Fri, 18 Jan 2013 10:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh0-PN6Q+qYr for ; Fri, 18 Jan 2013 10:17:58 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9C921F84C8 for ; Fri, 18 Jan 2013 10:17:57 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B9C352016D; Fri, 18 Jan 2013 13:22:46 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 531B9FE86; Fri, 18 Jan 2013 13:17:04 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 417D91FD94; Fri, 18 Jan 2013 13:17:04 -0500 (EST) From: Michael Richardson To: Stephen Kent In-Reply-To: <50F8301A.2060508@bbn.com> References: <50F8301A.2060508@bbn.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Sat, 19 Jan 2013 08:02:02 -0800 Cc: angel.lozano@upf.edu, vanesa.daza@upf.edu, secdir , jpv@cisco.com, roger.alexander@cooperindustries.com, mischa.dohler@cttc.es, adrian@olddog.co.uk, tzeta.tsao@cooperindustries.com Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 18:18:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I'd like this email thread on the mailing list. Is that okay? If so, I will forward your email, or you can repost, and I'll repost my rep= ly. Unless I say otherwise, I agree with pretty much everything you write, and I am extremely thankful for your review. >>>>> "Stephen" =3D=3D Stephen Kent writes: Stephen> 4949 the security glossary). These were good Stephen> omens. Unfortunately, there are=20 Stephen> a number of problems with the text, as noted below. Given Stephen> that this is a 00=20 Stephen> doc, I'm guessing that the ROLL WG has not been so Stephen> interested as to provide=20 Stephen> feedback. Pity. This is a rename and truncation of=20 http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ Stephen> 3.3 -- The phrase "sleepy node" is introduced, but was not Stephen> defined in the=20 Stephen> terminology section. I see that http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/?include_text= =3D1 also does not include sleepy node, and I think that it should, and be referenced.=20 Stephen> 4.1- the authors should use technical terminology from Stephen> 4949, since they went=20 Stephen> to the trouble to cite in various places, e.g., replace Stephen> "sniffing" with=20 Stephen> "passive wiretapping," both here and throughput the Stephen> document. Also, the term=20 Stephen> "traffic analysis" is much broader than what the authors Stephen> suggest here. Even=20 okay, than's a very good suggestion that will bring this document much better in line with other IETF work. Stephen> 4.3- "Selective forwarding," "wormhole," and "sinkhole" Stephen> attacks are=20 Stephen> mentioned, without definition. Using a diagram to Stephen> illustrate these attacks is=20 Stephen> not a substitute for concise definitions. In 4.3.4 Stephen> "overload" attacks are=20 Stephen> noted, but not defined. Also, selective forwarding isn't a Stephen> routing attack, so=20 Stephen> why is it included here? I'd like these terms added to the terminology document too. Stephen> 5.1.4 -- Discussions of anti-tamper are rarely appropriate Stephen> for IETF=20 Stephen> documents. There is no reason to believe that these authors Stephen> are especially=20 Stephen> knowledgeable about such technology. I suggest this section Stephen> be deleted.=20 We have some other work that proposes future protocol changes to deal with the case where nodes are compromised, and relies a bit, on the amount of time required for the adversary overcome anti-tampering. So, I would like some discussion to remain. Stephen> 5.3.1 -- Unlike previous sections, the focus here seems to be Stephen> protocol-specific. I'd feel more comfortable that this was Stephen> not simply an ad=20 Stephen> hocdiscussion if it were posed in a more general form. On Stephen> the other hand, if=20 Stephen> ROLL has already selected a specific routing paradigm, the Stephen> preceding section=20 Stephen> should be specific to that model. Yes, ROLL already has a specific routing paradigm (RFC6550), I think that this document simply did not evolve with enough with the discussion. Stephen> 5.3.2 -- "Overload attacks are a form of DoS attack in that Stephen> a malicious node overloads the network with irrelevant Stephen> traffic, thereby draining the nodes' energy store quicker" Stephen> -> "Overload attacks are a form of DoS attack in which=20 Stephen> a malicious node overloads the network with irrelevant Stephen> traffic, thereby draining the nodes' energy store _more Stephen> quickly_." This sort of attack is not=20 Stephen> one against routing, unless the overload is the result of Stephen> processing routing traffic? The attack is against the routing system. The result is not an invalid route (the traffic gets through), but rather one that drains the energy on a node which otherwise did not need to be involved.=20=20 It's not clear, btw, that we have any defense against such an attack, as it needs to be done by an insider, but the point of the document is to detail this attack. Stephen> 5.3.5 -- "In wormhole attacks at least two malicious nodes Stephen> shortcut or divert the usual routing path by means of a Stephen> low-latency out-of-band channel." This seems to be a narrow Stephen> characterization of such attacks. One might also say=20 Stephen> that two nodes that _claim_ to have a short path between Stephen> themselves are effecting such an attack. If two nodes Stephen> really do have a short, low latency path between themselves Stephen> then, from a routing perspective, what's the problem?=20 That's a legimate question. It's not clear that there even *is* a problem. The problem is who created such a thing, and what other things (such as selective forwarding) might then occur as a result of this shorter path? For instance, an appropriate pair of antenna connected together by coax could "route around" a closed door or wall. Whether this is a desired part of the network is another question.... Stephen> 6 -- I find the opening sentence to be very confusing: "The Stephen> assessments and=20 Stephen> analysis in Section 4 examined all areas of threats and Stephen> attacks that could=20 Stephen> impact routing, and the countermeasures presented in Stephen> Section 5 were reached=20 Stephen> without confining the consideration to means only available Stephen> to routing."=20 I think that with section 7 gone, this should be removed. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUPmRoIqHRg3pndX9AQLObAQA2R1Fn5zjzlPaMkb2Si4qy/vGkaqVY+3g A4X6cfjh7Sh/9bgkJEc7rv2NDXzYAWJohOqjc8KWLwaLs/ugZ4rz7YnGzwwdOog2 mcFsTzkyYkFdZyTTg8KZKkcbSx+45GBr59J6WKkQP7M+qvZYy3uR12VZGPGHtmcS ba8cHQU9WmE= =vAAF -----END PGP SIGNATURE----- --=-=-=-- From clonvick@cisco.com Sat Jan 19 17:41:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B4C21F8460; Sat, 19 Jan 2013 17:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15gb4y9n+Q2C; Sat, 19 Jan 2013 17:41:21 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2621F8D35; Sat, 19 Jan 2013 17:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22595; q=dns/txt; s=iport; t=1358646071; x=1359855671; h=date:from:to:subject:message-id:mime-version; bh=9rWgd94os6s+rO21unUuIc0gueKlCE8KPJmyESVkE+0=; b=VDVHPyK81HhQdBZ5+53705IDSjASjtRp+JUoRyISvh/0QZBBZA/sEuJd xCeQBul5baXyYXNgwziE9MDKbe6DSihWvKlUFHXaUvis+0iHaGd9t1NQU Cgt16Zny/px49WoF9r6eHyDUjNGufX8FhkA/w5dqyARg3mJwVUzAtw6pJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPhI+1CrRDoJ/2dsb2JhbAA6AQm+PhZzgj8eAi0FCkN/CQcdh327PI0HAQOELgOIYYl4k3yDFh6BJwIeBg X-IronPort-AV: E=Sophos;i="4.84,500,1355097600"; d="scan'208";a="66147225" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 20 Jan 2013 01:33:59 +0000 Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0K1Xxpc026734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Jan 2013 01:33:59 GMT Date: Sat, 19 Jan 2013 17:33:59 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rmt-fcast.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [secdir] secdir review of draft-ietf-rmt-fcast-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 01:41:35 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I believe that security was addressed fairly well in the document. I do have some problems with the text in the Security Considerations section. It would help if the authors would review RFC 4949, "The Internet Security Glossary, v2", and consistently apply the terms throughout the paper. Along that line, I'm suggesting some corrections for the Security Considerations section, below. Some are editorial just to make some statements more clear. I would also recommend that the Working Group perform a quick threat analysis and use that as the basis for addressing the potential weaknesses. This can be done by referencing BCP72 and creating a list of threats that the WG consider to be significant and describing the mechanisms that would appropriately address them. The WG may wish to look at Section 2 of RFC 5425 as an example. Also, the subsection titles in 4.2 and 4.3 could be straightened out. Right now you have: 4.2 Attacks Against blahblah 4.2.1 Abc 4.2.2 Bcd ... 4.3 Attacks Against otherblahblah 4.3.1 Attacks Against Klm 4.3.2 Attacks Against Lmn ... My comments are preceded by "CML%" and my suggested text is preceded by "CML>". ===vvv=== 4. Security Considerations 4.1. Problem Statement A content delivery system is potentially subject to attacks. Attacks may target: CML> A content deliver system may be subject to attacks that may target the following: o the network (to compromise the routing infrastructure, e.g., by creating congestion), CML> the network; to compromise the delivery infrastructure (e.g., by CML> creating congestion), o the Content Delivery Protocol (CDP) (e.g., to compromise the normal behavior of FCAST), or CML> the Content Delivery Protocol (CDP); to compromise the delivery CML> mechanism (i.e., FCAST in this case), o the content itself (e.g., to corrupt the objects being transmitted). CML> the content itself; to corrupt the objects being transmitted. These attacks can be launched either: CML> These attacks can be launched against all or any subset of the CML> following: o against the data flow itself (e.g., by sending forged packets), o against the session control parameters (e.g., by corrupting the session description, the CID, the object meta-data, or the ALC/LCT control parameters), that are sent either in-band or out-of-band, or o against some associated building blocks (e.g., the congestion control component). In the following sections we provide more details on these possible attacks and sketch some possible counter-measures. We finally provide recommendations in Section 4.5. CML> More details on these potential attacks are provided in the following CML> sections along with possible counter-measures. Recommendations are CML> made in Section 4.5. 4.2. Attacks Against the Data Flow Let us consider attacks against the data flow first. At least, the following types of attacks exist: CML> The following types of attacks exist against the data flow: o attacks that are meant to give access to a confidential object (e.g., in case of a non-free content) and CML> attacks that are meant to gain unauthorized access to a confidential CML> object (e.g., obtaining non-free content without purchasing it) and o attacks that try to corrupt the object being transmitted (e.g., to inject malicious code within an object, or to prevent a receiver from using an object, which is a kind of Denial of Service (DoS)). 4.2.1. Access to Confidential Objects Access control to the object being transmitted is typically provided by means of encryption. This encryption can be done over the whole object (e.g., by the content provider, before submitting the object to FCAST), or be done on a packet per packet basis (e.g., when IPsec/ ESP is used [RFC4303], see Section 4.5). If confidentiality is a concern, it is RECOMMENDED that one of these solutions be used. CML% When you say "typically provided" you're indicating that some other CML% solution has been used in the past. I don't see that prior mechanism CML% has been referenced. On the other hand, if you're indicating that CML% some general solution has been applied, and is applicable in this CML% solution then I'll recommend the following replacement paragraph. CML> CML> Modern cryptographic mechanisms can provide access controls to CML> transmitted objects. One way to do this is by encrypting the CML> entire object prior to transmission knowing that authenticated CML> receivers have the cryptographic mechanisms to decrypt the CML> content. Another mechanism that has been employed is to encrypt CML> individual packets using IPsec/ESP [RFC4303] (Section 4.5). If CML> access control is desired, one of these mechanisms is RECOMMENDED CML> and should be deployed. CML> CML% In the last sentence, you're suddenly bringing in confidentiality. CML% That should be described in a separate paragraph. Perhaps like CML% the following paragraph. CML> CML> Modern cryptographic services can also provide confidentiality of the CML> object being transferred to prevent the content from being reassembled CML> by an unauthorized observer. See section 4.5 if that is desired. 4.2.2. Object Corruption Protection against corruptions (e.g., if an attacker sends forged packets) is achieved by means of a content integrity verification/ sender authentication scheme. This service can be provided at the object level, but in that case a receiver has no way to identify which symbol(s) is(are) corrupted if the object is detected as corrupted. This service can also be provided at the packet level. In this case, after removing all corrupted packets, the file may be in some cases recovered. Several techniques can provide this content integrity/sender authentication service: CML% An attacker injecting forged packets is not corruption. From the CML% list below, I believe that you want to say something more like the CML% following. CML> CML> 4.2.2 Object Data Integrity CML> CML> Protection against attacks on the data integrity of the object may CML> be achieved by a mechanism agreed upon between the sender and CML> receiver that features sender authentication and a method to CML> verify that the integrity of the object has remained intact during CML> transmission. This service can be provided at the CML> object level, but in that case a receiver has no way to identify CML> which symbol(s) is(are) corrupted if the object is detected as CML> corrupted. This service can also be provided at the packet level. CML> In some cases, after removing all corrupted packets, the file may be CML> recovered. Several techniques can provide a data integrity service as CML> well as a service that provides sender authentication. o at the object level, the object can be digitally signed, for instance by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a receiver to check the object integrity, once this latter CML% I'd suggest removing ", once this latter has been fully decoded." CML% It's not needed. has been fully decoded. Even if digital signatures are computationally expensive, this calculation occurs only once per object, which is usually acceptable; o at the packet level, each packet can be digitally signed [RFC6584]. A major limitation is the high computational and transmission overheads that this solution requires. To avoid this problem, the signature may span a set of packets (instead of a single one) in order to amortize the signature calculation. But if a single packets is missing, the integrity of the whole set cannot be checked; CML% I'm not real familiar with RFC6584 so I just glanced through it. CML% It appears that each mechanism described in that document requires CML% a signature per packet. I may be wrong but I'll ask that you CML% review that to ensure that your recommendation of providing a CML% signature across a group of packets is correct. o at the packet level, a Group Message Authentication Code (MAC) [RFC2104][RFC6584] scheme can be used, for instance by using HMAC- SHA-256 with a secret key shared by all the group members, senders and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet. The Group MAC scheme does not create prohibitive processing load nor transmission overhead, but it has a major limitation: it only provides a group authentication/integrity service since all group members share the same secret group key, which means that each member can send a forged packet. It is therefore restricted to situations where group members are fully trusted (or in association with another technique as a pre-check); CML% I don't understand that last parenthetical. What is the meaning of: CML% "(or in association with another technique as a pre-check)"? o at the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082][RFC5776] is an attractive solution that is robust to losses, provides a true authentication/ integrity service, and does not create any prohibitive processing load or transmission overhead. Yet checking a packet requires a small delay (a second or more) after its reception; CML% I don't like the use of the slash between authentication and CML% integrity. ...but that may just be me. I'd suggest properly CML% expanding that. I also wouldn't use "true" to describe an CML% authentication service. Again, however, that's probably just me. CML% Also, I would suggest that you not attempt to say how long it takes CML% to perform a validation. Perhaps reword that last sentence to be: CML> CML> Yet, a delay is incurred in checking a TESLA authenticated packet CML> which may be more than what is desired in some deployments. o at the packet level, IPsec/ESP [RFC4303] can be used to check the integrity and authenticate the sender of all the packets being exchanged in a session (see Section 4.5). Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved by a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by pre-distributing securely the public keys of each group member. CML% I'd suggest rewording that last phrase for clarity: CML> ,or by securely pre-distributing the public keys... Techniques relying on symmetric key cryptography (Group MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol, or simply by pre-distributing securely the secret key (but this manual solution has many limitations). CML% Again, I'd suggest rewording: CML> , or simply by securely pre-distributing the secret... It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. In any case, whenever there is any concern of the threat of file corruption, it is RECOMMENDED that at least one of these techniques be used. CML% Should that be "object corruption" rather than "file corruption"? 4.3. Attacks Against the Session Control Parameters and Associated Building Blocks Let us now consider attacks against the session control parameters and the associated building blocks. The attacker has at least the following opportunities to launch an attack: o the attack can target the session description, o the attack can target the FCAST CID, o the attack can target the meta-data of an object, o the attack can target the ALC/LCT parameters, carried within the LCT header or o the attack can target the FCAST associated building blocks, for instance the multiple rate congestion control protocol. The consequences of these attacks are potentially serious, since they can compromise the behavior of content delivery system or even compromise the network itself. CML> ...compromise the behavior of the content... 4.3.1. Attacks Against the Session Description An FCAST receiver may potentially obtain an incorrect Session Description for the session. The consequence of this is that legitimate receivers with the wrong Session Description are unable to CML> ...wrong Session Descriptors will be unable to... correctly receive the session content, or that receivers CML> ...receivers will inadvertently... inadvertently try to receive at a much higher rate than they are capable of, thereby possibly disrupting other traffic in the network. CML% Just suggestions to keep the same verb tenses. :-) To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect Session Descriptions. One such measure is the sender authentication to ensure that receivers CML> ...such measure is sender authentication... only accept legitimate Session Descriptions from authorized senders. How these measures are achieved is outside the scope of this document since this session description is usually carried out-of-band. 4.3.2. Attacks Against the FCAST CID Corrupting the FCAST CID is one way to create a Denial of Service attack. For example, the attacker can insert an "FCAST-CID-Complete" meta-data entry to make the receivers believe that no further modification will be done. It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the CID. To that purpose, one of the counter-measures mentioned above (Section 4.2.2) SHOULD be used. These measures will either be applied on a packet level, or globally over the whole CID object. When there is no packet level integrity verification scheme, it is RECOMMENDED to digitally sign the CID. 4.3.3. Attacks Against the Object Meta-Data Corrupting the object meta-data is another way to create a Denial of Service attack. For example, the attacker changes the MD5 sum associated to a file. This possibly leads a receiver to reject the files received, no matter whether the files have been correctly received or not. When the meta-data are appended to the object, corrupting the meta-data means that the Compound Object will be corrupted. CML% Welllll.... If the MD5 is changed in transit, then that's a Man in CML% the Middle (MIIM) attack and the result is a loss of service since CML% there is a recovery mechanism. A DOS would be more like what's CML% described in the Security Considerations section of RFC 5740, CML% excessive NACKing, or via replay attacks. It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the Compound Object. To that purpose, one of the counter-measures mentioned above (Section 4.2.2) SHOULD be used. These measures will either be applied on a packet level, or globally over the whole Compound Object. When there is no packet level integrity verification scheme, it is RECOMMENDED to digitally sign the Compound Object. CML% Actually, I'd write it up something like the following. CML> CML> As noted in RFC 2616, a message integrity check (MIC) is not CML> sufficient proof against malicious attacks. The content-MD5 MIC can CML> indicate to a receiver that the meta-data has been inadvertently CML> modified in transit, CML> but a clever attacker would provide a correct MIC to cover any CML> malicious changes made in an attack. It is therefore RECOMMENDED CML> that measures be taken to guarantee the CML> integrity and to check the sender's identity of the Compound Object. CML> To that purpose, one of the counter-measures mentioned above CML> (Section 4.2.2) SHOULD be used. These measures will either be CML> applied on a packet level, or globally over the whole Compound CML> Object. When there is no packet level integrity verification scheme, CML> it is RECOMMENDED to digitally sign the Compound Object. 4.3.4. Attacks Against the ALC/LCT and NORM Parameters By corrupting the ALC/LCT header (or header extensions) one can execute attacks on the underlying ALC/LCT implementation. For example, sending forged ALC packets with the Close Session flag (A) set to one can lead the receiver to prematurely close the session. Similarly, sending forged ALC packets with the Close Object flag (B) set to one can lead the receiver to prematurely give up the reception of an object. The same comments can be made for NORM. It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of each ALC or NORM packet received. To that purpose, one of the counter-measures mentioned above (Section 4.2.2) SHOULD be used. 4.3.5. Attacks Against the Associated Building Blocks Let us first focus on the congestion control building block that may be used in an ALC or NORM session. A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect the health of the network in the path between the sender and the receiver. That may also affect the reception rates of other receivers who joined the session. When congestion control is applied with FCAST, it is therefore RECOMMENDED that receivers be required to identify themselves as legitimate before they receive the Session Description needed to join the session. If authenticating a receiver does not prevent this latter to launch an attack, it will enable the network operator to identify him and to take counter-measures. This authentication can be made either toward the network operator or the session sender (or a representative of the sender) in case of NORM. The details of how it is done are outside the scope of this document. CML% I don't understand that paragraph. Can you rephrase it? When congestion control is applied with FCAST, it is also RECOMMENDED that a packet level authentication scheme be used, as explained in Section 4.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid reaction. It is therefore RECOMMENDED [RFC5775] that a receiver using TESLA quickly reduces its subscription level when the receiver believes that a congestion did occur, even if the packet has not yet been authenticated. Therefore TESLA will not prevent DoS attacks where an attacker makes the receiver believe that a congestion occurred. This is an issue for the receiver, but this will not compromise the network. Other authentication methods that do not feature this delayed authentication could be preferred, or a group MAC scheme could be used in parallel to TESLA to prevent attacks launched from outside of the group. 4.4. Other Security Considerations Lastly, we note that the security considerations that apply to, and are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740] and FEC [RFC5052] also apply to FCAST as FCAST builds on those specifications. In addition, any security considerations that apply to any congestion control building block used in conjunction with FCAST also applies to FCAST. Finally, the security discussion of [I-D.ietf-rmt-sec-discussion] also applies here. CML% If you have this here, then you do not need sections 4.3.4 and CML% 4.3.5, unless you are making different recommendations. Is that CML% the case? If so, then you'll need to explain the differences. 4.5. Minimum Security Recommendations We now introduce a mandatory to implement but not necessarily to use security configuration, in the sense of [RFC3365]. Since FCAST/ALC relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [RFC5775]. Similarly, since FCAST/NORM relies on NORM, it inherits the "baseline secure NORM operation" of [RFC5740]. More precisely, in both cases security is achieved by means of IPsec/ESP in transport mode. [RFC4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti- replay and (limited) traffic flow confidentiality. [RFC5775] specifies that the data origin authentication, content integrity and anti-replay services SHALL be used, and that the confidentiality service is RECOMMENDED. If a short lived session MAY rely on manual keying, it is also RECOMMENDED that an automated key management scheme be used, especially in case of long lived sessions. CML% In my very humble opinion, you should start the Security Considerations CML% section with this paragraph. That will establish a baseline for CML% development of FCAST. The next several parts of the section should CML% then look at specific concerns for FCAST. Therefore, the RECOMMENDED solution for FCAST provides per-packet security, with data origin authentication, integrity verification and anti-replay. This is sufficient to prevent most of the in-band attacks listed above. If confidentiality is required, a per-packet encryption SHOULD also be used. ===^^^=== Regards, Chris From magnusn@gmail.com Sun Jan 20 20:06:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D9721F87CC; Sun, 20 Jan 2013 20:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnxKNDThKl1M; Sun, 20 Jan 2013 20:06:04 -0800 (PST) Received: from mail-we0-x234.google.com (we-in-x0234.1e100.net [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 75E3821F87C8; Sun, 20 Jan 2013 20:05:46 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t57so1482850wey.11 for ; Sun, 20 Jan 2013 20:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=PLAc6NhnUJwZx+BxxlluvsfUzkobuLah0503yl8xIYo=; b=RcGJwVnTM4/y2aTmfNibwf5Sy76xqedslNxd4si1f57HksFjNY1zNDfDZMDWqHP9MF AANaD7B43bMFOrX0ThFcajAd4nxW4H6IfDmvUP6bcTMndEVdkVke5rfJvTbJ2IVvaMQB yp1v4lZ64VSQMlPDrJTlw81ban+A8NbpRoplQRig4o0pw3NE5B8VpJXW7tyOBQT41sR0 9Kp3WVqE4rmmnnduxjSeQEMFLNs7NCUlCrWzXGyMEvB85XfMjwQnIoskQo/g+kEWocz2 hUE5Vg9ljsMlgjIkYm5Sui6voPXRCpbXD5ws/U5XR2IWFYTabwe8YpNRQfNdhaZrYb2C dxdA== MIME-Version: 1.0 X-Received: by 10.180.107.130 with SMTP id hc2mr13043462wib.12.1358741145581; Sun, 20 Jan 2013 20:05:45 -0800 (PST) Received: by 10.180.144.77 with HTTP; Sun, 20 Jan 2013 20:05:45 -0800 (PST) Date: Sun, 20 Jan 2013 20:05:45 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-eman-requirements@tools.ietf.org Content-Type: multipart/alternative; boundary=e89a8f3baa6f52f6a304d3c49326 Subject: [secdir] Secdir review of draft-ietf-eman-requirements-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 04:06:05 -0000 --e89a8f3baa6f52f6a304d3c49326 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards-track document describes requirements on standards for managing power entities over networks. As stated in the Security Considerations section, controlling power state and power supply of networked energy entities are highly sensitive actions and thus authorization, privacy etc. may be required. Similarly, the date provided by those entities will often require integrity and sometimes authenticity. The document may gain by also making clear the potential need for the energy entities to identify, authenticate and authorize the entities requesting access to power data. I would suggest to add some text around this - because I assume some requirements on standards will be present for that. --e89a8f3baa6f52f6a304d3c49326 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have reviewed this documen= t as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This standards-track document describes requirements on standards for manag= ing power entities over networks.

=A0As stated in the Security Cons= iderations section, controlling power state and power supply of networked e= nergy entities are highly sensitive actions and thus authorization, privacy= etc. may be required. Similarly, the date provided by those entities=A0wil= l often require integrity and sometimes authenticity.=A0The document may ga= in by also making clear the potential need=A0for the energy entities to ide= ntify, authenticate and authorize the entities requesting access to power d= ata. I would suggest to add some text around this - because I assume some r= equirements on standards will be present for=A0that.=A0
--e89a8f3baa6f52f6a304d3c49326-- From new-work-bounces@ietf.org Mon Jan 21 07:00:09 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763921F8712; Mon, 21 Jan 2013 07:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1358780409; bh=Cv3NLeK+2ohpqs3aFQAZ8PPMLJ+Ixcjs3sIpzwe1DqI=; h=Date:To:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=iGPpuLsSBXSQqOY9IDx71g5HUAJvFtu9HpiuckCP55PWSJNKqYpcxDmtKZ29/mKVz hH4DM2lWr+5aSYa1kBWtXMZCh6cGs/o6y0/Y91+CnR2hxXxMFCwnMxWfmhFg2L+v0X ZdJiDackbE2b6rgcRQ+YVKrqIRm295LqkomS3Gv8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F3221F8712 for ; Mon, 21 Jan 2013 07:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUBVdQHc6Ngq for ; Mon, 21 Jan 2013 07:00:08 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 133D721F842E for ; Mon, 21 Jan 2013 07:00:07 -0800 (PST) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.69) (envelope-from ) id 1TxIr0-0005RH-PV for new-work@ietf.org; Mon, 21 Jan 2013 10:00:07 -0500 Date: Mon, 21 Jan 2013 16:00:06 +0100 To: new-work@ietf.org MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.12 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 21 Jan 2013 07:02:14 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Speech Working Group (until 2013-02-28) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:00:09 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Voice Browser Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Speech Working Group: https://www.w3.org/2012/12/speech-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2013-02-28 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kazuyuki Ashimura, Voice Browser Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] https://www.w3.org/2013/01/speech-activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kent@bbn.com Mon Jan 21 07:47:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CE621F873B for ; Mon, 21 Jan 2013 07:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlGuWF0VK5Ed for ; Mon, 21 Jan 2013 07:47:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6293821F8569 for ; Mon, 21 Jan 2013 07:47:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34467 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TxJb6-000C1o-J2; Mon, 21 Jan 2013 10:47:44 -0500 Message-ID: <50FD631F.5050304@bbn.com> Date: Mon, 21 Jan 2013 10:47:43 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Michael Richardson References: <50F8301A.2060508@bbn.com> <20711.1358533024@sandelman.ca> In-Reply-To: <20711.1358533024@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: angel.lozano@upf.edu, vanesa.daza@upf.edu, secdir , jpv@cisco.com, roger.alexander@cooperindustries.com, mischa.dohler@cttc.es, adrian@olddog.co.uk, tzeta.tsao@cooperindustries.com Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:47:55 -0000 Michael, > I'd like this email thread on the mailing list. Is that okay? > If so, I will forward your email, or you can repost, and I'll repost my reply. yes. > Unless I say otherwise, I agree with pretty much everything you write, > and I am extremely thankful for your review. > >>>>>> "Stephen" == Stephen Kent writes: > Stephen> 4949 the security glossary). These were good > Stephen> omens. Unfortunately, there are > Stephen> a number of problems with the text, as noted below. Given > Stephen> that this is a 00 > Stephen> doc, I'm guessing that the ROLL WG has not been so > Stephen> interested as to provide > Stephen> feedback. Pity. > > This is a rename and truncation of > http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ OK. Glad the doc because shorter in the process. > Stephen> 3.3 -- The phrase "sleepy node" is introduced, but was not > Stephen> defined in the > Stephen> terminology section. > > I see that > http://datatracker.ietf.org/doc/draft-ietf-roll-terminology/?include_text=1 > > also does not include sleepy node, and I think that it should, and be > referenced. OK. > Stephen> 4.1- the authors should use technical terminology from > Stephen> 4949, since they went > Stephen> to the trouble to cite in various places, e.g., replace > Stephen> "sniffing" with > Stephen> "passive wiretapping," both here and throughput the > Stephen> document. Also, the term > Stephen> "traffic analysis" is much broader than what the authors > Stephen> suggest here. Even > > okay, than's a very good suggestion that will bring this document much > better in line with other IETF work Thanks., > Stephen> 4.3- "Selective forwarding," "wormhole," and "sinkhole" > Stephen> attacks are > Stephen> mentioned, without definition. Using a diagram to > Stephen> illustrate these attacks is > Stephen> not a substitute for concise definitions. In 4.3.4 > Stephen> "overload" attacks are > Stephen> noted, but not defined. Also, selective forwarding isn't a > Stephen> routing attack, so > Stephen> why is it included here? > > I'd like these terms added to the terminology document too. Good. > Stephen> 5.1.4 -- Discussions of anti-tamper are rarely appropriate > Stephen> for IETF > Stephen> documents. There is no reason to believe that these authors > Stephen> are especially > Stephen> knowledgeable about such technology. I suggest this section > Stephen> be deleted. > > We have some other work that proposes future protocol changes to deal > with the case where nodes are compromised, and relies a bit, on the amount > of time required for the adversary overcome anti-tampering. So, I > would like some discussion to remain. OK. But, this is where the approach adopted here (and in almost all other IETF "threat" analysis docs falls short. This doc uses the term "threat" in a way that has become common, and is consistent with the glossary. But, historically, a threat has been defined as a "motivated, capable, adversary." When I wrote the threat analysis doc for BGP security for SIDR (draft-ietf-sidr-bgpsec-threats-04) I used the latter definition. That allows one to examine different adversaries with different capabilities and motivations. You'll need this if you elect to discuss who can and cannot extract a key from a TPM, for example. > Stephen> 5.3.1 -- Unlike previous sections, the focus here seems to be > Stephen> protocol-specific. I'd feel more comfortable that this was > Stephen> not simply an ad > Stephen> hocdiscussion if it were posed in a more general form. On > Stephen> the other hand, if > Stephen> ROLL has already selected a specific routing paradigm, the > Stephen> preceding section > Stephen> should be specific to that model. > > Yes, ROLL already has a specific routing paradigm (RFC6550), I think > that this document simply did not evolve with enough with the discussion. I'd suggest referring to that doc in this doc. > Stephen> 5.3.2 -- "Overload attacks are a form of DoS attack in that > Stephen> a malicious node overloads the network with irrelevant > Stephen> traffic, thereby draining the nodes' energy store quicker" > Stephen> -> "Overload attacks are a form of DoS attack in which > Stephen> a malicious node overloads the network with irrelevant > Stephen> traffic, thereby draining the nodes' energy store _more > Stephen> quickly_." This sort of attack is not > Stephen> one against routing, unless the overload is the result of > Stephen> processing routing traffic? > > The attack is against the routing system. The result is not an invalid > route (the traffic gets through), but rather one that drains the energy > on a node which otherwise did not need to be involved. I should have said that the attack is not against the routing protocol. > It's not clear, btw, that we have any defense against such an attack, as > it needs to be done by an insider, but the point of the document is to > detail this attack. OK. > Stephen> 5.3.5 -- "In wormhole attacks at least two malicious nodes > Stephen> shortcut or divert the usual routing path by means of a > Stephen> low-latency out-of-band channel." This seems to be a narrow > Stephen> characterization of such attacks. One might also say > Stephen> that two nodes that _claim_ to have a short path between > Stephen> themselves are effecting such an attack. If two nodes > Stephen> really do have a short, low latency path between themselves > Stephen> then, from a routing perspective, what's the problem? > > That's a legimate question. It's not clear that there even *is* a problem. > The problem is who created such a thing, and what other things (such as > selective forwarding) might then occur as a result of this shorter path? This may be a good example of my comment re "correct operation" as a better basis for a routing security criterion. If the operation mode for routing in these nets is that a tunnel between two nodes is not be advertised as a path between, them, then this is an attack. > For instance, an appropriate pair of antenna connected together by coax > could "route around" a closed door or wall. Whether this is a desired > part of the network is another question.... > > Stephen> 6 -- I find the opening sentence to be very confusing: "The > Stephen> assessments and > Stephen> analysis in Section 4 examined all areas of threats and > Stephen> attacks that could > Stephen> impact routing, and the countermeasures presented in > Stephen> Section 5 were reached > Stephen> without confining the consideration to means only available > Stephen> to routing." > > I think that with section 7 gone, this should be removed. OK. Steve From vincent.roca@inria.fr Tue Jan 22 23:59:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935B21F8942; Tue, 22 Jan 2013 23:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF9vycJMQAls; Tue, 22 Jan 2013 23:59:32 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2EB21F86F4; Tue, 22 Jan 2013 23:59:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,520,1355094000"; d="scan'208";a="191216223" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.102]) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 Jan 2013 08:59:30 +0100 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Jan 2013 08:59:29 +0100 Message-Id: <939DADEE-28DB-4A4B-AD0D-057AEB863250@inria.fr> To: IESG IESG , draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [secdir] Secdir review of draft-ietf-dime-erp-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 07:59:33 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- Since the security section has not really been updated since version 14, = the comments I made at that time are still valid. Basically: The security section of this document only refers to the security = section of 4 related documents. This is all the more annoying as draft-ietf-dime-erp introduces new = mechanisms (and potentially new threats and issues). What should I understand? Is the proposal = guaranteed to be secure, have all the potential weaknesses been already addressed in the 4 related = documents? I can not conclude after reading the security section. One more point. In introduction, the authors say: " Security considerations for this key distribution are detailed in = Salowey, et al. [RFC5295]." This reference is not mentioned in the Security Section! Cheers, Vincent= From ynir@checkpoint.com Wed Jan 23 00:02:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402B721F8945; Wed, 23 Jan 2013 00:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9IvfPR1tHuB; Wed, 23 Jan 2013 00:02:01 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 326D721F8942; Wed, 23 Jan 2013 00:02:00 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r0N81sR7028289; Wed, 23 Jan 2013 10:01:54 +0200 X-CheckPoint: {50FF960A-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Wed, 23 Jan 2013 10:01:54 +0200 From: Yoav Nir To: "secdir@ietf.org" , "iesg@ietf.org IESG" , "draft-ietf-bmwg-sip-bench-term.all@tools.ietf.org" Thread-Topic: SecDir Review of draft-ietf-bmwg-sip-bench-term-08 Thread-Index: AQHN+T/n2XmTl+Xf+0+ZDKEX2UwCQA== Date: Wed, 23 Jan 2013 08:01:53 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211198D6A5@IL-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] Content-Type: text/plain; charset="us-ascii" Content-ID: <30B55300D4BCDE4694820BAF62E73EC0@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir Review of draft-ietf-bmwg-sip-bench-term-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:02:02 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like any= other last call comments. Summary: I think it is ready for publication. This informational document describes terminology for benchmarking of the S= IP protocol. As the document mentions in the Security Considerations section, benchmarki= ng activity does not affect the security of the Internet or of corporate ne= tworks, because it is carried on in closed environments. I think it should = be explicitly said that such activity should not be done on corporate netwo= rks for fear of causing DoS to other components, but this is an appropriate= comment for the companion methodology document, not for this one.=20 In fact, a terminology document should not affect security, as it is not so= mething that is "implemented" or "deployed". Having said that, I found some= definitions in section 1, and in section 3, and models for benchmarking in= section 2.2. All these seem appropriate. I was surprised to find a lot of = MUSTs and SHOULDs in section 2.1 ("Scope"). Most of them could be re-writte= n as definitions. For example: OLD: o The DUT MAY include an internal SIP Application Level Gateway (ALG), firewall, and/or a Network Address Translator (NAT). This is referred to as the "SIP Aware Stateful Firewall." NEW: o A DUT that includes an internal SIP Application Level Gateway (ALG), firewall, and/or a Network Address Translator (NAT) is referred to as the "SIP Aware Stateful Firewall." But that is a stylistic issue that I don't feel strongly about. OTOH consid= er this example: o The DUT or SUT MUST NOT be end user equipment, such as personal digital assistant, a computer-based client, or a user terminal. This is a real requirement, so why MUST benchmarking not be done on a perso= nal computer? The document doesn't say, and I think this should be part of = the methodology document, not terminology. I also noticed that this document makes extensive use of diagrams. For the = most part, those are acceptable usage of 72-column ASCII art, although I th= ink this document is a great example of why we need better diagramming form= ats in the future RFC format. This is especially evident in figure 12 on p= age 17. Yoav From bclaise@cisco.com Wed Jan 23 00:20:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A1C21F85DC; Wed, 23 Jan 2013 00:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6EWhfwVf5bb; Wed, 23 Jan 2013 00:20:20 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4EC21F8816; Wed, 23 Jan 2013 00:20:19 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0N8KHPk013333; Wed, 23 Jan 2013 09:20:17 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r0N8JelC013744; Wed, 23 Jan 2013 09:20:01 +0100 (CET) Message-ID: <50FF9D1C.9070501@cisco.com> Date: Wed, 23 Jan 2013 09:19:40 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Vincent Roca References: <939DADEE-28DB-4A4B-AD0D-057AEB863250@inria.fr> In-Reply-To: <939DADEE-28DB-4A4B-AD0D-057AEB863250@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG IESG , draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dime-erp-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 08:20:22 -0000 Dear draft-ietf-dime-erp authors, Please address the concerns below. Regards, Benoit > Hello, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > -- > > Since the security section has not really been updated since version 14, the comments I made at > that time are still valid. Basically: > > The security section of this document only refers to the security section of 4 related documents. > This is all the more annoying as draft-ietf-dime-erp introduces new mechanisms (and potentially > new threats and issues). What should I understand? Is the proposal guaranteed to be secure, have > all the potential weaknesses been already addressed in the 4 related documents? I can not > conclude after reading the security section. > > One more point. In introduction, the authors say: > " Security considerations for this key distribution are detailed in Salowey, et al. [RFC5295]." > This reference is not mentioned in the Security Section! > > > Cheers, > > Vincent > > From vkg@bell-labs.com Wed Jan 23 11:36:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7721F8770 for ; Wed, 23 Jan 2013 11:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWZJV8giCi6k for ; Wed, 23 Jan 2013 11:36:21 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 57D5D21F85FD for ; Wed, 23 Jan 2013 11:36:21 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r0NJa5QY005423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Jan 2013 13:36:06 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r0NJa4xx022080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Jan 2013 13:36:05 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r0NJa2jq017422; Wed, 23 Jan 2013 13:36:02 -0600 (CST) Message-ID: <51003C22.2080808@bell-labs.com> Date: Wed, 23 Jan 2013 13:38:10 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Yoav Nir References: <4613980CFC78314ABFD7F85CC30277211198D6A5@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277211198D6A5@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 X-Mailman-Approved-At: Thu, 24 Jan 2013 08:44:49 -0800 Cc: "draft-ietf-bmwg-sip-bench-term.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir Review of draft-ietf-bmwg-sip-bench-term-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 19:36:22 -0000 On 01/23/2013 02:01 AM, Yoav Nir wrote: > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > Summary: I think it is ready for publication. [...] Yoav: Thank you for your time on the document and the subsequent review. On behalf of my co-authors, I appreciate the time taken for the review. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From jhutz@cmu.edu Thu Jan 24 11:06:43 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967C921F84F3; Thu, 24 Jan 2013 11:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzeNSoYeIP0w; Thu, 24 Jan 2013 11:06:39 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id B999B21F84DE; Thu, 24 Jan 2013 11:06:35 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r0OJ6XX9005266 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 24 Jan 2013 14:06:33 -0500 (EST) Message-ID: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: iesg@ietf.org, secdir@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org Date: Thu, 24 Jan 2013 14:06:33 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: jhutz@cmu.edu Subject: [secdir] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 19:06:44 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an experimental protocol for publicly logging the existence of certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority activity and notice the issuance of suspect certificates, as well as to audit the logs themselves. The intent is that eventually clients would refuse to honor certificates which do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Overall, the approach used here looks reasonable. However, I have a few specific comments, and also recommend that the security area directors pay special attention to this document, as it has the potential to have far-reaching effects if the experiment is successful. The abstract for this document is four paragraphs and takes up an entire page. It could be a lot shorter. For example, I think my one-paragraph summary above is sufficient to fill the role of an abstract, which is to allow the reader to find out what a document is about and decide whether he wants to read it. This document makes extensive use of RFC2119 requirements language, but the body of the document does not contain text incorporating the meanings of these terms. Instead, the usual text is hidden in a "Requirements Language" section which appears just below the abstract, outside the main body of the document. This should be moved into the document proper. For describing its messages and data structures, this document makes extensive use of a language which is unfamiliar to me and for which no reference is given. I can make some guesses as to what it means, but guesswork does not make for interoperable implementations. I'm concerned that this document attempts to specify operational policy, particularly for operators of logs. As the saying goes, "MUST is for implementors"; statements like "Anyone can submit a certificate to any log" are inappropriate for protocol specifications. In practice, it seems likely that log operators will establish policies regarding both who may submit certificates and which certificates they will accept, and no amount of MUST in a protocol spec is going to change that. Similarly, as an anti-spam measure, this document proposes that logs accept only certificates which chain back to a known CA, and requires that logs validate each submitted certificate before appending it to the log. This sounds good, but it's not the only possible mechanism, and so I think MUST is too strong here. Additionally, there is no discussion of the security implications if a client depends on a log to do this and the log does not actually do so. Rather than requiring that logs validate every submitted certificate, the document should only RECOMMEND that they do so, and make clear that clients MUST NOT depend on such validation having been done. From radiaperlman@gmail.com Thu Jan 24 12:36:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7211E80BF; Thu, 24 Jan 2013 12:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRxzIa70bRSD; Thu, 24 Jan 2013 12:36:38 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9F211E809A; Thu, 24 Jan 2013 12:36:37 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so6721014lbo.28 for ; Thu, 24 Jan 2013 12:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=/LddweJ9+9FxzIb7wm7MIxjKWbV4rhsJOsTxw3/pPTQ=; b=TjIAvGuwzWnlBfNh+/bIAT90B0yNTFlh/H4jgo+lEhdNCP2aKsumZ2h5WxatJ0w711 Ny728GvoHXMklr8xhwpWfQty1AYQBvwJB0StHyu3Qk6pZ0bwuPc+9RK0Q4PTGQYkAWa1 cd/XkGNYDJwGP55Mcafd/+nZAUHVNrXMx3E4n4Z9/11QJ1uTNUtIRXBrm9MVjRV8m2qb 843bFSFN6vME72S1ZT40rCXJpn8jtGsYvmIFrpFInFjlWwxxX5uQuc6Xuruywc+cM72C YUx7iBTJ00G0XDV1x0+oOwn5R7m3vtgXufyLH0oE6c5wDnJscwtTzt+3UakQlVqwvidp MEPg== MIME-Version: 1.0 X-Received: by 10.152.105.17 with SMTP id gi17mr2976974lab.46.1359059797055; Thu, 24 Jan 2013 12:36:37 -0800 (PST) Received: by 10.112.64.17 with HTTP; Thu, 24 Jan 2013 12:36:36 -0800 (PST) Date: Thu, 24 Jan 2013 12:36:36 -0800 Message-ID: From: Radia Perlman To: secdir@ietf.org, The IESG , draft-ietf-idr-deprecate-dpa-etal.all@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d040892fd6e98a204d40ec4ba Subject: [secdir] SecDir Review of draft-ietf-idr-deprecate-dpa-etal-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:36:39 -0000 --f46d040892fd6e98a204d40ec4ba Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational document is as straightforward as we are ever likely to see. It is three pages long (almost squeezed into two, which I would not have thought possible). It instructs IANA to mark two BGP path attributes as deprecated where the corresponding documents are an RFC already reclassified as Historic and and abandoned I-D. It's a database clean-up with no security implications. Radia --f46d040892fd6e98a204d40ec4ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the secu= rity directorate's ongoing effort to review all IETF documents being process= ed by the IESG.=A0 These comments were written primarily for the benefit of the security area directors. Document editors = and WG chairs should treat these comments just like any other last call comment= s.

This informational document is as straightf= orward as we are ever likely to see. It is three pages long (almost squeeze= d into two, which I would not have thought possible). It instructs IANA to = mark two BGP path attributes as deprecated where the corresponding document= s are an RFC already reclassified as Historic and and abandoned I-D. It'= ;s a database clean-up with no security implications.

Radia

--f46d040892fd6e98a204d40ec4ba-- From kivinen@iki.fi Fri Jan 25 06:08:53 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5FD21F8467 for ; Fri, 25 Jan 2013 06:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNytVqlfauJm for ; Fri, 25 Jan 2013 06:08:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B891221F8464 for ; Fri, 25 Jan 2013 06:08:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0PE8mET028423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Jan 2013 16:08:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0PE8lQl024499; Fri, 25 Jan 2013 16:08:47 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20738.37359.844413.211557@fireball.kivinen.iki.fi> Date: Fri, 25 Jan 2013 16:08:47 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 14:08:53 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Nico Williams is next in the rotation. For telechat 2013-02-07 Reviewer LC end Draft Shawn Emery TR2012-12-24 draft-ietf-oauth-assertions-10 Phillip Hallam-Baker T 2013-01-03 draft-ietf-roll-p2p-rpl-15 Tero Kivinen TR2013-01-22 draft-ietf-tsvwg-sctp-udp-encaps-09 Julien Laganier T 2013-01-21 draft-ietf-ccamp-lmp-behavior-negotiation-10 Alexey Melnikov T 2013-01-21 draft-ietf-roll-p2p-measurement-08 Yaron Sheffer T 2013-01-31 draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Ondrej Sury T 2013-01-31 draft-ietf-rtgwg-ordered-fib-08 Brian Weis TR2013-02-07 draft-ietf-sidr-algorithm-agility-11 For telechat 2013-02-21 Hilarie Orman T 2013-02-11 draft-leiba-urnbis-ietf-namespace-01 Tina TSOU T 2013-02-14 draft-gp-obsolete-icmp-types-iana-01 Carl Wallace T 2013-02-05 draft-ietf-behave-nat64-discovery-heuristic-13 David Waltermire T 2013-02-20 draft-shafranovich-mime-sql-03 Last calls and special requests: Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-08 Matt Lepinski 2013-01-25 draft-ietf-radext-radius-extensions-08 Kathleen Moriarty 2013-02-08 draft-farrell-ft-03 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Sandy Murphy 2013-01-29 draft-ietf-6man-nd-extension-headers-03 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-01 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Vincent Roca 2013-01-25 draft-ietf-eman-rfc4133bis-05 Joe Salowey 2013-01-28 draft-ietf-storm-iscsimib-03 Sam Weiler 2013-02-01 draft-ietf-mmusic-sdp-cs-17 Brian Weis 2013-02-06 draft-ietf-mpls-tp-security-framework-07 Klaas Wierenga 2013-02-01 draft-ietf-xrblock-rtcp-xr-summary-stat-06 Nico Williams - draft-ietf-httpbis-p5-range-21 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 -- kivinen@iki.fi From glenzorn@gmail.com Sat Jan 26 04:51:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0611B21F871D; Sat, 26 Jan 2013 04:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxsvfQ-1exK0; Sat, 26 Jan 2013 04:50:59 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 27DE621F8718; Sat, 26 Jan 2013 04:50:59 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id rp2so685647pbb.15 for ; Sat, 26 Jan 2013 04:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pOKAK6Dnb2zQaFMyOSwQJpZzA23hny7yngWb/+NO5eA=; b=VAX78SGn4b8Z5Cjrbq0shzkgrSrWekC1jjJSLieCY30OkgQVOGVBacqjVgJWWI6jRl Xhp8dZswkqK6fjNwm3CbDqEhxfJPtmXdT0ZFi+x72TBMSXWhL65S0c0OXA1eWQHhoEqY 6s1m1gBQRJvpno68GkZcb8v+q9o2mb390Yg8JDsPNt+voPSBrTqUr25CnXfpcwodJoS6 q9f58n1oKVFUG/X8RSXn2uOWG186Ex/FYxugLsXS0B9oVHwlFMg+Cmf0ET0nFl8MbIaC NCmyvZBqK68ZoMLOzXCxcIIs3ojpK0dKcX2rdFqs1x8j3bYu1aIWlXQAcYXPutGD7Nby jfWQ== X-Received: by 10.68.242.225 with SMTP id wt1mr21989465pbc.65.1359204658907; Sat, 26 Jan 2013 04:50:58 -0800 (PST) Received: from [192.168.0.102] (ppp-124-120-221-204.revip2.asianet.co.th. [124.120.221.204]) by mx.google.com with ESMTPS id uh9sm2538439pbc.65.2013.01.26.04.50.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 04:50:57 -0800 (PST) Message-ID: <5103D12D.8060906@gmail.com> Date: Sat, 26 Jan 2013 19:50:53 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Benoit Claise References: <939DADEE-28DB-4A4B-AD0D-057AEB863250@inria.fr> <50FF9D1C.9070501@cisco.com> In-Reply-To: <50FF9D1C.9070501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG IESG , draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dime-erp-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 12:51:00 -0000 On 01/23/2013 03:19 PM, Benoit Claise wrote: > Dear draft-ietf-dime-erp authors, > > Please address the concerns below. I responded to Vincent's original review some time ago (see below); I am interested in hearing my co-authors' opinion. > > Regards, Benoit >> Hello, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> -- >> >> Since the security section has not really been updated since version >> 14, the comments I made at >> that time are still valid. Basically: >> >> The security section of this document only refers to the security >> section of 4 related documents. >> This is all the more annoying as draft-ietf-dime-erp introduces new >> mechanisms (and potentially >> new threats and issues). What should I understand? Is the proposal >> guaranteed to be secure, have >> all the potential weaknesses been already addressed in the 4 related >> documents? I can not >> conclude after reading the security section. >> >> One more point. In introduction, the authors say: >> " Security considerations for this key distribution are detailed in >> Salowey, et al. [RFC5295]." >> This reference is not mentioned in the Security Section! >> >> >> Cheers, >> >> Vincent >> >> >> On 11/05/2012 04:55 AM, Vincent Roca wrote: >> >>> Hello, >>> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >> >> Thank you for taking the time to review the draft. >> >>> >>> -- >>> >>> The security section of this document is pretty simple as it refers to >>> the security section of 4 related documents and that's all. On the >>> opposite, each of these 4 documents includes a very detailed security >>> analysis. The contrast is extremely important! >> >> Why? >> >>> >>> This is all the more annoying as draft-ietf-dime-erp-14 introduces new >>> mechanisms, and thereby new potential threats and issues (it's usually >>> the case). >> >> From a Diameter POV, a Diameter ERP "server" is actually just a form >> of Diameter agent and the Diameter ERP client is just a standard >> Diameter client; a new application is only required to ensure the >> correct routing of Diameter messages. So I'm not sure what the new >> mechanisms you refer to are; perhaps you can elucidate? >> >>> >>> What should I understand? Is the proposal guaranteed to be secure? >> >> There are no guarantees in life, let alone security . >> >>> Or have all the potential weaknesses been already addressed in the >>> 4 related documents? >> >> It would seem that that is the very strong implication. >> >>> I can not conclude after reading this security section >>> and this is a problem. >> >> It seems as if the big problem is that the draft doesn't tell you >> what to think about the security properties of the protocol but I >> don't think that is really a problem with the document. As I >> mentioned above, it appears to me that the authors believe that >> security-related issues are dealt with in the Security Considerations >> sections of RFCs 4072, 6696, 6733 and 6734. Is that the case? If >> not, please point out a security problem with this protocol that is >> not covered by those texts. >> >>> >>> So, I'd like that the authors clarify this, and if need be, I'd like >>> the authors >>> explicitly mention which items in each of the 4 related documents >>> apply. >>> It would be helpful IMHO. >> >> Only if you believe our conclusions . >> >>> >>> >>> Cheers, >>> >>> Vincent >>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> > From benl@google.com Mon Jan 28 03:48:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D139C21F886D for ; Mon, 28 Jan 2013 03:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sSnGff3M0Ab for ; Mon, 28 Jan 2013 03:48:42 -0800 (PST) Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8049721F884B for ; Mon, 28 Jan 2013 03:48:41 -0800 (PST) Received: by mail-bk0-f43.google.com with SMTP id jm19so795467bkc.30 for ; Mon, 28 Jan 2013 03:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=70DbQ3OA4E+UhSxHXFKvGu3iJhSXVNp5mnujsr4+e10=; b=GVoeiRV9Gga9RQxdLHkfg6X6sNecfF+EkY2B6ezRbi58x3hqQlfh53l9GfkLlh2wPm YXtdTogC4KnVzSyQKohycBOhfNtZhnJOJ1Bn3sPcnvvyzOmURPSLtouS6jNpY1yEX4RQ ur1r0H/ptZLZLjqe4hreEr+HTuDEKaK5J4DgKADkgfhwL5PYx5PK32iUBla1iZuUqO5N lNXB8SCTJmoqHxd3saKu5KU7UZsb2qDJJH4rBUPUWLW7PCB50YOMWL8M06bRIcEIeysK J3yNXk1joMtBTScGJQMZSaAPppBfqoIoKRmXT5X1bvHTFbqb7z9ySTcp6QKn5JWm/5B+ 6DAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=70DbQ3OA4E+UhSxHXFKvGu3iJhSXVNp5mnujsr4+e10=; b=QVWOiZ0Vni62FXLR+mJLVFbtFviYiolLj176bmgARu9ZyEW+pk5b6Axg87QE5/xnfQ SD0SL0EERxeAApNk6orzX9/gClrlttK8hemdNBD7kBOsNPyHWQ0XgkUwgB5nWfj5b6S0 wWa91IeKWgBJozKhHRLpr+Um+rKkpNYQKf3KvePUDlKyf9Mfnhgxcktc0ulI282NkjUf k6yD4XL7GK8b6HiKjjDLSr7xe1/5qe5PP7IchJJhh2kPnIgLi9iYZeeqiBLTqN6pc11T bsF+TWjWLoitLvdqigWwc9JiVZGpUyEjIESd57loHAbdIjWz5jilOolhycvMlk9Z8n15 Z6EQ== MIME-Version: 1.0 X-Received: by 10.204.147.18 with SMTP id j18mr3878877bkv.79.1359373720433; Mon, 28 Jan 2013 03:48:40 -0800 (PST) Received: by 10.204.38.198 with HTTP; Mon, 28 Jan 2013 03:48:40 -0800 (PST) In-Reply-To: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> Date: Mon, 28 Jan 2013 11:48:40 +0000 Message-ID: From: Ben Laurie To: Jeffrey Hutzelman , "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmovUlEdzse/dF2WQWDmNgxzL/No3qnIa/j/0WhCEDUQTmSVk9L/5RlfJBB83iSCzz+zg9/Xa9WqGJJkc/Ap3fF5vAa2dWr994zwdwweOMVub30qin86rxb0FqH/U0ooeP4SlSKHZ/vKm3aNcKdRcxstTGHbsw1lffgrssX8VZlxmk6hmJDSdZcRHoJwyTHAxcFM0Ge Cc: The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:48:43 -0000 On 24 January 2013 19:06, Jeffrey Hutzelman wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > > This document describes an experimental protocol for publicly logging > the existence of certificates as they are issued or observed, in a manner > that allows anyone to audit certificate authority activity and notice the > issuance of suspect certificates, as well as to audit the logs themselves. > The intent is that eventually clients would refuse to honor certificates > which do not appear in a log, effectively forcing CAs to add all issued > certificates to the logs. > > Overall, the approach used here looks reasonable. However, I have a few > specific comments, and also recommend that the security area directors pay > special attention to this document, as it has the potential to have > far-reaching effects if the experiment is successful. > > > > The abstract for this document is four paragraphs and takes up an entire > page. It could be a lot shorter. For example, I think my one-paragraph > summary above is sufficient to fill the role of an abstract, which is to > allow the reader to find out what a document is about and decide whether > he wants to read it. Fair enough. I have copied your version. Thanks. > This document makes extensive use of RFC2119 requirements language, but > the body of the document does not contain text incorporating the meanings > of these terms. Instead, the usual text is hidden in a "Requirements > Language" section which appears just below the abstract, outside the main > body of the document. This should be moved into the document proper. Moved. > For describing its messages and data structures, this document makes > extensive use of a language which is unfamiliar to me and for which no > reference is given. I can make some guesses as to what it means, but > guesswork does not make for interoperable implementations. Oops. This is the language used by TLS. I will add a reference. > I'm concerned that this document attempts to specify operational policy, > particularly for operators of logs. As the saying goes, "MUST is for > implementors"; statements like "Anyone can submit a certificate to any > log" are inappropriate for protocol specifications. This is not a MUST, however - in any case, we've changed this language in the next version. > In practice, it > seems likely that log operators will establish policies regarding both > who may submit certificates and which certificates they will accept, and > no amount of MUST in a protocol spec is going to change that. > > Similarly, as an anti-spam measure, this document proposes that logs accept > only certificates which chain back to a known CA, and requires that logs > validate each submitted certificate before appending it to the log. This > sounds good, but it's not the only possible mechanism, and so I think MUST > is too strong here. I think you are right, I have changed this to MAY. > Additionally, there is no discussion of the security > implications if a client depends on a log to do this and the log does not > actually do so. Rather than requiring that logs validate every submitted > certificate, the document should only RECOMMEND that they do so, and make > clear that clients MUST NOT depend on such validation having been done. I've mentioned that normal validation should be done by the client. > > From olaf@NLnetLabs.nl Mon Jan 28 04:42:27 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9B21F843B; Mon, 28 Jan 2013 04:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv+IZZIYQvq4; Mon, 28 Jan 2013 04:42:21 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B021521F913E; Mon, 28 Jan 2013 04:42:15 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id r0SCg6Xn009077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 13:42:07 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl r0SCg6Xn009077 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1359376928; bh=k/fHh68ZTWx6Eh/81JNzsfzcuEwMNaLV4FPo7TOaHc0=; h=From:Subject:Date:Cc:To; b=RcBNZxIOXICfVdZWNkG4MtZm8fDqO6yL8dYcE3d/pytTHCxuxBZUGac8uekR/ZwgN hZNnNv8mJwYgtnY+uudBqsFbrXvWpktU0BX5paImvyTB8i5UYCKp918H/wnrYraFJC ZBiIiwB7oMHm46eouwqFhUSh1SXa7O4U+l/WA5l4= From: Olaf Kolkman Content-Type: multipart/signed; boundary="Apple-Mail=_9890420E-9C0C-45DF-9404-CDA4A1436592"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 28 Jan 2013 13:42:11 +0100 Message-Id: To: secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 28 Jan 2013 13:42:08 +0100 (CET) Cc: IAB IAB , Hannes Tschofenig Subject: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 12:42:27 -0000 --Apple-Mail=_9890420E-9C0C-45DF-9404-CDA4A1436592 Content-Type: multipart/alternative; boundary="Apple-Mail=_E4B6C245-88C1-483F-8C1E-DC5ED54D9261" --Apple-Mail=_E4B6C245-88C1-483F-8C1E-DC5ED54D9261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folk, This mail is FYI, it may be of business/personal interest to some of = you.=20 I have a specific question. Context: MSP for ICT St. You may or may not be aware that the EU has a Multi Stakeholder Platform = for ICT standardization. One of the stakeholders at the table is the = IETF/IAB and your truly is, with Hannes Tschofenig as backup, the = representative for the IETF/IAB. The platform is chartered to give the Commission advise on all matters = standard and to identify standards, developed by fora and consortia, = that can be used in public procurement (formally RFCs can not be = reference in EU procurement: when these folk talk about standards they = think ISO, ITU, ETSI etc etc.) Specific: EU Cyber Sec Strat. What is attached is part on the advise on all matters standard aspect. = The document gives a short executive level overview of what the EU = intends with its cyber security strategy. The document is FYI mainly. However I have one particular bit of information that I need. See the = section on "Where do standards come in". I do not think there is any = relevant IETF work in this area (info exchange and such) and would like = to get guidance if that is a misunderstanding. The platform is having its 3rd meeting 7 Feb. NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_E4B6C245-88C1-483F-8C1E-DC5ED54D9261 Content-Type: multipart/mixed; boundary="Apple-Mail=_AB0279E2-98E2-4C55-B90F-9BC33E361CD3" --Apple-Mail=_AB0279E2-98E2-4C55-B90F-9BC33E361CD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


The = platform is having its 3rd meeting 7 = Feb.


= --Apple-Mail=_AB0279E2-98E2-4C55-B90F-9BC33E361CD3 Content-Disposition: inline; filename=04420Brief20on20Cybersecurity20Strategy20and.pdf Content-Type: application/pdf; name="04420Brief20on20Cybersecurity20Strategy20and.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdWFtvFDcUfvevcAhNZgM7Ox7PzYVCS5rSVqpUxEo8dHmK SlGVIEEe+vf7nZvHs1mihETamTO2z/U7x8f+7N/4z77Bf596P3Wt//K3f+c/+c3rm+D/ufGbczwv b3hK428ufd+O9eTHIdRN5699H9s6KumujAxj3XUepEw28qP/4MdQJz9MXd3Oy5W05cOY6rEDN5nL FJjRamUIocXyUci8HMzDLJ2YB+JG62FOuzAHdrZkJ5xQB7ESz9D6qU1kw+W1f7UFTS5q+Nk1qfXr GAe3vfab7RaO8MFvP/i/fPXb+XYFRq2vNvr8Y+XX/OGtvfy58nH0ld9VbRPiDvO6buXe++3v/mIr 4bivJkM7+XU3dr7QxIkmbTAN8gvEtSu/J2hq+r4fzHClsvlOzYcj2Hw8x9jVqY8JglOq+wHOEOkt +U39cKTWP6Jn56vjlYMXel891g/f6fOEvYIZp/Qh+mpX6chuxUPBV2fG5QkPueqpLVqbT2tdzTaD i3FrMv+gbE0B4wWPsIZ54vEDXaQIaeqmaVq3vfShcNaQYt2FPvr12I91aMbxgLMidIGZ0Bm/XRbv ODPrMNDfaBFSKkdIxcO7kA8gLOWHppuAxvXUAoOK1zJOj2HtGlJ7ebDPQT7eVfY6jDI0lTNcVW9O gd9TXd6m72X4lEIjDLIdBuk44S+ZHUplOw4grUNaj1A+oDTV/SGYneWo5ZenjDQAKgPpGVSi3K6e P1AluNZR7hfxDN0AzN+p0w8EKBSAGb8vVDlXvVSwkds4HQzZhtc88KPOnLn8pHxf8dNV50rj+15K 3+3oEq9I10tX2mcubzuUbIITV7gSMVNimG4Esye7FRKIAo5fV/0Me0D0J+R8vGyek/7foJ5jOMdb cB7biSHxdf1GeA6S4Wn8nhzvVvXK0Zuqdqzq87BMpSmsLP8eSxqikNCqZzaF7PPVxW61YXaoJjT8 jdZR8A9Vi+z9IaQ6Dvver45+Wfntv8UucXekNaVE2C1fmrAYhrHGPnI71PWjl1oX0mtkFRks2a1Z j+CSRg8NL+XU4WqVVRpDjxS6rdGvEoYSZhRcCdZudSHDx0h0fH1wcBb+gvhlKTXl0IEcyosjddVp Qma8d4vN/F4VvEzDIfbYNdddTL0W7Wiba4Wt1TDAWzL1ZNy8tL3VVrzluqrpXnKf0kTc+2lo9rmj hbGShCBz1YRPgSAUNGzZUrRs5CQPIWcwhALAiY9X1N88qCUMn86MwxPZwbFRyw6OF97BMUe6Flc1 +3og5YSxDaDwyAdbmnnNEp8E2w6KVTNgDzW5gRwa2g7NCLadJqaU0ObGMdaDyx+u5IPH9j7xjCtb Mn+gdlO6RjBEjo3c9WIzuSaqd9KXoq8lCh00Qk5NK88kCg0uKGq10XDpO60Z8iyiaI37cMaN8TBL oD65Y5KnC5k5ETmwSBZCZFINqIdnMqsnk02Wz7JURxwBWFZmnlUGqz1jFoaWUmGpiMmGZzEi2IkY OTlwc89ey0qyoKwjVKD3wvQFObDv2dsQQ23WSFBvJ2wuFJ7YtkYg0CBCwm5Nbud5mfro37lPHOP7 Hp5axLJn3owDIiOTfEAB904pk0U6CSwSQqQaXnlaOC3JzJbhAK11PgsicpxZz8vZlQuthLloxYew 2Eakfxa94HxFcNDlfU8wvWYSy0Gy/8UopuhEx46WqUzB4H4QrBMfWliQMMrmQpCK5i8AhBrFrOEv Naoki+U2qsxtLZFQq+QMVrNRsL2MFEj2mBhVUEAPTxUTYRQoYCk7syShFc8VQSpavmSjQDIkVG0m lVuxfB5lWWoUJmcSmGHO0CsbRfjNkZoY3FJTCGI0aHHDeU6maqRCCuIukhsxSGTWKs/NkcqCBEKZ tS0nSVCMSOxYJkqMyszFqAUpWnJNhCyBFOcJQCGRAVXEyRC1BB86eXjH4CKUVACBqcu5l4Uw8gBx EWJLhTKvixB2OlwjbEFxNFWkYnCpThYiS00ILwUjFmJecLw0e4zZZu9mkQyCpToQIt5W266deJvI XApQWMxjOlnszmAuR618YRdacC7wpikslYGYa2VQ0bAwZ4phW1EB5uVoUVX2FJvtMu/NzIs8Mv8d gtwenkV09kmhGGR97c5s/3Lp7r6MGmF0MIfO7X0zob6vuw772qFGeNhVF2h/0OXKCd7ZCf4rB3C+ 9jp/q/3I23OPsoZbn/88mH+R9vFeZ4myjQwJOEgDtGxCqCdrinHZhu4bl1DLTtXEHO5StfW+2xkj +gxzRm9S0LEePTqWxh8dKnpQecdRBd5BYzp3e3dHg6757pafJsjXjnkhf5aOmy49+pIu3DNTjPh9 XyPc7+TWg5IXSUDln65HlaR9iUlkZ1GTjUL7gYtaajG1/XB2d3sQhxJ88tv+5WaQNjXg2U+43Bi6 ZHbO5444nzve/A9sF2FGCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagoxODE4CmVuZG9iagoyIDAg b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVu dHMgNCAwIFIgL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBS ID4+IC9FeHRHU3RhdGUKPDwgL0dzMSAxOCAwIFIgL0dzMiAxOSAwIFIgPj4gL0ZvbnQgPDwgL1RU MS4wIDkgMCBSIC9UVDMuMSAxMyAwIFIgL1RUNC4xIDE1IDAgUgovVFQ1LjEgMTcgMCBSIC9UVDIu MSAxMSAwIFIgPj4gPj4KZW5kb2JqCjE4IDAgb2JqCjw8IC9UeXBlIC9FeHRHU3RhdGUgL0FBUEw6 QUEgZmFsc2UgPj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9UeXBlIC9FeHRHU3RhdGUgL0FBUEw6QUEg dHJ1ZSA+PgplbmRvYmoKMjAgMCBvYmoKPDwgL0xlbmd0aCAyMSAwIFIgL04gMyAvQWx0ZXJuYXRl IC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVXfb9tUFD6Jb1Kk Fj8gWEeHisWvVVNbuRsarcYGSZOl7UoWpenYKiTkOjeJqRsH2+m2qk97gTcG/AFA2QMPSDwhDQZi e9n2wLRJU4cqqklIe+jEDyEm7QVV4bt2YidTxFz1+ss53znnO+de20Q9X2m1mhlViJarrp3PJJWT pxaUnk2K0rPUSwPUq+lOLZHLzRIuwRX3zuvhHYoIy+2R7v5O9iO/eovc0YkiT8BuFR19GfgMUczU a7ZLFL8H+/hptwbc8xzw0zYEAqsCl32cEnjRxyc9TiE/CY7QKusVrQi8Bjy82GYvt2FfAxjIk+FV bhu6ImaRs62SYXLP4S+Pcbcx/w8um3X07F2DWPucpbljuA+J3iv2VL6JP9e19BzwS7Bfr7lJYX8F +I/60nwCeB9R9KmSfXTe50dfX60U3gbeBXvRcKcLTftqdTF7HBix0fUl65jIIzjXdWcSs6QXgO9W +LTYY+iRqMhTaeBh4MFKfaqZX5pxVuaE3cuzWpnMAiOPZL+nzeSAB4A/tK28qAXN0jo3M6IW8ktX a26uqUHarppZUQv9Mpk7Xo/IKW27lcKUH8sOunahGcsWSsbR6SZ/rWZ6ZxHa2AW7nhfakJ/d0ux0 Bhh52D+8Oi/mBhzbXdRSYrajwEfoREQjThYtYtWpSjukUJ4ylMS9RjY8JTLIhIXDy2ExIk/SEmzd eTmP48eEjLIXvS2iUaU7x69wv8mxWD9T2QH8H2Kz7DAbZxOksDfYm+wIS8E6wQ4FCnJtOhUq030o 9fO8T3VUFjpOUPL8QH0oiFHO2e8a+s2P/oaasEsr9CNP0DE0W+0TIAcTaHU30j6na2s/7A48yga7 +M7tvmtrdPxx843di23HNrBuxrbC+NivsS38bVICO2B6ipahyvB2wgl4Ix09XAHTJQ3rb+BZ0NpS 2rGjper5gdAjJsE/yD7M0rnh0Kr+ov6pbqhfqBfU3ztqhBk7piR9Kn0r/Sh9J30v/UyKdFm6Iv0k XZW+kS4FObvvvZ8l2HuvX2ET3YpdaNVrnzUnU07Ke+QX5ZT8vPyyPBuwFLlfHpOn5L3w7An2zQz9 Hb0YdAqzak21ey3xBBg0DyUGnQbXxlTFhKt0Flnbn5OmUjbIxtj0I6d2XJzllop4Op6KJ0iJ74tP xMfiMwK3nrz4XvgmsKYD9f6TEzA6OuBtLEwlyDPinTpxVkX0CnSb0M1dfgbfDqJJq3bWNsoVV9mv qq8pCXzKuDJd1UeHFc00Fc/lKDZ3uL3Ci6MkvoMijuhB3vu+RXbdDG3uW0SH/8I761ZoW6gTfe0Q 9b8a2obwTnzmM6KLB/W6veLno0jkBpFTOrDf+x3pS+LddLfReID3Vc8nRDsfNxr/rjcaO18i/xbR ZfM/WQBxeAplbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjEwNDcKZW5kb2JqCjcgMCBvYmoKWyAv SUNDQmFzZWQgMjAgMCBSIF0KZW5kb2JqCjIyIDAgb2JqCjw8IC9MZW5ndGggMjMgMCBSIC9OIDMg L0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AZ2W d1RT2RaHz703vdASIiAl9Bp6CSDSO0gVBFGJSYBQAoaEJnZEBUYUESlWZFTAAUeHImNFFAuDgmLX CfIQUMbBUURF5d2MawnvrTXz3pr9x1nf2ee319ln733XugBQ/IIEwnRYAYA0oVgU7uvBXBITy8T3 AhgQAQ5YAcDhZmYER/hEAtT8vT2ZmahIxrP27i6AZLvbLL9QJnPW/3+RIjdDJAYACkXVNjx+Jhfl ApRTs8UZMv8EyvSVKTKGMTIWoQmirCLjxK9s9qfmK7vJmJcm5KEaWc4ZvDSejLtQ3pol4aOMBKFc mCXgZ6N8B2W9VEmaAOX3KNPT+JxMADAUmV/M5yahbIkyRRQZ7onyAgAIlMQ5vHIOi/k5aJ4AeKZn 5IoEiUliphHXmGnl6Mhm+vGzU/liMSuUw03hiHhMz/S0DI4wF4Cvb5ZFASVZbZloke2tHO3tWdbm aPm/2d8eflP9Pch6+1XxJuzPnkGMnlnfbOysL70WAPYkWpsds76VVQC0bQZA5eGsT+8gAPIFALTe nPMehmxeksTiDCcLi+zsbHMBn2suK+g3+5+Cb8q/hjn3mcvu+1Y7phc/gSNJFTNlReWmp6ZLRMzM DA6Xz2T99xD/48A5ac3Jwyycn8AX8YXoVVHolAmEiWi7hTyBWJAuZAqEf9Xhfxg2JwcZfp1rFGh1 XwB9hTlQuEkHyG89AEMjAyRuP3oCfetbEDEKyL68aK2Rr3OPMnr+5/ofC1yKbuFMQSJT5vYMj2Ry JaIsGaPfhGzBAhKQB3SgCjSBLjACLGANHIAzcAPeIACEgEgQA5YDLkgCaUAEskE+2AAKQTHYAXaD anAA1IF60AROgjZwBlwEV8ANcAsMgEdACobBSzAB3oFpCILwEBWiQaqQFqQPmULWEBtaCHlDQVA4 FAPFQ4mQEJJA+dAmqBgqg6qhQ1A99CN0GroIXYP6oAfQIDQG/QF9hBGYAtNhDdgAtoDZsDscCEfC y+BEeBWcBxfA2+FKuBY+DrfCF+Eb8AAshV/CkwhAyAgD0UZYCBvxREKQWCQBESFrkSKkAqlFmpAO pBu5jUiRceQDBoehYZgYFsYZ44dZjOFiVmHWYkow1ZhjmFZMF+Y2ZhAzgfmCpWLVsaZYJ6w/dgk2 EZuNLcRWYI9gW7CXsQPYYew7HA7HwBniHHB+uBhcMm41rgS3D9eMu4Drww3hJvF4vCreFO+CD8Fz 8GJ8Ib4Kfxx/Ht+PH8a/J5AJWgRrgg8hliAkbCRUEBoI5wj9hBHCNFGBqE90IoYQecRcYimxjthB vEkcJk6TFEmGJBdSJCmZtIFUSWoiXSY9Jr0hk8k6ZEdyGFlAXk+uJJ8gXyUPkj9QlCgmFE9KHEVC 2U45SrlAeUB5Q6VSDahu1FiqmLqdWk+9RH1KfS9HkzOX85fjya2Tq5FrleuXeyVPlNeXd5dfLp8n XyF/Sv6m/LgCUcFAwVOBo7BWoUbhtMI9hUlFmqKVYohimmKJYoPiNcVRJbySgZK3Ek+pQOmw0iWl IRpC06V50ri0TbQ62mXaMB1HN6T705PpxfQf6L30CWUlZVvlKOUc5Rrls8pSBsIwYPgzUhmljJOM u4yP8zTmuc/jz9s2r2le/7wplfkqbip8lSKVZpUBlY+qTFVv1RTVnaptqk/UMGomamFq2Wr71S6r jc+nz3eez51fNP/k/IfqsLqJerj6avXD6j3qkxqaGr4aGRpVGpc0xjUZmm6ayZrlmuc0x7RoWgu1 BFrlWue1XjCVme7MVGYls4s5oa2u7act0T6k3as9rWOos1hno06zzhNdki5bN0G3XLdTd0JPSy9Y L1+vUe+hPlGfrZ+kv0e/W3/KwNAg2mCLQZvBqKGKob9hnmGj4WMjqpGr0SqjWqM7xjhjtnGK8T7j WyawiZ1JkkmNyU1T2NTeVGC6z7TPDGvmaCY0qzW7x6Kw3FlZrEbWoDnDPMh8o3mb+SsLPYtYi50W 3RZfLO0sUy3rLB9ZKVkFWG206rD6w9rEmmtdY33HhmrjY7POpt3mta2pLd92v+19O5pdsN0Wu067 z/YO9iL7JvsxBz2HeIe9DvfYdHYou4R91RHr6OG4zvGM4wcneyex00mn351ZzinODc6jCwwX8BfU LRhy0XHhuBxykS5kLoxfeHCh1FXbleNa6/rMTdeN53bEbcTd2D3Z/bj7Kw9LD5FHi8eUp5PnGs8L XoiXr1eRV6+3kvdi72rvpz46Pok+jT4Tvna+q30v+GH9Av12+t3z1/Dn+tf7TwQ4BKwJ6AqkBEYE Vgc+CzIJEgV1BMPBAcG7gh8v0l8kXNQWAkL8Q3aFPAk1DF0V+nMYLiw0rCbsebhVeH54dwQtYkVE Q8S7SI/I0shHi40WSxZ3RslHxUXVR01Fe0WXRUuXWCxZs+RGjFqMIKY9Fh8bFXskdnKp99LdS4fj 7OIK4+4uM1yWs+zacrXlqcvPrpBfwVlxKh4bHx3fEP+JE8Kp5Uyu9F+5d+UE15O7h/uS58Yr543x Xfhl/JEEl4SyhNFEl8RdiWNJrkkVSeMCT0G14HWyX/KB5KmUkJSjKTOp0anNaYS0+LTTQiVhirAr XTM9J70vwzSjMEO6ymnV7lUTokDRkUwoc1lmu5iO/kz1SIwkmyWDWQuzarLeZ0dln8pRzBHm9OSa 5G7LHcnzyft+NWY1d3Vnvnb+hvzBNe5rDq2F1q5c27lOd13BuuH1vuuPbSBtSNnwy0bLjWUb326K 3tRRoFGwvmBos+/mxkK5QlHhvS3OWw5sxWwVbO3dZrOtatuXIl7R9WLL4oriTyXckuvfWX1X+d3M 9oTtvaX2pft34HYId9zd6brzWJliWV7Z0K7gXa3lzPKi8re7V+y+VmFbcWAPaY9kj7QyqLK9Sq9q R9Wn6qTqgRqPmua96nu37Z3ax9vXv99tf9MBjQPFBz4eFBy8f8j3UGutQW3FYdzhrMPP66Lqur9n f19/RO1I8ZHPR4VHpcfCj3XVO9TXN6g3lDbCjZLGseNxx2/94PVDexOr6VAzo7n4BDghOfHix/gf 754MPNl5in2q6Sf9n/a20FqKWqHW3NaJtqQ2aXtMe9/pgNOdHc4dLT+b/3z0jPaZmrPKZ0vPkc4V nJs5n3d+8kLGhfGLiReHOld0Prq05NKdrrCu3suBl69e8blyqdu9+/xVl6tnrjldO32dfb3thv2N 1h67npZf7H5p6bXvbb3pcLP9luOtjr4Ffef6Xfsv3va6feWO/50bA4sG+u4uvnv/Xtw96X3e/dEH qQ9eP8x6OP1o/WPs46InCk8qnqo/rf3V+Ndmqb307KDXYM+ziGePhrhDL/+V+a9PwwXPqc8rRrRG 6ketR8+M+YzderH0xfDLjJfT44W/Kf6295XRq59+d/u9Z2LJxPBr0euZP0reqL45+tb2bedk6OTT d2nvpqeK3qu+P/aB/aH7Y/THkensT/hPlZ+NP3d8CfzyeCZtZubf94Tz+wplbmRzdHJlYW0KZW5k b2JqCjIzIDAgb2JqCjI2MTIKZW5kb2JqCjggMCBvYmoKWyAvSUNDQmFzZWQgMjIgMCBSIF0KZW5k b2JqCjI1IDAgb2JqCjw8IC9MZW5ndGggMjYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Aa1d25IcuXF976+o0IubESTVdenq6ifHiqa9K2strziywiH5YXhfcdlNDWek3Q/Sf/ok gEShqg4GKHSHFEEuOTyVyHsmEsDfqh+qv1U7/G9/3FdD11R376o/Vafq1y++NtWbr+avdtXXN/JT z2v7n/i1bqqhOT7vuurN5+o3N/hvwdiZX7vdsametW2/uflc/frmpn6OP69u3ld/rrbfvbh5AqCm 2v7a/fr9k+qZ+YNX+pv/flK1h2pb/WXb7Or2L/i5rnuy+b/q5rfVyxtLby4lfTNUz7pDVwWUbCwl Ta0U+N/gc82TquRD/a6unh26g1txH6z4hS7rl9f52ODIbrdrNjdvJpwd6tZ8xi3Hf2b77u5JdfPX R9mzWQrq2II7oHoBVxWhDQeKBql70b5zQn/jfn2wzNlsQb9Rgh/dr/e/5DMr1L26ay2L5pLYptdE VLnuBqgyF6xf1L0Sf3ufQTSRQ33orPrMBQHWKcc+5DCEYR/bjoolgyEUbojAnd+XKE1T7yIqnZYX Ia+p91ZehJP3H9USwdOkkTPwtuViKmNl0w4RuJdFnOz6HRf0H4vg9n3P4coE09cRuGdF1PWH/TWp OzRcq0PfdX97UgV6q27rVk3f/Um1VQf2VX/29l7/6Ix/X6J37b7n1JXpXdtHoggWi2Bs3LDzy9X2 J/XHP5ZF4PZYHxeCkgicQTvxx+2xn4esjaYWoz++/aTMV+/pTf+sC/IC0x+5K1sgrG6pieUL7Pr9 HM4vEHmREY4u4fb+/TlDoxwbIylFd4y5jbvPJZZpMqEjeGIzLp+iQLk+K6v1V28ZpycbmwN+eFod qn9369QfQ95k/1aNzWunN79fKkkVn1tubFZmiYbkuoaRzWje/unJJpFVTZlbIV879iYRxi+HBv59 iutl+e03TyqkpVtkw0mXQOzg2CDMCXR5mmMzzCnFR4meFPabP7xMagOhs65FnSliOow4vJGhdT1E 0KBdN986tQGhuSwVm6iHerebJ9p1K8nsVHa2htlWEFlCKVzuEBDeobiicCD8945u/fV3cGR+AZv8 sqs+9E56Cz3+VyF5rVkcJD2pO2iaNYuDFjXbf+aaRZiZH/spnFaFG7Dgt2rhZ42VJ6TSxtlVL87w Q+a3+uvDSX9Ky4hb8xObrf4j/fvzqcL/9U8/qkOpfqXfe/HLa/3Du8oHkHdPNuaDCv9wp4AK9cv4 w/pHd5aIyhNhgTfbD79U5/eECOip+crD3fmLEqEYpwpJm3V6frHn06/UTT6H8XgVWVGZW5H2Qw+R blCZhyJNKTWxbitSwJFCH8HKOe3zlzOSoUxyJQ5I5St+KdSeujmiTqgt6ZOmwvYW8TDPICeA7RFJ FQVMeyZSHKDwRGZC8d6fEbgKKNwfxWLYksso7FtxQgwPaldA30GaHhSvjL5DF6EPHuLfVJ3UEu9g Mk6nNqaFldkSqo978eyEC/jKG2f4atP6sb+PH1vVf2oaSQ7lY3MLKUt/m6ZzSjbHM8Rbf3I+qd/K pHoz6981+ybOojvvj04fvATiTCGW0hxMMCQSyGAKwxtilgemaMyYO9iv6kofAkWKL4M4v7ZBk5LL Fu4uYU4U7xiRbQZbHF7EebYt+rqc1HtUEAW0dh2quuvpddtJx5jhQYQqulN+FJmEjrbfOz81N5qt EX7B8gcpahm5+aIKY1E7mMyNuYm0Z2aqdGyuS9/x4ILvnIMQz0d1kh9QZGdG+Yl8umaHxtX1uNk1 XZxadY2LpLK0OdP1h4izzNAF4s26A3ZSDDdc2q15suyeaOWvJiFxyeSQPxU2L449Ib68e7Hf1Qvi bcm7zWgPE022Geaw343M8CX0SRev0fofmiOc7z5VPpN+W6mCnpCIaTywf00rBrgZm7kqvuoMKwP0 M5o53Emua/+5/w3J/Vl277oX2MRZldCYnB5t9IGUaXDtOVVfJGwY5gfI0EQnzBuY+nq3We8kh3eA Un541RYfX4CH3RmLN3dLGaZHlK2uD3CbQt8cD6bHS9SkvyMWXnc1Ko8pX7W3kGQDxZO8meKZ2jnB WIZofBpDBCPUglgVXrRJ2+xkW2X+NbdLq7atNpzlpolsm0ZCtnxkLtsyXWka+CSKBxapUzi9RSEE X15t59Ww9RD6c3Drokg5phqmDc1wwJ7KnHGy0Y41ZTYuJ3jHHaIBwdtsc0pYwvV2pxY699/5XI84 p3b3iLHeKt9RNiZNlNH9mHRVFaVwmLSJ5ro6qxrRU8qbn8AGDbJhIodx0yQZIWJc6yU3mkI7ny69 9ISrYJw6SFPBAV7Bp7eHY8Su8jUm1Ol2kCa80De3e9ipCvBn339DqM/RF6mYIxzu0E32DJk2qu7f YdMpwWLijZHPOtc1GtEl8aJrhgiFYInq8FktyPdH4VKMK3PO6tFZE6Io3X4YNW+iKIHDfPCtC9+r BcuSEmFMO8qcwlTR1zItImEkuaPKTyX8I3Z41wvY5lnNQRvtPi0CZ37QbLK2O1wQi2fHir0Bs8XV 7H0e7bflsMUFinMiT8CNcWPDbHFNcX1+fo0tLoF2hjuSDB4kmOz0b2wljxSbLS4K+92rXNzQwdQ7 41EvonOkrt5Jpc3Igy6U7HBNSG1MvkBJ/S537YyndbuPUL199eqPL3OhJ7TuTa3AaDWbWWvdz4D6 6Flz6DQMXLrzMUzhQpNdtKo/IGPwRvvIbs0jUQWsEZ8N+hcx4L50/0NGIyli2r6Iw63RZuN4QVTR gKsV9ccT5jHsXttZuGTSKf0h1M85XJtPn9ZHkxiOovayKcsgMFggWTbBCwLXKSdMkaiIqiQCnk9s 4JhDC2oamYRkdG9lEi7Pg04A28ZJeJ5KlZXvmH+7eO0T+romsmAI6ju/oazqdSf9o6SCEU2HF5X0 nNpikq8Mb9hJqsLwiiyxGWSalOEFCpu168GIPcq2KQPPUFiC19rinyw+cBuSDJZIqjXzIlcktpGx G4YHYl9rNa/O7dNrbVbkpFehJre9bMCx78DSCgr7ttdwNYsemwyhEa/VHtQTjHiuiixr87ZDOzJ2 UhwUEjj0UjIRn709PxTVud2uvaqz6myiRyiEKvnO8Vl1aR4bUaaVGETXyoAXVSyMlydCArHeDns3 Ebwi19V1sjnP6AtcV1asZcT2sk/MwDOUjOLJDDLDA7EaZVSA59M4qlnavLGjmtMPOrP7nBYfseOj cQsDxkz88Rhfvak3y+I2wTazc88agC+yhbRqOLxIZlPXslNOocuaWBguEjVmtEKOCbNga29xpobj Za89jAeYRpSITuiDpn1SVcs5IMKI3RubI+AZZkHxYswMzOKk6vV6vqV5l5P2E2usj6ZgxDJGZV7b 8Al53uxMDGZ4GTGOENjUrVOyKxFY95LuEgLB5y/BPqRvbropxnHTs1Bjmt6U+1fTmEZGgWLqrYpS 6ocaM1vBbKdMvYEUJ/a93xNQo3wrgwYlobptZEqKiXeLjeKETyLq1wIwgpf2SRRv7/iwUOdviujr 2uvSh0EKvl6Yx7qZFbZ6m1ET48vQKoZ3MJUFwQO1cxd56dRHe9y7+BmKrnzqoz3K9NZUVS8qB3CA eNT9K5QDXW16XcRhgbuaoQWT4IUhqOu6iIfHZ9Qh6OfCYZKibfPuYMYIZipjpFiUDHYHGWSiUkw7 CJIHdEPtkpZRyxbZpXIjCFc5zMfnHmmWmrS23cHf+bTWZQIZjS9inNg8hFwpYDo9ZHjI5yJ4aU47 vGhqLF6PkvoSM0frw0bdyv4uBbyY1laKdAr9I5SggNZO8hIKmE1rmAJivAgWwfACewalkAXuM/C/ 0dMjvuOoxTtSmWQmQAypHuQkrpCxqKQQGRJsYnhH6TdSvDSbHF5M/cyNAhS6bNAYs0EX0xqKtNnJ +VFGIET6xWdvgSztnsTdbJYDf0pmOYitN93hYlufLGAvsyGygLlzwwJ08760X9r00tlm4GVZTdNL rszwQKyf1tTIqGmO7gg9ez+OA+jK1JTOF59CaPeyo8ZoK1srtkCdps4FkzP6SjSn7eV8wRUJ7A+I xwzvCppjx2wYeCE3Bzk3yvBArCqBd7DQIOdYk6210JbQ042J7A4NioJGe1dLR42QvZEkfr2rxuHL BRtcZp3tqicrbvaLkOtzMh3s1Ir7zneWcrrNLiWbfG0fM/98pYgEmq6XZgphNIYvi3KH7iC7pRQw zWlnveNoxIQLB5mxp8j/ePdTWi2Ia+iOlweVCGMx3BQLAWWMtcl4DR7MknEY8oe7s48C6uE/usn9 zRbTs391IwHn1z4ij1Pyq05rmfkPXEm1dzlUwfxHhGN2gSPyOG5QOCUvyiO3ZympI2C62mDpXm2q F4aX1myGhzt2OH2Q6NyHfPBxWuX78Hb01nEJEqWvD9KQFb7MNSnfm4R2iePyYvEED+tQH5jVdWTE HuXEHQMvJPYoxTnDA7Fj1/FvD5pMuUHKzba0x9uZVHDCnUsiD2ZYJTIyvIx2OlHDppeLoxzgFXpE TS/9R8FbVFmisetjd3OQY4cMECLTXFdTGT9ly24RCIrG/BlyHGbx7JkOqarVr8qV2trU1hP5uaYK TrcXpEoYJloohAEsnUloZDCFKhiMeb34cGZWapfJgn2qpG0r/VXFKJpimgE+NVVHAoEHYswuH9uD bI1MqbhkV8vl6ZNVWTwopa7CD2HrH7wtPF24k6uF5sS7gz0LTiHCJzlE/EAHR2A/srBbVfR4mKF4 0nsWohd4Ms6zXpEwIxHxAxmhgBHYycYLIxAifPRMZA6HSSzrjriOYyFGd8woxRCKZwpbroNqL6WB 12Zje38a0idPoX6b00xJZSOk17jQAazg8PPcRzMe3JxmfIJOg60dXcYVSuLK7UevEOlqc6+I4M01 HDzyefYv/ne6DrVYXWeoTiuOImA+Vxw14aG1h5xhuUgqjiHpkVMu6LmkJaOjTGyt2cksw/VY39Ry z2CE9eptvfvNmtEE1Yv7O9A68lRPYj8ErAbmxes/K9d5bNbfsdv0EZsoDOSYLljohw+8Sn2We2AC HUzfgOh+vjOOKd+gXJ+b1faN3By5PnJgNtbJcYFYFNrandlIIIsPnKNat0yNJF0kUb62lStvqHln 5NHE5+Lukog2Z4iM4pn4SfwPuKC+rrSD3vY7Cc4EvJBYW5UQPBD75UGGpaCO2H16gBkH4sqvE+yO DfmA8MLo7Lo64ShDkREGFJQJ3W4nZdmSvk1OW514gK42Da4J4CWFLQ7zLxbs3ZWGTK0TMAWq9qVu F38VyC27MOh604WZLOOSwqDr5aQ24bNcO6JeV5ehVqKZzd91MeNf2DJI1+/V9GnZam1W16MiI01E /Qh8bAknMagqMZ6DKzYpy4uGNmrMfS8/Vj56A+WT4mJCvNc+z/WHsX2qEoJIk8wi3r0+yLUH0+/5 +tEXvaoOqjdS/BZkFsgUCbNQeJRmFjuTqXBmvVei/Wiq5GE5PJIDaC4nmF8j2rRy6wRj1/bHsmN7 jZ1xmKzhErtHX47zOLxuKOv+Rhdq+SYIumsSFxnZX999hVdIZEckjjdDE4NMZ0cU7xBX7YeTb+3g +EhSKwh8i5tUOQfgYOdBITiati764n5s/hGkHwXRtzUTbURsmy3uYE7IzAVfrhC48c1ZxiK3/Zrx mAUJ7OgnOAYvENP6QPGUl3M8CEwj4fnk/YZXkCy/QTSkwxVoEeEhDCWYzfAaM7rFbC7NEIonB2uJ MoQpQlZhxsBx8TkHL0ucu73JG8niA+lpfHrwkRKzW0njJrqCIR8iunVhPVJWduZonHB9robbz7fY H03oBSEWW7wuZ1ggZlxUSwBtdnYY9DLysOf2VnmsLk7/+4OmVv52tLP/Haov2zKr9IdGe/MJdOJW ZX/D2vMykdoN4yOef7Epp9kwNhL9Zy7TIxK17ALygv0XbRgzwLTfIOLELeuiHwwv7TcYXlOLcRC8 wBQf7vzwnaSRSSMkLqQ2z2TId+ZVQpkLQV3g+DDHA93eY2jaqIn1AwaHTEWeswrGrcGUI3YVk24v vqofK20l41DTxaKNaDVuOo5IeZtxKw5hBMYMYoDZahijFZdAc40svRoBV7FFAItMsGlNNU5MJkOV HS9ja2/lDQVmjduMCXEmp70pQS+iNZzLwL5wRO4wgLdnjQgwwKSTYNQOpm9yPWoHk3UyvNMZLmB9 eG7tBBZDzNb7kJ+4g0/SNoIHfuKcoG/eSAKbydLN5APyRIT5wNxPZigr8eNtZ4YUQfAcL/S7D3hu rB4whb2VDFzoztk4mtDdy3VILF78eeMTfPW4qnZZwYnoHd5Bch9bRP0yqR7NPEZUqhqOlO6cXgaR RYe74CM8GpvlyqMgKq2qWnFuKiIIKFBB1dohZ6ZEy1MjPv/U3yj1cr04fCZ66TmRm/HK7i0RvS2z g24wg6MED8tQ+cpGhSHaU7+ihImECJOg4sycDNpNMpDCSG7PTwngXPexEM3sVQxjGb1CDLzHULey 0+wWMtkH3X7FGGnCNRMJo9sKa6CAaSN2eBGe46wRuk8UOqMqYLSaS0QpIFSmYO29aCPFy1576H3r XhqPDA9KoUr9s2qF1+57l13rX2Q9QkH8cbOTEWr5/FwnM4yV4UHJOV6g4+pyvuA3OZF2ubEvI7AR nr1WlqDbbjyC/rd1FRtfPChzSzMo80Id4xxWClV4ZoKyLjWrHwR+LpZqyiC21Az5EHPAudaIfYFq 7U0oZ9QnfdRazk8xez3Uf5LPxFnOJNeTXm957V4OAzM8LE9l4StsLyXdwBtjX5BW5eno/Pq99iht 9Ih6qEoqg/W/lfF+B8lTqMor99HmmMycHNwqgIp3yhi/QeYPuOj3vxR+pJdtHrbmDGUlzgSbsRE8 SFOch7FvZaIS73nmz1Qoe5WJKx7oiIQpmxpgN2fhNTOOVpOVutSAAWJZiSjF8GoZHsJM6JJAsKcA r5GzsgwPknivkvBewTK62j5T2cCDWGGd/PWWiFhFPeba3PYupIRl0boe8yQAH2X/bIrnLUNjiCf/ rV+jLk3/KmtQiHnkzhjNbD3lY6VNJ8fJp+txO6MZJwwYgfshBpjWJYZnZnkYgdAl1ZyPWUN/Dj1i pNgZdUobaorh7O095JgwA0a6OXDGSM9wcAQPp+EkWyKyD8JVVurAwPHWAwfPJzbC2baRM7SM7m3G +XZGK24+jAAW6VjbycggIxCM1UARRHvVttW9k4OMErLvgMcFJTsuOON4G8leEgpL4kA7LG3XOrcM HWB4RzkdNF2vd5bqEf3WlCaHQUPk0TMI8+S3w7GP+dcuGfLAEYQIHrTio2YJWe93ER3uennZdcqb i6g9yP4kwwO1GphUly+9Cwl3KhJfWR5Vsbm6wHOKlxGFiObZjKvDVpQfffOKh+6txg3lh+qi/rkK F8/g6m9P/m0svWlBmVp9ry0whVNNHs+nLR++tYnAeKuc/lufMaDXUpK6m+03jAXotSfjAwDmzYKc YxSBG8cwxw7/wy/mzQKK++3/lviaQSYXKF7ahTuBj8QNsjPFwKD7/mJ5fSn65as8zs79C17lFm8L 1jqlGlmbJtl5gJFk7BdH0EDzN6pRL/Q3N9/p737vejn/lbeKeWlX702laVchfco1q3CMpwqCjV8p YYnmYUHyqgXuC622//OykOzBeByCnh+ahGzzbvn0+fZ6kDOQjPDtDXRmfRi1T3NRwLSiLHQbl++I Y2cr/w2YWUAeFhwBLCHPPBHGyIPYb55Uh042B7xC/6er7F7mqC8Jm3jkQ1I1q77SnV6jvgsjxK5p DO03aa/GyDuYjOxa5B1ki4ctVnj7rbIyw6IYqUfTLiGkArySXW3YC0SHh0OScYjAm0mg7ojz1MEk kKmm/plUWgfH9ydsaB+B/dzU9puiKg0nGyR4MMC0OZCFI0yIeTG8U+7KJx0HMwjE8CAnzRo0cfFN LDlenhQbSZxq86bw/Gsms/uUpJ7h7eVKoineJSUFxlsW3PWZnc2pcJ638F0RXG4h9gbRLRp1aVVg ix9MSCR4EJ1PLBfvq459Df2ZoCRatUeMx7YlJjNdLCo4m8409pZ4skfsM9d1h2BjT/sQ02rMwGhk OalIyPAGmcFgeFiOKpMW+49mzgz8KJdKMvCMjIXgtTs5JMfwQOwHLUbOr/PddZDGhQ6njTqc7e1P P6VvSWW0d3IYntFeyItODkYwvNCw1Cmqk7zT54bPJ3/if1756c++fZrPx5B5HXwIp6xspbgGIWLB WKkSP72EV8L2xkcG/Rlzc25uRIhoRmfe8BG2L/zjfVoviIPEsIZb3QKwyOF2NpUnBIJbF0/Bmcxj j+s55sQC3IytmXyp8n5Q9e/8xfcO9I+q1+c7N7Ox2Y7nUZ9j1XY8C8X6YOBUISuvsvonb/3k97ly Oyabre/sVKdz5bMB/Sfq0z5V6i80wpw+ebL9VWKqOtNrhm1W6L/9UbGrly4f9ZmjrEY0bm2b1KSO e7npZpk6FnRJrdhGOE0YN9vf5WY0EXuozVUtQulcI7a3b8rSJZx9q55RxCKDqBspmyleWWMND9Zh mIIClhGIo8ocL+LJc1zYonOzlzM4QvTYDrS9VnzEXFJrTM3vo6tRIO0qS6Jl+mzxvXXt0YjK4V09 5NOU/7dwLiXdALl5gAJmCzRGq7mxm0IXDk1jyvdSWsNgjbf+ItYBvVAPqf7Ne1b8RVIJSQ7UmMYb U8KyzMBe5cbwQLz3/OcHXYeridY6Yzzyg4SGfQZkZ3rjmH6Y7SEHPR2Z/OndLehdr832vKhALjzy pdrc4hR3RPkydjFJ8mO3RS+jNdRm3CES0ebC3UC8qB5ZcDYveQunbaXjSlf+9cf77DOyk8XvpXRn kLAGTXs0+wr8e5EpY9/VBa15PCkz5XaQ15CF+DleaMo+09KKdK0pd7Vsx7LPXGzKKHvGiDc15Xe3 b4oeTsUMWszeLlQ/u7HLdGX7/bvPKKDz/E7Eq3UHec+Eopcd0cZc/sUpF7dDvNQQI/XV/e09Il8e J0JDtNk2dl7nDjhUZROVkkGU+ExcJSe8IPDbonhh37CjeNlKFq6+bqWjRPHghPK4GdErO5dPod8U ZX41BiYjtJatHVMBHC9wwZqNnIPLGlZNeSAKYypD2DD3lWW+tz7IiDPDA9VvNVL44lh8rykWPuiU 811hsxkvTYt/swuZuEx8WL9bPKhvBnipshTJtjHXiTE8EKthVQJUiVEjM44ZTRmxvUmEiJMIOatU q0C1H4NZ4YxlsAT/qPo/10x8Vr8y3ojiLyzUY/vQsRLuYXhNojrRowyDIC4Wr3BK2ke4V5hG7uUm OoYHtuikzPn0wZsYBJPkA2F/O5gi3/Jhem4prUUM7ygDVY6vEzzQ7ZtxqkVjwXX3qaxp0LVyydX8 e+uaBmEowkzjqBeO/qvtlOECravGjm4vO90RJfHOEIdXk5pBNLrrZTAwAn6+Ux0kVULya0RvcEWP 82ZzN7CVbbxEDkAAbUa1hzT9LJtvXnmjkT23XGpjCQauWQObyIe29+8+l579Mx0bhllklLgOSoyE 4MEov9GRBW1cq3HqgZ1gG/XRnGMxM3WQu4TdVyehuszFupwDq5gnyWUuth7kliyhb4EHFiQ0jhgM Dk2I62B4aak5vJiSHeUiSQpd2BPcmbbMRbSGbhP7beIsCB40TLNXjeZZ75uBIfOGdGN9PT4yt2n5 REJgxEXg5gvJJRleWmAUz3hMggcmjKHu4t5iL3fmRMjO7C1OZGce9yR4Mp6gMgvm+DNcJrGO5iin BZiGbKU6SEiPAOLGYud4F+ablt7j5obLi2O05h89i5gyHrdwSrcgu2wrosVhpAhjL+ZDE/VohbdM 2+4UcRNlIQH3NcfdjmYmXzC6/iXnJkWrFJuY4MxYEjET1J05XR/iMHB+dYyQk2Q5gx0ED1l8JBeB JfvLDj74ahx2J9nP6o5oq6a88MPZmxuhA8JYitPgGV7xvcvmeN5UVJeMz+GCPxd+RwJ9UaBp01ku tEsmk8SR2ceVmWcUqfk0XtV5TM9sSyUrPSPKYhPkHho4S5ClM5FwxwSuNhfe7gkeVqG0+0PQY969 ajIPTxqIgpOPwGAKQl/dyNwRwZPQ90XzFqUeki6Rb92ZXAtELzx+UeDD60hSRTK8bIcfmp8928Dw AslpuYeWQx4X5slbfZQ3tAirzUUOBfpmt0GJKoBqtZGs3hpRZrzFISkWAS9zzHiLQxw9wQOx32sB prmW8hoHoez1foWOpZFMVL9aWIDxLRD0HiWJYSr4Ku09Hk++ml5u0qHYCLNwHAldIR62MbcbUchs i4kwwmv1wra/nktIxaxGjLPZpIbGjRcynCbPCQzNRD0cZJfj4ea23TYyWMrUu8xcsMcv8Zaby4ez nym5O6mpWNPBO55q+b7F8y95S5o3L7AT4GxnzreMJREVROIbkSvkMF3FGC79Ih58yjYGzuqHFQ8h 4W7tiAOyy1mdAnZm751JyJyiNps9QnSOOs15jzv5Irwq4z0e8I3bgE/fxgpXUy7PflUqddDQsqIJ N5tyya2QQcolvWrogO8P6Nf1ox9h989wPsqX4mqsSvl408q6XArdYxjZjBp3J0ZJLtXJZZ8ET3Ip f3ZYIrJVjicVcrnt0zIVcfuZIP465lkf5ICMED/HA/HKcDwS7ERxp0LyKiKDwEldZ5lGY7a+uRRS oY7iyUk/IoXw4nTvTXQ9/3giVS+Oral0NPXFr8lVEW+HyzYi7CyzYOQEkvcT8YjvLEgIzEg+wwvF rXL314fn7FkTmbS12Vm9mozb2uyBEzxQr5p5Utl6P7LissZJBtGZ1u7sa+U7bG7ndYK3KKbN8HyJ 5uE5OukIAZ0YsrfWZ+NBAowyZ+g4kSoOdTmdDL15+Z1CiNASpSZ88TtW6uvPkuAk+cKotZUuR1er /7kUHFe3ctIzzJ0Ra54djbBioeA+cuJ2keywHGny4axOzNEUzuMNplIi+pjBGuJZ8UCqpNoED7Yf mLoNsjhelFQWfGSez9s8RW79DfIU0ezAOy5DoNWizfZ53kfnWZ+5gqNvMD5gP4oj6q5n96dcFx8I dbwywlzBIbjOIfij71iMXLCAalNO3OfwaU7yUWI3g86X7VhWjhQf5eZXCvvNH17m8iJ04ThcDfuk iIgSeeFzJA93cETQwNFV5+uJfuPwAwqVq5GKCVuOBlL/w2WiesMJdMEmQb97laEOxG0hKUXuJbSP KuwuJ8J1AAk2Kx46+PK/Gr+aE119h8dlrEWYZ0HWXQYQaoGx6gBOT3SZEYBM6vComaEOv2LHF/UD xUsrla42xKulSmN4kBVcuxsgHKud+DACQzdj+Qw9w1YZnimoGR6o1exZ42qw4b2uRDMvfLKP4BMl JVovExkEr/CRu/ogPd0pnvPZhefkBnk1zwEWdixDlcdtQYiWgkeyQc2plueAxzpIf8acAzYVkl4K nRla5yEDd9yjMrreCtGJja9QCxhdxfRIajLiEbXH1cYSm0afNDqRIqPHVMDIjskOKMwoTGdKiEXd dTGxQUoRKhZOTKHMoHzIGMghjG1bSaEpYDZjY7S2UlhQ6IzXchitnQygUMBsWifM3MvuCMMLlEB9 qR88/Jqf7E8+NsiA6vxjF5Szw9KnXuQDMRQwxtUr+EBcIuF8KvGBGlb9WLVvDanv8DWzCkCaIAUP rHaoXJZ8RzZTGHvwNqlzfGORsmgj6CL8PdaJi+vH9oluvfnlFzYqbdK171gA+uKZ7ekr7EXgQI4E YnxmZIbvHXjB+fFrLMr502Q6MtYnoRHhTj+x2Mn3nNJnPLDK0v5e3vp1gFdQejxvKdrB+a7h8HyW +6RtN1o1pbADgg1jiQcThngBqJGdTzlKRBxug7DL0cuS18YGm8epPdkbloLAm/3QexNKcx7VLafH KzxH7nitjGf2RHXAG6eLc/+WwRyGZwYVI6qj+vKz6tBHVZyTdIkDZkGvalMrya+Y3h2a4/OuI8LF gQPJUogwMuhneGYmjuEhmnpqS1vZvewjMvBCYnvZR2R4AbG+wafUw2/awYjQo9nafXRtq5Soq5WO ciWKpF9oQTjjXUCXDXximF8yGOLbMmRAFN4eoWF4kIF/oVyT8VXm6tQzxhlb3jLNL3uwvDvItShM mzI4Q0ypO5gcgxAYaGfWtXkM/CiTHpcRG2PsUYY+KHRZdWKzmB6tuWVDmDU7TEzVG5+f4tom1Z6P wc3Q/s/UqVZfHl4rmqqZ+llcr+RMfrzAye8lV198N/rv6iMU3YP7TE6dh0LrT56nN0olfbk1pY10 6qYduwH90fUdO8DRPnw/wvliG+r34rwcWPAjvsXXWJpSYfZBN6CgjPUiyol3xN3UfSchBB9Z+MN0 9cjwbBOK4IFLqkY6YSNvUKpG6J/pfwdba8m0OEyGMfwkDn7GNbcRmNmlixgyDhBLGmuhp2lxRulO mNXs5cjL9ZiP63QkeeHMV8MSO820JmRKY4e5OZhKmIBnuHO2+MF0mBmevd0+0QQnkHhcRPIXAgnl U8WaOxpVytLJbdy/5D46d8cZfCGRqDW3iTktm6Tr24w2LgPcB2o7BUybuMOLWES7l0vCKK1loa09 9FK5QYJXYuZgGnkEDxqhmmB8d9IkCGcxdCDNIY7+MPdoY0B7WtYswyF58rnyZlmHkxRz8n3T5vWD D9FqIWX5PePbIFeWM76VmUx3lOEPhgcpa6QszQxNtnXYQY+W2RY2LWEZmNQa45hOwY63ly6nYP1V mriAw3Y8PIs909Vdy52ZNtfSP/EF2PluvPASg7WWkjGlU/VWbH9X55Kgp+NVmL4LpqTpZz1lnnpM 4CHTs8T5vx1JWjN5MM/aDrhZxCUka/ZZXUzgbTIryBHY52/XuDGpxtXG1bOA7BG97MYkHGRHbkAB 0177UT7U5tFlirzqxiTOZfT6YnR/hZKuD+q4jDgGmM2IMI+pB5nZYcsPkoQxm8dNbsnQAHbPi4VG HIb5ytxt5BywJT4Th1aQ1wrZC8A0GyieDHEyPLCB9cJt/rTZvi0LAyRdawZpXzFJZIQBiifbgAwP Swqq3jyJzveKcdwduQ5Dz6c2lkbVNeIhhS4rLHD9+VU5iw51hLMZxxOdpGJrx+WckbXnO84YNi4l jGB/RsBa74vavcz6UkGljZBobGvmBSheRq7PAM1OCwXMJjDGzIPsC1Po+3fINQq4aeZBGCLs9aN/ eVnzGE1I0JRKemTi8ND5RRtOvnYdB4pb7Z0/mOOBeqW1NOlEqu+C1Bw8w9mwxeNhwcji0wfjKF6M Piwe26b2Anif3npZYkwA6oWEWRmk2aUmqWff4i4Us83yMHg+ZxwIm2uS3+jFRrRNY+cNzzl52kTw 6e4kyf3h/wGOF5JICmVuZHN0cmVhbQplbmRvYmoKMjYgMCBvYmoKOTk4MgplbmRvYmoKMjQgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDI3IDAgUiAvQ29udGVu dHMgMjUgMCBSIC9NZWRpYUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iagoyNyAwIG9iago8PCAv UHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDggMCBSID4+IC9Gb250 IDw8IC9UVDYuMCAyOCAwIFIKL1RUNy4wIDI5IDAgUiAvVFQxLjAgOSAwIFIgPj4gPj4KZW5kb2Jq CjMxIDAgb2JqCjw8IC9MZW5ndGggMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4AbVdXXsct3W+318x/Ui7SkV5Pndne5PHkdXEfRonsdj6Iu6FREmUYmmXJkU76v/J/+x7MDgY zMwLAQOuH12QIpcvDs43Dg6AH4s/Fz8WJf51h67o27q4fV18VxyLL57e1cXVnflVWdxdyaeeVMN/ 8bWqi74+PGnb4upD8dtL/F8wSvO1LQ91cdE0u83lh+KLy8vqCX5eXL4p/lJsv356+QhAdbH9wn79 w6PiwvzguX7zp0dFsy+2xffbuqya7/G5tn20+d/i8j+LZ5cDvamU7Oq+uGj3beFRshkoqSulwH2D 4epHRfJAlZ0yvvYlxtm3ezvjvc54+/dHxeVf15J96CdoPv+ent6+toy7XUGqJ52q7kufVh9doY8f M7Fb4ffIBx+7gHh7EfwLS//xlfvRlf3R6XT7KmHkzVLnqkPTmZF9SVude6cD6siYndG413laVVe7 w2Is0aotiF8v7bpuBoGMpG+MuWzBnxy4HYeD9d3cqoR/0m9yRV3vqoEJxMiV4adjgjCJA6n3sNgM NXKzu1NXcqMkbBI8R/mkLMu6uLyaeLOmsTq9EM8deLhePk1bz7VnEDfk4wxCNfTkfqImcntyk3Pf XLyE3QwC3Wxv3Z+oGDKl0DblPiQFpUaHsKMX2yR1Ivbb7spqYVPWft083czUkI+v8iy47btmMZqx YAyxXqRt38/hnEhvlUVuFj/gu+QY4zluExX6XmOM71tVXd7enu6v3xbuv2rkhRtcfzJ8ZLO9uL8p Tm8KZWjxwbnGwUWqoN/qJ46L+Qx/stkWb063hX7+dLrRoW71T5UsRTgd3bj6q+KZGX+z/W+14OL9 jCLnufQXTxLYqRo3D9lV2XfWrtfEbAuHvIV5DCMoD9lJanv5NqpeSqkn+EqSqwsKCB5H1JXiHUJ4 cfVneLXEXkYfXJoKWxyDCbq3p1f30BKxgBSn7CeW1a5BXKADbbaKrwOq51+bfFU9kk8zyDyy5cXj yjgHIXqBd3oTFR+JjtXhgCSLAsbFR/BqpNccD+JzIfXH+wQzY+h1twuiq6zcKHP347Rm6jM3qUuR etfb0cfoPaxFnDA3ZgH0mQVFwMrrfYOINVVGm7d9POXIte7b0Sw3/rrJ0bpq8VP3Ove54kGu6qfV N9/efkqT72a22Guq1mpjkMNhqokzaZDJz9lqJXa6h42vd3dYiGI5OhXUTAfWUdhKXsTwwNdvNG59 /TyBn3b+u8OTzqyezTfNDkko8KEN3qpVcqFtlTX/nTq0OR7olZSq7nqMv51nKpvtDwlTICbf9IeF m37IiqY5NMiYpwx3+ZV6DFXko35zrfmHfkL/P0tRk31J2+1imh71JX40a3dVSNORST3aRDSdML7d y8J0yiij6UjOoprD8PoqIEhozs39S83A1I3bsJ4Sca1T3cwWW0PqVNealI2p04v42pp4k6oqxacS QMxAFUPJ91LbzVCS0pziMynsNDAhxSE1MkbY3ug0ISxBVBRPqjqBiapJYLkUX3kw8MNO9OBsxNZl KVGZ4EEqP6idpgQkQmxdmeyWgOdxFuUZcccM7wYluIiVMgIbkzgQQMxedfEnlZmqYG6tqtsTVucv dVH2keA3Id754ht1CEr8J8gyZ6lb90o1SV1u3WI2ZeVH3FpTlrJewRzm6AkaQvFMAk3wINBLu+yR sm0OK5oaNflzEltLrYJNHsSeFi79GqKMkk2UvOn6gNVgGNVpVXZvqbYqgjb7XlLwiTK6zC4xfgay +6avR/qnyXhedt8cams4Z1K6g8lGiNKZNVvELREtbkuTJjPAm6z1TFupdBYzvoUGZFBY76wvWwDm pTemwBkwBdXNo66U9AeTUqepaPgpwGbFNtm+G1Vssk82uKGU6ggvQLV7s4aa2IVNwH9+9zFegyLa 0ZWe35/aQxbvu7KTVJVpGzzOet0YEsdm18xVA+7GxQsV4bXL9FCAyfFuVS17LBWGI0sqHUUVR4Mh 1h1Zm5hVV4nazwbLD+HVsI6Z4LkQrsRrbnyT4v+tvgRy+qo36+XJeNZLX8X9AIkt1cHoIgOM66LF 44ZTHcwCiiH//O49spuIYhJi62ovq0YGmUysv2ocdgsZHjRdU+fjWK53Ch6NrIFIWHeVZEuTCVhn coXxIhwhrqTetSPgGVxJvTtIZAWBxPY11chNv+p+Z4mdg+flirXT3TkexKee4qVaITQu6p7AYanJ BaTXlAfiPEwx6d1HrLAi4iMKjYQ0hJis0CFia1PZnqia9RQJSRejtTUlFgaYTKtvfE2r2jD3+ylJ FyOwM2GQEOjHLexiT1fuyTWrpt9Z21gQrAzI9QvNQRoAqF9IEBbxC21pdncGXpzBL7SlqX8Dj5ia WtgvmN51ZuFGRJue3vm613amqkrw/rJxnmOmJ7wcxXi/760w57zKc3Nt38rKjPP+zdjCoO5ZA1dK TxMxoyH7Q44613JYkQ7hanhHlw8iuYEloSXJ7T85dYBr3LVPDsU2vcaw8aVl2hnQJ3SwFO1cR9h3 UadrPToctzSY4cu+FmYSMEzv97a+8Oxb3Xl4Ngkaya7iYNYMZBCnAVFPMSZVI+1VWUu9YYZrstev /pjCinl3YVUZlzYBtPmIurTwdo5VfUpoZdII4FoTcCIDl59fPirQk7T98puvvvz2q+cTDn/OyCY6 Ue1NVWtCuStXJEZiSnlvyqkM9+kf/wB1WB/k68qUyBhknMnWQBmpdWVaBRju19g6yyC0No6GAf4m mVLsEhhTk69DSenQ7a3hZraF9CW26cX6p81kh51Y8og+7m98F8+lieNDa4hU5hlg+uwnrSYhAmEE 2JVSP+1c6PCDjaw8UjLVhTF3ZodpQv9aYw4kk1XXyRod0IuQ9iJh3UmCZLUzQZIggjmaUJwkvGSx ojf+h6A7Bxz1a34Ewj66OF6GJ/XWiKmR6delKXowwLiuUTyzNCF4YKdG7ex1W91KQkPA87hZYyHI 8UDsze1J6yUnJXzUhwR1IJZd76WJ/nyWXaNdP4CX0IbECDQd12ck8LAPTHitOhBimwpbymfkZlN9 xk+6CrHfqmhdQjSH8k0YrcLWhZG89nTzwWav6pRnjQ2fy0umHc77XhaJZ7MV7J3YoDT3vJCk1jiy VyplGQDPM+xW+mz45BPsgri1tmrPyk1sowT8+Fq7YMSiOSow+yyf3jb7ALHi0dfHnLY1eShRTU+V XMfARYKrBRPmLWy2EQeDzM1se38TpZp4m3Zo7mCAca5SPLNwYHgJOsoAe7M7ywDzCBxqQQzPHPiK CJ5QaBLluqr6uUgg91nyOTYz3qNrKjX1CmWNWKGgIw4Dz33XNqVeSkwMKx4EXooY5zXDQ12L4/ms 0TRkdLf63e0rx7+xtrEqLGH/BS6TCQcuOHHb3Q9ziDyWQzNhbzAj1DcgKtRoTj+nWfd8iYF+IKy5 GP+BrqHTRWoUoBAPto8TxiJaW7dS8wtwJub+KJ7SPuMMDtpIprnerrCFbvV7gRjXRkbhHidB6YzB XbcL9ZNmw8frgbEpe9u+ijQlnDMdJl3lAhbfVFI9sTKblp1fwFIiLCYG2si+uwFcuJA4iymenIZj CryV/qoMArErEACM6xQjsJVeRkpg3oRxnorjQadUk1yS7Y4I6G/e6Dd+TWJFX0aDM1bD8AsTMT2o q3X3IG0rAaeQ4S7bUjZkCZ64S+nXMu7yJrMM0dZdSNuShRmwNBwoDMbWrIpE2yonzmNpbSt9rkyR wVmNqLkViXYnC3AGnrlw2UljAcMDsdp7cn/rSnZJq0Pr4QMCHJqAiOYV2/dZe8lDllcju52ddMAU VJFdJ6ya9Xu77NUPuJ5FDebL044jOxREpfkJH541eyvu8ZV+56VMj4vjyR2S1N+Pn0SLj7E+JcWl Wu6ko5NHseiWPR71z17Zj4+n2sYznTqDEfrmpD9zvvAJbDWaCZNwbqrfdYci/SCQzOo3OUY9iHpE HivfmYciS9mv8kgdAcHFSFAkM6+wOxPAi/s9hlfLqRtGH3T7zclpZIqbZvBdLUGF8TOZ3HGDxk+1 qs5kBww5twcKHWCSJDLIZGInJPbSqkrxXmYJHwcSJKSejUCUykN4CbV3Iu66NpHuQQQGnHpd70O0 voZyrrckKL5EUUKrF0XVdTrn/c56TufW3jqnZtcMKceKfC3BIQJrgefJDuqDWvQCD7OJ8ImlzaVU d4VPC7y4VVA8OQLE8MD3473uUIiFDE0PeSGiwSkzLt6EPIaodtNJCZKpyzavuNXsTL5N9C+TwH3Q 1Saf/wnYXrMP+onX8bPhjJm9KaWQuUMHnOD1G9ftknm4CNsTUlqZjZbfmdzidNEcz3UmO8egqZu6 kDH7MnlaTtqDG6ICLitPZdpeNinmjLHXmYx06wVUOO1psrW1K8shp9qhaXKePm/GIqncwxHlCXEn w60TaK5dVEKhSpq+qI92a279hU5ShTV8cLPN3x7fSROUkDNO1ukG/OVFVT3ZeZ1cia2z82ohskBZ VfFZq924JUnSmgq8ne841KWpmEwmM3QCgbfjZJR55hagYX5YIgwrDP0dqqJwLlIfvf1h/Etl/3DH 1vCnKqsj+jiGYDD2DSqafgZXsziWZmao6JW1nBwF5uaonFR1uXeHz3UF5RrwUkqxRH2xCSlpDRfk ODmdsLjCqJUQh9vKUmemlm6W0EEjmvtXbphrO50UU0d+jma3eQtR28iGJTOEbQFlWJ+HtK2prQ7K OCmAQhml2jFkC/rNyDu3lNV56kesfWy2bj2aKcTBwfXLFh6hTHXcOs+16WFVmZ0eDq7J0smdFPo/ ywed47QhGzxKPPctwfKixqhzq0iPNKF1m2y9UuQ7mHdEL4hqVzs5n8YAwX1lPgm+Kao9ydNLk18x ljzO2U7C4oszYsUtCIF8DW2REoSIzmzzet7r2rgPBgg7i8iMeL26Ns6B4EFmLoNSHb6Vba8cr1dL qzVVjXQtDrG4M6GRaUPCdgxRYxw3kvUFA4yzmOL1ktsxPBhFRGQMby/HoSheHn176RdheFCBl2q3 K4J6SFAHs9fJ+PAO6OsZgd2BByuV71eaUg7zMUZIJ2sWhbj5M4CYJapm2GshLISo1EjdIu10b48w bLbXYz6RYMDETzR9Z5XuTLWH3lRjMZM5HmaiyaXkElFvQ4hFi5YUcgh4greheLj0j+KBWM1ITzgm nUVsbbIpQqwnU5c55S4gWpyfPqcmtl0bdhrqM16dblSUqn+oZiZ33Pi22R72xNbzKwddWS5s3faR JxSRiI6YzLORnVa3tHarTRdHlRvKID8ZUg65D+uHhj/auI1sLLVu3Nkk1T5FXqCoV3Cw2CkaFoT6 p+yC2HH3SP++cBdsugz3dMSuUbo052cmmhplX2/XyAjz71E3a3kfCDKDGIA8dyspV2kSsVZm10hI XQCCM5GYxfAqqTVSvHhEYHgmwjA8z49+yi7pYMP8rNS20p7EqE0p3bLp76SzjALmsXMn5VCGB3Y6 E1JjUwuNmPG0/qIW6t1hs+qYBhJ2eHJGYl5wq+HKOR6mrMQ6m9ep6y+UBbqiH75utqjG5ARDXGmJ yC2Tm7vR9MkFPEPdy+kRyrcX7z68Np06a0sCTS2tlRQzWf0C5CLVC0G/gBDWex40bgfk/GDWNubU PGVDQmZPzLrppEmQAibz1c8emk72fxkedPwftSDq7Pv0BhyOqi9ZmjW9uqNRfdce2JzQbXZnhO45 Hui+vlcjdH0nNvU3p+tMEQ5zi86D8L/FlaKcX+m64s8DYSSE91JmkabNAUvBNZsB4W7ff0QdMQ18 Qu5uH4gCmdPfy4sAAfW7d2qn4tSe1896I6J9yGkXzvMh2oclQwgPbj/CVktfQGZDmobK9Fyvt1fx q8PI1KtSapkNAYShaG3W3ZLirnzVvQPlfG5Mxg1J4lsx/CJLzPJXVSf3mlC8vNVJtZeyIQXMI3Av e/AMD/zWJcPflK1Ow+fZw0TTV3TcoqNQDJSIezDQ1RXlSp53YHi4KmNBveY8ftrnPpSycUEUGEVH 8ZDBGa31BfVOemoYHgTkOjoc1WO8W3WwAx0zks9zqjM6leuDyW2XeBscmY26HBvIAi4Hl3iGbBTH ux8ahBpza5dwYuEB8i69wiMyIReQZbF4lSbgAaAQo0bn5QtNi5sLjB4sZp9HbCdH0Rk3PXeu3kXW JilJznxPvTHXKTLl9QaRLqgoOLFnbPMGPEpCCkHxpJcsQKwzY/W8Wto5w/k2PNAVEm3m+TYcebKu 7jzKgu3ogGFDjq5w+qPLlt2PNC9QrrnNZ9fhPZ53W7VEH7KbDhXuyw/z/fEvdbXhyFDjc1KU93Wc cmvI1DYO92fu4/qJRZf5pxFFFUKX5/fuNMy/J+g3WSFUlakM9V1lhdi7+4riCRzDa6RbB7sMijd2 Z0NMkVyT4Q1LUoIHpXDM1W9UE3KtHRfXikpjtEU+G/d/xNor06/M8EC9yvKTC+N6wfW47tPP+G0y Q1tGYmFm7izRmmblc54ZorohRks4hhmOL0GZfTfP/6KURtomiPyHC8ED+IO4x2Ymt2MGT+ANxns0 yGDQXXH2RNkSnD3Fky5Phhf2aFG6iZphlR8WgtoE847RwdikDnJzz1wi63ZwQqndQW74YvzK7LLA iWlJls4mUDijgEBNLr7evbW1SbzPR2Ajl66xCUPjNEDduANIKzKugMhs0YbY/zahFEt0uZUbvRbq Ze4tTXbBIVr38OscOqGJh9FqLtmcm8I6Wif1qoPJqBgzM29TqEw4NgdH3Xam61LE7UXmRTZTYdTs w6YjaJkaC1rqOl6NiYh9r6/Y3t+OD/65s27oPtXI5fIdHUBjdWLnMPpbj3qub+NipnQUGLLn3g3k pzi1eVgc0iBYo97rvSYNIpph+T7ijWkQ+BDxExRPChsefQ4Pdq28UJa/dbs8V3aLWC0faWMKd5a9 0VJGltHPk+lXe7nxjOFhNl45PI9anOmCBwmgK6+GBNpLIfGLKGuIYNB3FxCM1JvWC7qulTVnys8a WYEHFEfVIulKJjb5TvIlBp6QL1E8ubuN4fn5kqq5XL1mRbay2CUP1wVGWVyt5fZkYLdRBWHpkmn0 lNHmtoM5qS/MPhyBlvCAridIgFGLRfjAmzm1Sa1zDLGT6+zY/DMpHF525/zUGJPbcDa8K3NGYnvc Y0QnD+Gr9fHuqriyEQNqcQ8NV+0EZlM8ecmFmUpKnwcDbOSKDQqYnN1NMibMmOOBwd9oiebr5wm2 y6jdhdAz2bnTODp37qDWJl5j16Tqh2xPDK0nacfciBHadASXtGHgeSVrHKe4Pp1eJTSlqQfW3C4x 6TJpBQos8k9u3LVJ1+4gvXZC1ZqkKzxL4M2dl89ezQB0EqitZtla1clWJZYrXqegS63VsatD+nTh BlkVq6q9lOcCg7z8dIHy36AaTnt05GtcrJITr2qcOB9GnDMxQeeJUHAnkkQoLhQl9vhqXGwoy24/ XWiSpiIbj96sYiKakbDJyZiIKeXsbvVS8yJ4cg+PE4TOYzSvdIHYBez8kcwG9+rTgRFM4ttqxMGh WiCJPdfh8bq4xwmUM3TszHD0BFVieK10EwWoVXarrqh5y2Ioubc1UDho9lJfk4EXNnH1AkoaSfOJ VaBmYJ3HAjEeBymevH3JKIRKHvXYp9HOHKfQVtLHwOATJEnIbc3D8QwP5OYYzDQnkMMaDDyT2DYk KxB7486vuuIznFqUx0S7cXdoWLtdxU7Vewy5q1xhe5CnVoQ38wwkzxWinZ8TvdnGrzEgioHjZYt4 p+38cQ9HAG3m0+Mt+mXmY4pqVS+HqJH1kGLYYivueP9mUM+xFKWO597t6Ok2DlBHXdYa1liuubWX I45QKlwhxt2c6Hb4BDZZsRZpVodsy8p8TZpFFHVgqYfn16LCEX2z/WxEX7Uxi5d+ocZCwnncJ67M x7KE4X0+oqt40xJzwssaT5wPAxN7jMUVixcIWng+1s5pAZ1X7a472Vtgck/wqxFaO+lQpNDpZz/5 6eh6B9Pn0Hev72BSkeDNhGaCN6U2HrwpniyKGR60T/MY99AALqa2XmCV528qOdQdGEQXmK5wrJ7I ZbP/6kaNGerk5RtcZG8NdaGEWaxqWummD8xist2sGwPqrl14xtSiXpQEErySG3ARCdrP8MyJcpnJ woUl3BTGAFGKHlizAIyzmuKpTc7xPK1c9i6M8U011+9dGBarib0L822I9iAX9lrhT6oYmSI4SK8m EwFmqK49qTZO2GejJO5YI+xzZqV2xnhl+zwKXQWrkbp2Ef1FSl6gFC7zArToWQrX5AWKhw1LU87B VzvjEc/PC9yMNV1axd/PR4+hEtNJr+FskzNzWYyzfWLrDFAWxesjBppKxTYZYNw2ScSoehOKCR40 1+Whqh/K6hXPEIdyilL6H2Qec6VO2e0nOoPbDVEdooBxxli8EK1mzUqhE/IfRitOBT+UVn+dWuO4 FceDEF0ePe+cSm5mwnF0SdeIrAA/jY5jzVmHTTpAQRRzeOVWBl2YYlyeFM9kbwQPk1Dn+Tf1nm+h 6Vm5kSlHUKqP16iwRgye6ApEa/V6xocVV9H4umLzngkf3LF05cPRrRlvT8dxczSWsE2fBDLPFAe0 xg2kTjwx8sy7LVDHs5o/4465Ay3CbaIlrXmUickPWvL9eA2FeEYv9/tsE2LAq7TmCv35UKb7Le84 Z9vKrS1TQFvxiFvM5z1gOyzYiAfYvsu7dn0nl9EGlEN1QpVEo49+VdcCgxoym8Uhx8cT6SQ7Opt3 7A6LTBrS/+lex3d3bLs7F9w5Mv2Ikjg/TqYUuyTmcaE/0lmrC/r+UcIkiAqbZ2O7A9ZoQwrj3iDd xp+NtXCexo6vsJoXZBkuePP7L4e3TS8dyatWlAc5iMKgh2w85ezWuGQfKRYezGCtPcg2bsQ5EFdc ldKhY+mUVcPI2mQDG6kbDigKms2AHBoYeune5HUcXeV8K7kQ35A6B09f4Hik4h4kjgZSn7nN8f9x u+T6DdgMXUJRFPoxfPM7a7LPvkrfS/HDV2VuZJ7ryrqeYW9iBzkfO0VzwfBbpRlvDJtJ/NezPGHU 6FLj7EsXBjVJXP0WAv6PP4L89SqOp3CtzZxDb4a3jH4hFcf5SAkh3H6KP1iZOQ38k/3BbxJkqF7V W+KaVw1wf6we58h41cBXY3MeyINzC1yxlIjYlDp/wVzKaWOKF/dMDA9PGXA8GLwGKNNqNli1xq7b +0yrxj7Scjyxam88HURja9LNg4Mbn1QSK3MZ9xmZtRfzZngg3l3bigWFcSLIEHIWFnjgDOVKNsj2 dH2ftbIYHgQgkJkri7qW23qneM6Z6vRzi2B1KwdgBHxRL4hrOInldSf9dAwPQlMNO97cO2mtCr/o KUQ9kKHnvWFZm+dVKV7e7HupVzI8zJ5Vfby1TjCblrWZF6Z8d4d6R8BEth/zDnc02LgbZpC/8AsR axqxhTkL6IRyD/GmjXm+kQLGpcfwTJBmeJCeesmkxlUG3slBJwaekKwwvJ0U+hgeiH3q9qK0jKSm 5w7cupWS/uZ0xA7SEHbwu1TF9LWxNZ3sjKS8KQ4reYaHKTr6VTCeJ3xoN1G7awJOLKVcTbzi0Dki M5l7WczEhTI3JZ2KTm0UkSeYFZd4DFlRg4Nsi+q7ZEUp60BfztgXw3ptR/Bwh4dmMXPaXeVr/gtd p6coHbGDCp1KnJg8pataY6dsclKpUlG4ng97lH28NPLNJ/3M5M6V4segg5/votWlPHQg/J1rS8KU iPbhzKxknQQP2je+SujpVoTYoSgw731Ep6IEI8K57R0KR+uzbyyaxMUxwCz/XuMtEY4HPnhqOM29 3abevAblzPXtKoETHW5KeQ7pfBMdulAZHibq0pA3OmW0beWkzrjmDjXiwCja9fzQTX2MYQc5jy00 u73kN9wWnETVR6kjnt0/FA2ORMbILST+M2WWiuR668D+RQgw2ToCmRoeGg1INqUszSZv3p6nk0+m 1Y9AbSudmAwPCu7qZqrfKs2f9TlJvMfiVH7V+gOv355VG1vT3xDQxlH58ogdon7XlHPLAY++Hl+a GRsplE/qznCs97mmhAMvx/Dut4wMC3D3KsyTNHLNltOiErTHXUxDkpJRCRqL1b6yDHwYgb2a0BWm vN7y8DqJpBwEEZxV5rlnyzVsfMos4TRmQTYbbF1hNmDmlZw2MvOYa8j2xd3du4SnSUiyUe3l8glh zgI0buoUT05kMTwwWzU2aVHGwA8meTwfsQcTXRieWZJFdI1QOLxCEpj+cnE3LuCGJEa1cdItsGLl gKNBAVUfUtG1S4d6J0+IUNPxLokZTxGt8s51L884M16l580BUxkuuaHQz775OupErGC5f0L2J2ku U5rnX6ZC+w4PZ4Z+KT7grrwQrQk1HKLfTYODDnzyWe6iwZ1nHA/uwi3aFs75NPbshlWOJDZNbyoF kN1iaR0n3+IFVA5v3VvOLKA/IhpHXAmj1TmnOSBYo8t2/2aKIa5j/RPNd4lgcZudjQP+aCZuISJG qGd4jZyLmXqOtV0YvpGguCSp3ERyrqru3XChSaSGcfWorlkhs27R9iyuP+RmGg3mPr8X71om5GZE dYYU6oC7H2YFJGiOW0+qCnm1x6GZWFmYu0eBvnhsk6N75DBPKTC8ZsmaCqh80i5sIHPFDXNSfSGT TYgiFE8Op1G8zLeOqoPcQEIRH+p08PqluE82+Y94dSditmT2dSU97xQwy4nVlTRjUbzkuftuAJt1 AV56usXvf8hyi9hdJwxel85P6N9JQ8qUH9Yt5t1fjS0x8YuDBpyhhb/uTRGPG69bqkvjUE6UwQaY VYe5a0gwVhJlmlJunpHZz/GgDr9keagxr0ZN5fiQG+WbzuxEEkP29DrJIROjRhHrrC5yuB+YTl7u u8jxO80ZfKRvZ615AY+SaJ6ISvOMgVSvrUyqR4S1Ta9QhLBrsyRl2O+uXkOl0yif8KKVZyAoL5J9 cIhaHFcOQCc0xBJVbbtDKP48mNadWW4yzubFyta0glK+ZsXKdt9L6YQRmDz3idx7U9ohePApN/cv 5ykyEkLx6WtrBCbZ3KONc5Fs+iUCnMDWVM+9+a05oCacyxPdmqNq//BpPAmeWLaUzTq0DMmRKnwx TcH7rtRi1wGX5mKX9U2x/YeoZWn4Ke0BLXzdydW/+65dwuF5mYihMjjJPBkc5PVP0jfVFdt/lq9t sf3Vv9hGqqELoJHNTvsr2Z8wnxne76k221//m6kL488e6zf2d8X2wv0OHIWZo0t1CfmFHezXpanJ V95n3J87xMrgeLTW8tf4m0YHt6Rutq1+9Fedn1B88bu7qri+K754iq9Xd0Z6ZXF3Nfzg6XP7g+dP vY1PkA5Z1gWKSk/aVlzLrhSO7XFgFl8+FOh368f/vx//Xx3w4/fu47P/yl9v3he//TUKDX/+fwbJ DMkKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iago4NTUwCmVuZG9iagozMCAwIG9iago8PCAvVHlw ZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMzMgMCBSIC9Db250ZW50cyAzMSAwIFIg L01lZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjMzIDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOCAwIFIgL0NzMSA3IDAgUiA+PiAvRXh0 R1N0YXRlCjw8IC9HczEgMTggMCBSID4+IC9Gb250IDw8IC9UVDEuMCA5IDAgUiAvVFQ4LjAgMzQg MCBSIC9UVDkuMSAzNiAwIFIgL1RUNy4wCjI5IDAgUiAvVFQ2LjAgMjggMCBSID4+ID4+CmVuZG9i agozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAgMCA1OTUgODQyXSAvQ291bnQg MyAvS2lkcyBbIDIgMCBSIDI0IDAgUiAzMCAwIFIKXSA+PgplbmRvYmoKMzcgMCBvYmoKPDwgL1R5 cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSID4+CmVuZG9iagoyOSAwIG9iago8PCAvVHlwZSAvRm9u dCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9HVVZNTVQrU3ltYm9sIC9Gb250RGVzY3Jp cHRvcgozOCAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMTY1IC9M YXN0Q2hhciAxNjUgL1dpZHRocyBbCjQ2MCBdID4+CmVuZG9iagozOCAwIG9iago8PCAvVHlwZSAv Rm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9HVVZNTVQrU3ltYm9sIC9GbGFncyAzMiAvRm9udEJC b3ggWy0xNjcgLTI5OSAxMDk0IDgyN10KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA3MDEgL0Rlc2Nl bnQgLTI5OSAvQ2FwSGVpZ2h0IDYyMyAvU3RlbVYgMTAzIC9YSGVpZ2h0CjQ2NyAvU3RlbUggMzgg L0F2Z1dpZHRoIDU3MiAvTWF4V2lkdGggMTA0MiAvRm9udEZpbGUyIDM5IDAgUiA+PgplbmRvYmoK MzkgMCBvYmoKPDwgL0xlbmd0aCA0MCAwIFIgL0xlbmd0aDEgMzcwNCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAG9l3t0VNUVxr9zz9w7E0nCBBDUMWXGGJ5JAwREXjJgErERjOHRGaTh lYRgiUQCCKSUwRiBQXyUlqY0pWIptUjjCBRHammysILl4QMqfVAtVYq0FK1FmoUh6T7fjPzBav/r cib3d/b+9j7n7Hvu40wWL1pSgVREoBGcWz27BvykrZXmprlLF/sTfkoVYPWsrJlXnfC7RMTHvAXL KxN+2k5pH62qmF2e8NEu7W1VIiR8NVTaW6uqFy9L+GkRaT0LFs5NxtO2ie9Uz16WnB+nxPc/OLu6 Qlr5pIcE/pqFtYvpIn2QtP1qFlUk85XEPd5D1a8qE3+MSemA8SysgIuCBS+CyADcH3q8EjNf5hx7 96PhM7uO/lRleJi49ejaiDFeyzs3pmPHlSZPi7NFXIf5JiD97KYrTTLntI4dn53yrL4aMVHzseJw DxzXaUWUjQ5o5SI1Vopt0VYkDNFJdpBXyHbyM/Iy2Ub+m7xEfkpeJP9FfkL+k/yY/Ii8QP6DPE/+ XWrU+Bvtc/gQ5bBxjp6xNc7S/it5hvyAfJ/8C3mafI98lzxF/pH8A/l78nfkSfIdPIpMme0dZMk8 b1N7W2wX3qL9ZpJGeYP2MfIIeRiHpNdvaL9OHiIPkq+x9l/TfpU8QLaSvyL3k78kXyF/Qe7Dy7hX 6tqX8DrflPmNohHHS0iXSBw96UUk8hL2yv1gM6KFQdGMovFzDBHuwSPQ4zqxG88gX/J2Y4aou5m3 izO8yFpjeEFmtBGj9gKasVQ8o2mhmak5OYKJaPHMTM+jWOwd7PNT8jnyJxxzO0ZK9Me0t1H/EWd/ lsrW5HhbMVaytnI8U6PGD9lvC8aJ/QO5MhpN7P19zraZ9vfIRnMf47u4XbiJynfIb3OEjYx+i3ya cz7F6JO4LPlPMGcDo4+T63lNo8xZR65FP8lc2/mxnOsaKo+RDcl7pwF3SNzcRxr1stJmheuZUc/r ZhSN1bJ+pySympHVaJHRIliFx0UzES00K7wK38Ro0UxEC80KG8U8rebp/AZZJ+8Rk1WX8DiPUTSW U1lGPkwu5Vkvketv+tdiEQqlZ23CY0+jaDyEGl79hxipwUJefaNpiZjaFuJB9JG+JqKFpjajaHyd farIeWQFOZecSZaRXyNnkPdjutRm4356xtYI0w6RXyWnkVPJKeRkXqlS2iXkveQkciJ5D1lMTuj8 s1R6F8cvolLAZ/xO2uPJcWSQZzOW9h3kGHI0OYocSY7AnVLt7bSHk0PJfHIIORhDJWcQ7Tzyy2Qu mYMJEh1IewDZn+yHvnJX2nLXmetlbC1VGTubvBVdxc6CT3iL3PEaAep+TBW7N/O/RCWT9s2kb1zi PriJq3Aj576BWb3InuT1SXplvXrI7pQtdfSg1h3d5Mmz0Z0zdkvGjKZpa9nPTI1e+bqkQvN0pVNJ I1PJLuR1ZArpId0YJvkOjgltKtyjxDNjWny2zI7pkr3N3CWz5OxniRpBGp6S4xk5YnK0yOGGUvc0 bFC1A7+QD76QWf6vk2TiAo5iFNZY6+S9Ow2tKFPnsUttxHqVi3USHSXv9l04KMdw5GKW3i457Tgu u85xawYOi1eJwdaN0k7CFMlqsiwrE0vQqjah1Uq3xqqd2GI1qVVyZaajt6uvZF5ESO9BNfKt51Dm esBqcAO11rNYorzyNiqzxluTUiw0ui5huF0ke8QrckW362rrrLsMBapNRq/Cn3Aaw6zhmIMN1hyp dL86rvaqk+p9qxRvqAOqXR21J/Brfgv2wgW7FXstn7zb9orvw1jtSsYniN8b/aV+c1SqjfZhtUXO v0TO/gIGYzOeFn2zPUGqGKwbkaulcvlV8hX59teNouTb9WIfwJMotY9jumrCEmelrJXE9F61C/m6 0a5XB+k3ymzd1BknEyNcAauvUyY7yTk7Zo2xTuJh1FuXJHMP3rM3WNtlPbrZTVa9mpNYE0yyS7He 3oAesjIBaWfIFeltX0Sp2mflwqu3qx2fr439unXWSnWKUG6fVxdUm5PnZKtddpsF1KtWZxjGqHYn X+13Rjjpspr1so776xpWdcquNQgDgKDbsV3aUsjxe2NW9t3lseB9If+hcCA35xrX73X7YyiJpS33 xzs7S0Iunx2O2TfHdLYn5srOOv2/gqdzc4pLQv64chcWJIctnFUg4uSQzCB/RpbpCgty5UdrTnEc TknoRaWeCMdVZ0McBZkvmx82M8sk7Mnx+wvnF8TULHFSckQYEBDruhx/kdRRVBrKCvuj/ujd5VF/ kb9qdrkUxlYCFdFwnpQ4OTRfOCUUiAXDvqtmRTg8UsbpYsaRLpIeDcsIDyRHkJZS3hVJSs0p9sd0 n5LQfaFYpMAXCxaEfYGAvzDWUhKKtRT4AuGwZKVdrVQqXjn/hmTN6VJz2gCJd02MImsQ9MUQjkbN mJNDWYFYJBr1ReU8kn4cLdcICtcKwaQQhxlDVqIwriIlMpg0WQGfEbICWQGpM2wW2WvWvlAqDYRz XUdRqZvl2Tf/VfC/F/lvzJED8gvucwWy64wXxUJlxyZXpb1N3sdu9AqmuOAoj225kHfk1JHB8J44 cuLIoO4ZgYzsQEag0oX2Wu1rP9OxyZ3e9skip78MIWM2q7esdlcAXdA96NG/TUl1ipHqPfGB6X9+ UPeht+UP6Xl9Dyfrlj7NzXUrnv/Zirqd1uXlzTvr6pqlTLmxzadjpzyF/+1j4msYULJ/Jc7IkT0C d02dNnHilIGTl1fPWbgA/wH+KSIaCmVuZHN0cmVhbQplbmRvYmoKNDAgMCBvYmoKMjA1OAplbmRv YmoKMTUgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAv R1hEVURJK1dlYmRpbmdzIC9Gb250RGVzY3JpcHRvcgo0MSAwIFIgL1RvVW5pY29kZSA0MiAwIFIg L0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMgL1dpZHRocyBbIDEwMDAgXSA+PgplbmRvYmoKNDIg MCBvYmoKPDwgL0xlbmd0aCA0MyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB XZAxb8MgEIV3fsWNyRBhZ+iEkKpUkTwkqeL2B2A4LKT4QBgP/vcB6qZShxt4733wOH7qPjpyCfhn 9LrHBNaRiTj7JWqEAUdHrD2CcTptp6rpSQXGM9yvc8KpI+tBCAbA7xmZU1xh9278gPui3aLB6GiE 3fepr0q/hPDACSlBw6QEgzZfd1HhqiYEXtFDZ7Lv0nrI1F/iaw0IuVEm2p9K2hucg9IYFY3IRNNI cT5LhmT+WRsw2C15bKUoY5u3tuZ/nYKWL74q6SXG3KbuoRYtBRzha1XBh/JgnSeAXnBNCmVuZHN0 cmVhbQplbmRvYmoKNDMgMCBvYmoKMjI0CmVuZG9iago0MSAwIG9iago8PCAvVHlwZSAvRm9udERl c2NyaXB0b3IgL0ZvbnROYW1lIC9HWERVREkrV2ViZGluZ3MgL0ZsYWdzIDQgL0ZvbnRCQm94IFst MSAtMjAwIDQwMDAgODAwXQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDgwMCAvRGVzY2VudCAtMjAw IC9DYXBIZWlnaHQgNzExIC9TdGVtViAwIC9YSGVpZ2h0CjUzMyAvQXZnV2lkdGggOTcxIC9NYXhX aWR0aCAxMjkyIC9Gb250RmlsZTIgNDQgMCBSID4+CmVuZG9iago0NCAwIG9iago8PCAvTGVuZ3Ro IDQ1IDAgUiAvTGVuZ3RoMSAyNTk2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdVW TWwTRxR+s7t21sYQJ6JpgvlZMzhKiIPDT0lDM7CxvUnAQB2Iyy6/tmMHpyVgAaUph8pSlYJMqYqE 2kqtKg499FTGcAHUQ5A4cCBqTwipgJDaSyVQT5zaJH2z66QJSnvv2Nr3/+Z7783+nD39fh58UAIZ 9KHRTBHs5WlEsmLo3FnNkaXnAKQwXDw+6sjKIIBy5/iJD4cd2dON9Gohn8k5MvyFdGsBFY5MtiBd Vxg9O+bIHj9S9cSpoardI+zu0cxYdX94jLJ2MjOad/y9gqwrnjpz1pE9PyPtKJ7OV/2Jifiu3B+9 R4T9E9tpGaqQkcgFWG8rJPBDBHpRHVLu2BphdwF899FPg8dqu19Ck2qrr+/95QPB3P3965GZqelh DdyiTh9IttnO6x6eRp03NTM1M+1N2TtVjTaR9B+T48Xx0vjn49fGXfksy2XZUJZljrL0UXbsKMse YUePsMMWO2SxgxYzU+xAir2TYtYgSw2y/Um2L8kGkuzt3WzvbrZnN0sm2O4E29XHdvax/j7WG2NG jMVjrC/KYlF2pIcN9rBED4v2MGhpQQT1daqkd9buuNdA6DJjrc8Ieg1NNda4jdWKsUoyVoKxQm1U G9Tlar3qV5epPtWrqqpbVVRJBTVxq2ZmX4KryUNmhZDPLF6fgMRg9DYQMjN+uW3RFSWrEvyL/SaP r7ISfBMysKrSAFGrrSJB9MbrdeSixtcOlOkY1/eNVbzaxVt+SI1VJBLl8spgkBgj+2ns8MEoSSTN ioqBscMObfAXty+65SvKSmenMaJxGDS5nrbilQ4o3twEHdBUbCyewabYU5w/pXm8mOb/apUIHkcF pBIeYIB34WPXr64v4SvJB11AIQmbIEFWuJrhezgAj8lNaRdJQSt8A/chB3vw1wTXpDG8oh9q7GwL JWm1cgzGyAPpOMmRQXkGdzmPma/Lw+RbsheuYGOpaz20yD7XMxiXDkEUHsED5Tw06RuMeCzao+/Y zrrf2tb1ZufWNyIb2sMtzaF1dO2axuV1/tqlS7wetcbtUmSJQNigvWmNN6e50kz7+9uFTDOoyMxT pLmGqt6FPlwTcRk0LfDU0XP4FU/d8dTnPIlf64bu9rBmUI1Pxql2ixwcMJG/HKeWxl/Y/B6bV5pt YSkKwSBGaEZjIa5xktYM3nuuUDbS8fYwqSzxxmgs720PQ8W7BNklyPEWWqyQlu3EZqQWYxveDepS sS2XQ0Ymx5MDphEPBIOWrYOYnYu7Y7zGzqWNcMQMl7RKeKL8Kd4y2XSbL0dzmcMmlzMYVJaNcvkC r2vjrTTOW8//1ogNzPMwjRu8jSKwxL65DQh3hfxUK78EBE9fPEfU8zSZqsYd8r8EYRQlzrWJk8ws D4gNEWJ9waDAcumWDlkUeGnAdGQNsoEboEfaLC6lhWVi1vJaSlhKs5a58DTFzhrUSFf/5wqNvJTV 2sM4Wfsf4koI7RqXm9PZoYKgmXyZxrFC7KV908eR0TPVZhqVjgj6Z9JYxIhow4DJI7TIl9Oo021U YJIQPnZMO8TRGnx5jEN6qBrFIwbG4hExymIwAqDIRQfM27B55lllixa4uRm2gCVw8IYYDqXZKJu5 Yb4mHcjh+RzWzECQ6xa2z6Jm3hJTon7e+gy3w4UDtKOwtle8Z52xbF4TUjVTCsiWmBYqtF680Gg3 Gvzc7YhiotFuzSQBmHXDXaoegluQBwU5FOvHYKQYGusPBPFw2+s/IAWcAhAGV+cwKQjC9Q8mZ59/ heZ4C0CtmpGPzwO4ICkKNsBqtsVxSqIX1WYgBFWMs1/U0B6WkNfQrHIJ67RVYoqN+H5IaibNU4vi GdKTphiO6LWYL37VAJRU50VPqm91H7jx3Q8QRNn+vkCewi68SvjdBHJJeYhfTzWwWve5ZI8CKuZQ awhEJv3d/knifziJ/40dm+uCdaFgXbAkw9RV8mi6RXn45/qr8g9A8LNCd5UwygXr9FqiEHysu8Gl SLJC3OB/+uTJpP8JJnr6oKsrEtnY4ZHqPMRVmpqYniC6pEvIEZ2Upu9KOwQme03/gU/1xRbaiVST 2jlUyA+9ZzsQqK/W5YZagD4znorvbDuQz+ZGTh4X782/AQF/M+kKZW5kc3RyZWFtCmVuZG9iago0 NSAwIG9iagoxNTgxCmVuZG9iagozNiAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9TWUJDVlIrQ2FsaWJyaSAvRm9udERlc2NyaXB0b3IKNDYgMCBSIC9U b1VuaWNvZGUgNDcgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDUzIC9XaWR0aHMgWyA1MDcg MjI2IDY0Ngo0OTggMzM1IDcxNSA1MjcgMzQ5IDQ1NSA0NzkgNTI1IDUyNSAyNTIgMzA1IDc5OSA1 NTcgNDU5IDQyMyA1MjUgMjI5IDQ1MyBdCj4+CmVuZG9iago0NyAwIG9iago8PCAvTGVuZ3RoIDQ4 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkk1ugzAQRvecwst2ETFAEoqE kKpUkVj0R6U9gLGHFKkY5JAFt+83Dk2lLp6l5/GMPbbjQ/1Uu35W8ZsfTcOz6npnPZ/HizesWj71 LkpSZXszrxbmzKCnKEZys5xnHmrXjaosI6Xid6ScZ7+ou0c7tnwvc6/esu/dSd19Hpow01ym6ZsH drOiqKqU5Q7lnvX0ogdWcUjd1Bbxfl42yPpb8bFMrHAiZCTXI5nR8nnShr12J45Koqo8HquInf0X WhPaznxpH5VpWmExFQqDxZASBk0hc12TFNc92m4tniZVKRBlSYUSGRQQbVl0CwVE+53oDgqI8q3o HgqguWgOBVjciT5AAaKpaAEFiLaiGgqgYd8WCqBhXwMF0LCRhQKcqpBchgJE96IdFEAtFH0EiHaZ KC5FQDQomstCg7l0lKE5AVGpnKE5AWeG4sJ/70nuXv7I7U3NxXs8Z/hI4aXlBXvHt782jZMUCPwA qnS4PwplbmRzdHJlYW0KZW5kb2JqCjQ4IDAgb2JqCjM2NwplbmRvYmoKNDYgMCBvYmoKPDwgL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvU1lCQ1ZSK0NhbGlicmkgL0ZsYWdzIDQgL0Zv bnRCQm94IFstNTAzIC0zMDcgMTI0MCA5NjRdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTUyIC9E ZXNjZW50IC0yNjkgL0NhcEhlaWdodCA2MzIgL1N0ZW1WIDAgL1hIZWlnaHQKNDY0IC9BdmdXaWR0 aCA1MjEgL01heFdpZHRoIDEzMjggL0ZvbnRGaWxlMiA0OSAwIFIgPj4KZW5kb2JqCjQ5IDAgb2Jq Cjw8IC9MZW5ndGggNTAgMCBSIC9MZW5ndGgxIDE5ODY4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ CnN0cmVhbQp4AdV7eWBU1dn+uffOvmT2ZJJJMpNMFsJkgSRkY8lkJSEECGQgAQLZWGXfRTYBtyju S2mtYuvW4jIZUIJapRbrUlFrrbZuxW5aFZe2VkVDvufcdw6grd/vj98//SZ55nne9yxzz3vWezPZ sG7jImZmu5jCxvSt7FnD1Fcpf6/t27QhoJoseylj2tTFa5asJHv0XsaMKUtWXLiY7NItjCXLSxf1 9JPNvgaXLYWDbIlXmLV05Qbk46+SA3jrXrG6L55eWg+7eGXPlvjnszdhB1b1rFwExqt1G94Ca9Yt iqdLHajO/k1buu6ZlcclnvtS/sYSGOOWVwowO/sF0zMZXMRQo+NaaTfTIJWna28b2vf5rxwLbRM+ Y8kGOBh79INtz3N++rJ7r/zq9PCVxg/1D8M0ogZ6oZz+tuHXGTMd+Or06QPGD9Wa4okqeWNGJTAk 7z1s9EpTIPYIsVuIi4XYJcROIXYIsV2IbUJcJMRWIS4UYosQm4XYJMRGITYIsV6ItUKsEWK1EKuE WCnECiEuEGK5EMuEWCrEEiEWC7FIiH4h+oToFaJHiG4hFgqxQIguIeYLMU+IuUJ0CtEhxBwhZgsR EaJdiFlCzBSiTYgZQkwXYpoQrUJMFaJFiClCNAvRJMRkIRqFaBCiXog6IWqFqBEiLES1EJOEmCjE BCHGC1ElRKUQFUKUC1EmxDghSoUoEaJYiLFCjBGiSIhCIQqEyBciJMRoIfKEGCVErhA5QmQLkSVE UIhMITKECAjhFyJdiDQhUoXwCZEiRLIQXiGShEgUwiOEWwiXEE4hHELYhbAJkSCEVQiLEGYhTEIY hTAIoRdCJ4RWCI0QihCyEJIQLC6kESHOCDEsxNdCfCXEaSG+FOILIT4X4l9CfCbEP4X4hxB/F+JT IT4R4mMhPhLilBAfCvGBEO8L8Tch3hPiXSH+KsRfhPizEH8S4o9CvCPESSH+IMTbQrwlxJtCvCHE 60L8XojfCfGaEK8K8VshXhHiN0K8LMSvhXhJiBeFeEGIE0I8L8SvhHhOiGeFeEaIp4X4pRBPCXFc iF8I8aQQPxfimBBPCPG4ED8T4jEhHhXiESGOCjEkxBEhHhbiISEOC3FIiJgQg0JEhXhQiAeEuF+I +4Q4KMRPhfiJEPcKcY8QdwtxlxB3CvFjIX4kxB1CHBDidiFuE+KHQtwqxA+E+L4Q+4X4nhC3CHGz EDcJcaMQNwhxvRDXCXGtENcIcbUQ+4S4SogrhRgQ4gohLhfiMiEuFeISIfYKsUeI3UJcLMQuIXYK sUOI7UJsE+IiIbYKcaEQW4TYLMQmITYKsUGI9UKsE2KtEGuEWC3EKiFWCrFCiAuEWC7EMiGWCrFE iMVCLBKiX4g+IXqF6BGiW4iFQiwQokuI+ULME2KuEJ1CdAgxR4jZQkSEaBdilhAzhZghxHQhpgkx VYgWIaYI0SxEkxCThWgUokGIeiHqDvHTMk7NsfRJfpyZY+ke0G6yLo6lV8HaRdZOoh2xdAuc28na RnQR0VaiC2NpNciyJZZWB9pMtIloI6VtIGs90Tpyro2l1aLAGqLVRKsoy0qiFUQXxFIbkHM50TKi pURLiBbHUuuRZRFZ/UR9RL1EPUTdRAuJFlC5LrLmE80jmkvUSdRBNIdoNlGEqJ1oFtFMojaiGUTT iaYRtRJNJWohmhLzNaMNzURNMd8UWJOJGmO+FlgNMd9UUD1RHVEtpdVQuTBRNZWbRDSRaALlHE9U RcUriSqIyonKiMZRZaVEJVRLMdFYojFUWRFRIZUrIMonChGNJsojGkWUS1XnEGVTnVlEQaJMqjqD KEDl/ETpRGlEqUQ+opRYyjQEK5nIG0uZDiuJKJGcHiI3OV1ETiIHpdmJbORMILISWSjNTGQiMlKa gUhPpIslz8Cna2PJbSANkUJOmSyJiKkkjRCdUbNIw2R9TfQV0WlK+5KsL4g+J/oX0Wcxb7t/SPpn zDsL9A+y/k70KdEnlPYxWR8RnSL6kNI+IHqfnH8jeo/oXaK/Upa/kPVnsv5E1h+J3iE6SWl/IHqb nG8RvUn0BtHrlOX3ZP2O6LVY0hw05dVY0mzQb4leIedviF4m+jXRS5TlRaIXyHmC6HmiXxE9R1me JXqGnE8T/ZLoKaLjRL+gnE+S9XOiY0RPUNrjRD8j52NEjxI9QnSUaIhyHiHrYaKHiA4THYolVqPR sVjiPNAgUZToQaIHiO4nuo/oINFPY4lY9aWfUC33Et1DaXcT3UV0J9GPiX5EdAfRAaLbqbLbqJYf Et1KaT8g+j7RfqLvUYFbyLqZ6CaiGyntBqrleqLrKO1aomuIribaR3QV5bySrAGiK4guJ7qM6NKY pwdtvyTm6QXtJdoT8yyGtZvo4pgnAmtXzIPNRtoZ85SBdhBtp+LbqNxFRFtjnn5kuZCKbyHaTLSJ aCPRBqL1VPU6Kr6WaE3M04daVlNlqyjnSqIVRBcQLSdaRuWWEi2hK1tMxRcR9VPOPqJeoh6ibqKF RAuo0V10ZfOJ5lGj51LVnfRBHURz6HJn0wdFqJZ2ollEM4naYu4wGjYj5uZhnR5z8wk7LebeA2qN uQtAUylLC9GUmBsHCamZrCaiyeRsjLl3IK0h5r4MVB9z7wTVxdy7QLUxZyOohihMVE00KebEuUCa SNaEmKMT1niiqpiDz6NKooqYYzKs8pijA1QWc8wFjaO0UqKSmCMfzmLKOTbm4A0bE3PwBamIqJCK F9An5BOFqLLRRHlU2SiiXKIcouyYg0cpiyhIdWZSnRlUWYBq8ROlU7k0olQiH1EKUXLM3oU6vTH7 AlBSzL4QlEjkIXITuYicVMBBBezktBElEFmJLJTTTDlN5DQSGYj0RDrKqaWcGnIqRDKRRMTCI7Ze P8cZW59/2Nbv/xr6K+A08CV8X8D3OfAv4DPgn/D/A/g70j6F/QnwMfARcAr+D4EPkPY+7L8B7wHv An9NWOL/S8JS/5+BPwF/BN6B7yT4D8DbwFuw3wS/AbwO/B74nfUC/2vWsf5Xwb+1rvC/Ys3x/wZ4 GfrX1pD/JeBF4AWkn4DveetK/6+gn4N+FvoZ63L/09Zl/l9al/qfsi7xH0fZX6C+J4GfA+GRY3h/ Angc+Jllrf8xyzr/o5b1/kcsG/xHgSHgCPwPAw8h7TDSDsEXAwaBKPCg+UL/A+at/vvN2/z3mbf7 D5p3+H8K/AS4F7gHuBu4y1zgvxP8Y+BHKHMH+ID5Av/t0LdB/xC4FfoHqOv7qGs/6voefLcANwM3 ATcCNwDXo9x1qO9a0zT/Nabp/qtNS/z7THf5rzLd479EyfbvVSr8e6QK/+7IrsjFB3dFdka2R3Yc 3B4xb5fM233bW7ZftP3g9je2h50607bI1shFB7dGLoxsjmw5uDnyiHwpWyxfEp4Q2XRwY0Sz0b1x w0blnxulgxul+o3SmI2SzDbaNwY2KpYNkXWR9QfXRdi6Get2rYuu04yPrju5TmbrJNPQyLFD63zp jeDwtnVWe+PayOrImoOrI6sWr4wsxwUuq1gSWXpwSWRxRX9k0cH+SF9Fb6SnojuysKIrsuBgV2R+ xdzIvINzI50VHZE5yD+7oj0SOdgemVXRFpl5sC0yvWJaZBr8rRUtkakHWyJTKpoizQebIpMrGiMN aDxLtacGUhU7v4BpqbgS5pNqx/jCvpO+T3wa5ov6jvkUpy3FnyLn2ZKluunJ0urkncnXJCs274te OezNy2+0Jb2Y9Iekj5M0rnBSXmEjS7QnBhIVD29bYms7b9uhxOp64rHj1La2JgZzGm0eyebxe+QG v0dijpOOTxyK5wn7i3bZZpNsthGbHLYhuy3BnyDzt5EEJZwwtrzRZvVbZf42YlUSw1Z4+MXnWma0 N9rMfrMcqTZPN8thc3VdY9hcMKaRKVJAwl9+7CDFwK9G8vgbhyR2KFHSSkPStYPts0KhliEDm9kS NcyYF5Uuj2bP4u/htrlR3eVRFpk7r2NQkq7uHJTkuvaou6VtLtmX7NvHatNaommzOqIH0jpborsg wlyMQLC0wURW2xlasH7j+lBowwK8LVi/IaT+wpI2cgsvJOB3/QbY/AcEm/GU735RNuRbuB4vtRqq /buL/B9Ikf4PXON/+SUOMgzRjpoReS/rl/cAu4GLgV3ATmAHsB3YBlwEbAUuBLYAm4FNwEZgA7Ae WAusAVYDq4CVwArgAmA5sAxYCiwBFgOLgH6gD+gFeoBuYCGwAOgC5gPzgLlAJ9ABzAFmAxGgHZgF zATagBnAdGAa0ApMBVqAKUAz0ARMBhqBBqAeqANqgRogDFQDk4CJwARgPFAFVAIVQDlQBowDSoES oBgYC4wBioBCoADIB0LAaCAPGAXkAjlANpAFBIFMIAMIAH4gHUgDUgEfkAIkA14gCUgEPIAbcAFO wAHYARuQAFgBC2AGTIARMAB6QAdoAU3NCN4VQAYkgLF+CT7pDDAMfA18BZwGvgS+AD4H/gV8BvwT +Afwd+BT4BPgY+Aj4BTwIfAB8D7wN+A94F3gr8BfgD8DfwL+CLwDnAT+ALwNvAW8CbwBvA78Hvgd 8BrwKvBb4BXgN8DLwK+Bl4AXgReAE8DzwK+A54BngWeAp4FfAk8Bx4FfAE8CPweOAU8AjwM/Ax4D HgUeAY4CQ8AR4GHgIeAwcAiIAYNAFHgQeAC4H7gPOAj8FPgJcC9wD3A3cBdwJ/Bj4EfAHcAB4Hbg NuCHwK3AD4DvA/uB7wG3ADcDNwE3AjcA1wPXAdcC1wBXA/uAq4ArgQHgCuBy4DLgUuAS1l+zS9oL tQfYDVwM7AJ2AjuA7cA24CJgK3AhsAXYDGwCNgIbgPXAOmAtsAZYDawCVgIrgAuA5cAyYCmwBFgM LAL6gT6gF+gBuoGFwAKgC5gPzAPmAp1ABzAHmA1EgHZgFjATmAFMB6YBU4EWYArQDDQBk4FGoAGo B+pY/3/5Mv3ffnmd/+0X+F9+fd6FC/g3hhg7c8P5XxJiM9hytp7tws+lbB+7gT3B3mC9bA/UfnaA 3c1+wqLs5+xZ9to3Sv1/Gmcu1K5kFuUI0zEXYyOnR06duRsY0iac57kBlksTOOcZsY989C3fR2du GLGfGdI5mUkta5VfRm3/kIZHTmN/1THrSBm35cugbeonfaq/7cyDZ+75RgNmsDY2l81j81kX62Y9 aH8/W8qWITIXsBVsJVulWquQtgR6MayFyIW1RNXncq1ma9hqto5tYBvZJvysgV4ft3jaWtXeyDbj Zwu7kG1lF7FtbHv8fbPq2YaUrap3C1J2sJ3omYvZblUJJs8etpddgl67jF3OrkCPfbd1xdlcA+xK dhX6+Wp2Dfsuve8bKdeya9l17HqMhxvZTexm9j2Mix+wW7/lvUX1f5/dxm7HmOElboLndlXdzG5h j7FfsofYA+xB9rAayz7EliIi4rJYjfQaxGAb2rznvCumaG4+G60diAZv90C83VsQv93nldgUjyOP 3h7k5NEZiPcDr2V73CMicS1aRvpcO3mMeBuu+UY7RYn/l5e3mMfpVsRLRIbH7Gb4vv9v3vNznK9v Zj/EDLwD7zyqXP0ImtTtqj7ff9vZvAfUtB+zO9ld6It7GFeCyXM3fPewezG3f8oOsvvwc06fryj1 AXa/2nNRNshi7BA7jJ58mB1hQ6r/f0t7EGvHt8scitcVO1vLUfYIexQj5HF2DCvNk/gRnp/B90Tc e1zNRfaT+C7lcTUXT30SY+tprFDPsV+x59mL7ClYL6jvz8B6ib3MfsNek6xQv2Z/w/swe0n7Z3w1 swZfvHwEvXErW8AWhCf3L1zQNX/e3M6OSPusmW0zpk9rndoypblpcmNDfV1tTbh60sQJ46sqK8rL xhUVFuSPysnOCmb6vW6H3WY1m4wGvU6rUXCyzW8INnYHojndUU1OsKmpgNvBHjh6znN0RwNwNX4z TzTAy/Ug6Rs5w8i5+Fs5w5QzfDanZA9MYBMK8gMNwUD0RH0wMCTNbeuA3lcf7AxET6m6VdWaHNWw wsjIQIlAg3dpfSAqdQcaoo2blg40dNcX5EuDZlNdsG6RqSCfDZrMkGao6KjgmkFp1CRJFfKohqpB mRms/GOjSnZDT390RltHQ70vI6NT9bE6ta6ori6qV+sKLIvimtmVgcH8YwNXDdlZb3fI0h/s75nf EVV6UGhAaRgYuCzqCEXzgvXRvK1/9iKAi6L5wfqGaCiIC2uZefYDpKg22x4MDHzGcPHBUx/iqs/z 9MQ9umz7Z4wn8iaeDVNU6hGa4dpwhWhfRga/liuHwqwXRnRXWwfZAdbri7FwUagzKnfzlGMixRPh KbtEytni3UFEtiHY0B3/3bTUG93VGyjIR8+qv9lRTTbSA1Elp7u3bynnnkUDwXq0ELFk7XhoUw8R 7okHs2FwTBHy93SjEct4GNo6okXBNVF3sJaiDQcqyW5YNqtDLULehqi7Lsq6++KlokUNKIsh0jDA O4ZfIK8r2NZxlJWMnBwsDfgOlbBS1smvI5pYh07JaRjo6F8c9Xf7+jE+Fwc6fBnRcCfC1xnsWNTJ eyloj+adxMfhhQ5US6Ft38otMqPZUX22IdAh+5RO3ltwBBrxFqydgAR7VEcm79HaCYEOycdENnxK PAdX36gHhpJd14TCYBSta/JlYHCrr//lknzUAFxG1HD2mjS4CO25a6LP+c5Lo9z8gvICDYvqz7vA b1QKQ73AeG3/+TplHot4MHAJBt6dTbwNBfkydADJhqiMdqou3oveQJTNCHQEFwU7gxhD4RkdvHN4 rNX+bZkV5A8G1d6Oj5L2b1iUXkFpUZbR0t4hDP7MJtoYUvuVd6tqT1bts2bTt5KbRXJgwBBsmTXA PzwYr5AFMIPQObqc5p4rK5ylmKyNWCiDjT3BgD3QONAzNLKrd2AwHB5Y09C9tArTYCDY3D8QnNUx AX2pzvvtvq38o52sRWppry3Ix9pTOxiULm8bDEuXz5rbcdTOWODy9o6YjIei3bWdg1lI6zgaYCys emXu5U6eJcANXtNMGAY1v+9omLFdaqpGdah2H57Lqj7KBJ/E+oZk8tlFPhk+DfnCqq8TL8ww71J0 AdbhhkA/755tnUsHujv55GKJ6Er8SlEpOIlF5eAkPMrVWaKm4KLaqDlYy/3V3F9Nfh3364O1USlR QnCGsCYNdAexTmHIdeAReSdGh52Pfjk7MDQy0t6RccJ3qjMDU2I+MLcjagxhH9BmT0G+yRzdcE+O 7urr4dfBIpjqfGY293ViLogKkaU5akQNxngNyNGoluHDEYX60DfoQLX8LhjRXZ3RzhD/0I5l/IoC AXuUNQWr0O1UpzaHf1BR54AzWMwHNrJGTdmXcTLi2hgeUqseH0x8GBZc3iK9BVfeF0RSX3cAPaBh fbMw1GktNfF+g2cRlkRNziIVJl88kfFmKdlmqylqLESF+OXaXIgK8avvRFB441XrsngGfLY9asYV 5ZwXyngBRAdJzfxa8HsZLp5n/Tmvpm2IzQxuwdLIL1r9KD2So9bs5h4s/lTeDE+wQhRGXYZs7uJ1 HCevnrfcgrgr2e1DI/cEL+QrgHgV5Af55sAHJvMdxcBmnQPfdkTnhQryDd/2WlX3wIDB+p8LULwM 1rPMawk0YK9hTMP/jeVFxmQNu087mt2n3M8mK79l85VeNldTyrqVr1iXvJZl41nZJcqP2X5dP9sP /35NBZsrP8f2yw+wDM3GOErZjdohNk65nWUiP6/7ATSG/g+GMQvu0/j/6WQwD0uCV2EG/MeMG6c1 G/5DSMus6v/QGJHPgT7nd48m5KTXHTghfyhdJncqBuVGTUjzvHa69hldr75O/4qh1/CGcY6xz/h7 0zJzjflu83OWi1FIi7vh9crL2gR8jp5VslY2jc17jFnxiCeRVUkPPeSprzcU6B/H4xuZBfAAyMAk qS5s08jWIykp1cEj43T7FEfzkFRwuFq/D482q4ffHn6haPjtU87KolNS0VvvvP2O/dMXHJVFJe+8 8s7YMZIjw6HCnSDr9W5dMLNQHpebU1ZSUjxJHleaE8xMkFVfaVn5JKWkOF1WkJM8k2RuS8rLX89V pg/r5B3B6tkl2vQUm9uq08qpXmfBhGz7rHnZEwrT9Ipep2gN+lHltZktKxoyX9c70jyJaU6DwZmW 6Elz6Iff0Cac/rs24as6zYqvblR04+dXZynfMxlkjU43lO5NHj0+o3m2zWXXmF12R6JB73RYRtXP H77Uk8rrSPV4qK7hVvTQfSOnpQ6tG70w40h10vSkB5MUNjTy3iG71Ar+5JAtzlaV/3XIovJ7h8zg R/As2TRy7IhHajXZZ2ojrLpaKgq9oz5JGTumK1s03lFKrfdIHQZ3RrI3020wejKSkjPchhSDRa/V 6i0GzetC8dGEq9Ls0DrYRHbJoVybzR2/IpVxRSrjisCf8CtSbVyRe0h2hNPTTYWFxV40oNiLvMVe ZCy2I1exF1mKeRY7S6+YaSq05WqSM9uSI7p2XHm1M6kSl/8KXX6xo8QeV0UlY8eoTeEdmSvl5OQG ExM9jnON4/2fLidJ6UpSSU7OuLOt1eywelKs5Sm5waDnzNJATaosywaX3+v1Ow35KTPTcv1pDqkq rax4rFeSJaQkJwachslu9JI5rThXPlm5fXzTzVO+/ofeymNk1Wt+OirTlJTnH36mtK+7q2j6weny 43qLUaMxWvQ8apNHTil92gzWzN49ympG3jtss0tTa3iMEAKVERSVEQ2w2os1Q3J+OFQcdrmlqcVh h9SaVZxVbPF5eVmfHQV9dpTy8QD6eAB9j+AvGAx/9PSpI+HYoeQ4u4kftjnwSNVS+KiUy8qZScoJ mx2Bcqk8bLZIUx38L6smrsod5Y7ECUOS5aEanzZvVuKQlDeonc2qT1U7KytPOSori4pCoS77KTvm 4St8RFFvIJEnkIEZSb2gGRcfYTQRC3VxW+eJ9xKfmR53uk7pq9t8R1fN6jnjk8wag8WQUDJj7ZSK rrqs4pnLVi2dWTJ+2XXtoTmtE1w6jazozHpzUX1XVdmM0pTiWctXLZ9VIl0w7+q+4sRApjfbjxmp zxwVTC+fUVI+bfzYkknta6e37ZxdYEv2u8wOr8uZ6jKmBtPSxtRml02bUFwycdZaLEPz0UfVynOs BIt/NByw1fpri2oVszGp1IIIl/KAl/Iwl9p5B5QOSZ+HE1huro1JFmbnk7EqPubB7/F+VRkFOKsd XjUkG8JuR9JTrNReKo8/ViqxUqm0tLBm9JDkC9teypQyMzVp7xdOmfimpVXDihByvt51nXLw97UL uhBxNb7HQwu6KotoGhRXjh2zADNah0UPY3wcZyx+POwl40oLscidXeg0fDZ49BTyxJLisnKl2p7q S/EnjL+ubfL6toJJG+5dti1x7LTKiT3NYy0GDGC9r3b24tKey9tz7txX31/r75xRs3qi12LR6SyW udWN2Y2La6aumZLdWDpjnC8tmGawJ9uS01KCaa78yI7240kF1XmNs2rrMQPmIroB5Vk2jl0xmIr1 61h8HTvJI8XXtcOIFMvlocOgBqsLHPgjvoyofmQAv88L5A7J5rC1KEFKSH7XHzZZm/xZQ5J82DVF +WAs6j5stDaNzR+SdIPGVmwdr4ROqW9SURcNz+MYtcXq2nEuWMXpGJOqGcyESseuQGujEpC1+uQJ LR1FPTcvGlezdn9nqK1+nNeok51WW+6ESNXmnRnhrgmVs6tDFr1Jr/zIkeywJmenOcMXHdp4yRNb x9tTMr0JLq8z158xKuPIA3P2dISyQkGDKw0bP+tGXG7FM9sc7JJXhv3V4yWzr5KPtUoT2l3JZ3gl H12VfOhVPoq/4DFWNKJGrSgeLLAaLJVRSPUjd9GQbAqbXBmN5spcnyYBg0wb807BwNUcSmjVTsXK yseXurZSWMQKixF1bos4f0AVJyadXUOVnJz43FUjVa7cqnekuvlGNnn/vL6r5owq7r1u4fQ9Yb3b 700OOI13122vr+4oT/aUzq7JmBhuzE3GtqLRYIPZ3Dq7dc9g74ZH905uqJPNYk0dbpg1Z0LvtnD9 7kUTnaPrsLTJrAvR2o85GsJZ5oHw6KKy6rLVZYorgHi5AoiSy5WRz9fDfB6tfB7GfHW2Yix8+VB9 6M6QHEKwHkLOUKlmiMIIVseYaqMYmKarhscvIyP/6V2aazXyMY30kkbSaFKL3syZ4n2/O2FNgpxg fD9VHWBd8Zm6dp2YosVvhWiwYeqGQgiohMGVcd6wwgJ4/uCTPbllakD1yv7c5OFYeuOatnB/c5FF b9YpsqI3l81eG159z7qqCWsP9C2/qbvgbuXCzRPnT8rE1pWb0bJldqEnxaNPSHZaXTaLOdnrmrR1 aOuGoxc31K//QYdr942FUxeV850oG8/vL9VuYRNYfyzRjol3Up14Pj6GEC7O6loFoR4pwOpm5EME Y2NGZw+NvBR22rGRZJtOlU1OyTk1pikw1d7Et+lTxdVofeh4yad8VzgeKjl+dhtQVyGPR11/EIfg uT0ai5ZYq9TpppEv1WgNOr0nPc+XXRpIeNZgNmqdtmcNroDXG3AZdtrtfHvYGWxaOSVYm2UxKFqb KylBazQbvSVtVb16R4orK/D1BwazQaPBm+IJZLlSHPquBZfNzrPaLC4fH0eX4GzVpi3C2SqDXXWk Ojg9uDqoJPKmIgZgtemq7VLtk3xRgq3OM9WPgZL4KM7mqcxDkcOXoNRSYDVgYIqkZ0j64mGTP4xB hy8/TjqcbG9WJ9+rp0Lx5Tw+7/go+feTmYsvSohRWUlxojTJ4AwkIwx6PcKBWWVw5Y+vCnEkn23w Xn5mQ4z00piq0XmVAO/3/SOnlW3atZg3N4Ut1WVS3lhpbNgptWK5fEntcAh1VQG/z5dc1UYrxz6K 7ztkMku8NZb4QAGrzQWrzbWgleGUxIICxhvKwqiBJWaataOaUxsdU9UG4yBXWSkVYfHF3qWOkeKT fKTwdp9teK50bmyIw6lDojM71me9JCUmKtsMrswUX9Br053Z++2ISO0GZ3KmNznTY7TazjwirbKa cZQ1aBS91Sj9/YxVxElbwb18LH39srTJZDUqmGRGi9d+5pEz2Q7c+qgx076E1WYGez/sc9oRDBdf V3Ls/JiU6+Xva2ZKja54KMBqKMCf8PGiMl+U4puWi4coPT0RQyw9vdjE13cTX6JMvFKTuk6ZMMuO zOBnvRmTsNepET5v71OrhS32RnXK5j6Kr3QUM7uki7VMwTaoC1trpkxqLKhoLpiafF7k+WofH3Ch ylfooIYbqPiJja/56hfRzhuB/PCg05/XH//moB3S4ynD6MRBO95N2pfQKRieLoM7v76wcn0Dn7xJ GS59Yn5dYeWGetFlOmdqUmKaXT/1muaKzvox9oK2lslZczY1+88OZjlYuaA+qyMyfKXotn/3KHux RCiK0WzYHJmeUlQzamz9aNfExVdMjY/6A+jBYnZj2EY9yLuxulQa/R96SQ0n/GrYwfHeRK/50s18 Jzbz7jLz7djMe8/MO86MXj1C4z3dzqNvKpgyOjmrWYTeWcnDLsIcv3WJR/t/i/U3Q+tRDlBMnQZv YfOYSdv+PYi3tM69aGrGudDZWr8Vum8ECgHq5ishP5e9jQi5WC67N5xanSeNckp5DinHKuVYpByD lKOXRitSniyl84AgCGB1/IHVBQOs7p9qOgKSzrfN9CKTZHLzWz03D5eb79BuJ2Lm5jFzP4LvM+FO 5YiNta5BNyUPSVLMNiWIM9ygFhuqOlK74iNTHNr4KhF/xW8u6JSLgaePn3PFsU15u2r9/etW37Wq rHL9fevB5Q/4Ji2f3rysPsNXvXx60/L6gPSXVUcvbandcXgdeAp4W/Pu3srShbtbp+zuqSxdsJtG j3wPYlPC+g6vGSfl2OJDA6wODTAt8VzwncPGZ7iThbFpMD6JGW82S8Gszg4bQ1NybJ5As4cfvLAQ 8lHBz6Hq0YuPB9Eofqo6f9KJgaBOLp18j6wzGgxJaVme5DHjqoLfnkvZNVWVadaMrDSLRpGU3sR0 h9FoNLgLp5YPR8UcOjcQ9pTV59oUg8lkTMC+KLGMkY/llZr7WRWbfziPOYIF8b5WGW0Bq5MDrI4F ldGhBbzhliRrwalgU5r1VFLTWJwyB/XUlSd4U0voiFl84jgdvDXqXYrj29u//I1DAu5RqPXySoM9 kFeY1NgfTtthc2oNVsN2sQW+y+9TnLZ3yycnZaW6DVqjVjMvLdOeYNRlt6yfJifQ/v+quB1/lU4I Z0xdC40mozbBy0ZGeLuVj7VF+FafE+drPUuU8X0OiofyJuJRwybGimowvb84HEpPD6GfvwxblHGh miZ76NT4cU1ufqjObjXSofoETkJSUfFb7+DsZ3+nuAjHoOLzn0tkONxnW4Zj4HeHQrk3PRFrZxJf Ss8UndfA746GcsSX8vUtZ3vac66dzrQMx3cGBW29kd+JKI9hrbwe9yGlkjmXr3a5fKHLNaCPc9Ud Kpevn7lo/8M0wv3xoQ9WRwb4C/U8wQV/FsUzCMcn5EDwjK6C5lyzNrkZG5b23O0InxdijwrF96jQ f7wdOXsf4lDP1GXlZx24EXGmeZLSHLrWm9UlUe+mo2NSUdOYSRc14IYERyin8exKuTkybcKSK3rl TLGPDP9z+sK67I6IvFF4+FgYN3JauxfxaWBvH8UDnWPhiVjYcIiQWvMqpHLO2YVSToaUE5By/FJO upSTJuWmSqM0Up4iVY2XxldJ4wukCfmSPYDHcvgavnqo5IwbWDgCqMGOlUR1cw5b4LZxt62mWc3H b3Gq7dPtq+077Rp72JnYZC9pzm6uujZfyudp+fwhjt2V2LQkf3O+3ABv0lR1TP62qwvPbI5XV58I dYX4o8BQiAMnL8aXVEksrF1IDuFORS8lKOpDNSVXr8Qlnq+JhzlJrqRyF23250ntXo32zOeKNWlU un90skX5mSw/qFhT8tL9ubDOfKnV8LGcmuk0KL+X5adloxMdgSdu8muy9KpsdGWkePEIVbld77Z9 /RNzgkHRGBJM8j6jcXi9sJQ5NrfeaNbjhshqHE4xGuW/Gq16nNwshmGvsGQDNheJZZ65UdmG/spi M48y38gn4XEYjeU+Kc8nedVjnFfKSShLkHONUkoYSVUpUnIFeHyy5G9ONrmaTS2a6ayF39lgva7G Co3g8EiF8Juh0HOWcheeOko5pfEDkFTi4gtWYqJbL5ds0Y0tTgk4ZN02o10584TBnpWenuk2aiVJ +ULnyAykZjl0Zx6yO7QWd4JUqXGalPkeb4JWMdisw4Xyqy6zFquTE3s0U46odytmPJ13448T8trD OqNiwU3X2ycwW/hd1nn3CFKbuCc486DmRPwW4MwgIoK/Byi3a5NYIftLOCsrXcpKk7JSpaBPykqR spKlHAQkScpTt39nAFv3GD6crDa5tXuMxAIIDcuLr/tg9QygMkYpWJ39YHXS5/FnuQnpXl7Ia+bv Zgcf2Rij4FcOoU6w+gzoPP8xft8B+5OwESUO4Im+yzkkVR8KzszD0qsf5E+DsbQOo9EYpvx1gt9m qrcSoaf4bUSIqT0UH87q8SpDPA3LcOh1OhrD5dnxk6qDH1uV23Umq354vt5i1umMVoOUcJrfUeIp o1EarbE4vU4sF7r3DQlGbb0rxa7X21NczhSHUfndTSaNNT3J4bVbdE8oGjwdwM36V9cYHSnYPNT9 w4mo85cOf2dhszpr62bPDNX1rFjWu27Z/wAxpTJvCmVuZHN0cmVhbQplbmRvYmoKNTAgMCBvYmoK MTAyODIKZW5kb2JqCjExIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAv QmFzZUZvbnQgL0tBSklGSStDYWxpYnJpLUJvbGQgL0ZvbnREZXNjcmlwdG9yCjUxIDAgUiAvVG9V bmljb2RlIDUyIDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA3MiAvV2lkdGhzIFsgNDg4IDUz NyAzNTUKNTM4IDUzNyA1MDMgNDk0IDUzNyAyMjYgODc0IDI0NiA1ODUgMzA2IDQ3MyAzNDcgNDgw IDUzNyA1MzcgNTMyIDYzMyA4MTMgMjY3CjUyOSA0OTUgMjQ2IDM5NyA0NzQgMjc2IDUwNyA0NTkg NTM3IDQ3NCA1MDcgNTA3IDUwNyA0MTggMzE2IDY1MyA2NTYgNjMwIF0KPj4KZW5kb2JqCjUyIDAg b2JqCjw8IC9MZW5ndGggNTMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2T zY6bMBSF9zyFl9PFCINJMpEQUjXVSFn0R037AIBNitQAcsgib9/veNKpOouD9HHvtc/BJn8+fDpM 42ryb3Huj2E1wzj5GC7zNfbBdOE0TllRGj/2653Su/7cLlnO8PF2WcP5MA2zqevMmPw7I5c13szD Rz934YPefY0+xHE6mYefz8f05nhdlt/hHKbV2KxpjA8Dy31uly/tOZg8jT4ePPVxvT0y9a/jx20J BkdMFK+W+tmHy9L2IbbTKWS1tU398tJkYfLvSveBbuh/tTGry31Ds90bHp5HaXm0Nk3ee95PeE2U am69KW3xX7Nzr4a64e6kLJpasrbaNOxXgsjaXUIHIrBUtQI3wu0g3IIITM07EIGFqk8gAoOwBREb eWEHIqq9MIDI2o0TDiBi3wp0fC6J5k6IXwl8EuJXAlMzfl3yvCF67fArUdW+Dr8SNvZC/Eqg9nX4 lbCRluLru3QC29SMfZci7Fo1Y19i5Z2wB5G19ICcgwSmKuFcClhtVSWcxKw+bEU4ibzaqCKcxGyq Eg57QiWqOAWJWXnm3JJArczySUTQoVSkkQhIIu7b35PX1dMv8nal+2uM3Ob0H6WLrgs8TuHtV1vm RQsk/QH23PJICmVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKNDY5CmVuZG9iago1MSAwIG9iago8 PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9LQUpJRkkrQ2FsaWJyaS1Cb2xkIC9G bGFncyA0IC9Gb250QkJveApbLTUxOSAtMzA2IDEyNDAgOTcxXSAvSXRhbGljQW5nbGUgMCAvQXNj ZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWlnaHQgNjMyCi9TdGVtViAwIC9YSGVpZ2h0IDQ2 OSAvQXZnV2lkdGggNTM2IC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNTQgMCBSID4+CmVuZG9i ago1NCAwIG9iago8PCAvTGVuZ3RoIDU1IDAgUiAvTGVuZ3RoMSAyMTY2OCAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAHlnHl8VNX58M+5d/Z9Mpktk8nMZJYsk8wkk50EMoQkTBIChGQ0 AQIJAQSVskYEBVHrhqLWta5Yta0WlcmwOAgqVeqOtUrVuhVbbd2iWLVWMJP3OfeZCQGX2uXz6x9v kud+7zn33HPPeZ5znrPcC2tWDS4iSrKJ8KRkYFn/CiL8+PYBlgyctcaJYdPnhEhki1ectgzD2V8T Ijecdua6xRjOO5eQYrJkUf9CDBO4TiqXQASGaTnQs2TZmrMx7NMB7ztz+UDqep4Hwt3L+s9OPZ+8 AWHnj/qXLcL0XZA/yV+xalHqOu0mxHjriWH6k6eWHaAs/cXCTRpCWMhPnURHHiZSwgGDpI8Q1QCd TERwlV0X354IfX6GYr627gtilUEEIXs/PPc5xicvuefyY6+NbJF/JP0NpJVDDvgD90lvH3mNEMUd x147erH8IyGn1EUB/iE5n+C+iufYHQnuH/EcP+DLeE4R4O+ILxCf47XPMPQ3xKeII4hPEB9jymHE Rxj5IeIDxPuI9xB/RfwF8S7inXiOHArxZwz9CfF23J4BkYfjdivgj3F7EPAW4k3EG4jXMclrGPoD 4lXEK4iXEb9HHEK8hHgR8TvEC4jfIp7HQhxEPId4FvEMPvZpTPkU4knEE4jfIA4gHkc8hvg1Yj/i UczzEcTDGLkPsRfxEGIPIoF4ELEbsQuxE7EDEUcMxbNDoMEYYns8uwxCDyDuR9yH2Ib4VTy7FJLc i7gH7/sl4heInyPuRtyFuBNv/xniDsRWxO2I2xC3Yta3IG7G229C/BRxI+IGxPV433WIaxHXIH6C uBpxFeJKzHoL3n4F4nLEZsRliEvxhksQFyMuQvwYcSHigritHPRyPmIT4jzERsQGxLmIcxDrEesQ ZyPWIs5CDCLWIFYjViFWIlYglsezKqAQP0IsQ5yJOANxOmIpYgniNMRixCLEQsQAYgGiH9GHmI+Y h+hFzEXMQcxG9MStVVCybsSpiFMQUUQXohMxC9GBmImYgZiOaEdMQ7QhWhEtiAhiKqIZ0YRoRExB NCAmI8KIesQkxEREHaIWMQFRE7fUQP2qEVWISkQFohxRhgghShElAngatwQglyBGBhDFiCKEH1GI KEDkI/IQPoQ3bq6FzDwId9zMOnpu3DwB4MJIJ8KByEHYEdkIGyILYUVYEGaECWHEJ2TiEwwYmYHQ I3QILUKDUCNUCCVCgZBjnjKEFCMlCDFChOARHIIiiAA6ikgiRhBfI44hjiK+QvwD8aXwWPp3oUb0 C4z8HPEZ4m+ITxFHEJ8gPkYMIz5CfIj4APE+4j3EX/F5f4mb3I4EfRfxTtwEPYf+GfGnuKkaQm8j DsdNUyD0x7ipEfAW4k3EG3FTE0S+Hjc1A15D/AHxKmb9CuJlzOz3mNkhxEuIFzGz3+F9LyB+i3ge cRDxHOJZvO8ZzPppxFNY+CcRT+DzfhM3NUDJDuANj+ODHsNS/xoz2494FPEI4mHEPsRexEOY9R7M OoFZP4hZ70bsQuzEB+1AxBFD+NgYYjviAcz6fsR9iG2IXyHujRvB69N74sbJgF8ifhE3tkPo53Hj dMDdceMMwF1x4yzAnXFjGPAzTHIHJtmKSW7HJLfhtVsx5S0YuhlT3oT4Kd5wI+KGuHEm5Hk93n4d 4lrENVikn2DKqzHlVYgr48YOuG8LprwCcTliczyzG65dFs/sAVwaz5wLuCSe2Qu4OJ7ZCrgonjkH 8GO8diGmvACTnB/eDkmPaJscn2gijsOq6Y7HQH4Nsh/kUeUpjjjIEEgMZDvIAyD3g9wHsg3kVyD3 gtwD8kuQX4D8HORukLtA7gT5GcgdIFtBblcscdwMchPIT0FuBLkB5HqQ60CuBbkG5CcgV8uXOK4C uRJkC8gVIJPl3NfcUXIKcXDHgEuIg54XN4DLpBvjGawDrkGsjutZq12FWIlYgViO+BFiGeJMxBmI 0xF1iNq4jmU2AVGDqEZUISoRFYhyRBkiFAcFJ2gpogSRgdAjdAgtQoNQx8EoCapCKBEKhBwhQ0jj amZqSXgO8GOQYZCPQD4E+QDkfTDnH0HeAnkT5A2Q10FeA/kDmOVVkFdAHgF5GGQfyF6Qh0BuA1Pc CpKgm1DT6+N61jnWoXLORqxFnIUYRExBNKAeJiPCiHrEJMRErLIRkYkwMOzheZ6Lhx13P8JzZCfI ARCeJ1iWcxCdaPVZWLIOxEzEDMR0RDtiGqIN0YpoQUQQUxHNiCZEIyIX4cLCOxEORA7CjshG2BBZ CCvCgtU0I0zhW6C6IyBfgxwDOQryFbSBf4B8CfJ3kC9APgf5DKz6N5BPQf4K8heQd0HeAfkzyJ9A 3gbrHgR5DuRZkGdAngZ5CuRJkCdAfgNyAORxkATIg2Dx3SC7QHaC7AC5hVmfG0Edb0Cci1ga18NU iC5BnIZqWYxYhFiIGEAsQPQj+hDzEfMQvYi5iDmI2YgeRDfiVMQpiCiiCxFEBFDVxYgihB9RiChA 5CPyED6EF23jQbgRYoQIwSM4BMUeScJ3gpFGQZIg74FiXwb5PcghkJdAXgT5HcgLIL8FeR4UvQfk It7r+DEfcFxIA44LIpui52/bFD0vsiG6cduGqHJD7Ya2Dbxygw1wzoZtG17fIDk3sj56zrb1UdH6 zPWcYl1kbfTsbWujyrVUdVZkMNo1+M7g54N85mDX4MLBNYPXDR6CCOndgzsHDwzyidH94YzB6trm TYNXD3KZcJ0jg1TLol2DSk3zmsiq6Optq6KiVeWruNrPV9HDqyhXsorOXNW3ioNUO1Z58ptZ6opV pqxm3aqSVeFV/MrI8uiKbcujM5YvX37e8q3LH10uPm/5Vcu57XDGhZfL1c0/iiyL/nEZJfu4UaID 2c+NxnnF8r1cEnY9PuGS4VF6BijgdFDE0sBp0SXbTosuDiyMLtq2MDoQWBDtD/RF5wd6o/O29Ubn BmZH52ybHe0JdEdPhfSnBLqi0W1d0c5AR3TWto7ojMD06HSIbw+0Radta4u2BiLRlm2R6MwInRpo jjbxlQ4YQUgO/K3I2ZRzJEek7LOvsHMr7IftR+z8iuwj2dx5NqrNOi/rqixeCwcOD1aH9SrrVut2 q1grnPCqFRmbMrgV+k16rkQf1r+gP6wXEf0dek57lXardruWn6Gdr/1EO6oVbdfS7ZpHNb/V8DM0 8zXLNbxWw8K8LqwJlDZr1Q51eGpQzdcF1fXqGWr+KjUNqwOh5rDak9dcr5qhmq/it6poWOUraP5E Margwgq48Il8VM6NyinhqZPCPpQOwMuYjajR0ZygZIeJimmCXj3U1en3tyWko7PaYrKZc2L00pi3 kx3DHbNjkktjJDp7TvcQpVf2DFFuSlcss61jNoYv2rKFNNjbYvbO7tgd9p622CY4CbOTUTgh9iET aejxz1s9uHr1Gv9qPxxA5q2GmDWD8CeAwhHOB+HAzggk8X/HD0sBFyG1kGj14PxByAMSQzTLfRBO WIAl+Y4s/m+jWdn+Zz/0f/bk/+8fbJk/j+3eEpK8dtyG7fnkfHIr2UZ2kYfIr8kz5CXyGVXAXvFF 5FHyZ/IB+Rs5Bt1USo00mxaMu+8/PE1eKF5G1Px+IiFmQkaPjr6fvHf0fdiU1oyLuRZCZpHveMxo xujwyXHJa5OJ5PMSJdEJ9+q4ZyG3I3R49ChXD3fqRitZmLuEnQtPOiK9Pbk9ufWECqwgq8ggOZus I+vJOWQD2UjOIxfCdvol5FJyGejiPDi/nFxBtpAryVXkavITcg25llxHric3kBvJT8lN5GZyC+jx NnI72Zq6xsK3w+8NwlV25U7yC3IvuQ94F7mb/Jz8ktwD4V+B9u8jD0AcxmD4foi5g/wMYn8B6Viq +8j9ZDv8xsgQiZMdZCfYDMPpUILsJ7vJgyRB9oA195J9sPv/CNhxP1j2MSGOxaTD350S0z9ODpDf kCfIk+Qp8jS0jGfJc+QgeZ78lvw7V34zlgvL4QXyO/IitLVD5PfkZfIK+QN5nbxF/kgOkz9Bq/vo G9dfhRSvQZo3U6nehlTvkvch5TDkhPlgmjcgj7fJe0IOhyDvw+QdKiNfUI4cI6Nwxqx3g2ChmwQ7 MuvdDHa7W9Azs8d2CDMLodaZbe4Hnd8P9mWWYec3p6zxAKQdAr2mNc20/E3dPJ+yFep7H6RhumD6 RG2+ABpGm7F8HhnT+LOCnuKCRR8bs8VxKzAdMv29QtLaeWOcDt8lfxE0w7T7qqC7N8Zpj2n5HdAg swLL40Td/gnuReuwe5nOmU7T97Brr0H4ffAOH4GmGT8ULPEh+evY+V9T14fJx+QT8oVwPEI+BX/y Gfkcwn+HmCMQ+gSOJ8aeHPMl+ZL8g3xFjoIFvyYj40Ljz9mVEZIEGxNKKUd5kjx+djyWXaEimGJI wKfJqJwqqIqqqYZqYSoiPemKcuyK/htXjt91/JpcyCeDGmgm+EsztdAsagO/aac51EFdNJcev2Yd u+KEK27qod7UfSbhTuvYvQ6YIplTubC0BbSEroWjnwZoEM5LaTmtoFW0BmKKIRyC8AS4ViKwgcwk C8iZ5Kj4Pe45KFcmeJWhcPP8eb1z58zu6Y52dc7qmDljevu0ttaWyNTmpsYpDZPD9ZMm1tVOqKmu qqwIBoqL8n1ejzvXYcnU67RqpUIuk0rEIp6jpKjJ3dznjPn6YiKfOxIpZmF3P0T0j4voizkhqvnE NDEnu68fLp2QMgwpF5+UMowpw2Mpqc5ZR+qKi5xNbmfsYKPbmaCzO7rhfEuju8cZGxbO24VzkU8I qCHgcsEdzibLkkZnjPY5m2LNZy3Z3NTXWFxEh5SKKe4pixTFRWRIoYRTJZzF8t0rhmj+JCqccPlN E4Y4IlOzx8Z4b1P/wtjMju6mRpvL1SPEkSlCXjHJlJhUyMu5NAZlJpc7h4r2b74ioSML+vyqhe6F /XO7Y3w/3LSZb9q8+ZKY3h8rcDfGCta/YwEFLooVuRubYn43FKxt1tgDaEzs1bmdm78gUHj38EdQ 6nEx/akYiVf3BWEXWRXH1BSj/elzAmWDEkL9XC5WlssTYbIAArFNHd0YdpIFtjgJB/09Ma6PXdmf vmKMsiub0lfGbu9zg2ab3E19qb+zllhimxY4i4vAssKfNybywnVnjPf1LRhYwti/aLO7EWoIuiRd MDtvhJNwf0qZTUMlQUjf3weVWMrU0NEdC7pXxDLdDahtiIBMvE1LO7uFWzC2KZY5JUb6BlJ3xYJN cC80kabNzDCsgCwvd0f3HlI2enio3GnbUUbKSQ8rR8w0BYzia9rcvXBxzNFnWwjtc7Gz2+aKhXtA fT3u7kU9zEpuXazgMDwOfsCAwl1Qt5NSpxNDtWNSr8zZzdn4HmYtiHA2w8HdUAcXdDEJBplFG+qc 3dRG0sngKakU7OyEfCDAe6dE4GYg3DolYnNB4xZ+vqdINqwAFCMmGyuTCAohPl4mfM53Fg1TswIV OJsWNY4r4AmZQkAoYCq3by8nx3SRUgYUQcbMGWF1KC7i4NwJl2UxDuopRDErWpwxMtPZ7V7k7nFD GwrP7GbGYboW7NvW6WYrQMHaqVbSdUIIr1fjtRhxtXV1pwOwfuyONfsFuzKzCuGpQngsGDnpckv6 snOzzN3WuZk93J3KkDihB4FxJL6W/surM8qhszaDo3Q397udOmfz5v7E6KYFm4fC4c0rmvqWTIBu sNndsnCzu7O7Dmwp9PsNtvXs0RmkjbZ1NRQXge9pGHLTSzuGwvTSztnde2Au67y0qzvOweq3r6Fn yAPXuvc4CQkLsRyLZZEsiZMFWE6zICAT0tv2hAnZJFwVCRFCeAAW4EIcJoI4SgYSHMbp0uk4iBNh XFiI64Ef6GGWJWAC8MNNzoXMPOf2LNnc18M6FzGBKeGPxqh7Eolx7kmwZpeoYgr3ooaY0t3A4utZ fD3GS1i81N0QoyYKykmAT9rc5wY/BU2um9hoD7QOHWv9nNeZGB3t6nYdtA33uKBLzAWZ3R2T+2Ec EHtbId1UJn0QPTW2aaCflYNEoauzntky0AN9IZ0hJGmJySEHeSoHSNEs3MOaI9w0ALYBAwr3b4JA bFNPrMfPHtq9lJXI6dTFSMQ9AcyOeYp97EHBns0Z7hBr2JA0pvBewiCHshHYjRBibBCEh4HDZTWS qqDkA264NNDnBAuIyEAnNHX0pQpmN4hZBC5R5FskiMKWukhYtXivUq2IyQOQIfyxc2UAMoQ/aQ8o hVVeCF2SSgDP1sWUUCLfOFWmbgDtwKUWVhb4uwQKz5L+mmXTkSCz3GeDa2SFFh4lhcsxtbelH5w/ 3q+EGHd1+mbIS+ZlUSyPAxgrZTVXgd55b1di9JfudcwDpH+Ki9xscGANk9j2QMMmPZtPjojN8RcX yU6OVQvRmzfL1N9+A+pLph4j5EJE7LOp3xIiqiMzxEqyhf8ryH1kC5dLtkiSZIuoAcJPkXr+70Ql riFX8J+RqaI2spHvIRFgm0hKWrlLiZV/lthYPP2SnMG/InCj5AKykcWJ2oW0G7lXyUbuCWIW62B9 ux1FHAa2kXX8M8TEB0gT3E+4CnIHt5rUQtlqQK4D6QbpAI3A5BaO8EkXrGtnA10kHxqGi9iIlWTB SldFLJBCSkwkh/jgC65sYiQGoiUyYocVt4RwREEyiZtkEC8pJGKiJrmkgORBLhqih+/inPBdHPuB FSzMMG/hyrln4QXHk6JGMRHPFz8t2SU9VTosu0welf9R8a5yQJlQVavWq+vUj2sqNa9qT9V+rLtd 9yu9S/+7jPaMhw0zDKsNew2HMy8wOo1J0yZ4Hkmu5l+HFTsPZawh7WQ66dpH1PQ2KNwE+uzOxkZZ sfQRCHLESZ+FUlN6W9gg4tQ2W727QnIF36FvqZdewXWR+pG33nwCDgczaoIHafDN4ZeHdSNP6GuC w4eGS0soFEGQTA0nlUok7twAV5HnqywrC03iKsp97lwNJ8SVV1ZN4stCORwPKTFmEsfClH/96xl8 04iHW+eq7SwVU7/X7DDIZLwjR+0tc2rb2t2V+VlikUzCi2XSvMoGd3Rta+7zCktetj3PogDas4Ej j4k1R/8m1hw7VdR4bB/3Xk33JI9knVrJieWy2/JzjJ7S7Iltaq1arLGZs7KlMr1GURjpH7kpy2tW KMzerGwvy8s7UgtWnTH6oUgldoPeLmebn9HueDbxP8I9Caaz0H5oBL7R93YqtXSaL0H74oZOEUyQ H6wosbCokgRdEA/LTyGW+qz2Ef+h4Xp2oKCtA6Ultn3/bgalJT3eTA2qtzyjshI0JzGmNMl0bMzM AW2iRkUqXqIw1c8ZbLzo5Rtmdt/+5kWVC6ONNoWEFyk0cm2gZVFz+7poUfDUc9qbF7cE1QqVTHTA 6rZmmD0u06y7Pr/z55Q8MDvD7rNlZPuycwqzVG6/u37wF0tW/fLMCle+U2bxQ9eBvRoi2g8tLIM4 yErU06PEwN0CjTqLuwa6hCWlJUuCBsJyTYdNUJAtQbviYXGXoKBhf/2wnykHmhL4oB96B2iDssq7 cn0V+vLKMhe0I3F5gHO79UwJov29D3x1X/JZV3Gxi067/9Ofn5I84p9//bqLLjvzuoFS7ub4yB1t eUWiJUV5HVs/uGvu7Wsmf3119cp7wPJQJ/4KqBMsT7BGQ1l5Ce6asFZucBqcUKcsixqMnPUQLWCN YLeatvt8EmsiVVOrUFN1R55Q0zwIxcOScTWFLuRn9Q1m1NQEg7rhENR6938jS2weJypEaB4uPdPN uFOonkIrHzmL6Ya7WK5RiMXQKJIheolcy8618uQ6+iI7Pw26lxLVpLDm5UAnUyYPKM3Q7XxmRfJa pSWPeckto0f5AdBYHtmT0pjUkOCuC5vUdpJjl+ZrabvUolLTaVKdEk4foqcSw+iR3XBuMFglidHD OyAFEDqUhk6TJOicneHcDmsUmgd0oGG/H3XmZ1o7oK8RVBbW/xfzHWtL4zWV9lHpxgVVVIKWeugW uUYpFs5XqxyhPF9Zjhr02M9iRXfmFFhUybsVlvycnPwsZTJHqVNKJHAQXV+Up7QWorbo9eJMGCsK UVsw7nLX7QordLPEQpVpECoNrWJHOiJtWeZX9eXYwY30enUOPlztCPnyQjlqj0KnkEjgIHoifZay jmQlWKeO/AGfF1aqS0rMwaAiYLFkJbiFOz2lKpUCTh4knsoOq0pp2UuLYSoQGD2yU+fmppUmRo+E nezMrGNHNR7NwZLSgMSR3+GIZkSx5PX1GeYa9hIAKhAKhepp8NBwSF8GjVxfpq+ZGCwr05dBxXb9 d59ygnrcVMOzoSWPuvXjLciGGTMtozAAsVOjZKXSXuL1lGSruORlogxHSW5uiSODT97AKXOCEG9X VhbfF2gocaqoRURz1Y6Cau+QLc86Tsv2Y++o9QpezKybfezPaZ2Lzi+r1LprCr8e4WnhBI9WA3cJ vnL0qIgHO2TDHGBTqp94JHu5a2EuYOd+HZYTvVfwGd4E9e+QSFTutEtxQ8TOsLFDNdYjoEMwH3Jo OOU//rUb0839RA2BkxCNd6B84wUPbzoz1chUpfm0NNC5Zm1XUXK4pLm9YMVZ9dHKbP6iZfesrksO jNX9imBQap40/7wFjd2FymRL7sQotPj60ffB5XhJC9mbbvGTuRt3eUKekMqW4G6NE1WANbkqoqDF u/VV8GuqS1e+LkGLw6rJNnFBp0lQjylBu2HwwNEVBg/wo8N+PTpTHYyyh4YFz8p60D4S+C9lm1ZZ bkBUkeqBOLsJSFLhk4diCX/FtAseGJiyurs2SykCZ6opm7m8pWRaRXZJ+4IlC9pLmga39gTmzpyU KRVzvFStVJY0z63yh/3G4IyFSxZOL6E/XnzzaeUmR25WacBRmKV05bvMhZN8RfWl/pKJ0TUdvVt6 AxpLTqbG7M6y52epsl02o7fc7sfrq0HvKvDLH0CLyyXRVHsjEvDLOyx6SUZavRmCt7WPa1shGjww chC0N/S9qdIacR3vZi7moJh22HgDT2YDyT51TpmPucjkPgUONAr+aja0iO60F1hVx4bHmo5BZS2w 5xRalcxNQumvGH1fdD/4ST85FUu/jzi5q2FmYeKuDasUvlm6WWOzibnjGwS4HZxMhJXfkyhd/hOc qj41hTruZkX3N1/61AXrH7t4quDrwc36pg5MnLSg0atiFSvNUdE/rd13QePEc/ecyxvSlRkRta9s 9fpazmjklek45gOmQk84C1YsZSRMC7BWcbm5PMHN2Uny8siEBNcU1ul5M/3MTM0JVTn9upyWs68q 5Gz4LC8PTC5MUEvYdjiX8htyt+Ry4dyZuX25vDbXkcupRLm5IjsMp2GNCiYodouOttuPBlongq3D cghMfCesahcRS1AYVWHWxQZW2KXu7Z3fO6xng2zvyuHelaC+AzVsZlIDjSCs/R+XBuzkzWSLCp+v oiK1uGBtrKyCTfbGlhaTRIJbl+JE2FQWqqziz8r0FxYX6Ku2nDJ17aklE9ftXHuqPm9ySf3AtDKd Uq+UKLKb5y2vXXp9X9GXfRNPqbROra/oCTg0OqlUp5la2+BtOTMyfXWbp7KwvjAzOzdbk+UzOzx2 d46hIHrx3NcyPGWu6nAl/OMjjmyEtkrEK2CVN5HckLKrwlW5l+uDYd7P/Ricu1FRWeESiUvSHQ8W CW1hta/V1qybViM4tpoEbYV23J6eFdeDhWA8Tbl5Zozd/24e4xp7XnrJcLyN63FVJjh/UKhUbwL9 wRSalC+4ak7x9KlNHuiSOY4Cq0IFY6a3xK7KbWyM5A9sPjU/eUxfOKXMWlJWmVPRX1HaWJxJP1r7 yMURvW9CQb9SqxCJFFql2K3AWZAiaYBRVjPj4h2DNafPKtXkVuYnX22cGpq5GPp7ZPQD3sW/TCrI bSkNZpO8R7g1wooLPs0hntQM25OgjrihVfQQjZBS6BtKmEiWFgkqLErQZlh5oQph0eUfW3odYPNs tvT6z3ISWmN6DSbMxMDvC0sydy6c5YwtwKAqYqllQuupgdO2nlk15ey7F+S3T6kwycV8pk7vK4+E FizJKmsvK2+r9qnlKqkoluW2aM2uLF14w841Fz++aRK4dpPW4rZOCELTu/GayI9avQ6fQ2ED38iR NvAjz8HbfR+sT69PaUtpq9nLwecHJMitCisMrmZlTZ5NpClMNzjwHC1huaW1XNBUOYR2hjXt4mnp WTa2NnSe2PXl/24eqCVc4o/vsyGTeWz+yvuEjYG0zqr45xSWghxnvlXZdOPcxVt68ssWXDO/bX0d m6Z5YZp2tHKgsnSq35hR0FieVVpW6cxNN6+B1lnQogZYs5tYS2EeJsy4FSPljZHSWYsqqk/vDGlz q/KZ3lpBb7vB//pJORWj3nYYDK6iBDcl7i8XJZjmXHyRoYizFT0uYo7XDMs7ItKJuGkzRX0i7g5R TMSJRNlB0CpbtTCGnZAm+I6v1fJ3otFpOD2vkVtUtF1ugQTyr8LZ6eboPwTOdjjld3tXzuv1D8/r BW8behOmLEHmbOX/t88W3ILE7RrXbsE7pHYYhNbNGfMqBTtJ+d0FnpG3bbW9kxsWtpRo5SoZz4lk 6gmz1zSs3XF27aSz7j19xdbFJZ/zc+aXTA1aOXo0UFTTOznXYDZIM1xWk8Ok1VjM+rr1D21Y++hF zQ2Dd8xznr7OM7EzCH3fCl+S/FR8NqxRVqesYtIRmBrO31FS6FUkqH1H5dQsX7olw5aLY3e4JOKc pouw1isMZ6F6mPsdKBs5UMY2WfbAVPKH3TTONQpjh1EYR6BPj5sdw+AjzGtgzBG0IuJ+KpIpJFK9 Nddsy8tS3cUmNJmGu1TZIY+n1K5cYTCIIWq5p31tR15zvkYuEv3N7jZIpTKp3lvrn6Uw59urgiMB BS63FdyLwSp7vlnRNueyOQHYoLLmwZ6dLXktfyf/EpkE+3bzKYd6Cc/Qlkj5andrWevjrbyjlba+ /TSsUFRU9XQnzemklk7a+elBeDFupMSoM3Jao7Gvmv+qLlLoLGrY1wBvOGjDwepW7Ryq4+c8F3bO wMEG2mX9cG9vRk29MA9gUwII9r4sAMYg1jaj45+sbKX//OHHn13X8FwDJ2qg2u99Pjw2XYITCtAr lAC2e8AoJhOOX748Cfhbk9mcw48NaGCcKpglwDYjOzJLmcyukIniFiSkZqOaodyXl6eBm4QQf6dJ t9RkKO+/rMs/3agylAX+MG1th3/Cmu2Dq352WlDvKnH4g5V+d2HVgktnFba7qE1vTD48s8Vb7c2Y OdVX7TXURup3ZDkMkkVza6aXZPJ9JQHLRNf0dZ1+o0btMdm9nAze1M2raxg8JeQJ91S46qpCZvOM YG1/nntBy/RzosUKeVHyq8hMq7/G0TjDUlg1ckpxCSc2uJ05ulC52Rdkc+GNMJN/EeYXIbIM28Ee ouTmx0OFmQmubwdMmnXpvqFL0PawPFzc6mm2TkPnjv0jAyYSwyFhky3+w9KP9+J6YbIFLf74mjrl H/TCRiRn5F9UZZd6vKXZKoOnxleyoCI9V0hz8iUtcza05+amGz0dmdxaYW+eMrI9HTN+nhCur1ty +QDz2WeMHqVbxNNhIuUiTVj7R2EN8Cjbbof5lQI+2j1nV9iqa8Havgx7D+kFwJ5vuXZirVKVMLAx nLUcaDJ0fbrEaRomdUVrJ0a76sbKzq+HaQ3s62gVtGTahOqWabU1KSvtBSuVkwXpcpZCCXOJCo4m 4uZ27yguNsFOy4NhTZiYcpXi/JbsZv2YmWDdCpM9KD9b3utGQu+wbqf8tmTjKpFHv8UmbJtD2POT SCk1mfi9Snsov6DMlSFNvpKuVZpUJst0lfq8ZQ6VVps8RgMqpQtWbmKRXKemLyfzv2mdrz+lA6oM YadQqc01JF9NFmfasf50PdTfSNhLRtgzD2vVRgrTM6WCqglVigi0VrbR1YymSm10CSuQXtjuSkWP q9zxOeo3rTJmjOPNBssgkcMIP5NswzIMNcNe5PwdOTkhUPz8+MxJeWxWHoKPFnH/nnWYeFurJ92B YHbZDuaZ3Dqpubi6pXja8V4E5kkvnKCB1RwaZi9AmGvc859ldmJ92aLmhH72jYhUmzVixzOnTC2R q7JLvD7YuNK7K7zFcyvBvh42V9fnVnoCc8e6oyKrwOEsNCtar51Z1d0U0ue3t7Xl9axvc47pk9MX n9QxvxnDn5tuFqfNnGn213n9k/IMdadtbh/zVmCDEDk/ZYNCA1N6juC0SA44qyM7YNIuOC22VBWc lhKcVqHV0zKmcBgLoC+wXV+2z5VW9L9y5z/R7ImK/G4PNqaymzr/iQc7QS2gjn7wXxFYG4pAGwbY Hx97R5LJDcJMPQeOCpj8YEuENwdZYbm21S1M0GHTL3v8anD8O5IfegfUX3hHkt6XAZeQXuSl590i Ud36xDlrY2uqJ65/8JyzY6urkyPGUGd9dVelzVTaNammqzKLvr9q36WtDRsTZ616+JLWyRsT5zcs nxUomLF8KrC4YPpyqOXG5PUiArUcvwJ2VSrSK+CLvm8F3KKb8R+vgP9ZHuNUkfdNh2n8rhUwLELm 5U2eWOdMe0uFtcCRAyvhvLbpncEFbAV8VF8wJWSFFUlORV95aVORkQ6vffTiiNYRcCTnphcjorfS /WVp/sSCzPaL42trls4q1bIV8GtTWkIdbAUMozy3F3RYRuCrOOY/h3xa8JhhFcnSKhyKoIJX8wrw U6zvwKS4M6wI+1t9WqOzxSis4tIOChwqTIVTPUbxz9OP0w2bAn/LII/6kXB7YcavkGVaczKMhcUw 1Ke2A9IdxD2pujpbneO0wJsQjm/zBLIUbMrrqSsaOZSu//Eusjw02aflpXKFysjei5hHP+KuFA2R CeRarP2Der26toC4i5nfNquL0x66GKb/O9wRuzodoWYbAuZIaYJOjYelqf0TWGYdBKHBspHQgRDb 3RI8dXGqs/1LmaAfEQmvrPUnLwY44/glgzCrZGMvd6Uywx2sym77UST3DEMmbIYqTlfacYb0GFNG puHxQG2m06qXSpQS8fqioAGmFL4ZZ8+iT+Nq4EloPPCeSad4EtcLyd6WFqlcKjV6UFtiJ6yYFpJ5 u2ZNnhxaWAZaChunZ/tCJJQLv+ru6Qsj8+ZJynzTmXq6I1Wgnt2R9qJp2RHYQrcPSaaS+mFYPMGC NBQC9cDKv+wA20aHFzYHQ+ydDZzD2/30mic178ZV+/gqa3ChD18B4JwaZx6a71YXX+VtP2uWb2qe ViYSyeQSqbvAlJ1vVcMySik2ZtwNE0kvW0Yll41T0Hdrk99/fN1kZ8sstfw7VlnHNZj9feomo6Os NcJ3GNM5H2w8wT/pIB7uQaDQSkUl0Eonk/p4cLIOlL7Tn5Pjh346fzdf4Z8c0flZ86ytiGSCvnd4 2+XTCNPxwWH2OgxX+qBbptiQyXjcE/1w5b1b6ErPtJPLxylIkeH5jubG7/fkfn1PugNyL45XQ7Hx O1tdqpXJRG+TRaQXaqthHdE/vZu1NJO6QZ0Nv6TC30WmRyZHIpHabg2re7wiAi8Vpsa97XMBQ9Af WRNjjexgKFgPSjgQLBPe0AgvBlEX8F1DqrmcpAfci/i2PudKtcvv6H5imdLgDlTZpkH3S54/Tk2w LafLDXx7v6TnHe+h8DbXmPF4cV2m05IhlSik0EMDmRpVqoeOU2G2y6RVa76r636Z3v7/8hudGPS7 ju3j8U/ATOmMlMdXwvSUbeI5QMdaQ3FLnlJsbfEIMwI2Mz1py455fGGxI6zQNT8kOfqyE/fmxjbl 8P1HZdVYBOzKwYDnKrAoWm+aNXdDu0tQEMwqM7ywyOuvSu/OjU0eYTpYt+SyxdxYRFLWLMwmuY50 A4R6m5LX8zuh3h6yBOu9m8rlGpIFWz4Nu8OeLKciy5LgVoe1YU2Wo8WqMLQo2kQzSJuw2wNv/Oqp NWjBlVKW7s0sWDCBA2PvrMKqb00OlXbx+PKgyuDz5VFfeWr2bCgzsGmgyZQp5S48Uz6zPb/EwknX qo3i5EG1BV6JhLI10hf5/RJDUZW/xiZLHrCapDqLnvolVg1f7vYaZbzKah7ZxvVn6WUykxfe9VLS BAvXj/n9sM94J9YvrNB6qU6rpXoJ+Iw9ux2Z8Et8Ce7huNyrTw9kevDLYYU1oh37eMQOU0BWazYR hh0uP7ycGz6I7zpLSwgM9PN6YYk4lve/lFVpiXA/+6gIvxphPaqKsg9q2OaJ8NEIc/pSyk65j9mn BSN7bHZerlXR6ckDBrMYRijOpclUS0UyrSK5k/bJYfP1NHuBRe4pCGTYbdl6TlRSYc8zKyS6bGNp piM7WzcyIjPlwYyR8PuFdb2SqEgm+wbi0Z2wclNFSP1bB6GW4CDHL8rplvQiPLla9FxqzZ3cBvnc MfoZfYjfLsyvbUMEdkQSDypy3LCM0EJeB+shszL2ycjJM+Ex3yvsFMFHaA9pXJUFBZUulQqpOTnM mwqrPVqtp7rQP8Gj03kmjEQKa1hETWFhLWMts30tvYqr5nrhO0B9nEiVe6gLPhoMwp4EtE9WJUG/ +L0SV22yJPusJpOV3qHSq8T0ywmBYE11AD4fYTsfNeAdXob35gZoR09iO9pDikf379Zy7aSYZj7E XQ//2u4QtC0IE6rliXMvRCmIDed8tnS7Yt9bhTXaTvhMgLaPfSsQHffSlH2DBXOlYbZD7Qfd9/pt 4Qx4htxJ5QrKZVKO5c8yZJPPfzljyBV+INtvW4+A5x/7eE3EvxxauevCix5YXFC2ctcFF21fnJ/8 UmF0FFXn1rYXZ5iCreV5dcU5Bil3xS1HY/PmbPvy1puPCbx37pYlEXihuepXKzfvOsNvDU1buBGs cR20s5jYTAJkV6onquUFVJ5PZXkU/qkQvI6Dl6ugv3AJ/HOmAvjOa0eORQkd8q1dEKk3wEi2ISx3 zyrQ6qhSDOtU//GvuaBSofoRaF7+g7DvDNad3+snvRQqagtbCvJpATxn3KPYE35IftBK5vdiPr29 6c6ZerFeBpNFCW5uVnlTC3/43A3etsck8HHSSKUMBiL2adKnL5jtegkn06ioSay15Dl8QYvsJTa/ WpgNvVHBPuECJ8O3rlaK9YU+i8Okke0UiXnKS1XyYy+xD7sogf8Hkd8H7W8SzUjpTiMqoiI/lU+g 8hqqDIPyhLYYpqYE9/HuMi/8kpqHuI+JcvQDbJZKaDZKePW0dLe+usbprPm2JrQ0rC4zSQKdurFV YM9xLYPbg1EOWidMR9kJZW+s/cedIOgcGhdo3Qbfro4vHbxi1/L/zSczw8zrTT3tRMNUwYetJ72P lqSmwfBJrPA5xD5wlooRi8mZKZforJmHp8wK6I0Fkwpr5zQF1HK1TAwfbFqnLDgrvOjGhaWWaZtX 3UiTCr1Kcoa9IEspMxe5XUGv23ikefX8mR5XbZE1x+tQZQdzzQ6z3uJ1W8rmbIjUr9+ybeUt8BkF 2K4Ddoz3wrcfDnI72u5BcQYV66nSlTaai8JI9Cx8aGTU7+WegSmHEb4cUDJXYgTFGcXjR6VFO8NZ Hcqxz49gFGJGEF5bCc6CKcUW1qQeQVyQwffef1yVgkOQpj7aOnHw4feKpCpZ8hSJIbcir2KSnZPR Z0YOG41s25WnGRaNVLTV7ve6DF971To5L9Wa9fzfqupy/NkqqaVImK1ngCbYjwR8KGmb3NrS3OKf 0n/m0gWrlhY3LD+T/Yei/w88f7bZCmVuZHN0cmVhbQplbmRvYmoKNTUgMCBvYmoKMTE3NDUKZW5k b2JqCjE3IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQg L1ZFV0RaVitDYWxpYnJpLUJvbGQgL0ZvbnREZXNjcmlwdG9yCjU2IDAgUiAvVG9Vbmljb2RlIDU3 IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA0MCAvV2lkdGhzIFsgNjMwIDUwMyA0MTgKMjQ2 IDM5OSA1MzggNTM3IDUzNyBdID4+CmVuZG9iago1NyAwIG9iago8PCAvTGVuZ3RoIDU4IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkc1qwzAQhO96ij2mh2DFcX4KxlBSAj70 h7p9AFtaB0EtC1k++O07UtIUepjDp91ZZlfZqX6urQmUvftRNRyoN1Z7nsbZK6aOL8aKTU7aqHCj 9KaG1okM5maZAg+17UcqS0GUfcAyBb/Q6kmPHT/Etzev2Rt7odXXqUkvzezcNw9sA0lRVaS5x7iX 1r22A1OWrOtao27Csobrr+NzcUxIBMfmGkmNmifXKvatvbAopazK87kSbPW/0vFq6PpbZ76pyigp i6ISZZ4DISn3u4hbIATcRiyAEPAx4g4ISXlI1T0QQrWP1QMQAnLEIxBCMyYj2G+EmDHe8r67mr3H 2ung6SJxU2P5/idudHFA0g9rLYX5CmVuZHN0cmVhbQplbmRvYmoKNTggMCBvYmoKMjc2CmVuZG9i ago1NiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9WRVdEWlYrQ2Fs aWJyaS1Cb2xkIC9GbGFncyA0IC9Gb250QkJveApbLTUxOSAtMzA2IDEyNDAgOTcxXSAvSXRhbGlj QW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWlnaHQgNjMyCi9TdGVtViAw IC9YSGVpZ2h0IDQ2OSAvQXZnV2lkdGggNTM2IC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNTkg MCBSID4+CmVuZG9iago1OSAwIG9iago8PCAvTGVuZ3RoIDYwIDAgUiAvTGVuZ3RoMSAxMjQ1NiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHlm3lcU8f2wGfuTchGSMIOARK4BMRAWAQU RYhssoiKEJu4gohi1UJRXEulr6/VUq3dd5e2dqXWy9W2sVq1rV3Vrnazm21tq61Ua7WLFvI7cw/g 0tff5/1+7/N7749fzLnfOWfOzJ05Z2aS3NKFLa0NREfaCU/S6ufXNRP5lZAJGFS/aKEV9dDThPip ZzXPno961B+EaIJmz1s6C/UEaKc1NjbUzUSdQD3JbgQD6pT1F984f+ES1BOMTJ/XVN9XnzAF9OD5 dUv67k8+Bd16Rd38BvRPawcOam5p6KunbkJC7r9Yp7e8Nn8vZf7XswsJIIRpGmolRvI8UREOmEpq CfGvp6OIAmpZvXK9N+P0XO10Q+4ZEqEGAyE7frhqP+OrKx+78dyhnjWa46qXwVcDPeAL2qnW9xyC OW88d+js9Zrjck99lTI0XRrey/0uxURbvNxvUowd8KsUkwz4BXEGcRrrfkbtFOInxEnECcSP6NmN OI7GHxDfI44hjiK+Q3yL+AZxRIrRwCC+Ru0rxJdSdCAYD0vREYAvpOhUwOeIzxCfIj5Bl0OofYz4 CPEh4gPE+4iDiPcQ7yLeQbyNeAvxJg7iAGI/Yh/iDbzt6+j5GuJVxCuIlxF7ES8hXkS8gNiD2I19 7kI8j8adiB2I5xDbEV7Es4hnEE8jtiG2IiRElxSVAREUEVukqCGgPYXYjHgS0Yl4QopKB5fHEY9h u0cRjyAeRmxCPIR4EJs/gNiI2IBYj1iHuB+7vg9xLza/B3E34i7EnYg7sN3tiNsQtyJuQdyMWIu4 Cbteg81XI25EdCBuQKzCBisR1yOuQ/wdcS3ib5I5E+JyDaIdsQJxNaINcRViOWIZYiliCWIxYhGi FbEQsQDRgrgS0YxokiKzYBBXIOYj5iHmIi5HzEE0ImYjZiEaEDMR9YgZiDpELWI6YhpiKmIKYjJi EsIjRQyFkbkRlyEmIlyIGkQ1YgKiCjEeMQ4xFlGJGIOoQJQjyhCliNGIEkQxoghRiChAjEI4EfmI PMRIRC5iBGI4IkcKz4H5DUMMRWQjshCZiCGIDEQ6Ik0GT6VwB/SSikYHIgWRjLAjBiOSEIMQiYgE hE0KGwGdxSMEKYxt9DgpbDggFo1WhAURg4hGRCHMiEhEBCIcEYYIRYTgHYLxDkFoDESYEEaEARGA 0CP8ETqEFqHBPtUIFRr9EEqEAsEjOARFEBnUh+hF9CD+QJxDnEX8jvgN8at8W/qLPCN6Bo2nET8j TiF+QpxEnED8iOhGHEf8gPgecQxxFPEd3u9bKVSweOk3iCNSKOwc+jXiKyl0GGhfIg5LoYWgfSGF FgE+R3yG+FQKLQbjJ1JoCeAQ4mPER9j1h4gPsLP3sbODiPcQ72Jn72C7txFvId5EHEDsR+zDdm9g 168jXsPBv4p4Be/3shRaACPbiw1ewhu9iKN+ATvbg9iN2IV4HrETsQPxHHa9Hbv2YtfPYtfPIJ5G bMMbbUVIiC68rYjYgngKu96MeBLRiXgC8bgUAqc+fUwKGQV4FPGIFFIJ2sNSyFjAJilkHOAhKWQC 4EEpxAl4AF02ossGdFmPLuuw7n70vA+1e9HzHsTd2OAuxJ1SyHjo8w5sfjviNsStOKRb0PNm9FyL uEkKqYJ2a9BzNeJGRIcU7Ia6G6RgD2CVFDwFsFIKngq4XgouB1wnBU8G/B3rrkXPv6HLNc4t4HrS UGw5EVBqOew/1vIiyAsge0B26yZaJJAuEBFkC8hTIJtBngTpBHkC5HGQx0AeBXkE5GGQTSAPgTwI 8gDIRpANIOu1jZZ7Qe4BuRvkLpA7Qe4AuR3kNpBbQW4BuVnTaFkLchPIGpDVIKM03B/cWTKRWLhz wEZioSukIDgy6dVSINuACxELJBNbtS2IKxHNiCbEFYj5iHmIuYjLEbmIEZKRdTYckYMYhhiKyEZk ITIRQxAZEgTYS9MRaYhAhAlhRBgQAQi9BEnxUn+EDqFFaBBqhErSs1T7OScDfwTpBjkO8gPI9yDH IJ1fgHwO8hnIpyCfgBwC+RjS8hHIhyC7QJ4H2QmyA+Q5kHWQivtBvLQdI71MMrHNsRSDswSxGLEI 0YooRBRgHEYhnIh8RB5iJE45BBGMCGLYzvM8Jzktm3bxHNkGsheE5wmOZTmiGrM+AUdWhRiPGIcY i6hEjEFUIMoRZYhSxGhECaIYUYSIQ8Ti4K0ICyIGEY2IQpgRkYgIRDhOMwwR6rwPptsD8gfIOZCz IL/DGvgN5FeQX0DOgJwG+RmyegrkJ5DvQL4F+QbkCMjXIF+BfAnZPQCyH2QfyBsgr4O8BvIqyCsg L4PsBXkJxAvyLGT8GZCnQbaBbAW5j2Wf68EYtyGuQsyRTPBViDYiZmNYZiEaEDMR9YgZiDpELWI6 YhpiKmIKYjJiEsKDcCMuQ0xEuBA1iFSEA0OdgkhG2BGDEUmIQYhERALChrmJRwgIJUKB4BEcguKO JM4HIUk+kF6QoxDYD0DeBzkI8h7IuyDvgLwN8hbImxDo7SDX8TbL33mH5VrqsPyttN11TWe7a0Vp m+vqzjaXrm1EW0Ubr2szA5a3dbZ90uZ3Veky1/LOZS7FsuBlnHZp6WLXks7FLt1i6r+otNVV03qk 9XQrH9xa0zqzdWHr7a0HwaDa1LqtdW8r7/XtcQa2DhtR0t56cysXDPUcaaUGZo5t1QWULCxtcS3o bHEpWjJbuBGnW+jhFsqltdDxLbUtHHhtbYkfVMK8s1pCI0uMLWktzhb+ytImV3Nnk2tcU1PTiqYN TbublCua1jZxW6DEOZs0+pIrSue7vphPyU7OR4wgezifxGubdnC98NTjBNfr9NG5EIDLIRBzHLNd jZ2zXbMcM10NnTNd9Y4ZrjpHrWu6Y6prWudU1xTHJNfkzkkuj8Ptugz8JzpqXK7OGle1o8o1obPK Nc4x1jUW7JWOCteYzgpXuaPUVdZZ6hpfSkc7SlzFfLYFPkFIDLybY9pjTsYodLXRzdFcc/Th6JPR fHPUyShuhZkaIldEro3kDXDh8BJhiVgbsSFiS4TSIBd4/+bA9kCu2dRu4tJMTtPbpsMmBTFtNHGG tYYNhi0GfpxhuuGEwWdQbDHQLQG7A94K4McFTA9oCuANAUznjc4AR3qJQW/RO0en6vncVH2+fpye X6unTr0jo8Spj08syfcf5z/dn9/gT53+CUklJ7Q+LefUQsUJjU/D+TSU8NRK4TmUEcCrWY5oiKXE S8nWUKqkXnpzV0213V7hVfkmVIjq8ZNFukq0VbOrs2qS6LdKJK5Jk91dlN7k6aJcYY0YXFE1CfXr 1qwhBdEVYnS1W9wY7akQ26HgZAUfFEh0Vygp8NinLWhdsGChfYEdLiDTFoBlYSu8ZVC4QrkVLqxE wMX+Fy/mAZXgLTstaJ3eCn2AM5hZ761QYApz+Ysu/r1mNrb/2Iv+x+78//7G4dOnsae3hPTedsED 22vINeR+0kmeJs+RF8gb5D3yM9XCs+LryG7yNfmenCLnYJuqaAiNokkXtPsXi73XKucTPb+H+JEw Qnxnfcd6H/cdg4fSARdYbgMtTJFw3uIL9HVfauu9rdfb+6afjhjltkZuH/R2knb7znL50NLoy2Y6 t5KV5TudVK3v3dK74aIJNJMW0kqWkKVkGVlO2sjVZAW5Fh6nrySryA0QixVQvpGsJmvITWQtuZnc Qm4lt5HbyR3kTnIXuZvcQ+4l90Ec15H1ZENfHdPXw7875VpW8yB5hDxOngQ+RDaRh8mj5DHQn4Do P0meAhtaUN8Mlo3kAbA+An7M60mymWyBfyLpIhLZSrZBzlDv17xkD3mGPEu8ZDtkcwfZCU//d0Ee 90BmX5RtzNKv/7Un+r9E9pKXySvkVfIaeR1Wxj6ynxwgb5K3yP+m5uWBXlgPb5N3yLuw1g6S98kH 5EPyMfmEfE6+IIfJV7Dqjv+p/iPwOAQ+n/V5fQle35Bj4NkNPWE/6PMp9PElOSr3cBD6PkyOUDU5 QzlyjvigxLJ3p5yhe+Q8suzdC3nbJMeZ5WML6CxDGHWWm80Q882QX5YZVr63LxtPgW8XxLU/0izK f47Nm325wnjvBB8WCxZPjObbEGHMGetn10DE98lxkuSMvjiQi/NZYDFk8fuQ9Efn0wti+A35Vo4M i+5Hcuw+vSB6LMpHIIIsC6yPi2P7FbTF7LC2LOYspv1tWN0h0I/B6XAcIs34g5yJH8h3A+Xv+uq7 yY/kBDkjX0+Sn+A8+ZmcBv0XsJwE7QRcL7ZeavmV/Ep+I7+Ts5DBP0jPBdqFZVbTQ3ohx4RSylGe 9J4vnbeyGqqArxh+cKapqYZqqT/V0wBqgK8iqktqdAM1pj/VnG91vk4j9xNIg2gwnJdhNJxGUjOc m9E0hlpoLI2j5+siBmqsUCPQeGrraxcqt4wYaGuBr0hhfb0w3ySaRhfD1U4dNBXK6TSTZtGhNAcs KaBngD4c6tJkFpDxZAaZR84qj3L7YVzBcKp0OUumT5s6ZfIkj9tVUz2havy4sZVjKsrLSkeXFBcV Foxy5ueNzB0xPGfY0OysVEdK8qAEW7wQZwkPNhkNep1Wo1b5KRU8R0lysVBSaxUTakVFglBamsJ0 oQ4MdRcYakUrmEou9hGtrF0dVF3k6QTPWZd4OtHTOeBJjdZckpuSbC0WrOKBIsHqpZOq3FBeUyR4 rGK3XK6Uy4oEWdGDEhsLLazF4Y1FVpHWWovFkkWNHcW1RSnJtEunLRQKG7QpyaRLq4OiDkriIKG5 iw7Ko3KBG1Q8vIsjaj27rcjbiutmiuOr3MVF5thYj2wjhXJfol+hqJL7ss4RYczkRmtX8p6O1V4j mVFr958pzKyb4hb5OmjUwRd3dKwUTXYxSSgSk5YdCYcANojJQlGxaBdgYBUTBm5ARaXNKFg7zhAY vNB9HEZ9gaWuz+JnM54hrJJNcSBMIq3rLxMYG4wQ5hcby8Zyo9dJZoAitle5UbeSGWaJOFPtHpGr ZTV7+mtCXKymvb9moHmtAJEtFopr+96LGsPF9hnWlGTIrPy2iQob1FtFPqF2Rn0jY11Dh1AEM4RY khr4dl4EBWddXzCLu9JSwb+uFiYxh4Whyi2mCs1isFCA0QYDdGIrnlPtlpugtVgMLhRJbX1fKzG1 GNrCEinuYIlhA2R9CVXu7WSI73BXptW8dQjJJB42DjG0EJKSUNzhnjlLtNSaZ8L6nGV1m2NFpwfC 5xHcDR6WJcEoJh2G28ELEii3grld4t3vDNMWVTa11c2ZeQ/LFhisJXARCnKhwij6ocoyWpBrdVMz 6XeDu/R5sNJF/YDC2wpLoTEQmhaWmmNhccuv/2ZIZpwADENUD4xJAYNQnh8T3ucvh4bebEBJ1uKG ogsGeFGnoMgD7OvtH4+TY7HoCwYMQc3SWcrmkJLMQdkK1WqRg3nKJpbFcKtIxlvdQoPgEWANOce7 WXJYrOX8VlQL7BegnO2+VVJzkYb1w7BOJLEVNe5+BX4/usUSu5xXllZZHy3rA2rpJdVl/dXWDrVQ Ud3Bbi70dUissIMgOX4JZXU3DgvMhM1aAgelUFInWI3Wko46r699RkeX09nRXFzbOBy2QYdQNrND qHbnQi7lfd9mXsZuHUgqaEVNQUoynD0FXQJdVdXlpKuqJ7m3w3dZ66oat8TBr9/aAk9XPNS5t1sJ ccpWjlmZkblYmcJ6mgCKWvY3b3cS0i7XKmSDrNfDD3DZhk5go6Tey6HN2O/HgU2BNqds88ALdlh4 I6QAzuFi60yWnqs8jR21Hra5SCikEt5UpEIeETkhD36z+/mLWqGhQNQJBcyez+z5aPdjdpVQINJQ CsHxwpnUUSvAOQVLzk3M1AOrw8hWP2ezen2+GnfsAXO3Jxa2xBSQSW5RY4fPAaWtHPxGM6kF82ix vb6OjYO4YKuznVlW74G90N8huJSJGuhB09cDeJTIbdhyhEb1kBtIoNy+HRSx3SN67Oym7jlsRFar USSlwnBIO/apTGA3SvV0BAoZbGGDq6i1rWTQwNgIPI2QLWZQ4WZw4LIZqfxh5PUCVNXXWiEDClJf DUsdz1ItyxtYGuBIVCQ0yKI191USNi3eptNrRY0DOoQ3K+sc0CG8VR4ICpu8rK3sc4B7G0UdjCjh glD2NYDoQFUZGwu8V8LgmesLrJsqL5kgLIGjkQ1avpUKqkW9rawODn9srwOLMKy/MfSltjET62Mv WlVs5v4Qd95W4/U9KixlJ0D/KyVZYB8ObGES83ZY2MTTcalBnGxPSVZfatXL5o4Otf4fN8B4qfUD hF6IAv5sSqkja3gPKVWoSDn9lcxVVJCrFZWklE8nZVBeCiOBL5VwhT+lgt+TkcBYogYLTzhIiwps StDZaz18u1zPXc7t5kv47YrVSjXUkN4F/CfwK5UHzxxSScaSmp1ET9fBT+DhdN+2oiJ1imoXqByx 0n2sX7rOGaTg9GZzvpDlt5qvMpXlq1ZzNSS/5/PPXoHLgcCc1AM09bPuD7qNPa+YclK7D3anp1FT rEmW4ABOpfLzE+IcXFZiQvaQIRl5XFZmghAXwMm2zOyhefyQjBiOB0+05HFMp/wnf4zji3viuaWx I6rTldRuC7MEqdW8JUZvG2I1VFQK2YMilQq1H69UqxKzCwTX4vK4N7XhiVHRieFaYHQUsOdFZcDZ U8qAc5cpis7t5I7muPPi/ZbqdZxSo143KCYkPj1qZIXeoFcGmMMio1RqU4B2cGldzz2RtjCtNswW GWVjfdl6RkBE1hCi2AOxCyQWciV75Ody7yZB3H0Q6kjuVvgTtXDf0W06Ax0T7qUOpyagyhzONLOX 1khOZQ0Jz4+s7Lbnd9spBglW1D/bIj3NQ1mAYuMSskyZ2UNiIULKTAcnCCYWUcWeqU/9/mTvvtiU lFg6ZvNPD0/sPWmffsfS626Yd3t9Onev1LOxIjFZ0ZicWLXh+4emrF846o+bh135GKyaUt/3fCz/ Acki63BGUhRJ3MUthL/gC6fwwJfE980p3kstUlC54jlaStLhObZORyvTk+UJJntpieTUVMoT7LEf tHfnw7UbZrk3Iz3NvPNf7glmbwsOwEWUKS8Pv5BgWRXioBQDCwYXDUxFqQofXn6ZY/aGeUMLl2ya MaiyMCtUo+SDjaaEzNKMGY2RQyqHZFYMS9Br/FUKMVIIN4TFRhqdbdsWXv9Se15AeEyoIVyIGJ4a FRd1162lV5TbLAkWrXkwgfyX+47xz/AfEjvJpEqM1tagoNhkL1co2TMVXq7FqY3lk4OSOXPySwr2 sD9MTyuJwqjgxoxX1Cq4jQpRwSkUUale39GtBlrJ6LSCT+qRhPLwX0iAMYAz8QGacH9aqQkHB83v zqj+sNoPwg+mblg9dthxU6+cNtXePW0qxDjjs24wQJydmn/vveU16SfEXhD/kIuzxIUkZstbXcU/ kxTf86V5xNRRBTPL0gwafzXPKdT64ZMWFizeumRE3qLHL2/eMCvtND95etro1AiOnnUk50wdFRcU FqQKjI0ItYQaAsLDTLnLnmtbvPu6koLWjdOsly+NH1mdCnmZ6ztL1yjHkhA4CYv792Uot5tEkRCu lmjhP1ssf9oZYSxTjoElmv8B7MLzO/DPdbja8DAy4XLjQoLYekvIgq2XEUqX+Uen2Wxp0f79DMqr cY0Y6arJjdMatEolXPhlWoPOz09n0NK0McOHlY0ZkQO77WrfWf5dWEEZ5BocZ9fgoB0wxBii46ZL JMbo9Z3cChsLeHSbP5wdRi+tdOqcKeWDI+LLIsbgBPIDc+STBM6Rg93G7hzI/XZ4yPg/aXnxHOEc ifNTmfpP4IFJh2TDdGO4EP5d/6j0eFt6lH9QfE5C2oys/nlrI5Ms1sFh2vJ7qie3VcYNzJ72jCrP ii4p7NkyEI+r+kuzx4/Pnd1RB3kr9R1TKCAaQSTx/HkazLXCeRoDVy2J6Dt7Irw00qkxlAvycSN4 aRScp7gvLjlP/9kW8tq9+ANHPk7hY6n/PFEocpd5ly8WFw4buezZ5UvEBcN6e0IyqvOH1WSbQ9Nr 8nJqsiPpsZadq8oLrvYuanl+Zfmoq73XFDRNcCSNaxoNTEka2wQ5L/Md407BLMvIMcz5djKKczwd nxGf4W/2ckXOOOKvcFDHkaE6LdV+ZxrqZAtgqHUoxw81DTWFGnJpLiwLp5l9luQeGWVWJpWHGv31 dAwJpUZF6KmBUMD5YIe1kdNtn2rKyUlNnT7VbuyeCm+2TsCemgqfzGan9f/4budjq8jq2z74qe/w 69PhzMbYs68BEG8/7lRO403VGZNL00L9FWp/jc7udGXHZSUG20ZWVlWOtGVMW1kzeJwzOUit4HmV v1qTkFORFpdhNSbkjasal5dAY8YsHJtoCAsPSUmOFkJUETGRAZGDImPs1qi4ZOekfOfcMYP9A0MM hhBLmDkuWBUSHhIQKQRbBlujYpOdHsjSUjjb9/OvwM6c27czdYk7OPivFfDXM9OdhqCUskSdMqIs Xl6B8FlYuc0ZUInbUf5Qh/Dmy4cK243OgH/G/cI9mNX3FWlg65nkUzV76ICB36+NSLLEJoXDZpsw pa0yVhcNWxLOoEAbbMm6oTr5SIryH9iDbJ813jCLGzD0qkvkTclV9W9FmB2FbzP4bdIP9iGZWHxZ 0aSJ9sK6eXNmtMxJKWiax/6ngv8CYma07QplbmRzdHJlYW0KZW5kb2JqCjYwIDAgb2JqCjY0OTMK ZW5kb2JqCjkgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9u dCAvWUJNSVBaK1RpbWVzTmV3Um9tYW5QU01UIC9Gb250RGVzY3JpcHRvcgo2MSAwIFIgL0VuY29k aW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMiAvV2lkdGhz IFsgMjUwCjAgNDA4IDAgMCAwIDAgMTgwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAg NTAwIDUwMCA1MDAgNTAwIDAgMCAwIDAKMCAyNzggMCAwIDAgMCAwIDAgNzIyIDAgNjY3IDcyMiA2 MTEgMCA3MjIgNzIyIDMzMyAzODkgMCA2MTEgODg5IDcyMiAwIDU1Ngo3MjIgMCA1NTYgNjExIDcy MiAwIDk0NCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAw CjI3OCAyNzggNTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAg NzIyIDUwMCA1MDAgNDQ0IF0KPj4KZW5kb2JqCjYxIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3Jp cHRvciAvRm9udE5hbWUgL1lCTUlQWitUaW1lc05ld1JvbWFuUFNNVCAvRmxhZ3MgMzIgL0ZvbnRC Qm94ClstNTY4IC0zMDcgMjAwMCAxMDA2XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDg5MSAvRGVz Y2VudCAtMjE2IC9DYXBIZWlnaHQKNjYyIC9TdGVtViA5NCAvTGVhZGluZyA0MiAvWEhlaWdodCA0 NDcgL1N0ZW1IIDM2IC9BdmdXaWR0aCA0MDEgL01heFdpZHRoIDIwMDAKL0ZvbnRGaWxlMiA2MiAw IFIgPj4KZW5kb2JqCjYyIDAgb2JqCjw8IC9MZW5ndGggNjMgMCBSIC9MZW5ndGgxIDQxMDkyIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AaS8CXhU1d0/fs69d/btzkxmn8zcmclMJpkk M1lhQiA3kLAFJEqABI0JOypIEpaKSolVROICdV8BW1Gr9GVIBAPaGq278kpba12q4Fu0VuUtbanV QjK/z7kTUPu+z////J7fvXP2c+49y/d8t/O9s653/TJiJH2EJ/KS1Yu6iXIFH0Twn0s2rJNyaXE3 IZr3l3evWJ1Lu68lRF2+YtXG5bm0dIKQH76/ctmipbk0OYuwZiUycmlahbBg5ep1V+XSgQzCL1et WTJWLq1C+qrVi64aez/5A9LSlYtWL8vV392GsKR7zdp1ufSuYYT3dvcuG6tPUW5pypXlfIEFFG4C +RupIw8RDeGISJJkPnoeFb4gKqRZucp4ZIH7zlSnpe4fWo+WtSI/+WP+Cyx8af9XO86sG7lFJFoz kjqlPitAO01otIksEMmZdf86JubexErOXRMOkVb+y0G+OFjf4OBPkC7+z2QX/wk5BicQETkiYvVw 3Yhn4VTZYf7jwaamCnkIYaJMCQfiRRWHWMGA11/xC/5jbi8pJEFkHBtw+pSSjwYmTx6L1IzPRQaL SyuONej5j8hf4Dj+I/4YiedaDcbLKk41mJBB+R8SC6UkSHbzH5IMHEdk/v3BgljFruf4N1H+Ov8a Wao0e23AZK3AA1/hnyY2EuQP8gfGSg4Mmq0VpGEtfyvmZBj+UbjjcKfgBLKGf4xshtsOtw9OIBb4 Qbgk3ByWwz/JP4l+7kF7C/wk3Bq47XACpvAJ5F/BfP5x/nISRttb+DuJA+HN/B1K+AhCL9I/QX4A 4cNIs3DXWPoBhKz8/rH8+5B2In3vWHgP8n1I3400C+8aS2/g1yvt1o2Fu/m1A4Gg2BBAuQSXguMR uxOxOzF1dyJF4FP+en6V0oP9CCvwxNW5EKu2aSAUUdZo06DLU7EbU7oJU78JM7cJM7eJCKhz7bk6 1+bqlPLXos61qHMt6lyLWUnxa/G+tVgwAl+Ek+B4zPtazDvLz8AfhjsKx5Mb4O+A281S/A8wj0Xo 1Tb+8oF4EMC2YjAtV9Q/wy/HVMv88kFPfsX2b1M6PQPE5YM681hoYXWXKXWXDeqMLHfZoDc/F6LW FQ1mfgm5Bo4jefAL4KrgGuEEfslAQTJ4mL+ArNYS2RzczG3mNwubVUKqkdqe4ytIC3ZgkNj4UlKH CkXBzjo6rkvXrevT8aJO0qV0sq5Fp1rDb+a383yQT/L1/By+k1cNZYcHNLWVCORp6trKHYbdhoxh 2HDUoMqoh9VH1cfVp9QqSZ1Sy+oWdZe6W92n3qHerdbtUO/QcF2GbkOfgRcNkiFlkA0tBlVQQ3c3 bOEXY5gEvgjXDbcDTsAcdyJf4i+F68RqdGLaLkU+gU+QEuGOIn4coQopC+pZUM+CXAtyLcgl8FlJ C1wXXDccK1WfLznXhtU/xUrgClFqxpPMhMNzzMhHDG4mUiakTEiZUOsodxY9FOFLcC1wvJJ3HDFA DfxzZamx8i6EasLKT8FxSjtWJsPx3Fl5UeFwEc0U0d1FdEcRlevqGyrkMDybzdYZ6Yx2xjv3CGsi a6Jr4mv2CHMic6Jz4nP2CPWR+mh9vH6PkIwko8l4co8QjASjwXhwj7B91r5Zz816a5bQOWvNrM2z +HFYusGBRKpCCcNRFh4Y8HgrxlkaJnD7MJxO+LvgjsHxJAg/CVcPtwZO4PbBD3I/R+7PkftzMgeu E06FFj9Hewt8Vs7KWP4uOJUSO4YY971yEENu70Bt5ZyGmUC5nXC74Hg8ey/a71Vq52L7lPwM/ONK /hz4rP5uONbLvefb8EBwC1k/4Afh6uE64brhVOQtfgGIwwL2ZPhBuG64fXACvxD3An4B93Pce7m9 fIlsKncEidMJamOzasUGkTMCBkz0ccW/V/G3KX694hfI5pmmr2aafjnTdONMUyEiXJw0oMGdih+S DQ2mpxpMcxpMRQ0mPM1FQsTEORRfzXz6heJfoPglcl7I9E3I9PeQ6a8h00MhU0/INDHE2vmxd01c nuIbmE/vVvyZih+TDUHTy0HTgqBpXNDUYKI7KfpAJit+QPF9zKd/e8rSaCG6Z+jfSCOeRwfqioJD HFECmh2oawgO0dGBumkIRgbqdiL410DdHcFn6TdUIWn0q4GCE8EGBz1NZwggcfTvY+Ff6QzyJNKn EK5A+Cipo1GEjwzUXcfq/xTt70f6JySsZe0eJi1K+110hpL/0Fi7BwdKFuOtDwyUbMRb7ycllNW+ Z6DkBHLvGCjZhuD2gZJVCLYPRFkHLx+oKw42WOkKUsCxuktIlGM9mTX2xul48iqkp+UaNw2UsFaN 7AVDdMpApBxBIevlszRCWpTXBQciyiDzSUTpnJ9ElE77SFQJzdSidN5EwkqoHYhch6eon4qeCP6z 7hk2cPIPahnYGfzjsxjffCT/i84YeDL460NsugaCb5UM0ejB4H9Gngm+VDBE5w8Eh0uGtCh4rmSI oweC+zHJGdTl6MHgvpIVwZ9HlNI9EZRiqXfVlQYfiCwM3hdFeiB4XcmzrBtkNUY8H8XtJZOCs+qe DE6NDlEUy3V4mawP1kZ6g2lkjx+iMwafDJYXDLGupPCMJw8Gi/HGWETpyrxxh7lqoqHr5RLNOs1i zXzNhZoJmkpNqUbS5Gv8mjytTStqzVqjVq/VatVaQctpiTZvKHtcTjB2LU+tcG1qoG1KBCUuAjVS bECFm+OolsPeydj5Zq557mSasTWT5tbJmXGJ5iFN9qLM+ERzRttycdt+Sm9rRyrD3TRESWvbEM2y rC2+jG1K2yFCaXLLrT4WXrvl1vZ22pwZXkKaF0uZr+ZiHPoLF2ZUkclu4txQ7663TbKmpzb+L16X ktnVmPj2cn8bRcydn7m7eW5b5on89kwFi2Tz25sz0+ZKl7Qd4nq4NU2Nh7huFrS3HaJXcz1NF7F8 enVj+/lqJMx1oxqpYwGrNkjCrBoJ00Gl2izlaQDTcFPj/jA8VukFOoNVAvi8oFRaoVQCjPewZ7Ww ANW4AClQnlXABVg1wEPuYZbvPsxIqEV5mMVIlIf5WaX90SjeVwKvvW3/uCgq7I+OU4qf/LY4ohQf ou2EVThEorRdeQ9V3pN7RDxXB1AwVofTos73pvH/NbFs8v/FE+jgoj8sXdK0LNLUFWlaBteVuXnD Snemb7Ek7V/6B1YgZfhY1+IlK1m4aFnmD5FljZmlkUZp/yKl3b8VL2HFiyKN+8mSpta2/UvkZY0D i+RFTZFFje2Dj26e0vy9d207/64pm/+Xd21mD5vC3vWo0u7f3tXMih9l72pm72pm73pUflR5V/NF k2lzS9t+LZncPgULyMJBzqDHfujyhdonO8XuScrmmBBy/9B3WCAgW4ZEe8YYmZwxwbF9U9pQ2sCK sDtZkRnZlrEi9w8nhHyH6eNjRSKyrZHJJEHcTZc1nv+tXbt2HXPr1yfgr1vPChHBpg3Nbc5MvXBh W6YuU9eUkbsa2ylbtfVj15Q2WXyu7q06bk3d5rrtdbvq9tWp1q9vR7btufBbYa4zvCa8Obw9vCu8 L6xmBZe0HZTrdoX/EubXA5roOlxN7FV4NUL8WHLdenRm7VqCl6yFy70usT4xpa0hTJaA26XgzEuJ HS4CVwk3F05FfgX/t3B/hPs7nECuh38H3E/hBlkOX8qXNrkva2RvbMcTDxE3XzGYqq4YP4Rw0fJc OHdhLmy6IBfWNVS4UT5QX6lvsIDxpuQw/Nfh3of7HO5fcCq+gq9QHo4+s6t9LVmboJgtgsQ65q1N rKMJRCib7nVrEwlUYGlkIIW5VaYX6bGL0LXrCaYCC4IAlZT8tawZ3oG2YxcrACpW3QY3iwTh/JCu fIRkP4Y7AffZ6MzsWdUVJDJ6efY4b0fln485QqLkbrKLFJBTtJy8QIaByR8Fq9NC7iTTyFtkHzGT jfQNzGYEHMbjwBdB4P2pxEVV5D7yHrmE9JJPyHFIzc3kI2rDc5pIN6TGdPbP8JvJTdlDqKUnU8h/ kMN0FZ0LvcIUMp0rwUxEyfbsMHGRePZI9l2kHiKf0ILsfjIdsU+JFdz5ZvJjiNGXk9ezTEtSQBaT x+i19M/grbrIzUKV0J+9AlqLA+R3tBmx2WSj6l3dAXAHPyY/pS46nD2W/RP5JWjpMjzpR+Qm9HiA DHNl/BTVbiKRGJlILiCLUHoNeY/aaTkvZwuzk7P3Ifcx8jcuwb3Ma9CPBJlBOsmt5GHMxjvkBFgB A62mD9Encf+a/rfqXfStmawnV5M+9PxRtN1LDtFyWs65wB9yGGERmYey7WQP3j9IjtJm2k6H6fP8 HlVqtD6bl3Vk/5TNkmLShh7uIs/jHadpCnXwBj7MrxMCwjpVxch1GOFS8iA5Sn6NfnyEef8H+ZoW 4/6Y+yG3Obsg+3j2E/RFC95hPLmQLCRryAbyA/ITrOoL5EXyV3qG06HmW8JLqqtVp7K3Y25jZDL6 Pge15+LZN2OVBsgQ7ncwSiuVMIrx9AJ6EV1Bt9O76RB9j77HqbkQSOXnfIZ/g/+DUKNSZWvxJCeT 5AElC8hKrMAPMdu3Y7yPk5fIa9RBY7QUI3oH7b/iJnCNuH/KvcV9xG/htwtnVTeOHh/9YvRMth+6 p0bAXRtm8wnMwl+oE30oopfTtfSP6PkO7inezIt8hK/mG/hWvp2/ib+Tf5X/T6FXeFJ4XzVDtUj1 pGbR6JWjv842Z2/AXFDIagFAUgmpIuMAP8sBTVegf924e8m15DrST24DvNxOdoPfHSLPkdfI78iH 5EusAKEh9PkyvH01oG4LvQ33fXQvfZ6+RF+jH9Ov2M2Fcce5Gq6em8JN5VZwW3DfyR3l3uE+4/38 Esjffbh3QhX0HrC0IGRVFbinq25WPaZ+QxPXTNcs1r559uRI8Uj7yEejZNQ7evHo3aPPj/4pOz+7 Ef2PklJShp5uRS/vAwzuwf0EIPEgeZm8SX6v9PVvlKMqQLybRgANJVi1ejoNrMYMOpteiHse7gV0 Ie5FdDFdiXsz7aM/otfTG+it9C7lvhdj20N/Rg/ifpoexv07eox+Sj+nf+MAxBwPaI5yhVySS2Ok U7hp3BzuItwruDW4u7lebgNW6DFukDvEvcPb+Siw7SK+h7+P/w/+Bf5t/huBE0qEpFAnzBdWCNcL bwm/Ft4VzqiCqibVStVO1Qtqn7pKPU99ufpe9T71Z+qzGrWmBezqtZq3NVltFBjrFYz7ANb02yup fouuVeUJV3HHsC/cfLdqK52HGVNzrfwq/jb+N6rl9BQv0fdpP38Zf0X2p/xU7mt+DZ3PPUfDfFBV C1XOLSRLn+Q+5k5zfxIctJX7M40LP6ZPc2v4KRx0DMCpvxUcwvWqz6AN+D2p5TbRYe4laK6uz/6C 1Kp20mOqndyviSQc5+zkGHb1Vu4eNPpP7jLuZtImVKnOkMsw7z9TXYX5nsTdRIv5t4Wd5BM+wv0d 0tXdwBpH6EyhgLuUS9MngXFHaICcpD2km95FZPoM/ZAOgSd+nH+MzuKMWK0MZ6LjoGw5wofo27ye tLM+0hjnoC3cKW4e/6z6KF8Nseco+Q25mvI0Bdg5d42SK7ED7uQKgdOagE1+SyuIm9wDfH969FmG sVXvqm4GnD3Ml5CLSIp0cG+QWuyNT3C3kRuhozsMGLyJpLh7ybXZProUeH828CdHILeRJDUAW7rQ t82gF04uDFzYiVd/Dfz/OrB+M/1v8gMqYWcNk7jASm4RmoCZuoB/b8a9lHQg9SC5XX1A9Vsyh7oI EaTRnYDyP5BLQXP+iPd7oaH+MTDbw0IJei0BM/egxYOj04mM+0byBuXIJvR5EvZ5izAdmPfu7OUY 4WWgUbNAE18jl2XvIVOwdhdlr8/eTDqzD2cvgYQ7N/s48O+G7ACpIVtV7dx8VUKoAo59jb4IevQB vRl4ezp5H/goSt3kc9z/gf5PUj1D+oXfA3fWZ2/J/g5a1jg0r/cBz8wE9lpN/hvzNp0fJpWjF3D7 s1P5blCoY+TC7GPZINWTldlVwLzPkj0aFXBPHwmo9gB2bxaWcyn0t4g4aRK5l6h2ESJPntcq10+a WDehNj1+XE11VWVFeSpZVlqSKC6KF8aiBZFwSAoG8v0+r8ftcubZbVbRYjYZDXqdVqNWCTxE6ZKm yNQuKRPrygixyPTppSwdWYSMRd/J6MpIyJr6/ToZibVbhKLv1ZRRc/m/1ZRzNeXzNako1ZG60hKp KSJljjRGpCG68MI2xG9tjLRLmZNKfLYS36HETYiHQmggNblXNkoZ2iU1ZaZuWNnf1NVYWkL3G/RT IlOW6UtLyH69AVEDYhlXpHs/dU2iSoRzNdXu54jWhCFmvJHGpowngqZ4DB9tWrQ003JhW1OjLxRq Ly3J0ClLIoszhHHNCaUKmaK8JqOektEor5Euy2A05GZpf8lw/y1DIlnclTAujSxddElbhl+EZzRl rAm8tzHjuvqE+9skHg7+fOt3S318PzhEiVXu798qZXZf2Padtr4Qe0J7O56R4aJTu/qn4sW3YJ2a mfiW4ba0t2XoFrwQEkZUGVNudDnxJ9p1uZTRRSZHVvZf3oWF8fZnyEUbQwNer3woe5x4m6T+1rZI KFPvi7QvavTvzyP9F20c9MiS5/slpSX7RWtuWvebLWMRo+m7kWWY8lyZElOqs1jzRefnlbI+RmZA aMhISyT0pC2CMY1n3rLxpH/JeEw/rnaKVpmlWI/LMropXf1iLfJFDJFmVFExIvX/g2D9Iye//H7O orEcdVT8B2GFDErOA1oGRG4M6DKJRKa4mAGIZgpWFH2cpKSrS0s2DHGZSLcoIYD0SFowt4vaa5OY /FCILe/NQzJZjESm78K2XFoii30DRE5CyuK6WMnwuRLHPFbSd67kfPOuCOD4KdBwQhwZbez8zyI6 7U0razPU+f9RvCxX3jw30gwZTGrq7xqD2ebW76Vy5WxCMW8oG4vRXENMeEaIZtTRGRGA3kUQ5pCB nyo6NdJ0Wdd0bDX0MWOf0sb7ODyAxTgfrzwK8HvJwnPPY4k2I3uWEFUr8L90SKMFACs5VJqaEbum 5/x2fSg0tr3+/xoNZU+xVkrwbbOxMWdqE2Ojyo0xM+F76e91z9jPN7cCO3HNrQv7+/XfK5sKvNff PzUiTe3v6l80lO1bHJHESP8hvo1v6+9uAsbKLf9Q9vDNvszUW9oxlJW0FkDOkcn7I/SmC/fL9Ka5 C9sOQfkl3dTaNsBRbkrX5Pb9BShrOyQBPyu5HMtlmayKxBKgedgVA5xWqe87JBPSp5QKSoaSXgJt mJKXq4Q8SpZAiavkiefqccgTcnmykteOi2GKKa1tY/OlrDxmjEECwdltmvqZio5vJFvAT1zIPUFa 4cqQdyXCuQh/zKUJLxAyE+4UXAncXDgJ+RnVK0RUzSczEUaEP5JihNNZHG0r+XxSjLwiTT4Jq17J fiKsZSGZjrAP+ZMQN2huJT7+VjJDINkzCKfiuY0IZ6H9HMQnwpnwnjounV2CuBXxieo0sSJuhGtC u28QNqK+Ce9bivI8pDk4K55vQuiDM+KZRRgm2HX4SIPjH0YokYuVHDYFuYsHV4LzJFxqyBlanFLr iQH1TZBxv70s30YRw4qDp7ERJjPngb47Ic0R8EwecCJ4P/HDz1ckH/bG/3mFwA9EILlGIWkVgjso ApeRgDTCePokOKxy8DSVkE2qwXeMg9SWBu+SuyZAsn2afEMnQPZ4g37NFXAd3Ff8SqFFVa96VS1q WrVW7eu6QX3GcMR4qUlrusP8vOUj8QPrLrvf/kreG86D7kHP73yCf3WgI7gr9EXk+oKPotl4VVE4 sbV0QllP8vflQoW/6ofVP6s5M/722l9NFCetqV9NOIoRqfyYJh5zNHs/R5/hfsnmi3tugKiEIe6X T/FEr2GRA5R4tGrVcyjnCE+LiI5eQS8l7oT4Vd1I3QXi6brZI3WkHnHxLLzyVMgaskbhUb9Azkr8 8FlZRc6Acx5G+y3gh5+FhsKEeX3w6SHPq55/GnnjUPbrwUi0SglLU1V0KPvZYHF1FRnKvirnI+Jx w/OOh/dPI9UYXUZO799iXlFjAj/aOqjhvWaEA3k8GeKrnzKZ9IIZEdnp9bqs+tXCr1yriZVat/j8 d4Yuvxp64q86Rr46abWlkzmP1I/U4VeeStCejpyuhfZSvjBWXVVTWeF05Gn4EP+dBCfXOLnxZYm0 PT26eJwTRKbWW8NHaMFGj6e+trZ83pLRD2j86hK5dkJ54W2j7zGYvRDlXozbSC6UfXpzX2BFjYEN ysgGNWR41fCu4TODYGTjeVrNm10ur44NRtYbjbrVfJ+p9RE23yfR5QvEpmWNn5J6THp5ivaiv/bv dm5njauqtHSC0qH4NQn0IRX9ca4PraMzuWuhPbKTWjlyt/UxK3ejcZuV09+rs5J7oRchRK973Bxu UVN1X17rpeyFHSdH6upErO7J+pPlkBNoB3XECmNctUjGOdRqzpHnCnDctfcs2/Egrfjqmp0XhLwz N42uic5a/mPa/zatodkrixu/HL37pXf29T92P+ahDH2Yr/QhLRcUCcXa6SoeL7eiE3aIPzo9OpA7 lObVfY42ZdTf7wTtsFc7XU6bQySa6poaW3VVYRlXdu+y7Q+OvvXPa3bNDnmar1UtLW5efvvoD343 +voovTLa9AW94qXfZfofZT24cvRJei95Fft7rlzYzrW7XnTyOleX56iH11GiEQSL1kYO2mSjQai1 OIKOPgfvGKLFOJ+xdFo4i8f9IDoFqO+YPdJxEhNzwpamVpsrjcXooD12dAk9ikXCGnUkfB5o1Feu 6NFpNIaoLa+8trlm8orto0+WhLe32E26PF1tZfnUtZ0r9jM4mUv7uDbOhV1ZL0ucqi9/ac1mFaQ8 ZsHAE06kLeCAdtDd9ChVQ01TdQB4uHUhW6qRDrZQyZPwWVcS9pAjNJdTjZzhXBBUKflx9gRdA7nL QBKyn8hqAy/r5NpqnVxf3amju3T7dJxui5HtD/GrHoAVG1t5Ksrgf2wklCTlhrKyhoYXFL8sKbPn 8tkT3CSsKE8uknVE9UZwRQ0WcogvlE0cn8dx6DawjQGQHZTzJD7Fd/Hd/G7+OK/mn6E/594Qhuia /ccU6D7NJrSuvm6rqiyxSXyRbUgoOrhJo44W+oXqtn/NVz2BZ5GZ2c/4p1UrgbMLyOGBRVqIGuoB lQqrpB4wmbxD1CLbdF4Sk2OcHOuK7Y4djwkxK8s2d0JVthkKut0gEJ7oYRrA1I6tJjZWR89Xs9mw 2cCnbJRn0YJIQbgAejCI15xaE/X78n0BH6+2xyxRQ8ztcXk4dUiwLiZBtXcxzTMj5jQiVkClxdSn hWcTHYuJRw+P4RVF71uMSHGiuPg6e5VtHPCLy2nN4zDDhbFxostZWVEzrsYKAMqBEDfzlnULux68 9oGbfrv4hetWv9iU7qlZFyhLFaSLahurp1dxOz+jcy5q2PXS6L4vRw/e9cnz/xz9bP9di3r30vRn D6xNhSbOHX0Qa3QKaF6NGXOSe+Q82d3l3u0+7haIW3ZzGyBMc+YGO/RfDcDsu0HHeCWuRTyCBf4a RlGXQUZtQPxvMo5QLVAuUpVOa+R4qHr/ieozZJvZbJGt1SnLZssOy26LYPG4DnMF9MTY5CbqZosn TzA8gtUF4qXWNPnHybP0H4mEglV6OuzRSmue0+lyhKoncdVsAtgWOkVnhux1l4xyXeOdek3UG50s vPLwma294wNcNMrll1/N/eHOYikQZHBYgjE+iTEG6Er5Rxq3Ie1y+ydWuWV4HuZZAk5nkaZOM0Pz M41ali4WFmovdi10X6FdZ11ne9DwkPk+617DXvNrqtdcr7rfc73nPi59I3zjcjhovuBR+Rwep8eV 79boXAa3Ib/KM82zzbVd0rg9HOfyeowetYn3cCo1hHLQC7tgGkI3dDo5z1jfp6O6Ib5SNooq73YP 3eXZ5+E8h/lKTNytg5QzBoborbKJqP9rjr3Tvsa+2S7Yh6hGtssYlJdIstQn8V3SbomTPM/Qb7DP TFSW8zqhjNvMbeeeg3r1GPcXcJ6e4GEoLs/D84m6HER3zMa2EtnGOjnS0QNC17NfzZjJp7fr6HO6 t3Qc6ehpT5xgKExZGVs6zYm5Kk9t8tzqQXm7uW6rqNr0ohlbkvb0doAOAIhJgvKhakKqq7BUak2k ZoxYqjWcJlRRUzOOf7Lz7HEIadLOK5fuikU9bz2w58PUzEe/mUQXr1ow1UtVo2eidDK992fXPbq+ 59DLb+9YseInB0ZPjRfL2enPXOzy+VjPCjrrENFnjw8Y0zpmzFRnTDfomvRTDc1h4S0dLSoaXyRX dVW9VXW86p96DamiDbrNkavLnig4VHC47LWyY5Fj0Q/KPg//OWqcoS0aorcMxuMiGeJODB5N0dQQ X3WAV4lO6hyiuw7ky4lkVT6sCwZFU1H8GboSrKCO+yPsn7AG3A5lDbCSgxkjNQ7RHcgv7SvldpTu LuVKkX+gU7MZYx/iPpH1chXdXTVcxYGHoZOelu3P2Tm7p5IhnM/OIZwTDN90nOzowfp09JwAHwXU kzjZW3+y4yTjTRQcVFOWDMT0FkEdDkVCBaFoSFCrouZYTA/kkhRKF9OABbGQoXAx1evK1KnFNGjK Z9hGrBs7Ziq+DhdWrKejl/SAWWDLpACpk0GqOjRGpFzYfAz7MOLFNl+E7UO2spqVtftv+OmCyYc3 9XXfPvrFtiXJkMdrvcoVLV5+T8QbTNx9gTRn1/Truh5YKczcdtflcxbeubP84DWZ6x5vLMwv0arq 1Yadq+Y0j8+PNwT0l94wZ8XmRxkOl7BbD2F19eAEfy/HnSZqIU0m2cLLFlpspA4NEC7ldSo1FYwG ExGMJkFtNGFX+WWbRpun0Wi1vKBRG3EGYqKmZ+iD4F0NdJdsUlG1TqtWa1WC0Sg8g8N5nmjpctmg 01l4uovfx3P8EP2n7Kb1yvay0C7gq+MW3qKWNVTjMX9nD/XUKStUhw2E6Kci43Lr00kRFFY8KY70 1lnTVkb701vLEgLoFYtaLBZgtF4wSj291BGxRqyhalqJgPKHDu4ZeYFbf+We0QJ6+rbR++nyPv5H Z2/hHh6BihT0HfR5B58BfXZBGuU9zPgj37SiZodnN8iMTDRG2WawyA6Q7aodjt0OzvEsjUJC+Q34 NoVVO63scoV4gfzT7xBu+3fiNAQCzoh4SbJhMgv5TI6alzWM2JWMsrLJrD+QiFQZcKywYOLc+yHy tuLAlwYDXCCf+AN+kh+kAT+X90v+v4gLTgOn5/9Ldmk5f4C3aP3OfBLsxukDR6nWwmlJsh5A3XHk 6JFkkuEa8eTJ//6SJnOXuGnriy+KcOUpn+zTmi0Wk6gP6IItIbXDYhe9Vq/P53fnq0NAAAPRahYM ptqqlDBRpoQDRblsKZbL9gZy2S4le8ChBPI9or3KZDHg4WnLTMtUcUZgTqjdskCcl9cWuNyyQlwZ 2CD2CVvN/Zat4lbbtsBNwQcsD4j3WR8IHLIcEn/hPRR4w/K6+Gr+64EPLO+KX1g+Ez8LfGP5Wvwm /5tAic7S7OOCYCkwSSQ/EPDrzHqfzul3+ZxaTuPTOqx5PsdVAYsoiQG/P2wV86zdkEugwDUPca/J Vi4AdikQzN9DcCjAJm6IHpCNWtHCO5xOrVan9cOsS9ZZ0IbbY5atQ1xqcE6ABoa4L2WzJJtbzKfM vPkx6Yp+BR48XjCobi9AVWGrGNjW14FvrQMgbzWXJVQA2a0d5jJ3Yitwe8JNxJNUHP6f/lZx04t1 mjr8GPYfE5AYN9Pb0U5DGrUjTyHb4FvG0Uqao+EKE2zg+J+N/P2S8ITFo/PmeSon0Q8j9N10x9yR P1+Yjl/56Zf05XfmFAaTmmjU4k7dIVxy5t6bLlRFo0JZqKSTmriCkT8wuj4z+7HKAjgsoJw8WRdI 0iSX5JPBuy33BX5q+antoOVpm0EboE4X3cRf47jKeSvf73yIv9u7l3+G1xl5s8DlT8cBoiqpFa0F PqBj1QHOR+lhiFfNB6X7VXE/T4e4Yweg3BWpOMQ3HNhu2mXiTEN8Uk7m6WCuSCmtEPfus9Kgtd7K Wb1yjMZ0dZKbWtxBN+cGWuLmuWdEly5ROMlER+9sRnm/6u2ZffJ0DwjvCDD86U/rT355GhN8Etv0 NQW1Sw6f2gimJmaIOaNqn66UGB3wtB5VKdW7TFDtnLcUuO46TDzp7emg9ghjjJjgZVN4RZdaiEhM UrUVMLReWYFVEH4dDE769OGt72/acPLeG17fGFw+euqZ0X2H+g/S+l/csb3Y5svzGlRXjFa+dXDb 6NvHhkb/tqPn8bwDj//r8Nk3aOsz0512X4phAHB/qo2wMnCSEOXldoPPkH+jeJf4O1G1QdyQt1W8 136f4zXfa/lvi1q31ZaXH+A1DrrVe1OAi2vVQR8JhTVBnykUcYU8wbjZbOI8cRhoav11c2yU2ESb ZEvZZJvKNpT96CCbQ9uMCCPwk+qr5QiVIrQ7sjtyPMJHQi613c7NcxnBesJnVV0Qr4yiyM1TK5lq L8tU7wwvGluDBDjOEcAo+E4g4sRXyqKABRJPMmdNpxnjCRbf7w1YHGI0Lxaw+OdTrwNevjU4n/rs nvnnpp9Rzx4Ae09lNZtehTkFeQxJAmRQENBCzDqxigSkMlI5v8DpL5xdycVxojzx+b3Pj67/YPP8 z2jF6H+eWrg2Oi60ll+1WSqJ9o/+8rejn/zy7cV+OhXnuR7amM9gvRgnYU9hxitpjVwvV6/w/8D/ QOpn7r2pZ1LHq7XzPd3qbs1m7WZdn7pPs127XacrCPryQ+Fo0JcIRbQymxBtyGwO6nxaDZvKEMvR hDguqPZp/KKPoxHg1vxKsidRRkpFxrZwv5VDJSUJANSefN9nfn++VrcX1oF76xkvQzSiZo6Gx7M+ lVuUZ20o21uSCJYm0XSVd68EbH3Mx/vmtlR3V++u5quJqCyVqKyKqCyVGI4WKEtVoGQWKEtVsLPq +CG6VSFcbJmUtcKe6Th5uuPECJarA3Is41nFL4GtEIwqaAsUBBomRmfFk18S8R8J7CclHJMjOqg1 xHYACK7CxISYTFGpyFTjKsGssvX7dgHZXoKYhZP+4nWFVepo1Gy2XTRv9B0xPv7TtStTkxri6898 kUolJJe3oDUlOCyFjsqK+DIVN/JZpGzdaHyJPxIfbVhY6JKSkzaN7o26RHkJ33NdIB4d/f0VLQ4o GCmZDuz1BLBXFe2QW/XC1DLOU+iNc6Jb9HBSjVzTVXOVttvd7bmqeId7hyfjzngMpckNhq0G3l1T 5m2p6a65Rfi5cLxGMPI3GoZr+OnaQNDn/nvYFvS5QpEqBZ8NKvgM5omEb5anlN9f4nK7w+p4CW+O h3U0EQwY2fYJKNMfULOdEghbrS22HTbOYptj49he3GzL2gSbwNbYhg15Alo0xIa4r2WDvq4lRi2x YIyLQX8vi2wXxkRWHptRvRS0BsqQBNtgWLdkAtsNBIat6QlFkmZLJp7DfGO7rkpKaERtNF5YVFhc yKuNsYKoJWSdQKWgaNUk9KXEFIEnSuYJRFeoLqWGqLmUCdCQOhgVQ6w4oaDEhKKR6gVmZIgRaykx cpTDjNYqYMrqkAPbUu2wqtU5NAngqIFOT2F1xwl/xj5u3fjL0ZGtPXf/va/5loZgw0WcyXNBft7a 49tGf/DmffOXD9z1xsyNa8bb7T4eKLN194Xrj/z8Ly+MDt8Vi9KblteHYrGq6OrRRZNqz/7in4OP /OqyBe4iR6QSK8+w50PYy030Bznu6elpMps0Eh3KfnWArUi0aih7VraxaJWyK6qUJaqyo4JsZ9l2 GlbWLqzspDDUopAisURhpWLY2yCC68qHK4FLwpVBTf5fRAdXD1cHfswwkRQUlE3kyvx6jtQnFS7s CJivL79UPJrEbCaGj2DlEokPE8PQufjknu5pu6cdnXZ8mmCfttMv17QgygHiDKFwOOjzh8JVQV9Z KNwU9E0KhbmgTx+K2IM+XygCRFQailQHfRNDEcxApKDAN2niRINBz5WVlvr9Pq3NHubkMD0WplI4 Fe4O7w4fDR8Pq8NDnCR7xWld04an8dI0Oq0pGq5ugVTHVe2cuugP7sRs8XQvUzOLPb1gxnuBBBhu yHE08HN4gY2EXYr6izLmZEyRcg4MAAd5Lrb2lVAz5HA5MMS/5eR0L982oXu4DSa9lEiluEYFGZj0 wZJUauTZ1NyYZ6RfKSofeSbVGnPnSrgmTCIYg9/TG1aGPDZ3FIihYenZu1bkEuXS1fSh0SXfpvgr vlON4YxKEN+rADlB8ry8JqRg9ZACOiE5Xu0JLbIurdEGfVwo7A76bKGwJ+ijoYgu6LOGIjYrBzNt KCUY9Hi0bKt6BAZ1nrCuW9unPa7ls1qa0rZou7R8p3ZYe1TLawVWTatAoBaa+KdYW0RG5XwGa9pF UneoL3Q8xKdCLaGuED8cOhri2KJcgJVgWx+bvwdrkiO4WJd6tkOxCsyPnp/p78/ruZXgrvq3qcOk KlMajUYxU/yqb+fp7J1KXKGT2Y95K2YoQv4sT2iy0U57Zx631NXt2mJ80jIcVdncNBWVo5xXm5uo fGWKnG6/6PTgTC+VJ+dxLXk0b4jXH/DETbp8/1D2X8q4ETn9FJsPFpFDbOr8YZ0upZW127W7tPu0 que0x7RZzJoyxZimz+U8ZZqcrK7WGz0GLvJ4AazzywdDx3+C04YLTnSIX2EqIETOzmFGIEZI/NCE KdLjOV5E9Pr0Rq/RP4Ea9D6DZwL0K8B1DM8xjQs0y+dwWR6QGZPav8VkCk8C9PcmYG9uzD3lkXWX rvKESqTKQleBL6nMp6pQmdCRy+775a0ddeWeYPHFNZNb+Z3n5xRna8LTmFOJZGSfSEQqEYnK4QUw /PoB1y/dJ/1MOiQZaXiI3iZXmpfWzOMuCXCAOj4Udo7zWSeG9UGfGIpIQQnHXTLE7j/5rfj+JcLx WrKXruKGuBflpPN/Y+V0Or2C1fQKVtMrgKjfGVrUMUZaGBenUJTTpxU1Fnb+iQ7GwrGd3puA2t01 RtvP82aOmDq32RXqXyPcHVp35tPK+VGHwpwtX7VAEo0V1y958Icr6Q80ozui46V1/BWMMYtC07/x 7N65QUde2XrsxTAOEf+GWUnR1+TPLG5qJlqX2WOKW4osxUJKY5tIJybb3WvoSvfq5Eb3PfT+5Bvu 992f0S/cJpMbbLw6NTXF17hrUtPcvDNV6I6leLVblXK5+AQpQmoCqXWl3dWe6lR9xZyKlbAS2+De 6FmX6ifb3FtS95F7Uj8jj6Z2V2Qq3nS95h6u+AMUk0crTro+d3/uOV7xFfmX65+pKD6VcU1NLqTt rvnJy11XeV52v5R6x/1O6hP3JymzJejThcJS0OcNhcuCvriCsbWhiBj0OaFTCvoKwaGDYSA0j7g9 hHrcbiaNTkol81JuVyrphsSFvkPJ6XFxOi2+RkylCuPa1MXAUp5kWViSQrtDmRDDCsdD6tBOuYJW UKz2a7JJtEgWKzfPsrNcQRfAFQyHgyX/qoNFAP/JUeALBZErwiliLqYc3qodE0+1kE6ZnDr2cQfD 7MA1PT2kpwNmCrIvKULBSnOemHa7rWm3aEsTrTvtGsoePeBKu1J56ZyyUjHBbqfYSiHKkP53iICi ba4OUXp+h32vmPJTR077oi2p0XgK/H2euRmnNPRLeoL2JReA34+2JEeGUwsizpF/COvPbtgULI5G q6RefsPCeH5h9MwHgpI823++oP/MzcBi2U+yn4M3nEUK6fNyc7+N2rZTyLhzqrdz1JbP0UKu1D7e fpX9Xuh3s5zGHg7bsGb6UBhr5gvBrBHrGslj6xqx2ayU48K2cJ7NFsYO/YlsKdwLhaCOcj6v1qbj lfUw2uZarZKYEmWRF/HZz1NWLA4iOYTHIooYJu4sYrKDCDGsiErsA8fjRVyRPY8tqSMUSoXpcBh8 icKHKMwg+JJTsp6hv7AnvggoT2EIx/AdW25FAgMCRPxTRYnGOHrw9yehOGOrS3AikFaWWMMOr0hH Lz4uiOtsHlsR1HRp2xwy09ZJFtrWkMttV9segPHqM/SA7Q36L2r7C0cZD9gO1SbtAUgcIlz28cGA rZ7DGAadpnows58dBFDJ/jSLDowFPiV10JMGtWTRd2WLLW1z2qD7dsB50mDC3h0wpPGYo7ng6wN5 aU7GwQUja7iUwxyESLeTDh5ABTBicuEYxxn5dyhThA0f7eYnMoih7zJYKjj7I19sDgCLAdKEiRPy J6hmndXw5nOgcmab0Hj2F+dS/L6mErsOkjmwkpAA5ATxnd1Vh0gZluuO2upk2Xr3Ot86/7Xx7rK7 /JqN7qcLDsc/8H3gf79A7SkUy+KxdDRdOCGeKltYeFlhd1lfmeFlQr3+In+z//eeD3yqx+P09YL3 XO8XvFf4bvyLArVfjuTHteagTxsK06BPE4oAmThCEZIvlRTnx+sjcyJcJKJxFEOud3BaDQ5OvaI3 5ZW93V6Vd0YZAyNI86SMymWZMm5X2XDZ0TK+rIQqQiJV0D1VWFsatpgViDIrmWaFBph3lpYN0R8M hphUn7iAcRpjTMYYTHXMZt92xPjSP+N7MgQn2xXuAwI+UzVCiZ625agEk/QLilx+dzQeK3LFKmmB H16hp7iSRn3g1sdWE5L+jNaNshjAFotMEMIBaQKBuSUBHQYlJglFCwO9bi8DucS/r+/Y8lcwvToj 0IUQPZk+XTnJoo/4Y7OrRp4BDcrzQUFA/3rwNzs+eLW8t6H6ovyV90y/obWyhbtmdH1fEDRofHAd v4rFmgeufvSoeZpe/3Bf2z3Ndqz89NE10MlcAQuVGBmRi5pom+YuyqvNMPtu0yynG+iNdAe5W/uK 5ROiEywymUz5+Vr+HthxHJWTWmdc5EkA8j2j0d2kD4YyF2m1Jj4Rrgvak3aO2EW7ZE/ZZbvKPiPO ls9bXy3F5TgX99aJJsnEWUxB6MZmFI4pu5iua7bYA4sKRHASnjzZAeamrv6kePqkomCRdTEp6o8Z jHojp3bDfjUa4dRBR7iU5uu8pcRlgRezIhnKC5RiVD4jAp3WY3aW0ogNnnKSce4wA+emibFV6FAx TWOsoIAdVzB7hJBErHmEQtqzKueouWPUGH/j8pP39I++PPqn5Ttar95K+2E8r6db8BnC1QfX3HLb lQeeXbt1ZvoXlsyjRkm1bHBZbcMi6nse2pvbR1ePHvlm9Cbh8x/9dDQz+vTAtm0/oXV/f7RvI+NA +7IfCyqsw3hugeyx3VWCTzgtnAEfNAuw/VEl5tA5nM5aO0Snykdrxtd4eZ/Q6e70dHo7fWqVSWUm xcO1wjrDOtM68wZLd6A72J3sTm3T3mjYatpqvsGyNfG48HilaDNVmqpM1fmV+VX51UzxWSpIASlY VFQKZeokrl5IeVKBVBDHvFUTq6ebphe3GuabFojzi+YnoJ0Pcr7KYLWvptXd6mn1tldcUnlJ1SXV l9QsHGfmDYYiu8FXFDFItROKUrW9tl77toJ7Nfcm70s9nhyOP1/8cmK49lRt3gXa8T58TO7bR9+C PnozHdObyqbq+8txGr4m6AsEDudDkypXee7Pw+LUGc15RqM5YSw2CzGdEqgjdARcVLycj8SZPpXK gXAVlOTQog7RiCwmrc9ZuWP4CMW6z3rMykOtvfXp4N5AQmTnpqgQ3FVGnyv7S1kWqEOeVi2XvYUE T8qkshQQilD2LJ1K0lCjuccO1joSPQDG3tPsuLN3pDedVEwZAJUMLzD2Ah7Tf5sZX0HO6yaUWAcV e6ChzR29FaQ09njMUKKrJEUWhjTs8DQpJPWlxkpiMJYkCkWgEIu5qDhqAxrRJtWVFMhEQReKlyMS 4OGhve0AUdMtMSw3rRCXJISOdhzJ9SZg1q5wMkaD25IWUpZ0JRwjMe3UGinjoOqFiY0TRjYKTlFO xXHUaq0McDncUhgriOWsTHIqDf7JqK1j7yUrb0pM+vMvb27+y7MTqoK/8nryoWT3th1YtenH42oL Rx+5Y9bxn6/aON7lDemh1Ehs3X3p5gsnVTZvWr76zgvvP6ZT1UPN/uvbf9x1w8KK5SWBX627pfX2 31Z7gkkG+ZNAezIK7fmrXItPTbiF+QsDV9AruCvyrwhok6H60JzQvap7fI+rHvVpOJofcDK5IAxJ wRKKaNwRHCeJFm1oiBuW7dBOEdllrrdZQMpa8LGLgJPZuOzV6hQKoVOIgU6hELqwyxlMBBhOMrMW JCAGOgO7A0LgML7cd2a/lA2MI3EqlMOJpw9KSyFAMMnrNGb+EAng6MhQzR4wYLBUYYITMEjIiRXK yhDZUA13rggWVuBSRiDKUvE1prFnnGNOywQq/28MJNMxYVnswsOWmMEeXNH6HKh6cuR5RuJ/2hmv mqmJiapZoy+0FtSOO3P6HDkXjGb7qksoJpQSQ/a4aj9mtYxef4ikwLoUJ6tS6OugVKCEcqvTXxVX 16pnqTdahGgkWlgRqShsijQV7inUFBWmC7mW1DrDNZb7C58r/DqmrjPnBN9g0OcJhYsV8RcqGnco AvYeKgIuCqm3GHzeX59is4bIp4rUq0QYJ1fEuD1Rp9PKxrQWJkKSNoXPxZlMbM3Lg5yrqKW0akXy ZYxjToXAeiw31leLKdqd2p3KpI6nhFRQUhZTUhZTUhZTCttsm+10jZ3aFapvh1Ya2q4Ae7Pdkzz9 LQ/JeEZlkZh1DvT4uDoYG3BekM6pgVh+ear5wo37x2lB7GOhuN7KTsw5tSVaGC0wS1AnWmPGIugS 9SExWkriBnhsbevYSTkUimyPYi+SHrZl6XkuLidr44AF6sTvMHd5yv4bUyXzv6bHK1sSjgtPvvnR pympCer/mVWtBZ78WdtXbvnNbIicTPieEuwZef/Njx++/0ft/+Bsmy6IRqsLekf2z3mzd+a6A+9y UUifgANf9mPNJsBBmg/ktIYHdXR8USzPOgRdHlhUfJjl16V8gsHGGXCmCnWeK11fL44cxTVMk+z8 1KNTmzT4yF+n0etT6rTGZnbb00Y4H4Mnra4KYR8LoeLokz9DpEZXnZypaxfadI/p1DF1QltiiBvj 9ri3yFccLyyvUae9Valp6kZNs2G6r1XdpmnTtuvbjG3etlRr+WXqpZpVhpXelb4rKjcIG9QbNBv0 VxmuMV7jvcq3yX+VtD65RbhF2++/KXlTalv57Zr7DHfY73Df573Xd2f8ruSdqce1T+ieMDzhfdz3 M/8T+Y8lBzWD2qf1Q96nUq+kvtF+Yzib/400c2VyWWpl+TadMN63KrAmeGWpsEyzTLtSxzfrZgWn x5uTQrtvQfLCFN+iadEuNMA0AIfRBoPfmSz2FwXLNWmDLmfSIucT24RaX0rnFwzW3Mz6bFqNgRq0 6UKowiGN1rOjhpfYNUYu0mmfXKLz+7VQVECJiZNdLVFTH7F783z2eLLIF7cZrT5bYSDmK0yXj/el h7Ldgz6DXhrKrpHzUlqNZDQYwj7U9nn9/oBOr1dEKZ8fGf5kvlYbZrJ2Klmu1sB45DXZnypHstxu K4zHwcISfCmOf2zQ6CbsVO8px5oNyNUIhgdqlUCOwWI2Vd5XvqOcn1PeWd5V3q0kjpefKteWf6b9 k+4ig++A13CYk4gX58cG2dhiPAqj28dqJwxxlw+G2HExGLiTJzziCbc4choKVmyBEYYAGQ07L58z q7yt5k0vIsSR8fmIdiyHkVP878L/PD/+nzka0VynxQ1pr10R6TuUC7uPMeLYgEy2z4vDKqQ+wDwp BS/othnqlQqgjVDuOmBzpNbQCDMRBAs4putn5JLaCxlTyO6cOKZkUsaKsxzNpurJgbzE6I3x0TdG jxSMri415jVNoF+5q8eXUMPHccnhNdk9HnsRJxaMryqlAuVK8p2xiapZ0VhV5IYzz/BLzj4kLP+h KwYdZSoc+eGIhtvae3FFzG6yaXGKlCqq3DwS5L64NuWC8BRlJ6kzsifx71L7YAM+kZ8xZksh1Ss6 3Xpo+rl5Dp+mLKo1GHAooCDIKDHin5tOyQabjZtX6WRVkP5IQdaInJYdDGFWKnUr0xol1EBaAvqV dGhSVkkCQlFJqsoo6/BQo5yfz3wrimBk/bYcYJVgILPZTd1Krlup4RajAU0dvg5IwowEq9kBjh6w kDiSHIFIlX47cQTnBUeUrMTw8IeJxIvi20eYotcnrzH4+ys529waapOC6b76x3UH9bwtYdtENlXe SG423Fytzrc5a8X6vnpB55+lmqVukprCs2rl+m35Wr1ZI5HwDNqsn2GYUd08bkrtjIkLDCsMW3Q3 6G8wWFqd1zu5YH1nPdelhRF9XVlRadUz2IBGYswOH9SljXFDGsOCtFJbLQK6OQbiXUZeUoINRsFY 52YifpEhPcfd6V7j5pPuzTi5/2EQulqMOFUn13EYdjcz5yqtxrwN8VNlq2AoGy6lpV1RUmkyGquq MPFnsQLqeZXPsH+tIVH2RnOaRIPRvuiOqCBHT0W5viiNiqxS9BluCkzrHdiowTRsU1fIAV8yXa6R zWlJ06Lp0/Cihp7S0BaYHU2ZNOVKRW0CjrU3AbOBkwkQOKY3AYei7ELsRCjNSP3pEWiTT/bUn+wF d5uwplmdRCKZQ24DvBHakHYm/rLlUrjYadUT/BGVfdz4mvEcLKP0WpishqUwp642pCEx5dv9xGa3 BE1+Go5MUKX9ZLy2SqLVVQabX/RTcxherbrOz1hSJgRTRi4ZxSyGBStoZi++OOkBIwsutm2g3sY2 ZkeC9GIDP1WOkQIijw+ISnDQnB4nYexMCWNkwXHZYEi7JRhqwoEWnZK9hrQeSzkOTh/XI9Qj1CHU nde6MGhkF1Qu7VEggDFFeM24nK2a2uE6Z63MzCFg56acALMzYYcik1vRBugAkjk37daCmomd1wSK 3vhywdz6aIxLxqLJzK6rL5jgt+ldFtHoqOteXl5L7ymZ0zh//KwbVls9P7p8SnnjVfMLti0Ph0tq yyqqSufvKApOTmwZfe36CXkaU934uxvvoB11npKu9HRm1ZU9kz0BO7fbYENRQH+T2/n7A/hvttM4 1gHjpcozEreiOnMDgD9VjiAQOascvyoRts8ROQ1tKuobjW4X/thLZ2fsgDVP1oFhyoPUHNUZQu2c Rjlxrf8wkRN0lH2KMz3xZWxacAZjFDCGR/B4BNqxNqxtQKWKwZYMaEQ9z80x6GXd+Rq9ULOX//fT LMtojEWZYoWdEyaGWezI2PuOMELJWI+NYow+oj6oPqD5PCioYlNMHTVSbD2/QbiR3yo8yj+p1UzT 0FptXqGpwR7Ia3S7jETwOYkYoud7Uh5U7VBxXao+1T4Vr/rCiH/0chcYjaKpxdRt2mES+uBlTDCC ZeqIFKLDpqMmjQm7/+m6alNX9IXmnP4RG4NxiWzzjHT04twAGK233upKK3bHytaIeyTeoIlJfECi Xr3bTzxug9GvRSoohCTqMfhg5ab2wVQRAMcAX+EUoSTqYTDeQXvx70XsMJmZUTJ9j3LiHNYUwpTZ ek73wyQDOmHL/bf+5ic3P9myZ75FcvuLzdReWrk6ffFDDy2tro5zXx36669P39VXW8sfeHC6V4x0 j8RH/lBR+epzmV/4oNEgUwFDM0E9QvQfA1qBnqMfnPd7JjAKDVA7oxadpivUHeKYcZxyzBzKB8Z/ yg6uHZHXDzKKkl+OP247CfSd6Kh/8aRyBnyE2d7ttykWOGuLS6tIhK2ey7RAxfntrcJc1Vx1q6bN 1+bXrFBtUPWRvtBTvpeko9Jx8olKNw7/QjDfPc/fGelyd/k3uHv9/bbb7DusO9yP0ke4fZFB/JfC K5pXPH/WnvB/Lp2mbjU307bAdnPwZqkvciqisUr0WXy8KsEFgTDwpRVDwCnARVeoL8SRkBiSlMPH 7tCO75w2nAqZQsvzj0H18oozqtNgeO8O5KVZII+3pTFIQ+jNoJHOMW43csakqJxLdUHvtYNk8OnY caJjB1UceWKt93ov1+Klu7wUXw/AzvKUGv8nIapzH6Ko1FPCUw5xP86pF5hVV0dvz0hPx4keBawS CZzm9cCurqf3hG1si+nn5i/JX5vP35EPfNzTjr0xfvx4/MMGjLgANgQomyFIIroZT37qoD2tEsU0 xYIBVwIzDu8XcwiPJgBiPVQN8IIxLlFgDXFwO2BkmF0DQ2TAbfzM6LvXP/gZpU9t/Y/ykgkBqyES mbR04oUPb1t8wbgqesmBX1H1sXepefvsWDLm2BAMzFz88CNnppRtxOgbsyegyboNAngp1zwGW7Gk cupcpMYpFuyqlHPkMWAjUr5TQVhOA3oKcZDBk6SIg5JSG7lfyzlZz81QluQ/DFOEfEaokcoP2hjq Eu2yzgxZL49EsXAlJQwcsUOBuZJwOaOEBBiMF8VhhsUYj3EOfV1kQysiGXieNfV351M5vyufyw8a 8BiDU8FhThiyqOehhziaVc+TcMANn2PYTJKSZUVKHWVw+B8KdbJMwWpHEjnkxowhEgxdfNjRcaT+ JJOvPmTY8xBJQnyaNq0qiQWSJ8PstCt5rXCtql/oS+5LDic1crIvyZGks9iRmKeap21N3K3Bn35Q KTlOP00/X3+v8Fjx7qRmOHkqwUkSkUKHAe0Q++WmOmmOdKm0XL9KulraRXZJT2gOaV4uNsS09kJj gy1gb3TkFzob/IH8xiCaGYQShzJrwRJaUhLkDUFiCBnxDcwK2ebocvY59zn5oHOHk3N+UdSiRl/x D7dVLHx6WrV6StmUzWPnM7NPjvR2QMHBLrD6zO6coUdRwY+wrWKfZyho0htLCNrCaExbJJGEAC+u iUq0WFWiIEYmLjMLOQC4At+wlGM2ou2gzgwpwjARhHhMCc4wIzPIqhjnUkWqrUy9NQbD3CtT+mbe ffzrX22cAwzpTZiotdQScvpKDaOnytR1S5JtTRdnVl28YurEMy+9RKfN/tlDCqI88+HD0/zWSM9r 9N3G7vScla++/ntA9Czgy7mwpM6DacymMYiOa52gd0YLQJDgjAGBWUGYZkdKJpSpwzkCk2f8wUV2 WMGVLCJb2QkZ/nDLF7VqmC0cjPtRzFqzyAGGU/GJZPYdpQUirz/NdoNQbjAAgBh6BX5ltvwIYdHG wBrkOHkEVjbnoDnf0YePkTKEZ11gp+ZKJ3JvzNnwFTAQFvEffhkNPtXsAuO4WyNobhd+IgwIPHuV BkNjOzHG4DsvLxjAOFkUowXYs9EiMMM8Ab45GPg+CU/AIBt97XixoyNRofQVPWXgDq12p7vD00W6 8t7hVR7JDzbNn3biGC3IZkY/ZWaVNshIBEvim4oqJXtucVmVT+3RtdkvdXbi65qLvRpY8as1+FpI 5Zih3sbdot5q7Be35P+Ue9J9wP42957lffE093febuvSdGm7Mbptuuc1r1pOaUDpNKYbOF7H9oka +2RmjW4qN003J9jKteoW439ottm3ee6zP6J7RD+kPaDL6F/h/sQdN57W52mPavAl31EN18NCNnc7 MGkZiIubhDyScjrYCOw47+t0bHbschxzCA6H77cCxQoeBQFB8NmAnQXvytNtaTbHl/gogwHNmzhC 8aUtTrrGudm53ck7T+fl9TGDmh1aLgULkWNaXoSpCEaizcDYRq19wuwQyDYGV/iPUlvKzKy0eWIW zZKZP2WmZtYTHebSPCUwZYxzgQgwewQfHIDBZ98dwFIkwUwh2QbFXuvFoTnjtdc4wGtDPGAW3SA9 IDFQUI4fj4NxOqXtKTXBeXBPuyIcoFGOIz9ENHibIZI2yqVpExz0ecMD8TSDZQQMRwz4cilfrmws pc+l9LkynZKSzbq0A+ekHsmaNsEpkjljlM5f+G7drs5ppV1jFAy4wOmIhkC9QL7U79OlS7cu3FIa dLx+754v/nrw/pdHttLHVaJnSc3c67kJb65bt+SqvG0fU/reF1TzxhO1bQXj5evAD82BoePVqltI gtOO7e5oqUKvSmXGLZcqcrUPuj2zmmrNRVTLiBi1Ya4/l/HvvNj6NpYzdtSoZuQJFnOyXlsQDeCr b5h2DFHfgE3Nvlk4OSwO1x/BlxU5ogSSNCy+KL7MbjBMGOvYRj6Er+RYG9iX++T8InUBnqQtYoeb 6nlUzXYgVfhqpRvvygZlNyr56Nb7Cn9tNpeWnCNB4LATw3j9EVAg9jWiT550s3Sf474Y38g3Gqd7 tvBbjKr7BZos3Rxif9i8S7tLt1Pcac2U6kR8M851FncmOL/W/FRAe3uYPhXQDPFaORgJ7Ao8hw84 rAVRF020QPhNFRfZrGqtRi8CwIfoRYPbIfAOcV8N0OLEEBVlU7yI2ixW8XaLhRYwYB3s6qpSwtra XFhfnwsLypVQdvpDVTvMlIF4p7nbPGw+alabPSWH8bmnZuyAhkmsCUi5AF1Ftq1D8GnHiV5F415X hw9r6kcg2QJbKvTHFi3Mc8aijljUGfeTwrwCv6IjYpZRIDXMKh5M0ncU8szCN1JdiY+3wZyzL50Y HVIYJkh+jkoHfdQfnTR35MOi+GTPwEDbgZ7L2mqrAq7KmcFgrEz2f8nPGnm0L1xSUBBvXMwtnF63 7ZfrG0vHB6pDq+328hXvTJ4O8CMTR6fyH4Ann0BmkHb+HvlHNmfLPbH7aniYVV/MbSjegL9dKFaX qS+6WRLqx825eM249bHui7cL21XXu25wb6/un3R90/b/09iXwMlRXnfWV31XH1V9V/VZPX1P9/Rc 3TPTI0HXoHukQQNoJI2E0ACyARtHIxHMKWvihCtx0MQ34PUoztrY8S9BCCGECWYgWhavLVASTGz/ Ypv1KhiMhLUsZomRRvt/X/VIctb724zUVa+qq6urut73zv9739p7138h+gX1ofVHrE/bDkUPqd+r f2/t/NbjW1/fenprPKaH+5VGaCC91faoc3SgFRciloHMaFzQll3o+uMKBkMuJ4IOAcBKf3YoAI0E Yv4JwGJojQCSuzWXfyz/XN6SP8K++uTmygycLRxqeOnYwFzmscxzGQuvpMFn+BofyeBYQ50dZaNU wTiKyqPWaJWGziiHzTGnEdzpZHudIFC9OuFs2B9axpYdsfQaHm1U6tbYuDaDKsdnxX9EXZbLMgYo aq8h2R0aupRVq/LYdy090HcpLJvCmKXHSCNjsLNnX89cj6VHJf3a4yG119No1iwzG9gGujcvxjaI /3ZIwTfyPXQICAKfYIBtQBttxpPWACvV95XY+tJ0ab50vGQt+ehIvGUiXUC8YwTINi3dqm/t2Wps 3Y/f3LaVfq+E21Pf6tv3xZVsJY/irOzVI0yOTEdegbA/cu5dw0+fi3jIMIjwa0Su6Vkj+FCLtXp7 LOMWcdyCmmiFyszwGLRkna9xVqzf4/49EU/RPVpu2rL1O+x2IcOkxx+gGCwNC8hyxHY4caqy+4RS 2WViByu7SfpXdiknONgaEqmtFM6+QSqipZwiLCasjN0KfRgHQ0sceiXz84wIPYFsKIwytMI89Er+ 53ns2U3eLLntkDjn6z4XY0Z3rt00vCLXSCSjKkNgoK+3v7fea7GPFNYXavnOwsb8hgRLLEEN2NrG mA6IQUsXLrG1EsJ411hCuLKyQWfL1ZUJNlHclGAbNyWH4zg8vkRY1zuqs7WjjQFDXKZDjl9qXZpg l3dfkRCuKl+hCyuiy9CTgm6Sh5guLCgifOGPoN/0h4oMUna7eLDJkGoKeLQB8FcNDPE4MGD4xCRb zI1yyDf56fZs1pQIRR4GohARKh9ND57KaAgfPsg/xczUa7skEj4YJWLbW8UCa2zYcmz/H0+9UPGh stoiV24bOvr15auq6UxPYvrlS7bt/NhXPnz+nrVuf8OxvV5psvDojuX18XXXrehf+KC7Z3jHs4e+ 3V9/+L+zy8ufm7z/qGGzu6IxyWZfPT1zOFRohvy6w2qxubzTV+66/rOb+gZUNX+Z6/p0bzp7jXjf J+/86qbLdt85t+WyM3/Uvznfk7t07+p6JGKF0kc1pWD5X/DmBsR9bd2YHILSA85L8ktcEUpqjrZV nihFWPQDnvgD8bqJLVd9FG1WgfX/FYYl2LSQqTeKAGigoFKcyPBzZLpUOkcXoWZpL4j3ecgKhDnG QJw0ZPp4Fz9fF4MXhtkdfoGZDH4h5PEq4VUU6lC8coPHsRoDQtGfrCJ10zqFxBb8QI5QB1O2/UEe d1KOvtiHRAN5hfAL4SCSGl60pjfXMaztEw2+xDcW6zgpndJflLj6lbjKlbhaltqRLr6rHftShwZZ hh+Z4bsz/MgM7uY0j/yCQCt2CBsQZ54iJd7VNTTY1tpcabfpY7g6Ss/BjUR0jGKxYOK40T1kdDak oSnYzXJeLswMzQ5ZDwzNDx0fslTsbHxoamiadhlDTHeq5RSyfiir7+gqp4qjHVI5pYxmM+VU4YjF Z9SyjWJtpJ5qLGd6cQDNaXCXMKv8fkXS1JxrVmIHJCZL09Kc9IpkRcbpWQMZz0yulu4a75rqmu6y znTNdokHuhgVAs13He+ydk0NfgPeIQLNEEJkWcICvRhqj9opVE616/bbyjkUS9iQ9IgXEjYtwRzO mCNJ6rkdKeOBYeRVyR9kftLHZkgWQ86E4GO0UWaVrEEHdw3DmUa7Rod2IpbGxnZ+euTy6XjQJ/UY C5eGjT7Jkl7e0/ux0XBz5cLwJdmQKqdj4W4fC9gePHvdnSs2Xm389cLfbUKcjbBByuVs+Rev6a6v X0hcU0vnckFpaKPlEtN7pMzMUiwcGC9uoUNsZ2aeFnJQBEkyEQPot4OVN8MjGRmVzMtMULW4oEG4 LAfxOmd8EK/xgQTi5cPE9y4vxpQp8UH8gh9Fo2xxuL32JB2l6hQOia7P7MzshRru2IkxPIUGLNyS 5V47jUZ7hz0Ia/A1CPVj25Sfmq4k2J+PgmMYEpCZFQwEdn4keHU+BjJ8Sec5tHYtgh1EjIyYhKEN DtonDAp17beL9KUCwgsdjiDd3vtGgkYSKsyyXj4eAP0C23v5eKA7M8cDiPf5eKA9fDyoai570Rjg 5DFc+0+PtY6BnTAs2kNBm82xqdx0bja3P3c6Z9Nz4znRoEWOFGdfX52vh4bNNXKcfBtdgmht1LRY HQMkONrhLacCGBZFbURPZZZ7NE9wFrfSFIQOjyMYkGaBImqSDj64rEErQ241LB/3eLyaN6calSYu HFmcgeH6rMrGVTalTquzaI9xWrWpB7MH/4oPB7ps6qtCxQ6nTDMV7hhuzYyStG8JtwZWN8PCFxVc B8/zdbv0rM3X5c4lSzo7ly75lNY7srBsWS3ucqRiiZKPhWwP0htLOzuXLGTO6hubYOTY0gl27Req uibnppFVuH5hJdtn2weuLbOjbTnvLgW5ExRM0/N77xAJaE4QB4MwGQ/Ej4ygyZ8mb0vE1F547wv8 IyBOcl4F8S+cV0H8yHDRR9KCvVwkfvWUsAPmUzkSfxkzSJ06RlE75bVjpqCG7FtkzMqL8F0OfyXG 7Bqr0C/dGmx4Kwch/ozKeGW28k3fN5P7K3YdGzMVi4I9xyuWmLNU1EeKqdJyjW7JPhGMuTq1uF72 ONCmwYdMCLp/OfDN8hwAJBT4WtppPmbAwyy1Cpon4fmaXMtDfzSKwbu5dHpWZ7LOqJvGad2i63Ry xCt/A48RB+gHOyv/kKFnzsGmJPzOg0+o59LYe3j6MLagn1otM9J7wH4sfojz26ndk1Rc2u4IEKi0 G5xwD0ZJpHxyMp+Q0wmW8iGrgNIOipqZoTJYMZO/U63vvziFRSaHiTNp802psnRpBewx89L+rZt7 M7G4/9qMWotc4J59/O3OytIF/cxH3z5xWTbb53Vsym/6C/EzX6pkOAcx9DpDTwXIvUHLc23+qcRg zqJQiC9NmI4fox2eM19iD3FAhJawDd7kPEKEUaGPFTIDxVqatc0DXlGUsXODocb1fy1C/AjbzLQT QJh2Aoh3oFn5WwtmbWFNYf60tSBFY3lY6vgi8GfpGVgLBaEB3gsMcGthYFAoaHjMuEAPWPIwUGI4 Do1WfvG4ZMcTqpyqtI2Is0hVI10F5J9pNJAZUZl/EVKTAAuAm2OT8jtQz0/LzXRTDNgVhv+fc31B mnXPeh6RH/Y/Eng4Pdd8QpKaWjO2Xdnu356+Wdnp35l+RHS9nTqVFmdcf+R70fKi/Jb4lnzK/+uA s+XH/BXpIb3VXCnvlm6Vnd1ip6Ln9UJ3E5kAxRFWJtiVygbdmlU2sU3yG8pvFNsa/+r0C64XpP8h 2aKuiJJOptMrxMtku9svB70xT1JO+dL2qywTyMZMKhv8G4J2TU4mU+mrRGs78dA9AE0FTmaKRSo2 8BvdjVYld0EESkCAezz46rZ1w4OCGfz6b3C7BsRpLsdB/JbL8VqtOdSW4/i9eLqP7JljUEDcpOEN r/CTTSgyE/0oYlS0dCyl1WCqFDsk0ZWSyFIpZgeK3SON1MByoVtwQ+7k9HRIZ6Kehm3Yw8QQKh4Q fdXTQWYtirKkKKo0KAjRI+yksU71/AClg3ZYNZqmSu4ez4xHPO1hxz2ve8RpzzzldKLROSAYYmnU D8C0EXLd3UJNAdacgOa28Rqbqc2iOdjUUPMIu/2JzDeQZMfQRj0VBjasy8uV3VSJQhE0RNrO413o rdZSje4elhsxjrKUOiaoHDKK2hSTEHCA2tYAvHUCwnRooABkjHL0qMMxCT23e/cuSvnsRtUK/QHs adYoKBg2Ifgr6RIqH/BKGmC8kkzVBkAnNt208jdlcwWRTVvIw84/jooxYtZFluVAGD/5LIRtAWgN KERHkPs0ZF9BcNSLCI2YPRkoUbRobZFhtf6tUY8zU2APXvmJkbffvq6jJ6ddurCsEC8t/FKrjS3U VmbDbtmnx8KdfqbYHjyz69XlAY8nlET2Qqwt+fHCP9+V6fZJuRwLB6P97IaF45NDKsvl/O5o5grL ZXOr4v7sNKyZS2BhyZA0YfYXpqR5WojCvOD2VchjZ452fI7LDMZlBrrrwMwmwwfEr7iHAcI0oUC8 xgUGiJ89ybPjtmchHJx4OTBdBCpeg+fz4g4yPCp95Ei0Bz/Z5fAZFOil87ZSMcitpFCI6xqkCTCX YTtyx5UI40qELso0ekCQ8OKpcdPo8XjQxYvH+eGSkOHf4jkjkilPzUbno6ejFtQjzT/RWlmntTHc XFJn0YPeHQPjUWZEx6NTqF2cje7HgQ5POeUY7WDllL2YXUyU45IcdklgOS++m5+G1kassaQ+62Hj HjblmfbMevZ7TntsnoORi8wWmPE8rNa22sGTcJl5/Iynr3/XNlk0ue/S6qsWWq1azJdWYyW0G7E9 +OHIxqEkt0MsxiOrKElNqFVoEXsPomCbLP/U1iLRSe5tTvIYbNTPTQz/xDoAQ015D+JX/PHRHkOm Z9xT4UdVegdXLh4FwjyK9hgZOmrlyKoRftwIZ5QRzigj61DwJE6sW/wcCFO/gDBPAOK3BvQEDpLo NOsq/OMV/vEKplgDxoqYaJAXtGP7VYPjiAcTdGJswwmmTw8ie0hLOsegn5/Dz8/hh/3wpnkOvYeO wfYL5jn0TjoHtn9iuOkclIHk22fAoziPHtG6+1asJoNKX7VhwqBjuifY+omdE3snLBMb7at61XzV DUCWzUR2oFkOZSUrx5SzUGnzwHuSMMDfosX1O2Sb1bEP/E65qAqi1uQlnA9aG0txepzd7bA5Nkxs dKi9q/yc4/06T6DqFe4EV/i+yuAI3xrhWyPrcF+/4ppC1zfjd/qA6xFO0NAA8S5/d3BwM57BO3y8 gDBHEIgP+Lvr1k1ubg8c5DVwibRUcOX8hfuCzuG+A+Jbyilw7wEvWh8/B0jEm8IKvLrx6jn35pMx FbhmlXKQ+JuMG4m64/jkryOWGbidk+RtI6M4OwmnWi+nUN545lDHYDnVC8Jwd6wrp1aNdvjLqSj8 6kPZSjkF+Jf3UHaknFoJwrg0O1EcG9mQmljuLA+OGc1yySk48qs2bqIHk696JLfDbrU5Vq3sRb2k NAnrE41mMj06m9YP6CISsw1DHizXKrmhnkE2PXhgUBykfZGxTSO5devSY+Nj4szY7JgojClj4hjG 9eFQpD42tXnyiLgFOmuveoTtuIebpG2LFH4I+eXoGMbd88vNfqA8kUvw1aVLx7gCW0SvLnbaw69r BtRDHWjF4c1nCzlPBhAvucOXv9hnB5aLGqESuGXQdNl/j+Pe1iUEQ4DKiV6QI1zF0G5k2y7svdiC 7WfjOwJdN/ZvvDt8w4Nr1+zKRLzSwCULS4NLMlHJGi9ubHx8nSiGh1cu9K5rum2Z6vqBxlVdWu/a hSWtvhi3c4syC1XEkzvkQueO7bevXTsxfPfCJzfqETj4USXrH2d/Ol0zGqvdlYW13OuHVroS+3qN ZHVwIbxlII7GBEsm2DVfqi7awx7Ezf43JFm/eF6SNbgko0C0ONHLlz6nHMmSSKjRvmwyV0bxFIZ0 u4KeywNnhIfX2nUIHBeBuLEp/ECYEE4Q7xgFGu8RIcmFSZKfKMlPkSzz6FqZG87lRQMZBJloHKxv Cjns+S01iMUuISHmwLW/MFy93DPr7fNSYy5qD9GBF+Jthisn5/ocsaqJEuvu5sE1BX4bxt/vmsZt qULyA5LjKF9cnOsyrumOkKo0Y/S9nOYX0GueX845eZjAySWFk0sNZ4TDLyJ8VwSAEsAzIoC0JPmR Sb4jyd9M8hslf4wT9EUg3n2KPlIuN+ptcfH/DbbBNh1uINrmbND472mMN6bQpGa2YeuyMoPTM9g6 0LAfaBxviAcabKox05hvWJLOSDklm4G3cjmVG+1wllO+0WyynMqagbfeYudIT6p3OaYX7Ovnv2gu m5VlnxSN5ByzTnbAyWQkgOecr2COPQq8xcv9yVxnujxenipPl60z5dnygbJFKCuoqyU97sKAL0/V zeAbZQD+g8G3gKpZ7Na8ZokmGFpP2mKLwxiuJVoWUT0DNQimkfz/irxhnFLqbDEc1w7GEYaNrf3L z669WY/43L2XLSwJGv2SdWTstk+6fTQQQyt7EXVLmOPw1AtrNy69e+GOTWmNx9zk9ey2Pbs+vZDc FklipK3awTZ8fXWMRy4gtIGHxDiThaToadsMCZiBNKA8HDXU9ukUAkN7YlYaO/QmEUaQdlr5YdYo 8NJKHjYfZUi5JmyHwy6AK1z0Ph0Xow/Hiadi1hDnuJAHpcuw4KD2scTJYQcQabWmPJ40B0lwVUS6 FbqIfwmlYVcEZsLs0cjhCKYGch1N/thlD/xSYqtdKyKbwvewz7gekH8cd6SNvoaVgyPm0uzF8Pdi opFma5yLVxPA180bFdj/68GKVnacluPWKeu0ddZ6wGq3nqRWfy3DMwcX5zwugHDBFJitrD1QwoRt 41dsedyTWvN42roG3f6fJSQ0TZZMs1OTCly2+e+EmKUPBVUhS99bylvxizahHVAoy/PKqJUZYMkA OkqKqNKU8vaCXw7pQpLFdBZxgVIdoIJeRWdxCxZhd1QXNBsWpE24L0IEFWUCCQxeA9cBf2D4bxVv td8p3em7M3B75Fb11oQT9W5mpZsrofibcbyAwjj9uNtM1IBFzVStndBtlLqNdlDGBYAB8mEKonD8 Ux//5Ct7X7nzhj0/uKrx8cvmPn3tp25aZXnsq/c9dteZma//2d986t9uG2l99e6XFn62/+/f+8wU nI5z/7YwavkOeK0oNMWONq+Vl3C8fZ/USRYYpQOwVIOaoFvKQS6DgzqH28O8+S2PcYA4w+UuiDYK V7eUKgGrzx4j6ACaHxpumB+1vG9g0u7g8TGXwKWwwMCdkLDIZyCjAYF7IQoBHAFwuZCuELbHLvgi Twt95848SYzYJxFPAlFnn5CkJcO4Os63QS4jg7gW0gE8evUO2nWQz6/jqJLdV0QLBx8uxk1XQxdA T7qlmGkIap2Fb4TwPM5denA3cfWnpCUE5Wkqa5StygN+671VtqTaWrK2urX6Mf/Hqrc47/DfUf0T 59cdbzn/zeXtWbK5f7J+c91qLGHdTkupHAjCrNLu7QjCuCpmhWJmfTGFfv6BSslirSkDjK5ERIGD z62pvr7etDQriVPSjPSYZJHe1kUewovr+jjBVpGeJrin2VDClpkaJkAvUhIQioTmNbG8KDDGbe0+ D1erVCw++OhL0TwAHK13NxxeZ75e8BR68g1Hn866vVj0uwZ01uuu6ZRkbLMuBCV1VwFibXLSku8P k6XDm6NyPiwuGjD9EVhCi7LRZgpMuNOLjb5FFius2rf+T6/edf/0X48OlPqizbULujZYDIaVbErN s7rL94mrdlx6xdXG5p7unKW5+7U7rr35T1499cjesNy18NY1/Sk0Hom4e3dYrpvsUX17F/56Z3Z4 8+Ufffofd12uBihPsXwBczeAl5MIHb7a5uVYASyB0FuYt54Jw5VOtX1pH/kkHJnZrqTndgj2vs5l KYgPuOvssxEHw3U2FEfSLqcC2bxqL08G3A6fyTcwDWB5X3Ce5znHmkwzH+8kERrvJD6MdxIPxuRY aqNiQc0Emdy6WhzvEg0UVfzn0v4ua0+sJ9PqHKqsV4yYkVnfubqyWR6PTabGM1uAVtmpXBe7LrOz 825lV2xvaldmb+We2J9XviJ/MfaV1BczX+78auWbkW/Evp34m8rTke+CbX9SOVn5sNKpd92Sv6W0 L/il4JdC812Oq9AxC5CflKPY9qDjqpxKW7KxMqPbyubRwdlh98UxrX0acwbcYHRjhuFZJk6hocdj 6PLtpLtgbxd6lfB4WHwu/Er412j/zpEA4WXVRewk1RejPIPUNI0n7mCfap0lfqSGA5wJ1VwpGM1F C4BLBrHIR7I6K4YIQkm8Z6avqQJ4CNgsyE9CsCxqYc5rhJiCICTMbxQA33aSjAN+BywfV/tHF/qC Q8mQuvX+Nff8Awv9fXOqMNz44+KO1vT+v7plydWWxz786Oa+RD6vuJswfW9e/+7332J5XU/kznaz v4W+/u7zT8+j0RTPGItPgbNK7Mk2X5U6uYy0p6P+IjdOi2qatV35iz1fJAZMuxaEaZGCeMdESKS5 Y57mJiz2ws8iSZtGXFKNaBTMVdGw4ReGb31xZ3Fv0VIsOVQPAEKtY+ThnoJ/+39ZpZTlInP0grBE l0icroDP7nTtRfd6nEC140q5oPRzD9aP7yYxbp8A8SvuhBLB8VbpdGf5gjEJWBfCNsfa0U1K2KKm Ce6b3Cf2yYZoyJ+2OoxOtr2TpUnKcX/x3mwRiYpCqrhckNyd/pCuMKtK7b6bCsKuk+h874BHuN3O kGSz19KYwVHwIwmR1tmMPquLgq7AQ5wHiN6mT5UpOEnTCkDQ8bqF3cCXc84CsuPUNrAWye5mG5hL TIbsAYpgUAhHxp2Jcmp7XW177t8H/Nbdcsfg6nouuykcCHf1BL2XXbpQWdmhSTYv+jgXJRa2PPby y8uqxYEVofI1C2vWFWG85SLcn7p+/yUJMuDALzvOnRB/CH7ptdbb/FLs5/zSj3oecUJkPFfKeK6U yWg/U0T1ozhRzCCcaYofEO8ZfcQPcq/DWZQz1kDFxu6wsZttzJbvZox1OrTbUux69LbN6zE2hXYi YiwATC1QqrCBurHGahsisy0y/GD3HXv1mPKqqUnPh/X6MnLRae2MpAI1m9jZ6zBPowXW2tjHbXfZ RFu+07E8xXak/hCQuHzAzegK3zWAi7BPyHJ/X8zpI9JZBFrQPlEs9vdxbgHmwFwfhQ21DfjebdsQ 793WUo7yqitcFLFO2VXVqmIgUDPczSrqmdTQpGdL4RHl8zmb5EBxU3mqf7p/pt8u9x9hunEfxOX3 vd/3Hc0dzf9z9rXcj6tvWN/IvpF7q+oOtKrbqn/Qtae6j+0T91lmwjOxmfhM4oGufTUv9ZyQ0OTW npCqL3V8L+tMWCKhADova+V49SHXQ9Ij+ueyn8u5AxVvqTpaXd+/vf/28u3Ve33fzD7W/6bljYSn 7OxNCc+KKZZm3YjEH2GVg8KzaLoSM/ydakp7Np6KpWNMiel4APSm9iwycDGjIxBAXthtlYt8ZUux /yrUujt70fIQP2rsU5qGmXRXGqFIN/2w4g8CjAUIivRrQppZQoZ7mvpuT2OuAAuwlgMGemJqtTTQ ZNW5IpsqThdniha92FMUi99hOjrA64+b2FgMDurswJEJZwkFey4DFGyzG9UUB88xkISTPYH3YfJQ vvbERS0fYJVK8NNyXnfI63UvNoCYNDtAIERPnXkXe0CANBMqh2q6y1sXKgjmw7BIlMppXUEJWdqP wIm97ExgCAMG5SjZEtT3gQt28r2o08OHjveV9/0fltDpASUf1OZhs6HNsTlxzjLnftg7G56NzcZn Ew91fCk71+WBeYygC68M2Wy4u7PduT+rPpJ7pGrbRvMpG/6SrjVdJbQrMqSmiBfVch+UmnBs5g1N atawq8pfqIZU0P7Ip9MCJiQQvXylNXMwCgBrRgCDVh6sUHhSbdeFHwyY50KJOTNQZo5XVQ/QZ04D ioDD5KZF8eJ7vHSC00bAi+/x4hi80HWLXtwl4M7A71vgt6GaPei5LId78LYWbXQmDxehqQWVBsCo KgC3wafeidL2oDibKdx29cqNenr7Z7//7K0bbs6Eo95MJvHV61ZsunbhZ11dj9w1MNbvVwIey2ML L33uY6NdQ6VybdX1X9vzUEqKsVWfefCK5oprZoebm3Z9OSr7VMiw0Ln/KS61Pi/E2dm2DMsn0YgT 5SnIN4sTbg8PwHjCQWYLcjLIFVlwES0F4j3uHIA4bcKmgm5nVY6EMJsJpogDlKJ17CxanZ862o7R /nSxCu9C8FWLIqiEMAhfhi+i8Wzf5NFUPF2T0EAYITp6GpXqcpyFbwqxNWhgSF9ngBXx3e44s3Hn wMaDKTauBW24QMqvIoeOK+X6D4SZ4QsGk4kL+q/C6wBaZ49v2zavAFKyDQqGP0c8VtS+eHEBI57m drZdFFvJh/wPac+Fn4sc0d7UHHNJ9kAMRVbrvds9272/URGJCKtFtIwLq1rMwmgRiu9nlnBP+2ot PehAYfc06KIjrwB+TzbWR0LxHwhuyvtV0WXQU+tOHkBRD3pvW622XGg8yGYwQRHaEx0IzgePB18P 2oNTiW8DNWm6BrzOD+36MZUCAsXocY6u2ydQv44tvHWCQX0K3DpDupdAg7D5d3NMUj969FMRFXoG c4sLjR6yyJshvMlGX3utv5S51F/Mziyvbe78i8FbuqJl6/ML/7Ty7N9OXlouXXd9//brxRszkZtW Fz5CmlFEbOMsZuTOiz1trooUeQwRgo0MdebWS+2MQNse0nnHCzhzJ0xMhh7jB8YCPPuAtmQmOA+E 6YuCeI/DhgK5RdfTp+btbt2n2pNVH0pBIA+eJGiGUxKAyTgGP8k04dFqn56m2eeVV1ZdZEdtcpgl Cxan5Nbdqg/wcJzVPKW7bRMDJgLLmDMV02MwAymWQowVk0g9xgJOZ0HnnKejxTC5owVc7buc90CY KCEieNw/ECgW2rzH4/5YUMSfh/0r8xScaIEJOXIO9iAc5LjRYEXyKvQi6YcDRWvdPZge1lenV+u2 mDO4njzPzPpUvph1FtmII+VcrrvzSecRtsIISqiXgkqin8gnuSW3O8PLpXyYdBJ9m6bZHLobWdEE HhC5gBZD/HY8OBsUZ7A4ELQQ0+lttgPTFV4wC6jO22kAycEPgLah/DG1F6d/PKh6PucG1aHEE7I/ IccS6EMSV5KopyaMHBVOoZaUpOKFuqhFPgQsztHItLkT9n+xYbkeNVHpom/hna5P3r1ibFc1Mbia jUy2Kp9Y29xi+fzZH87xaqgXZi6b/MwMe2ikL87yZx+ZGR9YJzouHxTz4FE/ePQUeFQXnzd59LDL JcQCdj6Pgx92uY6XCBAFcNuoazx5soUcOO8r0kYY9KoSuou7XB0ZfM4d4sHfUNDu5/6fP2AX+R6M b50TOp3nWOXCf5yNHvxPjyEiQY/VFbhK2qxu1TDhBTXca6CZ4LxxbbgR0kKxrKtDyvj1QE7VNT02 7GpKw0i5N7Th2KhzjWu5tEJdoa2J3eT8ivMh13+KPRyf6/iW8E3n111f076GdiLfRVHQYemw+pT2 ndgz8fmOH6rvS++rH8a65lzoYkoYs6k6X1d6zXWqbK5R48f3F4vmOps1134/XxuGlqjLHXcLaAQn Ttvu1v/Ido9/X4dr2FmX6qjofNE+n/lRzHG/9IB6n2YZDKxWxaAaSgWFuJ4SApI/hVFwLxqKxDRd 1bQelxRCX5F4LJZzOUHxaXytTphkwQDMJsEe09zIAEE9bZeYIuWA5zwsvSrZpD0uFGzcYCiGvXu/ 82nny2hJu8el3Rqjxgi64ML9yYG6i+4TIHRaH+xr0OopT0NwzcNdOsKeO6x0sBk0c2wfRevDcrCe IcGqAUdO3ZZJbMTOqm9oEKvqe7FTtN6twtAymziC10m6opMj4R54bxDeCeT3NAKh5DMimHRC+uOs j1kkYN88Keno8AHh9eZTWLtysJfhLMBKQRDsdUMKNp062tfgxVUSR09RdRG1WiRYdjDIQzG824cd eSfqCIKCj6KfPZYolsM/fC3qdKPlWKUeyiYWnikvPB0ppf19ls/nC3q2Z8EueoeSPpfsxtQT/tTK M+9YbAPdisuJ0eI9d8J2CKOlajnWHi2FTMrvE6uUavEJroLqtJbyabtsJzZvob02Cigv6sVjjhn0 JoT2XE5SUU3Q0smX8JMgPhFxoKVacFmFEj/5HajrFG5FGwn3rahncJtnr1a7MplaFw0dyEr6rta2 FkFBeeMfiivyDA1ZF4EaHqORaDUiRTiY/nxRr22v3eSarr2Vf6v0Qf6DkocOOBhs8ONeiqfrmVqt vGMgqaGTdFapWaVCslAtNAsT0Uejj6qPFpzu/GBusLheWMfGHGucq3Iri2OlsfL9jhllxv/n+ftL 95dnag8rn6eD888oT+efLj1Xeyn/UunH+R+XjtfSmE8SZZ7WqCvvKLpK9nIjukxZ5h+3XenYqF5Z fsC9T7lffUB7IHt//v7CTC16n+ve6H0Fi9c1yW5TbvNbMSbwNPN5iTkwKpSoP6Xo2UxKF8rVlCBL vpSc1lIpuPX3PkHAwSPn9hgGOg3q6EfpcuTKpVC5XAI35Is9TlcI06jAOtHCOSkfkqQ8OpT3qFpI VbVyAa2xojSNtoTn8Aw7iUGUYiefSDPZT1uK4INtAi2oKHDgdUGknZh1DIdgkKrPYF70PGYa+oYh lwxcLKqH3PoZ+SMSfKrHD80LHylnj6BYJoyWteMa26+xZ7VXtJ9D6n02143hHX9Kl/PoRcJ48Q6q RfLPMAWAtzBGuMeQurcXmFGYoQ787OQh155it/M7GOZOGH8SAkxspnQaLRrxVJ/ER0v7HSQY4uNl NlNmlGXSywYSTvPl42VHearrvNV0CvUiu7TYqbMnUB2yqz22sSuGHVBv6okYTCl60WAntUZzyUDD kYllqjluYJG6M/0s6hDEpQBhpZyL4oATi3v+wx2CqD8QFxjIKJhpLKBrqWz+yQK1+yXHhIqcYM2+ fjBJ3X7Pr0K0dfpgtInf8vTBMN96PGyKDpI7puTg9RzBIKSECZwCh7YFSXubZS2mHPGyGajho/+l rhYjS9mh1SnUlz4fKjZZZlN54eXyvy78Jr/wk+TQUsgTayqRrp79n+xv7lsa9aE+3YJsdCh89l32 4YAepDnrvDedeVtcc/Ypi7im30s2Yxx5519CwgxZ3m3bjJ6CpNYL1i4Bp+qGnDnUFVTEIRCHha6U 3xQ0SCZAyszzhZlTIFV6X2CFxPZ59/n2+e8r3Fd/zf1a9CfFn/S75BoyO+6cBzBE9xt9jsRwTd4y YK21bC2l5R8qtErNes/wGvd6Zb1/ZWpNYV1pbd0Y3qhtzI8P3+rY696r7PXvjeyNfsExp8z5H1Wf KaR8NlmR/XI1raT96WpZKke7hyVleMK1ZWB8eBGLmMN13wGsI93IJ9G9slaoq5JVqNE9pGrJZLNW G6bSIy7QgPJo0Z1wiTZvLumevlbA2EQ8q1ivNySgaPphfjgcWqHeqPc38oF9kW7AkxowSyOe5B5t HBGj7vzO7F70pd2XZVktDxhjf9e75XKxfxy/9p4Ga9hsjrzmcOQa+VCjkfdEisWefk+ov98Dx1N1 eaL9xbzmHuouqJLFU3c0ZNQupfEkumv0GKDA/X7SyjUrCiW7UqmkhJngVjy5EzPI1VBg53tC1xgs mXk4hQ1DO6C9rp3WrLSDtLH2jDiA7v4OdsPBRq0IefAEZnrpf0Z8HlVww+LYE5ljvAwMk6AgAoo+ d2hFuTh107ZFbUsF+0iEYPxhshNEnMixwe9G8Qzek4sGGhFMDTT3dKsn0SqdfmPM74cfOoCqym3Y o/BN5e6ToBxOZSnm90P+ZM/Ro7Q66jzqwMqJvQh7oMyKNztZhC66MaYkQih+8JQLJeGIMoB+kzou I5/3puFK+FteJKRaUOBvPoENWhtBdGy0UU7TQU28Bogaxm+CmZtaZcAecYbTh+VmXpdJ4f/ooEyF xq9j1YfVYS/e8PI91ACvgKhEAfXGebzwOerRTEYC4hd85TdNhri3qeAH8OMVRShDUeQm5tlCiCRM jZ1JKgCCQSvYYvNYwdM+bQTDzQFnuFlCy/AyXn5nhGYcfN2IR5plw49XuNlHL3xzlL4dL/r4IiiT ZMvv/v37iIjpUOMY/gY3YNr9PaOUTDpvvwDCGaGZMM0UU5FEE98mt3SQaqfj7LFyJuuOjKxd3VFg A7253ok9Jzasbi6MdwEyf+/nlnd1LfwwFy9smf/b0SsugWBKRNU+pePGG6+PhZMQS2rH7kcXjtzR a8nlQphreNvRo1v9alHM5Wyh5G3nztw8iLHiQYXre5BMfedzp7BOK50W4fYiKybhMcB+QfMhEkx+ TlKLwsMiJ0Ui+zjZB9J0JoDIPol/re5jFLm92KdIuSpCMuQX70TreAE11PbsnfQdciiEDEW9n7Mu GT0/3XYUfiHZPDw90NtzQAEa7Fk0TfxA0M6dFmJIKEsK0t8EAfu2iyoCfZUvlMVgvRbZMfDHtnvs ostlCzg1Z8xVCcUKrlwgh+4WQwyzCMdXBW503SjdpH00dn38xurtzjukO7TbYn8Yv736gPSA9mXh y64vxb5YeUY4Xv9XexY2SaVS7eyUGLfUNTLvq31t877g1LVYrKdTCuGAaqXCDftKJz7SGXNZJWcV aw2WhjPbNvGL4CLDh6stdmebSbkOCBmm/3Ma8X0S+7l0mpKl09KvkSzd03Ktd213WVx74Nj6jGTl NVQzyPoc8hT7tldZd7VVFataf/1bBBsjyBjaMp/A3JJnMQEZLO+zbajY2NkTFVOj04Pg4gMN989r bihuEi2/x4I3W/lh7p62cma7yIqHRv39pji3xduJLCQpzHDeIHXrwz8P+3a4qyvz82N+h7Ojwjrz JdWlLfzZwGNXLFk32JNplqTUqtzIwlNyRlOi/eDhYrK4YqGP/bZcCrjcXhjrasbXOvMH99y/vNrZ H5EvnZwTn0jXsh7FA+7FbBaWm8G9YfYtozvgtKrWOeucd873LesRq2MuyrzRW729A+MCUpBhNGeO +oLyNdYr5Z9bj8uOtqdbYpZoxCKLPpsHKYO7bGzcNoWsQY/Hvlxmfyiz7fJOzAfdI0qINUFI8gV+ NvynXw89I13C+4oyEk5RWCtn9Nlsh6SU24pWpzmLNWSxWC1u0Sozjy/qpW/BhO/M1uMFFGY74vrA xkvyM+Klgg/tvi41qhZWm8Nt1ca9rMdroBWWxRvrjrai64Es9tTQuRY9XbVI9C9NFQKM+9h7J2gS OjAAZtRCIByzMfHKelosXiNdJl7w3e7bc1Rtz6XVXk2S6EeQDPEJGF1PC75zxw0XpLylBwsOYPGC kA3aykUIq/4vhyNNaylE5I8Oo4vGNGbDPHJu9jA6aKhhIt88HAYpc/Jx+YJBRkITEnGSYRYPlgGe EK10BzNhhklkIfAsV7vP/EicWnj12qXBuLVktwhnH2aX37Q2qriZtvDLnKVTy/aNLuTPvJqt6jcI +BNpIQjnMsIOk/p3yyXYtgg2zD3qRgtBGaa9XwhgVvQQ+o9HMPtmUsjB9C4KJaFTqAhVoQu1Cz1C LzR3XRgQBoUhYVhYLqwQVgqrhNWo/x8V1grrhDHhcnSmGBeuEK4UrhI2CBPCRmGTsFmYFLYIW4Wr 0dyS7L0AXvRnRwJUmLxsbM34lsqGmz7xkVsu/8htV+78xLV/MH7V2AZB+D9aAKAmCmVuZHN0cmVh bQplbmRvYmoKNjMgMCBvYmoKMzAxMTUKZW5kb2JqCjEzIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T dWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1BRUk5PSytDYWxpYnJpIC9Gb250RGVzY3JpcHRv cgo2NCAwIFIgL1RvVW5pY29kZSA2NSAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgNTEgL1dp ZHRocyBbIDI2OCA0OTggNDIzCjMwNiAyMjkgMzM1IDM5MSA1MjUgNTI1IDIyOSA0NzkgNjEyIDUy NyAzNDkgNzk5IDg5NCAyNTIgNTI1IDIyNiBdID4+CmVuZG9iago2NSAwIG9iago8PCAvTGVuZ3Ro IDY2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkrtuwzAMRXd/hcZ0CEzL eTSAYaBIESBDH6jbD5AlOjXQyILiDPn7Xipuina4wxF5KVJUvt0/7n0/qvw1DrbhUXW9d5FPwzla Vi0fep8VWrnejhOlM3s0Icthbi6nkY973w2qqjKl8jdYTmO8qNmDG1q+k7OX6Dj2/qBmH9smnTTn EL74yH5UlNW1ctyh3JMJz+bIKk/W+d4h3o+XOVy/Ge+XwAodwVFcW7KD41MwlqPxB84qorra7eqM vfsXmgxtZz9NzCq9qJGsnSIyTmkqKJmm8L/kspRk2iCZxKFJbH8dq2tDbTd1oou6EhGVpsZ9GggR rZaCqCgCloJLIATcCK6AENF6IbgGQsCUfA+EkJyiGyCEKDqqtAFCiFrBFggBC0EHhICdIAMheLVg B4QQdcASjykiWkjlEtOIMD8LYhoRvJgID/4zury9/JHbTu05RqwzfaS0adlg7/n218IQpEDSN7Hz u30KZW5kc3RyZWFtCmVuZG9iago2NiAwIG9iagozNjIKZW5kb2JqCjY0IDAgb2JqCjw8IC9UeXBl IC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL1BRUk5PSytDYWxpYnJpIC9GbGFncyA0IC9Gb250 QkJveCBbLTUwMyAtMzA3IDEyNDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVz Y2VudCAtMjY5IC9DYXBIZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGgg NTIxIC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNjcgMCBSID4+CmVuZG9iago2NyAwIG9iago8 PCAvTGVuZ3RoIDY4IDAgUiAvTGVuZ3RoMSAxODY4MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAHVfHdAVFfa/rnTKzMDDG2AGRiqQxMQQRGGKlVAHQUUpNpiRbEXoiYmJCamx/Rudk0Z RhMxZhOTTTabYtqm7KbqbjbdxOwmm6p8z7nvHKPZzff74/fPfgPPPM/7njLnvKfccy+jqwcG+5mR DTEly+ld2r2Cya+8k6CS3jWrXWQnL2RMHTt/xYKlZI/bwZg+ZsGS9fPJzp/LWPiGhf3dfWSzn8AF C+EgW8oHJy1cunod2Xm3gZuXLO8NpufnwB63tHtd8PPZO7Bdy7qX9oPxqvkz3lwrBvqD6VIrqrPm MC8bj58sloufQZ7xGIeSVZcY+pf1MQlWuORiVvZ7pmUKcDZDjbbd0jamQipPV98yuuvb523zLMXf sGgdHIwd/mzTC5yf2XnvJT/+cOoS/efah2HqUQO9UE57y6m3GDPc9uMPP9ym/1yuKZgoU3hAr3SN KnYc0EdJdRDbhdgmxPlCDAmxVYgtQmwWYpMQG4XYIMR6IdYJsVaINUIMCrFaiFVCrBRihRDLhVgm xFIhlghxnhCLhVgkxEIhFggxX4h+IfqE6BWiR4huIbqEmCdEpxAdQswVYo4Q7UK0CdEqxGwhZgnh E2KmEDOEmC5EixDNQjQJMU2IRiEahKgXok6IWiFqhJgqRLUQVUJUClEhRLkQZUJ4hSgVokSIKUIU CzFZiElCFAlRKMREIQqEmCBEvhB5QuQKMV6IHCGyhcgSIlOIDCE8QowTIl2INCFShUgRIlmIJCHc QiQKkSCESwinEPFCxAkRK4RDiBghooWIEiJSiAgh7EKECxEmRKgQNiGsQliECBHCLIRJCKMQBiH0 QuiE0AqhEUIthEoIpRAKISQhWFBIY0KcFuKUED8J8aMQPwjxvRDfCfGtEP8S4hshvhbin0L8Q4iv hDgpxJdCfCHECSE+F+IzIT4V4hMhPhbiIyE+FOLvQnwgxN+E+KsQx4U4JsT7QrwnxLtCvCPE20K8 JcRfhPizEG8K8YYQrwvxmhB/EuJVIV4R4mUhXhLiRSGOCvGCEM8L8ZwQzwrxRyGeEeIPQjwtxFNC /F6IJ4V4QogjQjwuxGNC/E6IR4U4LMQjQhwSYlSIg0I8LMRDQhwQYr8QASFGhPAL8aAQDwhxvxD3 CbFPiN8K8Rsh7hVirxD3CHG3EHcJcacQdwhxuxC3CXGrELcIcbMQNwlxoxA3CLFHiOuFuE6Ia4W4 RoirhbhKiCuFuEKI3UJcLsRlQuwS4lIhLhFiWIiLhbhIiJ1CXCjEBULsEGK7ENuEOF+IISG2CrFF iM1CbBJioxAbhFgvxDoh1gqxRohBIVYLsUqIASFWCrFCiOVCLBNiqRBLhDhPiMVCLBJioRALhJgv RL8QfUL0CtEjRLcQXULME6JTiA4h5goxR4h2IdqEaBVithCzhPAJMVOIGUJMF6JZiCYhpgnRIES9 EHVC1ApRI8RUIaqFqBKiUoiK/fy0jFNzIL7EiTNzIN4O2kbW+YH4SbCGyNpKtCUQb4JzM1mbiDYS bSBaH4grQ5Z1gbgK0FqiNUSDlLaarFVEA+RcGYgrR4EVRMuJllGWpURLiM4LxFYh52KiRUQLiRYQ zQ/EViJLP1l9RL1EPUTdRF1E84g6qVwHWXOJ5hC1E7URtRLNJppF5COaSTSDaDpRC1EzURPRNKJG ogaieqK6gKMWfaglqgk46mBNJaoOOOphVQUcDaBKogqickoro3JeolIqV0I0haiYck4mmkTFi4gK iSYSFRBNoMryifKollyi8UQ5VFk2URaVyyTKIPIQjSNKJ0ojSqWqU4iSqc4kIjdRIlWdQOSick6i eKI4olgiB1FMIGYaghVNFBWIaYIVSRRBTjtRODnDiEKJbJRmJbKQM4TITGSiNCORgUhPaToiLZEm EN2MT1cHoltAKiIlORVkSURMJmmM6LScRTpF1k9EPxL9QGnfk/Ud0bdE/yL6JhA10zkqfR2ImgH6 J1n/IPqK6CSlfUnWF0QniD6ntM+IPiXnJ0QfE31E9CFl+TtZH5D1N7L+SnSc6BilvU/0HjnfJXqH 6G2ityjLX8j6M9GbgcjZ6MobgchZoNeJXiPnn4heJXqF6GXK8hLRi+Q8SvQC0fNEz1GWZ4n+SM5n iP5A9DTRU0S/p5xPkvUE0RGixyntMaLfkfNRosNEjxAdIhqlnAfJepjoIaIDRPsDEaXodCAQMQc0 QuQnepDoAaL7ie4j2kf020AEdn3pN1TLvUR7Ke0eoruJ7iK6k+gOotuJbiO6lSq7hWq5megmSruR 6AaiPUTXU4HryLqW6BqiqyntKqrlSqIrKG030eVElxHtIrqUcl5C1jDRxUQXEe0kujBg70bfLwjY e0A7iLYH7PNhbSM6P2D3wRoK2HGxkbYG7AWgLUSbqfgmKreRaEPA3ocs66n4OqK1RGuIBolWE62i qgeo+EqiFQF7L2pZTpUto5xLiZYQnUe0mGgRlVtItIBaNp+K9xP1Uc5eoh6ibqIuonlEndTpDmrZ XKI51Ol2qrqNPqiVaDY1dxZ9kI9qmUk0g2g6UUsg3IuONQfCeVibAuF8wU4LhG8HNQbCM0ENlKWe qC4QjoOEVEtWDdFUclYHwrcgrSoQvhNUGQjfCqoIhA+BygOh1aAyIi9RKVFJIBTnAmkKWcUBWxus yUSTAja+joqICgO2qbAmBmytoIKArR00gdLyifICtgw4cynn+ICNdywnYOMbUjZRFhXPpE/IIPJQ ZeOI0qmyNKJUohSi5ICNRymJyE11JlKdCVSZi2pxEsVTuTiiWCIHUQxRdMDagTqjAtZOUGTAOg8U QWQnCicKIwqlAjYqYCWnhSiEyExkopxGymkgp55IR6Ql0lBONeVUkVNJpCCSiJh3zNLj5Dht6XWe svQ5f4L+EfgB+B6+7+D7FvgX8A3wNfz/BP6BtK9gnwS+BL4ATsD/OfAZ0j6F/QnwMfAR8GHIAuff QxY6PwD+BvwVOA7fMfD7wHvAu7DfAb8NvAX8Bfiz+Tznm+bxzjfAr5uXOF8zpzj/BLwK/YrZ43wZ eAl4EelH4XvBvNT5PPRz0M9C/9G82PmMeZHzD+aFzqfNC5xPoezvUd+TwBOAd+wI3h8HHgN+Z1rp fNQ04DxsWuV8xLTaeQgYBQ7C/zDwENIOIG0/fAFgBPADDxrXOx8wbnDeb9zkvM+42bnPuMX5W+A3 wL3AXuAe4G5jpvMu8J3AHShzO/g243nOW6Fvgb4ZuAn6RtR1A+rag7quh+864FrgGuBq4CrgSpS7 AvXtNkxzXm5ocl5mWODcZbjbealhr/MCZbJzh7LQuV0qdG7zDfnO3zfk2+rb7Nuyb7PPuFkybnZs rt+8cfO+zW9v9oZqDJt8G3wb923wrfet9a3bt9b3iOJCNl9xgbfYt2bfoE81GD64elD59aC0b1Cq HJRyBiUFG7QOugaVptW+Ad+qfQM+NtA8MDTgH1BN9g8cG1CwAckwOnZk/4Ajvhrs3TRgtlav9C33 rdi33Lds/lLfYjRwUeEC38J9C3zzC/t8/fv6fL2FPb7uwi7fvMIOX+e+Dt/cwnbfnH3tvrbCVt9s 5J9VONPn2zfTN6OwxTd9X4uvqXCabxr8jYX1voZ99b66whpf7b4a39TCal8VOs9irbGuWKWVN2Ba LFrCHFJ5jsPrOOY46VAxh99xxKEMtcQ4YxTplmipoilaWh69NfryaKUl6qUohTcqPaPaEvlS5PuR X0aqwryR6VnVLMIa4YpQ2nnfIhpn8r7tjyitJB4/Qe5rY4Q7pdpilyx2p11R5bRLzHbMdtKmtD9u fcmqsFgki2XMovBakN0S4gxR8LexEKU3ZPzEaovZaVbwtzGzMsJrhoc3PtXUPLPaYnQaFb5SY5NR 4TWWVlR7jZk51UwpuST85ccKUup4ayS7s3pUYvsjJLU0Ku0emTnD46kf1bHp9X5d8xy/dJE/eQZ/ 97a0+zUX+ZmvfU7riCRd1jYiKSpm+sPrW9rJvmDXLlYeV++Pm9Hqvy2urd4/BOHlYgyCxY1EsPI2 T+eqwVUez+pOvHWuWu2Rf2FJg9zCCwn4XbUaNv8BwWY85ddflA355q3CS66Gav/1Iv8HUqT/A238 L2/iCMMUbS0bU+xgfYrtwDbgfGAI2ApsATYDm4CNwAZgPbAOWAusAQaB1cAqYCWwAlgOLAOWAkuA 84DFwCJgIbAAmA/0A31AL9ADdANdwDygE+gA5gJzgHagDWgFZgOzAB8wE5gBTAdagGagCZgGNAIN QD1QB9QCNcBUoBqoAiqBCqAcKAO8QClQAkwBioHJwCSgCCgEJgIFwAQgH8gDcoHxQA6QDWQBmUAG 4AHGAelAGpAKpADJQBLgBhKBBMAFOIF4IA6IBRxADBANRAGRQARgB8KBMCAUsAFWwAKEAGbABBgB A6AHdIAW0ABqQFU2hncloAAkgLE+CT7pNHAK+An4EfgB+B74DvgW+BfwDfA18E/gH8BXwEngS+AL 4ATwOfAZ8CnwCfAx8BHwIfB34APgb8BfgePAMeB94D3gXeAd4G3gLeAvwJ+BN4E3gNeB14A/Aa8C rwAvAy8BLwJHgReA54HngGeBPwLPAH8AngaeAn4PPAk8ARwBHgceA34HPAocBh4BDgGjwEHgYeAh 4ACwHwgAI4AfeBB4ALgfuA/YB/wW+A1wL7AXuAe4G7gLuBO4A7gduA24FbgFuBm4CbgRuAHYA1wP XAdcC1wDXA1cBVwJXAHsBi4HLgN2AZcClwDDwMXARcBO4ELgAtZXNiTtgNoObAPOB4aArcAWYDOw CdgIbADWA+uAtcAaYBBYDawCBoCVwApgObAMWAosAc4DFgOLgIXAAmA+0A/0Ab1AD9ANdAHzgE6g A5gLzAHagTagFZgNzAJ8wExgBjAdaAaagGlAA1AP1AG1QA0wFagGqoBKoIL1/Zdv0//tzWv7b2/g f3n7ouZ18m8MMXb6qrO/JMSa2WK2ig3h50K2i13FHmdvsx62HWoPu43dw37D/OwJ9ix785xS/5/G 6fXqpcykPMg0LIyxsR/GTpy+BxhVh5zluQpWmMr1s2fMOvbFL3xfnL5qzHp6VBPKDHJZs+JV1PZP 6dTYD7i+aph5rIDbip3QFvmTvtLecvrB03vP6UAza2HtbA6byzpYF+tG//vYQrYIkTmPLWFL2TLZ Woa0BdDzYc1DLuwlsv4513K2gi1nA2w1vgi2Bj8roFcFLZ62UrYH2Vr8rGPr2Qa2kW1im4Pva2XP JqRskL3rkLKFbcXInM+2yUowebazHewCjNpOdhG7GCP269bFZ3INs0vYpRjny9jl7Nf0rnNSdrPd 7Ap2JebD1ewadi27HvPiRnbTL7zXyf4b2C3sVswZXuIaeG6V1bXsOvYo+wN7iD3AHmQPy7HsRWwp IiIu8+VIr0AMNqHP289qMUVz7ZlobUE0eL+Hg/1eh/htO6vEmmAcefS2IyePznBwHHgtm4MeEYnd 6Bnpn/vJY8T7cPk5/RQl/l9e3mMep5sQLxEZHrNr4bvh37xn5zhbX8tuxgq8He88qlzdAU3qVlmf 7b/lTN7b5LQ72V3sbozFXsaVYPLcA99edi/W9m/ZPnYffn7WZytKfYDdL4+cn42wANvPDmAkH2YH 2ajs/9/SHsTe8csy+4N1Bc7Ucog9wg5jhjzGjmCneRI/wvM7+B4Pep+Sc5H9JL5L+ZSci6c+ibn1 DHao59jz7AX2Ensa1ovy+x9hvcxeZX9ib0pmqFfYJ3g/xV5Wf8BCWBm+ePkIRuMm1sk6vVP75nV2 zJ3T3tbqmzljektz07TGhvq62pqp1VWVFeVl3tKSKcWTJxUVTiyYkJ2VmZGWkpzkTnRGhdusFrPR oNdpNWqVEifbjCp3dZfLn9LlV6W4a2oyue3uhqP7LEeX3wVX9bl5/C5erhtJ5+T0Iuf8X+T0Uk7v mZyS1VXMijMzXFVul/9opds1KrW3tELvqnS3ufwnZN0oa1WKbJhhJCSghKsqamGlyy91uar81WsW Dld1VWZmSCNGQ4W7ot+QmcFGDEZII5Q/zb1iREorkWShSKuaNKJgOjP/WL8yuaq7z9/c0lpV6UhI aJN9rEKuy6+p8GvlulyL/Ggzu8Q1knFk+NJRK+vp8pj63H3dc1v9ym4UGlZWDQ/v9Ns8/nR3pT99 wwdRCGC/P8NdWeX3uNGw+ulnPkDyq5OtbtfwNwyNd5/4HK0+y9Md9GiSrd8wnsi7eCZMfqlbaIa2 oYXoX0ICb8slo17WA8M/1NJKtov1OALMm+1p8yu6eMoRkWL38ZQhkXKmeJcbka1yV3UFf9csjPIP 9bgyMzCy8m+yX5WMdJdfmdLV07uQc3f/sLsSPUQs2Uw8tKmE8HYHg1k1kpON/N1d6MQiHoaWVn+2 e4U/3F1O0YYDlSRXLZrRKhchb5U/vMLPunqDpfzZVSiLKVI1zAeGN5DX5W5pPcTyxo6N5Lsc+/NY Pmvj7fBHVGBQUqqGW/vm+51djj7Mz/muVkeC39uG8LW5W/vb+Ci5rf70Y/g4vDCAcin07Re5RWZ0 269N1rlaFQ5lGx8tOFzVeHOXFyPB6teQyUe0vNjVKjmYyIZPCebg6px6YCiTK2pQGIyiFTWOBExu +fW/NMlBHUAz/LozbVKhEeqf20Sf86tNo9y8Qemuqv7Ksxp4TqUw5AYGa/vP7VTwWASDgSbo+HDW 8D5kZiigXUjW+RXop+zioxjl8rNmV6u7393mxhzyNrfyweGxlse3foabPxiURzs4S2aeY1F6IaX5 WUL9zFZh8Gc2/mqPPK58WGV7qmyfMWt+kVwrkl3DOnf9jGH+4e5ghcyFFYTB0aTUdl9SGJqPxVqN jdJd3e12WV3Vw92jY0M9wyNe7/CKqq6Fk7AMht21fcPuGa3FGEt53W92bOAfHcrqpfqZ5ZkZ2HvK R9zSRS0jXumiGe2th6yMuS6a2RpQ4KFoV3nbSBLSWg+5GPPKXgX3cifP4uIGr2k6DJ2c33HIy9iQ nKqSHbLdi+eyso8ywSex3lEF+awinwI+Ffm8sq8NL6ywqIUYAuzDVa4+Pjyb2hYOd7XxxcUiMJT4 lfySu4T5Fe4SPMrVmPwGd3+53+gu5/5S7i8lv4b7te5yvxQhITij2JOGu9zYpzDlWvGIvA2zw8pn vyLZNTo2NrM14ajjRFsClsRcoL3Vr/fgOqBOrkO+qRxdcE/1D/V283YwH5Y6X5m1vW1YC6JCZKn1 61GDPlgDclTLZfh0RKFejA0GUC4/BMM/1OZv8/APbV3EW+RyWf2sxj0Jw051qlP4B2W3DYe6c/nE Rla/IXknJz3axvCQWvY4YOLDsOHyHmlNaHmvG0m9XS6MgIr1zsBUp73UwMcNnn5siaqUfhkGRzCR 8W4pk41mg1+fhQrxy7UxCxXiV9uGoPDOy9bOYAZ8ttVvRItSzgplsACig6Ra3hb87kTjedYneDUt o2y6ex22Rt5o+aO0SPabk2u7sflTeSM87kJRGHXpkrmL1/EUebW85ybEXZk8c3Rsr3s93wHEKzPD zS8OfGIyxyFMbNY2/EuHf44nM0P3S69Zdg8P68z/uQDFS2c+w7wWVxWuNYypQhjDsy6mfJ3NVfaw dlU+61L+yDrwbOwCYI+mj+1RFcr+PYrn2B5lAmtRPMASVB8C+exqRRI7jKeA1+HpbZU2FU1Hdfjh LxPuy3LACbgPtDI1/gVQKL9rg1/FDPK/lwnBv3kxMh3SbbiDo1IMZ+HbpWbpHcUqZbhyl/Jl1Yi6 VP2Gpklr116hK9G9qI/QF+rnGKagZjXueFcpX8XdoRL1FbFGNo3NeZSZ8Rgngk2SHnrIXlmpy9Q+ hkc0CubCQx4dk6QKr0WlMB+MiSl1H5yg2aW01Y5KmQdKtbvw+LL01HunXsw+9d6J0KLsE1L2u8ff O2796kVbUXbe8deOj8+RbAk2GeEhCq02XONOzFJMSE0pyMvLLVFMyE9xJ4YoZF9+wcQSZV5uvEKJ nOQpUXBbUr76U7uy6ZRGscVdOitPHR9jCTdr1IrYqNDM4mTrjDnJxVlxWqVWo1TrtGkTyxPrl1Ql vqW1xdkj4kJ1utC4CHucTXvqbXXID/9Qh/xYoVry49VKzeS5pUnK6w06hUqjGY2Pih43OaF2liXM qjKGWW0ROm2ozZRWOffUhfZYXkes3U51nWpEWOaOnVCWKp9jeZhwfq/LUu4szy5XGvWR+SaT1Jhv NeMtysiVxSo15I9K33pDWGoqhsvErBapkU0aHTu5H1nBH+9HbplRgPMBXmbSqELnDbdFPs3yrfmK yUfyJZYv5ednlY0blRxey8uJUmKiKu7TrLop75gaVSy79EQpj3/HCRt/X9nZgZE4zp/APOXp7CjK tso6t2h8TmdHcrgGg5CSMmECZwxGPsKcNyE/C0E/E3gVD7xdyz328Ii83IKJylJrrCPGGTL5ipap q1oyS1bfu2hTxPhpRVO6a8ebdCa9SusonzU/v/uimSl37arsK3e2NZctnxJlMmk0JlN7aXVy9fyy hhV1ydX5zRMcce44nTXaEh0X444Ly/BtmflUZGZpevWM8krM6HZE16V8lk1gF4/EMv7nQCtCNjp2 jEcK/PEBRIql8tAhAXxyP2IK/oKHVPYjA/hTXiB1VGH0mrNDpJDoj5xeg7nGmTQqKQ6E1Sk/G4+6 D+jNNeMzRiXNiL4RU/k1zwn5TcrukEOG+Hk8ueNzksNDfg5WbrzGThPZnQgVj1lKM1XpUqi10cX1 rdnd1/ZPKFu5p83TUjkhSq9RhJotqcW+SWu3Jng7iotmlXpMWoNWeYct2maOTo4L9W7cP3jB4xsm W2MSo0LCokJTnQlpCQcfmL291ZPkcevC4hhmXRfichOeE6Vg1V7idZZOloyOIj7Xigzod5EVwSji s6uIT72iw/irAWPZFLXsYLDAcrBkRiHZj9zZowqD1xCWUG0sSnWoQjDJ1IGoOkxc1f6QRnUDK5Xn V2RRaXBWeV6j6PAZhQkVnDZnT6jciEgbn1h8GilT5FUuIjVReZPWFhvOF9bUPXN6L52dlttzxbym 7V5tuDMq2hWqv6dic2Vp68Roe/6ssoQp3urUaJ1Jq1JpTbq1jbMat4/0rD68Y2pVhcKoNWvVaryd qpoxu7hnk7dyW/+U0HEV43m0OhCtPVijHpzfH/COyy4oLVheoAxzIV5hLkQpLCwhw4oQZPBoZfAw ZsirFXPh+4cqPXd5FB4E6yHk9OSrgpMPLM8x2UYxMC1XFY9fQkLGM0Oq3SrFEZX0skpSqWKz30mp i/q0K2RFiCJE/2msPME6git15YBYornvemiyYel6PAiohMmVcNa0sp87+RT21AI5oFrlntToU4H4 6hUt3r7abJPWqFEqlFpjwayV3uV7ByYVr7ytd/E1XZn3KNevnTK3JFGhUKQm1K+blWWPsWtDokPN YRaTMToqrGTD6IbVh86vqlx1Y2vYtquzGvon8gheMPaD1KLOZnZcjS49WOpuci93KyP4TEKwwP/i y022w2Q+xpcjbHmGyX6EKOKwYiWLZXZ4UQpfOZBLgT/ej1TwSXm/s49K3z1scHoRbnzVqORAtLVW nnZvnPAEp1xwxvH4nJlwZ2ZYGF+OKRPyC/JyI6QSXagrOsoVptWGufh80oVlTJ7k4YjWGXUqFd6U OzCZoExaKWfSuPQigF+D96DHJeqV6LH3YGlkU+TySCX2G7nlYLnlfP/hLed+ueUMLT9gsFbLzQ22 9T+28d/bdaY56kIdNQf/1lVuhfplzNxm9qnXEWrFh4XxOZpiNZqkhtQo/r5iulQdFmwRWG4R+CQf AZn5BA9ugGFooDc+PgLhj4/PNfC9wsCnu4FXapDnvAFz/mCz1yY1Npdg35Q7etY+KlcLW+yzckBS D+NPkrnMKmkC9XXYUjVec1ldSXVmYW1mQ3SDHI3S0tCiIr5ziF2j6DWPvG/gcEDCw/cP+YsUZ40p vxBptDaxq9jkK9M5juC+Yi/AeMcrIunYYFe/jIHHgIfpwjMqs4pWVekw/pEJYdqIjIqsotWVYlpo QmMjI+Ks2obLawvbKnOsmS31U5Nmr6l1nhkPhbuoszKp1XfqEjFh/t2j3KEz6pVKvVG31tcUk12W Nr5yXNiU+Rc3YOXwK9h7GMEwlsru9caWpktpoVK6TUoxSykmKUUnpWilcUopXSHF88HDoIHl6ILl yxxY3mnkdIxTPN9g4rMNkiE8CtnD+T4fzvey8FCMZzgfyvBH8NdmNnbkoIU1rsA0ih6VpIClzo2r 3YgaW488Dh3BuIvLG8IvXpIIeHDb1gZPBGLbVr43adX9A8vvXlZQtOq+VeCJDzhKFjfVLqpMcJQu bqpZXOmS/r7s0IX15VsODIDrwJtqt/UU5c/b1li3rbsov3MbYrPn9NXK1xGbcWwKG3qotFRKKMCX rOQpBZanHrfltQUhT23Mz++8kXYP77CHd9gTxQ9JHt5tD4+MntkNBRMSVOocXLkeTqlz1FqbiiCD HcflKzSySMqmPeTnwxB2Wrp0pZ4128TkolkloqC1ReAYVKJQvp7Xe2VnWmWZN+ms+RRud4Rq0xsa WzJ7hmenPWDPm+V1leDCVbmhoqRtYoz0yZpHt0+1Jua7T5eIla76BFNHqcQkWj+uJN3esOPBwarz +4rD0ivGn74Bd/l9m4J7gWIvopXHeg+smCClWIIhAsuRAVOouOA7rIWHKpR5sSUzvqAZjxmLQQST vXpPXYrF7qq18wu6vDSlbH6+kdckX4kiHPzYd/YCPCckGsVehUav00XGJdmjcyZMcp8VB3ldJZdN KoozJyTFmVRKSdkTEW/T6/W68KyGiaf8Yj39vHq2F1SmWpQ6g0Ef4uA9bhk7oXgRPa5lL3pN2fWl 9U31W+sfrFeXBTsIlieJbGMVgI/sR29lG0tDZsyLslHpHa8zKTcp1+Tg252Db3wOfkhy8C3VwVeQ 4xF8nQJLxmuAwUxe+E2ozpuC+kpND5oUpqx3Jxo+szXbumwrbMqJtom2iOK3yxzq9LqIj2lNIYwn bEVF2dkd1hNWbHQdHk9wk/MgKZsO4cGrujzXVPJ5G9sW3f9kaYI2DpI0F+nMHa9RvJjXuW1azuyq nAiDSmPUGj2lswrHVeY6Ur3NvhZvavr0jdOTaial27VKpVJr0OgTC2qzx3nT7Wne6b4Z3lQppGoJ xjsyOjzJGRZj1TpcjlB3QXJKfpoz0VMyq3hCd22GKdRuNVkirLZoqzYiOiLMnRObOiHNlTiueCYf i4SxLxVLVfezSWzugXRmc2fyMUCoZEZMwfJYgOVdTGYEMZNPQlOkOfOEuybOfCKyZjxOkiNa2oSO 8utBXvD8ePQpOlyr5DsRm3wRx2zD7YiYc/IJEpd3t43fh5BXsVRndaVnRVb3eeO2WELVOrNus7jY f8TvRUItH02cGpkUG65T69WqOXGJ1hC9Jrl+1TRFiCspLMamfUOLXCq9CcIWE5bkOm3omKc36NUh UcF+q35U4/sWrO2h6WVluX15vEPR02JT8J9aJOLH3Dqtr6azU5OXMu1Ea81E9M5rqGnMaIitiTih mcr3WvnEnJuLIx3OzHlP8algy7MezbUez8XVLxv3xcEuqmjcg0dk+1ndpekwAffPP/ccmX89VMpJ 7pqltYkVSSZsLBqdWufJcSTnuyzPIj7qUMtzYqGe9pwVnF+PpPJgR+fOWelmiynMERYWGaIONUbl tUzqoYj99NmZtWz/OXqhcQm2Xw01ZtTV/B5G+SgODlfiDiZfMqbytZnK12aqDjMnVT6PpPIVmopD ycO0hzmDax8szzfwd/IFggt+GuMZhOMkOaTvvfqwzNpUozq6FscT9c83MnznEyeSM4v1P97InDlf 2uTTeMHEMw7cwoTG2SPjbJrGaxvbNzYkaMNdUThz6iKza3JKNlbhVgZH0FD9mSPFWt+04gUX9ygS xanh1NdN8yqSW32KQeHhZ+7DY99Ku5TXyCcHxwgLH1VsPGiId+NAZalhpUdLj/KlgyUjdmqxTs5c v4LrRtqlj05zutKi9PqoNJczLVr/S1vpcmU4jEZHhisxk3PmqbQEcuA5ZIzJFIMHXRK7Du1Zhv/B xcgiR5gGe+PDGCmNXokrCJrieYLfGZ919F6WXVKcxbF0anZWFcDrqJIOKLIUU/C0KuQA0xpP4HEF doCjvBO4z6FjewI2REVWqO10Zyhe0h06s14tfZ8a70xJidfYYvCsio2ZNevUWfjWAP/L/uL9K7dH JY9KS73js0xRmYVsY5Qvyseqe1cfd6Y5x2/5wtb+RXNzvda0PWtlktrmxE/nlC+W7Gip/7ITH1/6 Gp6WYBniVMCXI3buXKxOtOoJeaU+YX3lDWzqxwE51PKSSw1RYpPi27f8cCRyIp0+tUoN35fgz+IP UM55HkA3bkl41pJfouErWy0vcyx5eSubKGnW2VJK2tc2plcXJGvT6muqEjzleUlRhhBX4YyBBtfk gtwYmyo2JTQ6RK1os+ZUpJfnJkYYsgce371m9NK+qnER2rwtr91eu2Z2AfZ/tULCPXJR97Zph0+f urPG6Cxs23r/+7vu+vKmhlOPpjTn4drhjtBPKI3KLSxN+fEnpVR52YVr2/PCkoqS04qSrLaEnOKa cZ7la1a2TbS4chJaQ0JUeEhxOn/2jPTqjgVLcmffvHZqftvq7RdvXZG6fPTCOluYTWuJtIWEWkyG 8PCQ1rs+vCx/555br9/ZP6lp90tHvJXpZdNntTjrmm3uolTldDyN4LMhFOAvDf7izJpbpk9rqvdU dC9Z1DOw6H8AZZAx2wplbmRzdHJlYW0KZW5kb2JqCjY4IDAgb2JqCjk1ODMKZW5kb2JqCjI4IDAg b2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0NQVEFLRytU aW1lc05ld1JvbWFuUFMtQm9sZE1UCi9Gb250RGVzY3JpcHRvciA2OSAwIFIgL0VuY29kaW5nIC9N YWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyCjEyMSAvV2lkdGhzIFsgMjUw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCAwIDAK MCA1MDAgMCAwIDAgMCAwIDAgMCA1MDAgMCA3MjIgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzc4 IDM4OSAwIDc3OCA2NjcgOTQ0CjcyMiA3NzggNjExIDAgNzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAw IDAgNzIyIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiA0NDQgNTU2CjQ0NCAzMzMgNTAwIDU1NiAyNzgg MCA1NTYgMjc4IDgzMyA1NTYgNTAwIDAgMCA0NDQgMzg5IDMzMyA1NTYgMCAwIDAgNTAwIF0KPj4K ZW5kb2JqCjY5IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0NQVEFL RytUaW1lc05ld1JvbWFuUFMtQm9sZE1UIC9GbGFncyAzMgovRm9udEJCb3ggWy01NTggLTMwNyAy MDAwIDEwMjZdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgODkxIC9EZXNjZW50IC0yMTYgL0NhcEhl aWdodAo2NjIgL1N0ZW1WIDE1OSAvTGVhZGluZyA0MiAvWEhlaWdodCA0NTcgL1N0ZW1IIDQzIC9B dmdXaWR0aCA0MjcgL01heFdpZHRoCjIwMDAgL0ZvbnRGaWxlMiA3MCAwIFIgPj4KZW5kb2JqCjcw IDAgb2JqCjw8IC9MZW5ndGggNzEgMCBSIC9MZW5ndGgxIDMxMzU2IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4Aby8eXxU1f0/fM65s693JrNPJrPcmUlmJsmE7BvJzYZsgSCoBIkEBGRR SABBcAEXRHHDWkXUVtzXlmGiEFArdWlt1UJrW21rhVbqVlH7LdJWyeR5nztBoL/v6/e8Xs8fz8yc /dxzz/18zmc9586aVZcvIiayiQhEvviy+QNE+Ug3IXnr4rVrQvmy4wFCdPHFA5dcli8XvkaI+n8u uXT94nw5eoCQWbkli+YvzJfJSaS1S1CRL9NqpNEll625Il+ODCM9dOnKi8fao7NQXnbZ/CvG7k/e Rzm0Yv5li/L9N0xFWjGwcvWafHn9AaS3DqxaNNafziakoO2Ny16jvP1GHhELIbxUTf6HNJM7iIYw IpI0OR9Pcgt7jahR5u1q09v1yfEfzLM2f63z6viF5OEPaybw9PXdJ+789uaRW0Wiq0FfvdKfN+A6 bTjXRS4Qybc3f3NYzN+Jt5z6VO+eFRpWmYZMlkqeZgvclcMq41BJKGhtE1V2sgmBESviVoR5CIIS UyKr7NkrquRhJKvyyYp8siyfzKqSX0T3yaRq9IDKPuT2VPK+QwZT5Sae6vS8bMvOqZLb9CobHpf3 s5GZ+TTbw0exZbv5KDZyTr52qLMrf1V7vrplrHNjVbAtim4hBBlhAGEXwlcIGszeRtII2xBGEVRK iffbiHAHwk6EIwgaPoWsrsra5leJaBGVZxdJELk0gkD6VRy6GSW2qnSAio5MR3hQpSUqlSFLLg3u wyDCUFcXn6kwlCpX0mxJolJpyPoKK19SCWwHKSZB9KRZl19pIdn29rFMbX0+M5QsqzzcZlAR8iUC UxEVJSX5q4ZKyiu/ehllKuSIlVJeK5wcEh24mzAyZC2olNtE4T+kB4GRjLCbHEBgZKXwNdmIwNB9 V7ZsHL+RsGvIYKkU0f9LEkLYhCCQnYipUpaR4/2/HCpw8eE/zlptynWHsxXV+cyQ6KnsaXMI72M+ vxB+QyQSFP6KtAjpz5EGkP5MeIOYlXk+OmQVKzfhfo+g+yPCepJA82PCBlKJ9EnhGuJXuv0ha8nf 5w/ZkmRlm0F4QrhK6bJaGAS5BIVLheXZymDoBeFRzFQWPh/SG/n8Ps+KzsqXhE+F5cSBXkfRyx20 viSsIGkE/iTDQ3pz5bY2kzCMxxwGWIKYIyUPKrEs/CaLgXC/p4RNxIW2g8K1xIn0aeG6rDN44AXh X8r9TvBRcL+HsWJ4MmS2VB5o0wsPozUj/A8g/j/K3Y4PxesrSVtcuJVUIDAA9UPkPkROFL5A7gug 6Qug5gug5gvM4gssWiIcQ8sx9EkLH5AB4U9kG8KDyKvwAOuzgCBH3fpstKRyn3C1cBUgIb4A2FHU XjOkt/CZXZW1FyjdruIE3vqS8C6ZjsAArPc4Ra58QbhdeZRtQx4/v+C3Wb0JoLsyjwuMtIHj4CVh k3CdAolrFQhkfoIiJVbheuXi0SGTrXIjsD8LxZWI70A4hPAlggrdZuEZZpF5CGDeQs+QxVppfUGY o1w8KWupCr4kTMSjT1SgNTHrjChzPmcso7Jm/UWVPwGtWEkZOFqlyqLSZNPBGS8IU7B+pgvTsguD mPuMLMblMJk2VN9YWfGCME2BxbRsUMpXZwu8SmZCVp9fVx1DBhufSafSMZXVWZT21BhJCskhh7sy 2CYKjcrTViEmQh3QVwfU1IFOqhRkVA6Jdqz+hUKl8kSVpB+5nQgZBBVwXInulcBxJTmi1FiFWjxu LRlFEIDbWvIVAtisMI60ItyB8DLCEQS1UtuPHEN9Be7Qj3gbAsOIaZRFxDJCP8ImhJ0IBxC+QtCS g0IZ7lOG3hWINyFkEA4jqICrUsyjFG12IURGIFSCZCPbITfSjWQj3cg2ChtVG9UbxY02nVwTK62U l/GonEcliOr69QP6TXqhQi/re/SCqA/p2fDogay2sQqJbNc0Vv2x+7Pub7oFe902zTYtO9hmojZy GOFLBIEcpCJKIkqivEU42HK45csW4WD34e4vu4WDHxz+4MsPhINlh8u+LBPkbn9jZd08upJupHdQ VZCmaSudTlXzhJXCRuEOQRUU0kIr1oKq3zhg3GQUKoyysccoiMaQkW0z7jRmjAeMh4zqjOaA5pDm iOYrjbpH068Z0GzSbNPs1GiC2rS2VStrVF+1dbA/Aag7EWcQGNmEeJuSExFTcgDxIaXMa4EOxANK WUbco+QkxBU8hyBhrD+i3ybE2xBAfEpZQlzBywgSuPsf0GcA8TYExv4gF0YqonKUidFQlJEo/SpK D0WPRFkmeiDKDrQ1svfQfyfiDAKf5Xu4kuckxBU8hyBhtu8q/d5FP074mxBvU3I7Ef93XT/qBpRW GXGPkpMQV/Acezcr1Vnb3Ox+jDgP8YMIhxEEkkbcirBSKQURU3Y/YpndN1RcCoHP7svGwSORRPJJ UT4pVJIhr69yXpuV3Ych78OQ92FIXgoitPLS6AG2I9vJ++7Ijs8njVWH2+ogRflUdpBdCIxMR/yg kksjblVyvAWs6rtyBrkjSssA4p1Kjl/HR4EcQHzqWoHdh+8O1FjZBtRukI2MuFzQnOw2nX2Y7c8u tQeH2XPZEhHJUD7J8qStgAmAvZl+ocQ/VuIHlfj7SnyBEltlo2T+j2R+XTI/IZnbDGwyieKir5T4 UyVeJlui5k+i5p9FzY9EzQ9HzS/QD0kEncKyL2L+W8T854h5b8T8dMR8V8Q8N2KeETFPjfChSkiI mFmAx/QiJS6U3SHzyZD5LyHzmyHzGyHzQyFzb8jcGEJ3+j+kGh0fUOLtSlyzt9ocrDYHqs37GTgT vTBrJfoXGKMXErNgyCZbgsOCXklYONsdAwQKs91tSPzZ7nOR+LLdq5AUZLvvCrbpmZXuhrISZBa6 W8dTUzZ5LZqN+USXTV6EkjqbbAgO01w2KSH5Nrs4gOSb7OIiJCeyi6uRfM2TF+k/yWKGYeg/sot/ iOHpZ6SED0s/JnH2DNLhbHcreu/N350+R1poDNVZaIe827PZJCZHn8wmS5A8kU1GkTyeTx7JJoMo PZRdXI7kh9nFdyH5QXbxUST3ZUsu5bfbQUqUce4lcSVdne32o3kw280HGsh2p5GszHbXIFmebXkb ydJsy1F+6SV0N8XKpotJUpnp/OziJJrnjT1IHylRmueSGmXkc7LdHCQT+CBtZto19iCdtIPrfLSd 7lZGkbPJCnRrySbjSMbnIdecXZxCqT5bAlDTumzJDwG52rEbJDh+XqRRTIMPJGWTz6BTMLs4gaQo u7gLiZ9fiTkXjN3VTlqUSdmySd5LzCZDwZ9QI1msTNlA4vS+PcERjPttyzA9Pxv8Rh7W0WzwXyVI 9gQ/714Q/Hv3MDTe4Geg5Gf2BA+j6wctyMrG4PvJo8E/LY4Ef5lED9kf/EWyPPhqfH1wuOSF4FB3 UXA3JpZZvCC4a7Eywo/juCwbfLJkmFFcvXPx1OC9yVRwexxI2hP8Hjpv4ffAQJuT64PXxa8NXo6F uKb75uDqZCA4UHJRcFkJv5E7uDR5bnAJHuQSXLNo8SXB+cm7gv01yowvSr4dnMmz2eCUxcoTTWpR GiYuPjc4ATNAQytvwAyasC4rcWl5zQscRtBUOobeDp5X9yKDFKabEFbJ5dqXtNdoF2hnadshb4q1 MW1YW6R16Ow6UWfRmXQGnU6n0al0TEd0hDmGR4/IKW6yOTSK5aaBEUAJzBDEIuMxIsSEUR2DoZUp EKawKTPbM3WpKcPa0XMz9akpGV3PhbN3U3p7L52SOXAxmbIglDkxUxqmhhlzMmqpnWbsU8iUWe0e dM6wm4YpmTV7mI7yKzb7M/aO2fsIpaWbb/PzdMLm23p7iWttq6fV3mJrmND5v0T9SmV/Z1dn6vTH czqLnCcVyNwzZebszNOB3kwlz4wGeqdkEjNDc2fvY5eyZV2d+9hynvTO3keXsEu7zuX1dElnL7o1 Kd1IC1uObqSbJ+jG5pIW3g31c8/oRnejunN3CyLeaTrdzTuBaKYrneYoY9GOMzsJt9AOpVOHcIvS 6Yf5GyYxD9xQ5gnGUl9KksoNk+pLlW4e3m13PI7bLUbUO3t3ZRwddscrleYZp5tL8s0/yjf/iDcP U3q6vUZp3wceznvsA0srQZ+zQPj/c2FR+/+HG9Kh8WtXzO5aJHX1S12LEPozt6xd4slsWhAK7V6x ljeEMkK8f8HFS3g6f1FmrbSoM7NC6gztHq9c91/Ns3nzeKlzN5ndNWv27tnyos7seHl8lzS/s3do 2rX1g2fd6+bv7lV/7f9yr2v5YPX8XtOU6/7rXoO8eRq/1yC/1yC/1zR5mnKvKee20yk9s3frSHtv B3DO0yFmNIBa+v3h3naXONCikE5T2HONf7+K0CeJMdWbMUntGTMCp6qytrI23gSS5k0WVFvHmjzX NIX9++mTY00iqm1SO1nj6Vraid9qfNasuRwf4GT16jxieBuvT3Up7eiwBjnE+KAn8jyg4nT7GsLH GPukUvm+ZHWqY/bu7u4uz9JOP5T4Ia53p3pXk1QKPZV7EdwTT60o+i5F0TdqXFW/6/5b99fdwgFF wz8E7f6IouEfgHZ/COEINPwi4UDLoZYjLcKB7kPdR9D3g0MfHPlAOFB2qOxImVA3NgN+q16KqZ7+ Xp5afTmvTlHlaZXnRgk1a1KrAQLEY2BACQ1rEDiUeBvP8ktTGE5pTOWfAjX5jHLl6jUo8AuUWqWK X8OvupwPz5v/j89YLViw+nYSVE9VQqHwfXgvyOhfEI4ifJKbPHpSvZxIuWWjR4QCsOtoPow54GLk Bih6n5B7yMukj7wJvbGLlpPZ8PR4iBeMvYFMAfjcRE0NcP1IZArpgStiMvkbNZNdZBz5jE4g10K3 mU4egF44DUZ6G7mT7KTnjH5KriXv0KXkGVz9JJXhbppKJ44eJjNIz+he3IOQJrKd3EctEFZTqYFK ox9ghNVkC9lPfk9GyRxyr3onRukh55IVo3vJXPJrOodeOFpIJpEV5BpyL3mIvESO0pvoAZV6tJ/U kAVkFdXSAloiXDf6JKlXv6d/fvS10UPwZq5A3/3kc5ZSTRj9gsjkExUdXQIlv4BU4buCPEz2kPep h9YIHcQC9XMuYHEV2SWUYI4Tyc14tv30SrpLsIw+iqepIxeTjVhSV9ADLKx+T/3V6AZix/NVY6Zb yaPkp+RV8neMNoHOEi7LtY7CDwB5miJduNMNcLr+GJB7Bd/XqJWG6SSM/FP6Af2LsEL4CCM/QY6R E+TftIQupdewVnadunLk2tHnSRxPKGOMSeQCcil5lsapTC/EtQ+wdewamMp7hPdVJaovR+tHX4X7 BiY5uY48jef6FXmHvAt8TaDd9PfsGmFIfePolZhvmizBU9xAHiP7yNdUTfXURB00RKtoHZ7sSnqA /oUFmMRmCwuEXepbR9eP3kbCWCt9ZBGuXEauJ5vJXnKQ/JX8nRyjPlyZxpWttIfeBhP5NXZQuECY K9yjklX3qJ5RvaI6qbapX8n9OncEUOfjVJBufPvIYrIBsB7G91XyRypQPy3CSOPpZIw0jy6mV9Ft 9G76CH2c7qE/p4fop/RL+h/mYbey77MX2OvsIDskBISk0Ck8KLylCqv+qPpWO38kkHs59+WocTQ1 WjW6bfSB0T+NHlOwUEhipJV0YHUtJ5vw9NvI3eQHgPlz5G3yO6y7w8r3KPkKOPiWarCavJhRhEq0 mJbi6S6gs+k6upXeRR+lP6N/oUfpSUaYiUXwTbJaNpnNZdexz9lJwSBIQptwhbBd+I3wjWq9uhLf Z9TPq7/SHNXGdG+dvH/kgxzJLc3dk7t/tAZrUYOVVwCaqybtWHOTgeWFZBDfVWQtWQcYbQDEH8DK 2UWy5AXyBnkLsD9I/oQdgMPkqPL9FJg4TkZIjjLgU011+ObnXgHMdGC19NNFwG3+eyW9jt5M78X3 fvpD+hDg+2v6G/oOPUw/pF/jmQgrY23sHDxRD7uQ9eE7j13MrmW3sOfw/RX7PfsT+yv7RhAFmxAU ioUu4RLhJmGrkBGeE34r/E4VV7WpJqqWq36u+jWefKJ6knqe+mL1LeqH1I+oX1H/Un1UPaq5S/Ow ZljzidagrdX2QC29WfuU9gXt+9pRXTHWUzdmnxjjUzy5i16oSrNtdJQN47l/wtYIb7Lv02fO6EHU WzGDhTCmh4WX2A+u2gYn8LPsOkJUnUqv8eBib5EXyVvqd1RO9Sfk58xHvgA//L4wn/0EpraH1gpN qs2qt8B11mOej7DDTMt2ocffgY155DzqJf+jOp98CfgfVG8FTCewD+gz7GcwnfvIe+RR9gKBUU8W 0TrMbiF5nnxD7qT7hBDdg3W3kRwin5Mjp+erSo+0s1aNh63VNAJD++iM0Z+zxOjfQfV/oZvJn4Rv sPbPp9NomjxOPgTWf0eraVCVU/nJr8H5isj9WLUfkyHQ4C9VUVDQ12SfUE3mqI5gvaZHfpHrVK8R rqcnWBvQ6VY493TOjcGD7wWv4nzUQnaB1sFFFIr+O3mbRiBP3tH8kdxH7iD7BSeJCY+xTWxUeEMV It+DS3Aq7no1+FMh9qqeJJeRpYBuaPSj3KMYYRmpJ/V0AZ1DOtEykRSNXoaZPw5eJI/OHd2h7lWn yK/oVOokL4N7eQDFe9T63DH0fA50+Ccykd5ChnILyQHIFQ+N0UqspmPqtept6qfVz6l/on5bM45c Aaq9H1j8KzkOqRGiFwMWn5F/Ya23g3pKQT9tmMVEyLBLWa/wEumgPjIAHlgCvt0OGMwBJldjlOvI raCnxyBDfkW+oiKdS35C3gPluEHnF+P+OowzhZwHrK8mj4M7Xk+HULMQWwpJ0Nk31ELr2Rrcj/PZ e8BnD2BO75OPwDlGlXmV0ibaCexdTP7FaRl3qCU9sAfI6B7SAEnZKbxF/gbHmkjawV8exXX9WBsW bFU0qD+kjJTmpo3Ws6XCS9QFaWjBqpoFyT6eDmIWVjzHCHHS6aQmdw5Gewa8rEf9GKRvCpLByZyq C9TnYd5/hCT7FVk1OpvepwUFyO3nzZJbW8Y3NzU21NfVVFdVjqtIl5eVppKJkuJ4LCpFwqFgUaDQ 7/N63C6no8BuE60Ws8lo0Ou0GjV2jSgp7ZIm9Icy8f6MKi5NnFjGy9J8VMw/o6I/E0LVhLP7ZEL8 uvloOqunjJ6L/6unnO8pf9eTiqFm0lxWGuqSQpm3O6XQMJ0zYzbyt3VKvaHMMSXfreS3KXkz8uEw Lgh1eZZ0hjK0P9SVmbB2ydau/s6yUrrbaOiQOhYZykrJboMRWSNyGbc0sJu6W6iSYe6uxt2M6Mx4 xIxP6uzKeCVcimGEWNf8hZmeGbO7Ov3hcG9ZaYZ2XCwtyBCuRKeULqRDuU1G05HRKrcJLc3gacgt od2lB7beOiySBf0p00Jp4fy5szPCfIzRlbGlcN/OjHvDUc/pIgaHur7lzFa/sBXqcYh33rp1Syiz c8bsM671h/kIvb0YA9ey2IT+rRNw61uBqSncxMuwzb2zM3QzbgmTI6Y8Vf758vZQrH9ZKKOX2qUl W5f1AzW+rRly7vpw1ueT940eIb6u0NZZs6VwptUv9c7vLNztIFvPXT/klUPes1vKSneLtjxgd1us YxmT+czMIgA936bklO48N+Xc7yBL+RylSRkZK+riEGYyW8Iz1fNoUT3ZenE9EIBPL8VVmYXAyNKM vqN/q9jI6/GINKOOiVJo69cEK0A69vnZNfPHajQx8WvCG/k6+W6pZej8U/lMKpVJJvkS0XYAp5hj i1KuKStdO8welAbEEBKYk6QHsJ3f25gG+MNhjuBbhmWyAIXMphmz8+UQWeCHIzANs4v185YDp1qc 5/GWTadavru8X8JKfo57Wogzo4t/97OKroKuJY0Z6vq/NC/Kt0+ZKU2ZMWd2qGtr/9iqnTLrrFK+ nQMUcEPbWC5T0DFb8DPU8RzzC0orFuXcOd91QWG2KaOK4adRFvXCYa0Oq1KpoaEJGbF/Yj7uNYTD YzTz/3bR8OhX/ColOX3Z2GNkGlNjE81PO9N0Vvms6Zm2ClNmgeWwKbPmbN1qOKttApjZ1q0TpNCE rf1b5w+PbloghURp6z7oM8VbB7rAhvIYHR7df4s/M+HWXjzKEtqIdctI+26J3jRjt0xvmjln9j54 xUI3zZqdZZR19Lf37o6ibfa+EJiuUsu+q+V9QrwEyworPct0SpN/n0zIJqWvSqlQyhfDIabU5Tuh jpKLh1m+TlT69fZy3LCOWbPHYKMgjq9/IJIQTQMtZAQ+OkLa2dOkEukcFSGTEbYgVCKEEboQrlb/ nIjq80kK6QwEP/IJ1YekXNNAZiKkhABJIC1HfVx7G0mgTwDlHvSpRj6uWk2WoW0y8hUIIjb07Ejt GHsu2lLCbWQa0ulIp2Mu7ajvRnkCayBJpJ1IU5qnyVReh7bJ6DcF95yBvnzsVtTZ8Cg4dICY4DSO BjIbcIdMz9co1WdFDJo1LiNq9NXCCst/9Gf1IcSAshHjmSFnrbAXbbCPYCtj+94Jmeom3BYmxAf5 Wwj5jEMFKIUQzvyEYb1KsGtisNSKoW1wzTUJeVxKygi3dgksrgpYzJVKnsDu5J9afNdBr9pPH2MW lhXmCC+rOtU+jU3zR+3Duu/pFxqWGZcY/2z62LzEssA6Q5xvY3aN/R8FGxyyU+fqc5/r+ZX3ed9C /yWFtQFT0UXBO0Nl4eXhz6S10f2x++OXlZhLrk9cl9yIOzFaCDAUqrGFDEi0P8foqxrtsKCTC4ha 9apADFrVq5R4dRr1q0x4kbYRPRSw84knJZ5oHmmeJh5v7h5pJq3IiycRjasI28K2GCJaqCInQ8KB k7KafIsjMAc4htpzO+hLtIpby7LtP4xq9Sr6CnnLPslkUE1xYkNBNtKqoJVa2zw/ug33ON53fOQY aT12/Bi1NTSMq6B9BTW1tTXVxXEpotVIkXhNdW1VJXQSzeI1S7VarcYUSDVdsPCc8zf8KLejtPLB mTaoKLa5Le0LN6+54wM+g0q6kq1nLXhan2xifwL61NSr4jebJh4VPyLp7mO4TbgmzNaP7GPn0JUH +VVzRj+mT0CzNZLIc2SSxigM0wLZGNJX6Jnea1p5M7/6ZF83nyquViaUnxwlE+Yv6OqaP59WK0lX 1wJOdJNHjwrPq5dwzYxOlr16vyaoiekTbq3H7ww5Y56EXquj63QBOMSzdnUxkiGN2e4eFgxyjMjR eDWRU+WIqmoRNY2vlqH57eTPVGa3RoKwOnlPyx1mapYLnNVmb+nX/+BTPJFa1X2sr2O27I7I0eLq CB8kwgeJ8EFWRuggdyf1oqOS6T7GHe1u+NvQ2c39buivpLiEp8/jqn732FV4dv70HevlBTQZCgfD TGO1iBamiUoxiWmMJoNJb9KZVBqny+FiGq/H5/F7BA2Dca+igiaZSqSYpsgWWQAugqiwwL2AlqgR hS2BBVQyFS8gHhdyKYocnyflUXLscy0ZpIPUobUwAL4Y35rqulq+NtwutcjLfMFobKLb5aqqrKut E55viKz+3vkLfji+NJxqqTq0Zu3bFR25t1SGuLc+5Y35HNb68kpvUsMefzNz6dYZC/s6B3c88ud9 Ox556KYX3qcLm24ZF/JIu0e+zB1ZcE5FqP5yvkq2gIguBlbd5PoXiYX+iNYQHX1sT2SedqWWUeyT 8Rot/Q8Ygos+Rqz0X1DWa4iLMdli1RG1TmtCZRDWBjYxZdFi6bGutO6yCiIIwuux/ARMWsd+RjzM TQ8rFHgU9NfX19wtjvRxGmy1N3x97CT9OkX7UliGNgeetcoZrqmqBM3YquMcBsUxdr9rQndwpDZ6 wWSffVyoapKd/lO95Ntnru4qjcVKJmxiL1+UDoeiRxVqwRM9gCcqJJ/I0ZvYj9mzglBsultgBqPB SInab9/pes7FXIUMczIYdYXDtH+PPe3OuJl7mEay1K7jy8ZortYNC9HnLGqKw030uOwnalHN1O/b 37EW0pcLaaGvCKfFXqaUegP74UvZhscDPfYNiif6BruPj/QdJa2tx7iDVy7QyS5zq052WxB5rYjM DXwh9AIIaM+vV/RQ1ik6KalfVNJsoa1V6XsU3MRmb6AIfbYGewOK4i84eyF94XANsddUK7BSFhC4 i1ZDw4BhXZXQc/KvdOUPrrvovvNite9vu+Tp/smLcs/S2KVtyUjURZ+n5duW3nKf+cBw/xOTNt+8 L/e8PdXF4Rge/VDYCjimyEE5qLW6rUtS61ObnZtd9xfc7XrK/rhrf4GxrLC1kDl0dJjeLUMS8UN+ JGzEPmc/BFSYvYUNl19B2OgAT7MN8ERqdyJlv9ojW9Q+M3FgX/u5EKVqw356NzFS356iPJjBDPba 3iEJMcESnDHYrG7q9pVZi2gRZw9F3tIzYJ4CzAfBJY4f6xOPj9ga0l7fsWbiaW31HUulxJGj4lF7 Q7rvmF3hxqSP1rSwM6EFVqx1AWQkHOE0CApUKA48O07Tq2bL6+fcuiA28S9bb9t73oWXX5l7O5d7 dnpDeyocEF89b/KyA+xJKdxwefPMdd83P/Hks6un3FLT8MQ1v82921DSWt5m0T14+ZybPwY8u8A/ D8K3bSD3yEai96qZRqfVGwzYGZethDoAcwMlgl5LdVq+3kz2EHsZBwaYyBjDwtyj1+tUxKQZZm/K Br3PtE1LtSeMX++jd3K6+qgPHLCbL7lmLCq+qmQHk7F2mIyFxPjSY3wR5peSsozcDVvKU1eLr50S U2oaBr/RSgVhSpfTwdzHj81sjMcXCCW5hkLVvFTRTPrYN/dySXD16N+E2+CJj0AbuEG2a/1uP9tu pvof++hOB3Vo6H7BSyTauSdhJK9gz3OYdsouEhfjjEeh+Ka4Kn4j0YgapuFN5mAgHWgNHAmoAv+u sA1T6XniFkGML9JGKBq/hejlknvwGOgKKO4bHGlIQ2iNfNTap0gurH8qxU9hVON0cHv/LDkLJqo9 U759lGDepeEl59TGCgtSHZX1U9/a+8qbS+5e2GrvuOiiDgS6f+WKn15+/uZrAi6PGOmuHdc+vW1t dt/18x5a0H7JSXSZNw/dAAmoyuoMaAReYFoh3xURjfbWxeJacZ20RbxRetq8V9TeYx4yMxqVGIlI UthgMQYM7rAn4DbqqZ7pAnqXzRlw0aiBRFyrJasYkkhYDLOwxMJlNtFhs4kSk8KsxGJ1WCxWttZC LYYNNhqGO0PlksI2C1NRt2SNREuwfig9KsqiVcDyNcDRYXVR1356HVBRLkshg7ciPgDY74wfih+J w1AEJuR4D2q2xTNx7R2XgX0Nin3Hvb7ukWN9oJ5mEd/WZh/n1CPNNjAfN+c+7oY+cKCGLZbylA6r B6mHZ/peS3EG1dDgIeIxKh7Ix31nFrRic7O2GfoWMNYHmRjWKthyg92DUcFdD8HHC1zYcX2puFgQ hFm5cENhuX9Zbvyki7ro3wropxPKIi0jA/7pIZeGFS775SF63Q3tqQa/qIvFjBffr2r89skfJoLq WMwlFtkL9O3/pO/kyqBnYP9fbQH9+aHZjqPnyXfe66b2Rf61bG3FE55nSvcX7S99S/t+2X/ShhJa TyfSSf7zWK9/EbuR3VDxJP156W9LPyr6JHKi6N8RrNKJunisMBottoQC+kjEGgo4IlJFrEiIkvJQ xbgkiRVFoaPqHYXlsZjeES13Oh0sWa7T6XUkJIZY6APvD+wqX1V0nLU4WMyKy6wWb2XVMFUNhcfP xhb/NK6i9kFUnujumL2HlIvlrLz70z7/7vLuY73gchCc4jEeIAzSx7w8RoBMyMsH4AiDaEVLM4c2 tJvKVFlYcnnUWncsEnfHNPHSmOQKpWmERylteZqGPVEeSaiTytTJNCEpsXlMX+E841p8ONo4Y7Fv qPi0jMVLUxUNkd7SG0t/r9Xwpl5EwCAXPRBI38nvmnAlZ64aNa+BQNfabFoHFJp8Sbjjp9MGrtye OzIy/aIOv7+zj2399JWB20f+cvuWiefc8D1aV9uzZeLs+9jBMvnCO3csXB+T6lcIAysaIrGZj/Ut 2GGX18yZs7qZjjyQ666srTtny8x525u59Jox+hf1BeBRURrYR1yjm4b0hupCWMU81YylZqRyLypM Pr2/tqDbd6PrFt8d/psLdctty+3rbevtN9ue0Dxpfsz9c/ebfoMGPKzD1Va4ybXZfaP/hsK9qheK DOn4kuA6zVrzWv+NBfut2jqLzR4NkDksQCEUHTKy4adsdot6WUCwLHPq6by0jdp8A3Eat8dW7KOV itIA7VZvNQQNzNDt9R7niB7K545Br+070cf5OhRVENfnsCpEmBaEi/4pM9fvrtQBvVFXocZsAmJ1 eq2eafxxs8sQI5pCREaPJUb0PnUMmidXPpMclbRvkPQNKrootUlcx9JwUrRzrNQ5NWCeUQhIe5QL Ql6lvqC49Kt7N/52XOvc1x7Y9Lu1q/712B9yu/a+SXtfuePBud5QWqtenksOv/a9tdv37cn9bsfA zZevW/5jOmH4FTr3QEs0DQORge6IelChvxQ1ynN9mwB4iUcij1I8uqRgieeS2H2J4RL1JbalKGy3 3et6tEBzsUUbCpBIRBcKWCJSYbnVwiI1fj/R2csKrYFggAVadBVa2gOJeHXp+Oe5HgY5wUkIeiaA KyrCJ95NHKKjwiE4agFSAHlPvLsC8oqXjvWOkRQUhjxgL+KAnSylRJ+9wFbANCXFieJksaA5XWIa l9Pt9Di9TpUmGkuJ8RhN8kjyISouKORRCnWpmDMSO4OcFO0/T02csqq4rguGpyi7EqjF7bI7HRYG W1GAOswxUFdrU+wBf1lTq1Xv6mgoY/P++f3nX5j7vZe3jr9+jljgr3pi9hXnti2eGIuFnEuFq5ZU F8faZ+SGD97xjx/M85lUo99+MCtusK66D3589QMbSoOgEFj1qm+Aj3F0mnzMpfLqWaiqomqgalvV k+53He+6P3L/y61fb1jjvKr8ZuF7DvXNhnuFew13OZ8UnjRoQo4up1zVU7VeUBsEg4FVyQ5T6/dV D+gfVf1Y/7hDbaJEO8NkelMX0IZCAU8kkpoxbtxfSgMpzQxK31QHNOFQIBGRqIaYtGbiFOHod6Uc Tpfg1rpdQ/Zyz7iSBC03mTwJ5tFptFbtdC1rRXSHdpf2oPawVmPl9om2smpX6uUUS6daU9NT81Ir UxtTd6QeTOlS14uuAdc2l+DyyVVQIKzmoJmZW8Ihb+XY8lAWxxhx9Q2Cb/YNrkrDIIE9kj4m4nus eUzeQdtWGGsKhPc5EUfGklNFQVSPibTUYB8+sOlsHKFVNqmcSXl7hheFvFxTEK3YdkA1pz1Yeazc f+0aMR43dS+eX1DdOOMnf6uMjf/20rKmqM9iVBv88fYy1cp4YGl//X2q3Mh7D/9wpHHN96ty1w1U hjLP5WbEnJaIZ7Fw1VynhEWXW3nXpiI78AtPjepx4LeUhuVurUpvKBUixslGtUatMcRZXIASZogb 46bpwgTDdONiw1rDjQbLhsS28udVzxt+pvqZ4SPVR4YT6hMGA4QcxFsgFHBGIvEZpaXDrEReVhyI W7Ety5GsD+hgImpnMPamJqAtCgWiEUmn1caZabqZTafxl2M05suU03JCzVZL0MIsLQErPE+MtBQV BbxlDmdpSZSV0BKT2Rx1WAINvCJGSmJR5tSVlb9IGRSs8VQLXpniCi7HT/Nx4Kch3XxMKVDFqSNC /QfJN8PFA6YJ0v9I/EjpNIarr/vyuPsu5bTOeWEeZQrOwAzHkDamiJxBmafQVVU8Z9V0kyQVPLW8 2A1iHGnKo4oTpuqKhGX1Zc0PA1Hv1G66bOSCn16Zm8/J8RSWeD535c03+KHzk5mjRzRR9aWkil4q uwyiOirELIkrgjcFb4jeELstcVPSII3JKtN/ya4kl10d4JlLtEuM64zrovuEn6iGNXuje+N7k4ZO aUJCTm5J3JhU74hvTz6heUT7pPH12JsJ7WSLhxsEAx5a9EbAMzfCTU3ZgZqNbmp7I+COSFVniK8I mVPxVKooSMWg2e3xRNQ1KcFcE9ETm2hjthZa5Kvh1+tNYnWNvcRbXfMinQlcraBHOK6mHefai1Uf hMdJ0V704LPTxNSJZthqikTjGLQ3NFAEIp6SbdwVkHcHEC7hujgjrgwlNVYjqCVWHAUT1sZMkj5G LGGxneL9OlGTRMlQbI4Ra8jcTnQJRd5B4HEVVpF6Cr8dxMBYQkC3FMcWoYadknmneC9kHwShTaOC QwaUWSMSzo7zMnBzrCN3/MF7fzlr7tu3jbuk1tU1TmJ3TWkS9dflPt7+09FX6yZQiLxFM0pftxdW OCAQI6+99UzuVw+9mvvjVqeD+nrS8VhMHYwWTM591Ni09JnlW5+hlfRxUTcl0cA1FuinGgfotYO2 yvaOCOwAaIoBXSTike3GVg+Hs6WusJV4RM9Oj8C56jD7w95IZSiQjEQaeXMB+jXK6GNtDDbuahTa Q4FG9NkT0fIRtN+NoBW1O7UCDQW0fATJFuJoT5waIaGMkAgmdiUECVwafeSLpKpQoCGCXdWSDriV gzh4AtdrMpHweNyssaFBp9PqJNIutrP2lkprFcVvHvju1aSrv4vJXT1dO7syXaquUN5T1GIjIs7d 0h6Rild3jl87Jq9XjQnsvkE4UPIFLpQVI4TH9gZw6BGulCpoVOIzsgojhoVxthcJbrPTotXJHWoc weHvEH6q5rTfKX8Fq/hvymavcyq3GulhV2dDKXuttFlCiedHmvN5dmtu7n+Tep7sc5voptMtJ284 ncd2eV4Wsy+A+yDZKpeFOQIMoQCLRHyhgD0S8YcC0MqNoYAtItlteHFA57P6g37mbzEaONY8E6TW IwZaYZANA4YDBtU8RMzgDYV5o98fqD4SpgPhA2FWEZbD88KbwhkUNArcAWjusUasAJ875Di9cL4I teUMkcX5Yk34OwBycLEvzmR8p8ADsMXOYnZ5CCjPnJdKmh48aROdv4+Mhz8oUlI9ns/zAREOImow G9PGpkl0knmFeS2ck/fR+8w7xw/Tl0zD5r1NmfEniX0nJEG5u7yJtphnpmc1LaOXlOuIpanJarU2 lZeny6wQRWboHZBDrkikLBSIz43UNdUH6jQUegdIyjlXCoYCsYhkraW16ZpA7c/TNF3+ehMtL7E2 OTAK34HhrqwyixlGt5k0wVA4MAQgN/GJ1vNMGjqoGWfhxovfZV11tfEYczm1Gp3GJ4+n48usYlBk YktwJ5xW3ubxL7JZihzz5nljXj+FqPoIUG8G3JubTxnYqZRuS3d5qs8C+1q1Bfa1kusbs6yx+s+w sMcKfaKuWdesmHyKfc1ZHeXmGHemclOrmGoVZeR/QeoYUdC80Q0sgwsK59E/L5pU0zTS0lE8N/eL Sk/nlJFZp8Uce6QLtGCi/1qacl3AbOfM+J7QNfLMNWWhWExT5EquoVuSuduXVf/XSnBYwt5LcnPo 9vOq4i6jAHaYWIs1EYdlYMaaiJE75NoFOJR2pTRQrNombYs+HhVOE8LUSJ4EwLkFvxQlJCbGBmKb Yjtj6tgw3SeLoXAJA33gCL8u9hvyAzrMdsmu06TijVcUy8U7iwVuYk+Dp1BZ8sePj0CnAJ8ZaT7e 1wxZZHNz3+yYk+JMre3/IAEAF5oezCNz1bdTz4DNO00Ko/BI3v7BS7ctTdP3c9Ezxf8YRexc0mDR T310Z57+tUsAgVo6XV5VxL1IxiKqL7qyiFXUd9X21D9B3iDqWGEtXUfWFa4L3Ei2FG4J7Ag8Gfgs 8E3ANFB/pJ4F7cGCoEOMijG11W4tsDr4Bp6+VnMafpFIeWMgHhmDYrCRk0A6FKiJQMe4Se4ggcIQ Vn5Jod9RWOgntbWElAWKHIFAEaG1gUIhiNNHtTXYFI7HAoV4b4uQunq/6KO+FsNB42EjM/rqOXno C4uqlQmhtEnWO13V9UXBknQ5b7PxtvIj5exA+SF4NLx19cN0Flweaz3DeDOCKwx9CiOCApdaleIq HNQ5xbvhUWgkTyXcAw5K0cF7qQaBIPUoGbwNoXy4Tte3ipu4ZBA0cDbTyu8t5Hk8jpbZ4C1USKTK BUSelhTCITrASkqbo97TLJ7nR/7tGflKbb6gL1dhKZtWYmTg/ymWpL8SrgFWw55FJ687zduFY9+m VG+d7FrormyNxWiwOm28UJhzSVVxjPP8ADwU24HzMF52stvBq/+dNTfwRF5nahALC61iYSBgNTdy FQASwB2JsMaANsLFtWvqmJcQOnlYLHRTayDQknchB/wRYrNaKA24w5DKWsLcLp1VT7kH0UznYXft 6h6JSqKtpJD4aY+fEv9KSJKrI2NieLCPS17oztCglRxXuPNSmCtqHPTcy8S9f1tUV79GUOlRuJEi k7eIzVe/tgUuZU5AfCOOjGbkVEENsYrWOrIqNBDeFNoUvpNss24LbQs/R54Lm1UhVTipKjZGCpI+ jTg8emG2oAbJ49Bm+HtbooOK4ja6szAjZgp1hHM1sDb+ssDzos7hb0XXI7Le7mklOktBK8EZi7GS 1dFqHR79eAh9kP4xa3G3Kg4Pfti9l1Ib/ItasDoLc9r4MsjvOoFR2oqh+dXQHPuBVDFID5zfFI6c XL68K5QLDswOpNpb1FNP7mXnbEg1Mrgbpen9325XLT358OXnAsFzLhVeitZGWAyyowfY/Qr+JzMp os/IVUvEJQX3Gt61v+t9z/de4buBj+16rUdb5GYek9vnLiwWiwuKHSU+QxF3g7h55BxT+DF5xWnF nVXceYVNlE3yQmQ0vBflkX07vYft0OzQ3WPabn6cPW76ufrn+p8F3qXvms1MpdVp9BoDdk+Y2+Q2 uwL6xd7FhVeo15nWetcGtlv3ePYE3vV/pTOeb7Hg8K6rRqu3G73BFZxHilyBl73EL2KJdMsCFXzp UCvcl1Z70M7s0Om5pTXIdXvZelYHe/exfBN3rCh7rFyVn8FV+WZaJMYCcUdcH1PHvT6PD3uuZnsM cPLHqFOHnFuDnM1kiVFzIUNMCwyuGPGpEKVSzfgqiIQnCx/4ssgg90o+p9PYG9TDo8dlo72BeewN JgS8RP1J1tYA4+lzJGj9BDSmR2m3GQc0xj69+XWBEpYWjcK20bJwqDhuE4kaopHvv3IXjL1GhNXs hgfl7u1v5O7Kfe+NH+K8cf3++dM3nLfjkq7ZCxber55nyq3I/SaXey138t+vUTMtp3dN/ckDufdz jz2+plKm3r+izriCe8OqYZ0/Bur3gU0f3EdCoH5TQ4hT/1xjw/Q43e454T4R+k9EldQVEmqCrh6J QGPXRCQz1wklf7mdlBcWagrsDAqHGKbhD/pdm1wPwuWxNQ3voj+vapeZiUk0sR5Tv4mZro7Fz7Kl ObtVWKxC7YpNBlLPO0AAjTHPBlBWFJQcPo/b62YayRFO06APUcQJj3HIXcRdxRwjybxLixdOKRrc x6to2jXhEHcBazWCjRtTfPONJfxdc79z+k6n0dyj2+Z/HLZtuOGG69ni3E3cxXva2XvogRtejHjY vSN72J33br+VQ5BrDX8ABCVSRq+QW8/zrfLd6xR0kkea4jun8JzI/MKLI1o7Py4jqkWNqiJ9iX+d f13kJukt/5vSobRuh+u3vv94vvV+61OndaZh9rvnFBgrGQ5mZOQGDmoIQ4UAyqSIQ5IiG6VbsCVD koVh/6bI0cjxiCBGeiKHIsKhCI24k4URKR4r9w/Tv8puCSZdtKy8AEgK/SYcjkSgWOmgllM1TGaS FJMs+QEOSGBjzhSNQSiM4cxk6uF8unz8PhzS5ntffXxPT7GERGzNQFMZs4uUPYARjrHmY9ihyTv/ B1f1YRsGhT7OpBXNkQtGZR8gVFzq8Dlj3jj+dMCRTNNiH6KUqyxNE554mvj8p33+eWzmt6dLsCyN poaUztRQ6ClwttA8E+U7b/8LqhV3P+ysse0cKnB/WB7nITj4RyaPOfrXnji67dKuq3CAxp+ozZ2X m9LbcMvW6Xc+xJblbjgb+517r7xnQUswV9PrCgoxtoztGPlx1ebl93+fy1G8DaQKg9M20DK5wVNx QWJdWNBYqN6qTWkqPFZ3qsyaEhO2dCSUipbWJmtTlyRuTtycfKp6OLm/uqDhO2/HJNlJ5lhrg7Ws 9qlx0HrmhALBUJDi7dwr5AlFc4hP9DHfU85EyqqLW41Wa6Gx0Kpaa12buN/6mPF542tWTSphNaok dc04Qapx6qfjnY/8nyyo6QV5BzRe9JUtdl+TjMMFTVZdEIoqqp4Ljiv3Ng7Tht1jPPfoMfDV1AkQ 5NG8mwQqKdz1QKniJuHb3GObAJ8jr2R3a/ixOTkkGAUriyXiqWXGpdYNxvXWGxObU3dbnzW+YPyl 8ZdWM9z+vVy1HcQGXIEEjTaS34LjO2+gUO73gEMS2wGSrUrxe/Adm+Jy7AbUntoVrxNeMSYCH96w eJ0zIKef/mLmubl/vSWvOr8i6Gu0x2Kl3945sLlqyQ37Hr7gi+fbW9Jb/L4iM7whzU8fvOycMild Hp51+ZIlNz79tS/qKEkw8t6HG2ZUzJnRduGmH857+KhoaguN51idDOo2gbpD5Nl9JALzy+OrjnAd skm0V4ciMkjuQERVgQyjf9ZqT2LDxRMKiJGIPhSwRqTgn32+k0WBoNaH1/eZiJMqA9gdHaZJOQJt iDukWryih4Y8PZ5tHsETEoPwI/UENwa3BVXB/TSJAys/HgpzISie4FsJIgJIEBaCYiKPNJ/yAp9y A0PpVEyuMR/h/+lDVBwNkk1tioamdcbnLXJ3NJaNNOZdCgtubrnAHVdPzd25cWXY/u1np1VIlatx xj10JYdIxegR9aOASDkV5Ic8Vm+EeQzFkaR0pXSb5XZpl/S2NCrxf1TCOUH4VZgoDECF3eja6N5n eaPkvZJPSixqyWkRI6FwXBoXnhPRvhL+WmKPW/ZYWJUO+ys0EoFZDFd9MlSOzZZo3i3kcbspxjQt i+qhM4Y2Bum84GiQBa+uqJAreioGKnZWqCt0Vm0Q3viWRKInSZNXp0+5dPKnfBTpwq1dwI5vWuLL Ja/CkOBQws5XPB6zxIwxXZoUl5glEbIlrC82pYk1ggjyBBfkr+FMaXAVXLarCrhar4Erh3sixuQM Vq7iolBcPA4NtrGgyykCSFvBXpSmN3nrrulfcX93PFB2Lv1dYcNUm7n1+DuZ/usv9cnnq6fGwo1r RpbsWTvt4h+/xxIXTrO6Y7Hy8tDMkZEvf5tNy288xe69vCECEwlaKbS7LHAR5ruLElZloy9afUii VartTiZKtN5NG9xL3U+5h90qlxubRF4vf/EwQLxg7E5LwGzSGQOmsBfquzw8eqtc69ZqQnCiQ/PQ asvcOMPgdqo1mhK3FzmvE68sqExqLwSwU6dWa8NmE4HU18NuO7C3bFK15Hb7cOyynLjpdbI9ZJJR 12+iJm9EujSMff3vjKuUz9s9MuKZ1rWo8yN40r/zOYCxgMVwlwP3OKi5QYUMdvR9Z23mn7WlvwW7 yzzkOc9eT0hnq4aWCQ2dMxggCRZYijqBCy3sLK5T5w0xJ7a0KFXkAceXOju5MTkzVxbOpWc1TGdb XbNDbrGchqmpwhUKps4BWkwdlfu+Pa6qfbVTj019a8A+bvlIH+u9bLKvqNxkU2wp++hftNx/No5p 5KE79P9OsEmepd6nPMOeN7yfej9NaBs8VFvqhoehlkyvnFfZU7Wc6KyVYhXfwxqo2oRNr51VmSr9 K/Rg5Yfkn2S0Ur1av9q7pmSz/nrvTvKEM4NX+vQebwILNF3VQCaFJoxbhXc09USE63wToXqvV6vX G7w4IejTGYkfVPg3FfCdd5S77QFbqCQcCMHpKZqsATHoA28al6wIjJNVCRUxDo/eMOQxGqD/XSkv TYAacWZKhHTQlSVKHIlEiYkYRVjYxjKP2wGXqx6HOwwlHi/yXo1WW5JIolPSjbdbVGKJz8tfcfFo zgMpJvA6DH8DxgQLwDguFIRKi7erceyoii+ZNgN9CQw2wZqJDIbXirw4emAPHHEiP43ALhk6c/Uo i8fnGfF5x1aQYpJzt1XecQX3LF9FsMzPWkj8jMjpFXU6Bz+8orA0/F/W2JkL7uu+LdzFxc3LZnh9 x5ZdMqQ3V4dKxpYd7P6+QbxnCDVe8eTzlffd4gOzcLhpAYQZ5xJYl7xcUJBfiTXaL+LVDk1D7oLi XCZ3eyzX3lkrs6nnpMdRw+9wqrKtld3ZVeT0lP3rz5JYPx2rUojGTHd8+5Cw7OQ9qplPTNDEYgxb YleOrGBs29rp0F2pQRt2uteOXMO65rQXJtIwC8E57JBrGazUMnrhPhId/WTIEW4FHX8lP2luCMZK 3aWeZDQVUzs8Dm8wuiyu2hp/TP1wdI962LMnOhzPpD+O6hu8EyQ5fUnRQmkdDkevL9bFVFF1NB4v jZfhDDatVOmc0ZRnIC0oHMeFPfOpkVSABqJFAezGBsxTJRGnFz3+QKFYRsvipYGyaMyKLboyt8fh jsXdHuxTlGjUDk0sqsExGo2blJUFAoXMbNFVwLIYprVDMl7KHGZmWa+Jrgl6pnsYeExcdro1WveY KCAuGTuwGZfKtZ99QtJgkWarvfpImpanFZ6USvXBwXNM0WqP9x2DD1o51ZIXD1Tx+WzR5fnQa0om r8ieuSIO9OX9oGOJIoH5Biz3EeT5jiIczvL4nOJDY7hXThnVqDMd0cpLc390tdVOHdGeo/j1cz+d N62NbQ00pXu+Pn6hL3IhUK4vSr6Qc+aGl8KDk/fhQc52PTuexmKRguiduVa6455xfrtXDUwzMnf0 n8IHwqs4J9/MJstOjSg2qEJiQ6Xc3Fl9S81d2vtrhBau0MyfUrOngV6jfbzs2ea9ZT8rey/8btl7 NR+V6Wu0XdrJBZPdk2pmuxfr7ib31zyGF4f36ExV+BeUlh2q+8oeGKciLT0tF7v6W1a573Huoo81 vkyPtBh0rp6WNU3CRB1z2p1M8Vq/5m74solWVuEEkjZVWpIqjaVKE81Vz1S9UCWoqsZXdVddXXVb 1YNVP6p6qepXVX+uOlZlHMAOTpNDF9Yt0l2uUzFdk26qboPuZt2Dusd1b+j+oNMbdX7dgE5w2HWC xxwPpjBiYnG6aSKr3E760mnmkROpaqsn6JnnWel50LPL87JHe9jzueckNC6PbBGrPQxqg9FaGixN l7aWqko7Ex3WWDDGYp/hFQN9q36j/mW9KoSEEb0InW2YviCLcsumFia39Lewlied1Mn/W0Eu6Slp HfVTf4rUiXWsrlItS7HqlXDAsAq1rO5R96tVau/4+vOwTMdtzp8OSXUfGzw+mPppH1Q7HEhexU2s E1zfxgmAVBqyC3rKcb65PHL8KM5ZcQ18lXJKAKdwFFVc/IVObMYJK6w3uirPjp4zeQIeRvogAfme ZX1joWQQBZUV7o5wzBhviFuKbEXEFNIXYT+nUagrImKhuYgaIojqVU1F3JJWNi25foQPP3RFwc0U jjaIjUvUxaDW8EOqMa6Zc6XyrAOP0NK5Ip/XiurcXAeKF9u4QgRHZ1Ulm/TMTT3LhmmNWy5pS/oK 45OaWs9b9daKzfe7LQaH2Yd/B1ze2TPHsL6pOOwtq9y6fen05c/cftGyukTA7nEGUyXjuqZWTbx+ wmB7cnvubjksxjyTO6bcTRvOmVFbVy7hiA8jqdGjKj84nJsU0xmy1T5BpxznpB6vLRrECesvZL8U v0HQFsWNRssqq1U0urHdAttZ1vrsfBcyO6VG2Yysx0n9nsShBKtIyImexEBiZyKTOJDQJix4tcUb 9DJv0maXRVqBM4894gHxEOx8b8m0QcViHoRLaB8XZ0PeMHcSwoAIKSn+wJIfgu3l6nxDWoTDmR/R 3kcS+a78zryrMpGxridOsaaj3JWVEizYZaR9eRz7YiqzOhaN+32FcGTp49gAUUWKacDkLSJmS9CA vKSJF1OfuaiIhHVFxWfhWDmNBRebdLV6QD8Q2hi9R/eE+nHdXpXuOt1mPcN/Bho2BjfG7lFvj2oU R1cvtXEUc2eKglrYaXBkcodl3pOtGNrQqyJ019pb+5/u3/DW9VPXNtwf0RpSVfQGjWFqU9WkcbXF 7VB3R0Y2DB66acc311fULlI9NqOg0M9iI4/m+jdKTZManz3ybk8jl1fTcGp5HriYRP4hX/a1hkb1 tFf/eNHr7HXpPfoZ/SvTGnS0lCUdFwQX6y8JrtWvNawq2l7wbMGzONq937GnaL/0etHBmI1QZwER LIWH8GYwwx+ZHKE4uOrAawPhAmjHnq9s1PZ3T9yoDU9UGeG+tqQoR0Slt5Wnsl9vq8Zh+500gyt8 u2JfgkdYC4OFrLCSb2vzfjzdU5KqPoTtP36J3mSp1nqj9bcrfkxIGxC84q4Eaae6j65S3JLHBkUc bIW7pG+wgRvY7lNH6qFBrBqMKfQD27eOwzx/qPjUaxlcjQVB1QpysP31lS8cWXzle3c+01Xf1K3X uN3Bikj1rEl1U8bN/ofnqvXU97OX79z1vTkNndMWtnq9Vd0P3vCPphSO5+Bv9kArXaCVIugDG2Tp XvOT5n3mvS6V3V6nI0ViEXMHy/Q6z8PBotelvGAF/TxHH8a/LA7TC/fqUjeYYEnARTFP9rrXh+MO LYbCGxdcd4QNK0IwJxUAWgAhK/7mkWVgBvvSABCojCdDIDKe4vyWpbonfSjNBtI70ywdhKSXOd3I Tn7pKSo7JKpEb3n9tWNb9mMwBQ1BmA/yEiQ6NyxwRBGi/JiovNvRlyeZ74imJJI0F0RjUoxp7HF+ ro5pLJCg8WKSNCOK2cLFtNiaUkiF+2aT3LcIKkkPmAcKBiIDyUz6QFozYNloX+veKA0kriy70b21 7F7zdtf9pY+7cJS31LLJerONwTGMU6kKdUMB4YxAeWJQtwIAUDcfnR9bVYgHJlcNpyrlHQCOcbdC W1JNAehJURcVlNcJv9Hoyupzl5+zcsLQkllLnl/SsaRJb6po3zJ5ecwTS1eXuUtmT1NP/fatyxzh kCrc/f3zW3Ze99L2LzdUt1HfclegMDly4+2O4AMP7X46XrA1vwqEPtCYk4RojTxbY5/i6HOsdCxx LvKsd2hjhifwrwy/sP2a/Vp4z/ye85/Cv82GjU7wS7wHcb6wWFgZWSdsjFwv3Gj5zPyJU5/Ujbqo Tq9P8WUQ0gm6PnXIRegE1zAtec4fL9Cq8a90Qyaj3sWxawR2XbI3Uu1ais2TA3s4skH2yA4ZLdU8 lT22GuJLR1oj8yJfRlSRUCLvpqxUuCr6K2mRPZ/GK6qVVWPCcjoEa8cbHqNAZX8of6i570QqxRcL nPkKFR4f4U6B431HqfiLQYWtQkwGYnmHc6E9WER8Dhf20G3+Iup2IhpzOHPnP4RiH16iCuepMS/x OALtwJ+2WnFmQfg5hb6RUf2crvnNC+ojU4fXH1p+/sjTt//6CynmlKrDTfTr/ZfO7LjAdf+1O699 +TPq/PThh64I2qt675cAina8T9QO/2IZTclz5TTVFASjzIp3MIMaUatKpnDsPmETzSaTHQw/JVpN 0aD29QiNBjWgWRzTaPULu6CaVMavc9Iyy/Wl6AJ5bEjzVzKs6WD6cFpIwxqjygmfCq+/2lOUiMhI I9sS6T8ehor+e0ISY0BPmg7hxarfHwKH/L3ZbE9gZ+PAEAbiqZxOVFaHTIdMDCqGqcK0ybTNtNOE E5YivP88e8j0lUlrwnHdijQrT/8yvJ8uxAFMOIcHsROAIyBgi83i0cGjg1CFlNxHePvu+E+hL3GH AUCd9xjAkdN67Bhno/yAOT/Trxw0z8dcLoKg8iRVh8MGeDHDJtVU1RSfeutRUV+w1Qq5xb2PbmeV kx52hM4f+UNrjeOmm+g7z125bvL46vFweYjuQDHbipMF6y7ywOCKUn/FVHbzgq70tgNz68vaa8P6 QpvVabBW1OxatwBoIt25CcKfQEkVZDz+iekteUZMNFpbS2Nb9DeV3ZV4XrVPn03sKf8q+nWnwVCl r9E0aJpC09Q6kG1CnwjWBycGb9VtTt6vf6LsiQ6jPDHaHjYnPPiz8kZt1NGSMKdNisbuw2Jvke0N LXK8uLoFuyOInJ7qihbKm4fsnuqWYUElOx0OTqKOQN12kymQZoKcHlctDAuFMk7HpsZtT2u74gHr RH4JNvx5Khsw29BEOnGiBwe6Dims19xIGys9q/Ay3qqglqa5dBM0cqK0HftcrYisrel2am0P4ujV xLDIKxGhUqT54yfDglp2xKsrQKismlqrg9WsWg7HU6X8fkHUlsoliepSrjBbS1eW3lEq9JQeKmWl 67qhLvO9B650Hm3m+Mb5SlDxWDzSN3gSq+WYUs3PZUI1Ot48klKOZeJVq1R6TCd2yMFwdar3GBfB +ORr8e+CeOwYwIdpZAPBavBh7t9WXAL5lOdtDcpqggaMt0WcEldt83497rZ2VdXhcJ6yrYQ1xXXi unzE46pKbb4P320qjguKoswFNi/F2Q9o09C4As/KlydrVpWNr2v50W+mDy4579onrzk0p+ui65at vvGKI5m+yY0902ube8pCly8ON6x95JYHrf7LhAdWjCupbVp410x1UyKKQwzy5vNuCY8bd0FF+SSv vKrruopxO5fe/IuWy4fvXrniwaG2im//YQvWVM2c3OG1Fbm4RjUBO3/1kPml9PA+/E3+V1ljg3I4 Ij2lplo9gbEefjZC+/8Udq1BblvXmRckwQdIAkuC5PIFkASWT5Hclbnap0SsVtpdWdZqbcuqJVeW XEm2Y8uxLDV1bY0jpXKdSZtkHSdW0noyVp2Z+vGjkrWSvE7aej2OX53MaCcPv9KJNY2mtT1p4tRq pkmzVL9zwZXlNNNyJBwABO4SwD33fuec7xy43WJMLIguuOzzjhV6UMkrK8TwidALIQEx+4iph+aF H1td+aKpg5bnM/WgYaRNPTcvvGPtNkqmvsIwGLgAKxzdt7o8+VwORCa/V0fSUUWNWLmxVsRaP9mM WKv7I9Y4/g8NY6O3D4tiCYtqDYu8iQV6d8SCS+hchMkRlo2ciwhKhEXIFAsv1JleP1kXGvX9dCfW 9NOFzKEpLtEal2iQS7TE5Yo6l1YIylF32DCuUipSfwzhh31YZI3iQnERdQuotYHhJpfQHS7xo/ih vkyuWUzUpm0oQj0LPZRHMxXawAdDGgw7Gtcufwj0YxQjFzS5ogH9+FdOGsB4bsvzSHuEBkutHP0c H0jtIWK2860I0udCNGqHKIczRDTaEI46lVN5Vh21tI2GP7bjAEZAhMiA1QlGcHOMJzktE0wQXyHE ccU+APiXNh1Zf+MD5dLqdmFlIhyupkrXrJAjI+3CSKKrCNrB0k+vHd/z+ePtr97Z7zFNTy65l/3N H4/kBta3pT2JvNc0xWzsTufZO5pe4h9UAC8NMIsl5MH+2IppR7riLZmKAaThBAwraTFu6mECk/mg qSPp7uenjW5TT3+HF1oWce1dzVXNEyITLUSf02K4y++jO5LGXtsWt5zlQMDm1Ve64xaaJyrxqeF+ nryaNeyk60icS6tR622ejLNZOIh5bt8hS5vRBF3bpR3XTmquhtbSZrGyoJ3XxMz0AgYePLhf4enx 50OPDcZ4ZwZqYQUffqurVyauR2D2fvKeFsa232RZ27d/rz7e9qzR1Ppa9z6+w7Juao8spXYPuExT yMd3C3ms9kA710E7H4J21tnPrHEhGx16XviH0FvC+8Jvgu6MLykV0vl83hhI3xDcEzwYvLfrSPBL qa8Ej8nHlKeTp4Kn5beU9xRVQP6zL5kMl8Jue7izckyrlNVyb4NpGdnV463pdYcEdRTVeL5HN2PI /0O3XHr55ZdbSy8j08dmAg4NNZZGU9ZBcATqYHbVew037GX44jQNDB8BSx0Jhbo/lo7rsbKpgxmH nELdF1VUPaqbumEYqMdcNwyn+0UQt9gCzprQQipOVGT55kwa7K60HNTgCURKDfP26sga8PtEmOVU uThzkwbMaHWbphGL+t/t/UWvcLiX9QKsRNf52Ttwx+yfK/sZMlhPnAodUL7NYJcjPTeWnrGTcu7V NN3m+SPlhZv0CpS2ARt+sXy+7ConGr1/z5zgRE6zCzYncgc0mFP4Me9cWLpw8eKOpX9VLvJ4BeYA 8jUnNikXL3YvXSAowg02ooH9Dk/S0UXpb1dyJK9Y5zxJ7kqGxsNRg7AdeXC6BjqOYLiG4VKPYKqh rsTnC6eHrD3iUQ5wPgOU9cW3x3MrLPat0e1Hb/3nPwd8boOKVXl+tLSmneno628f/NHYcCplIi3R edWRPe1//G53Hr2tO4SyTPLIU1yLr1BZ9D0wwAUTfU9xQNHCpLG7wqgqzGQq+aHoYDEoiigBWHK9 BcIEkofeAnAqWLFiBs4U3f4OjaASkEgrEVsgrSQxV2s2uYR2krQMqOdJic0iLZ7HFw7p4ePhk2Fn I9wKz4YXwufD7jCd19dskjxbqze7uHLS4PoJ7eTQcFkpobXEC/jkHZv7WAWv+e8/uax4ztf+iBQP V4/3/YifAXabEKYtfVJg4bBu+bUBrxxxjDom9AgG7QmRrRpImDpcC2+eztdMHTWr37TU/Jipjxp5 2dQjhmEVWd7Ui/PCW88Z1ggbMPURrFsVY62pTxiGJ19blfMwlza68laXdqvf7/I4JsTRkVJRjfin LOAhDsRu0PJNx9TxqZNTC1OuKfT4kCzrsiBXkglMmQmaHx9PvJA4l3BaiVl4ot7P5Sv1Gr6q8a9q L9TO4VULtdmaUHvfIQ/ocEpW1o7RPU9m8s1dY+fHhONjJ8cWxpwNLBbHnGOJyal54fq5HE1oRIRc pmRzAAbae0fuGLW1gRAX1IEYkS3oDByVy2MGjYwdinxnXuMmldnoS2WkoFvsLaQLfe66xkRPRkpq LBBsiCtBvgpotmG1HGzlGZ8bttxnhfWs15eF68qt+3JFRzbn9SAii8MccFDCLDd3TZ2fEsSAGWgG rKk3JPdm92bvtG+ztDDlHhQ2i5sDvxFdZBPcc8A2xqfQpWIZfqPnlGgL6Zj/NYdJlktMvbBlPqQp mEuEaPl+SL4tS/Y2JN9WOudB0vaz0se8LnKlcus+yqfh+P8/GZOt0vGqEln6kx349U1Hp7ffn5v5 6swtB2tF6PlQKqxWM9Uba13xsXYaObxqI1XKNfrxncbHAOeTh7aMb9m6fWbbF461P7eviTnaXUzd wh55YF2u1Wr798J5iOnH6LuOPXLYMqP6xrZ/d0vkM/k+QeEzuY0XB6AXVcFFePG9M9KQT2Q16kuD G/tnaswNrNgjOt8W3nD+KOmMiv1Akc432LspISyHMLpW9ZCSU6on5BeQsJVKq6Yu29ixALxo5P3A khw7ovDXO1bUAKKsIlM9m5XlkD9xq9vp8oDNtHNuEZ6j+UtnrK3d/ew+eDFFP0eTyGwmOKmi78sq y6rnVEElaKkCVqoEK1WrfxUWQIMq6YZKAFMlbKkStlQJW4LkqRKglPXayZrQqO2H2gBN0jUSmuQS jXCJdrgEiuQSrXGJtkhaMlAlskJ5elmlWCzQPg4rUcuhsIDcdyftIljJJWAlP8SXMZuFxIqP4SRH k5x2xSEIFhQnWF7naLPKaVk0cV+s3gM4OXoFuwHsuY8xZRZ/EB0a4V0bU8qEKfkWYUqZewIIU8qE KWUc9QlMCRPoAPk44KomQnOnN/8eVPm/++xLUw9ec9Ofqgq6ZLE/roSrya1XF/vbxU73vG96cu/G oSfaX9vHIWVPYjc7fnA0d6gtfWoQGBOz03I3BKKk+j/PoR8GHTm2xep+NcmKARb+A2+ogEQIT7zg 8YHTYLn4/cYw6rIKCP64mCtJNAV4G7mYtEWLi7mh1U3aa5nw2y4Yi6iRYFjGLoNWEcF5HDQ7m2hq LUqMT1xol0s0TfIsnEwSWA6gxJ4u9g/C80+xHXpUtq+3g/2pMhDVOeIPaNSu97OOIXgh9OhaVhNE NRJFhq9YSKWT6UTaSXzUIq4yo7GYL6w5uj2ZIvFRi0xzhjSwUeOaI+2OFylas8xFrZArH4NhX4kN oRDyBuW+gHu/eDhwWNmfOCLOBmaVI4nXhFd0/2EPvJjy4e5Zz5HgEXm22wu/PkhZRD3tEOeMPCVf x4ndAiMBNiux1TEuFQusff/379p7/5s/uPD+uas2xEPSVL2mFYNqoSfpfOmz7/3Fqw89wUovvc6q k5t++k937pi8OpFfvZPlnjmcidIMuxEukk/jCZZZEZ6GgjQkqQHFvqFQR9zQf5tLwRLHjaUZH/LI Kb2fb2Y0e7escGkV1VhTqbJj0sNVQUqgtItMtcTKekbRlLLIouC8OPLwWnOgEn9FR1EoABXD1MsE VDKGf6VsaaPo7+mBlnwbDTEox6Zl/PIOBwrB7ETN7p3PPexZ9Jz3OOHo/jbqpZTluA4Gc8UgEhh6 E4m53ibnhM2lsjY3DBnszYU82w+STl5BRal3KtO2D8O2I2BGAFEiYxTp9HzeHIULEv+qHoro8JAO jLaOzYEJFg/XVrZl1z+5gcmbGKfnwmcHwoPwJwARvr7ji2OD42P1/mmPP5hJlqNZ5gk0Btue1VWv v9DrfPKHX9m5vjV+9TqXGMu3bvnMm4NDSioBp5Z76H7BPRNLI0cfz+jaSxeEH+IZrRSesf5Q6o0q LZcSLKtKpuwS1Zj6Ss8rhbeVD5RfK56y0lMZVFZVPi89ajxqPi19y5iXThsSWHNBbzkamJQ2BkRL QsGw8Erd8ZigM0ajDl7xEW49TkM5W29FHI+FG9jRbHxU7dYTj6X0ZJLUCoc8jMQOvHHF0hKPxT4K h92FqiesFcJS2Hb+Wijjw26irIXzp32qeAOtoCqNKtxgly9BK5YkyU17K092sjUM7dXhuEzKTdZo bm7ubN7dPNw80RSbYW+WGqGlcIPNi4QPq2mv5ZPlEv0onC0jR5haothOKXEVKTzpO3zJoExCUCTv jDeLQdRLh8VxitcCwcI7GjWwiPVgE9dGagtkAIL6Pb86QEGL5VNzWdvWP2/50EbuZpyPC1sgjgaX aIVLNETy1OW2qtsuVCniaCWYVerGTUbhHWYpKSwo78AKxuw/SmR4+o2apsktbf7Sv8wFVFviCNqm NAX+4/hxzzvcmHDDONat4UC3hqPc6vIhlDALpGeXg/gZLzQlNyx/V6uBahJY4FroMukg+yj6yz01 /DSo+uKcLXGpmHjA/QjR3h9YPqz01DAr9cxf+uUcQiSQF8DuagXSiJ/wEY9+H3AVPPU8wEK+uSuo pK5lFx0FTQznZRYpBc46LFJ44QaEr8n51UfHysNqlhV2TH956/h+TcrFckq+9s2J3tWjt/9Vbe2j X7pmMtUVjnU7X2y/+OXbB8xUovzqX26dPjZTkVaymQcfHKn0TkzeMXjd7n0nemQZbGvkkl36SDjm WkKVw2+gmJw0GxD4Qgo4EvPsLJ6PS1Wd0aMCE7NSL95s5pQO+PaGJAElvkJWxi2dDSRTzIVX7bl1 FPuqRGLR+1Q1YuHuR6hLKUDvjchCZDHijCSSNLqgA+L+AoJf5GgAuJiqtoDQAkfT0oUdVGWQ/E0X wRilal12snnU5oeuRLyCAvQgKRr9VAJn/ic/kQvK2LB27dlth7r893/22bWupfYzu5deuLaR2R1b 2L06f4z92tj2XQAw5mghetjnfNKRZ48Ql2jB+lvgQXPRFHyBVKAS2BBwDQX+Ov10ej7t+oXn514h T7zjHC1gUUZgT0Zc73rYJQ8jU9IwbPtJI4eigSoB/sRen+RH9cA8boDoECu25lc0keCdCLwnAuKJ BPFEQnciATuRgJ1IOE8kdCdyz6HIZJFlxXOisFz06TuW3yTUaALlmaRhaIRLtMMl0B3JUxX7a7TM d6NJklYCIG/BZLp50hQa5n5TMOHwYNGKTAPNHBrmEhiPS2A8kmiMhBUB1PswxBqhhdBiyBlKGB3Q 1xn4bR/ilX7D3/EiYhpBdbGOF5EwBeemEqUazxfTBkUdD1y2gHmcnrNQwYDs8DJWDdB03u/8Hpx9 R8cfun7zoUpxDXsgUk6ZmdJgcY3zySWT/AMPzGy45c+eYAfJElj63J5hLZLczC527IIuxDr+HU+/ wXaf4X442D/nrb8DPZ8C61c7rg5OJbclt6durN+RvCN1e/0LqfnUa6lQKVJSUdo8OeGYCN4m3ua5 LfCNxlOOp5JvJoLoU8FGMNAIiQEEt6KJmB5VqPq+S8egg+TCSrRYMquhRmMimVCTyQTKNXRjRAre TKlnwRACYblGMoEq2w5PtNhwmLQK6yRpflB9WJPNDzRERESUn0g6pF195/s+7HP20fMIqqVmH0xs OdpAGZB55rTi7nI5W2wW18EH/Hqu6nAvQhcTvX34bi73IpSODGReYg8A3WazIp6PKZ3MUhjDCE+R NWwHE0BJHAKDrMq9RLxaFbmLbPJh+P+qVgV6j5eyyRH0cOxwdyisy6xBsG+I0QpfERM8pMR8bCOv kQ3Y2H+0v79urM5+2Vdaefyukb41bKg+vK79n3v71t9+/W2TzZWrGfN65e5UaVVBOPPNqRD4g/nu wv72Iyz19ZGeFcguc69+dmlj+7ejW3aOD19jjYMuk6kcQ3QfWJx/LuVASv19H+QWIRZmV3+NOFTE lWPIM8rDi/hxRVe7nmv9ciXXq/BOjlWoKz/oGHIMw+GyDu/nmMDLgqccG8DF3wjvzDTejDKDevvX oZL8VtSBvxEV2elDnEaQovERUVHWMT6zZWzjZHXLp+7ae3B6773X3X3XLZ+eub629u59ezZtcfwP Hu33NwplbmRzdHJlYW0KZW5kb2JqCjcxIDAgb2JqCjIzMDE4CmVuZG9iagozNCAwIG9iago8PCAv VHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9FQkJQR1crQ291cmllck5l d1BTTVQgL0ZvbnREZXNjcmlwdG9yCjcyIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rpbmcg L0ZpcnN0Q2hhciAxMTEgL0xhc3RDaGFyIDExMSAvV2lkdGhzIFsKNjAwIF0gPj4KZW5kb2JqCjcy IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0VCQlBHVytDb3VyaWVy TmV3UFNNVCAvRmxhZ3MgMzMgL0ZvbnRCQm94ClstMTIyIC02ODAgNjIyIDEwMjFdIC9JdGFsaWNB bmdsZSAwIC9Bc2NlbnQgODMzIC9EZXNjZW50IC0zMDAgL0NhcEhlaWdodCA1NzEKL1N0ZW1WIDAg L1hIZWlnaHQgNDIzIC9BdmdXaWR0aCA2MDAgL01heFdpZHRoIDYwMCAvRm9udEZpbGUyIDczIDAg UiA+PgplbmRvYmoKNzMgMCBvYmoKPDwgL0xlbmd0aCA3NCAwIFIgL0xlbmd0aDEgNzA1MiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFWQt8VNWZ/75z7jzyGDIJIU+TzDCEBCaRGAhE GJJJMhMeEQgkgRmMZhIIBAslEKCKClHXVwKC2loVqvzq6vpCbhJqJ+BKUGzLKuIT62MXdHXdahHb Ffe3hczd/70zPGL7a+/J9/7O6zvfPfecyYb1G9spkbpJknfZmtZOMp7MRJCsZZs2OKJyImTLthWd K9dE5dEPE5lWr1x904qonFlCJOI72luXR2U6Dzq1A4qozFNAx3Ws2XBjVM5UQK2r1y6L2TMLIZvX tN4Y658+gez4ceua9qh/tt5uYefarg0x2WPI69tj/hwgiu9Do8nJp3Jvi/qMImJwgsfSHLqDTCTI TpOoiUg+blpCCmTdbiKaePzwfS1JnrPWOKtR9Yn8hca4Xkt4+zHN8pedyjmrG4Y4w1/3QD3zM8OP ECnHNIv2jnLuosWoDyQOUKM2JIf6myZ7wyDTDTIwalxpN8SBBJtB++MmV1ZNkkPUCdgHOA5QqAV4 a0wjKQ9cJUDX7gAotEceJBUwBHgLoGsOQHMAmgPQHICmUoaJ5a/li/3j8jCC/QOZ40rPVGXJAdIA Qt4ve8mJtq+P0ZYY3QE6EfqdMbpd9vbPyEuqioPMdAZYAwjMbXf/rAWlgwYzzWMwuy5odg1Ak1eV KXdjVLsxqt0Y1W6M6gwwo/Vd0O+Cfhf0uwz9LmKjKeeEWFMxZnd/UlpMA6YqXgblYipFE4EYXSIX 95fmHaoKySY0vc/Ae2Qj+B0GbjHwAgNvNaxbDX6twa81+EqDr4zxet1JBh/FeQafpGO5SDbQBPS+ UM41aL30Uz7kBZB1Ol/OMeg8Ocug10CfAX2d9FMK6FxZa8hzIPsgz4as01mytt+XV1LVCbkFNkFJ Utf7MBIfFtOHIOmaHYA9gJOGpgV4K+A4QBqeLH0oNShVsgo1vGjDC4uXpPSiVKJUyApYZmI2M4G9 0oP55gFPAlQCFgBaAEOAtwAW6QF2yDIqAXgB9YAQwIR2ilCvCOMqQg9FspjGoS2n2EapoI4YzRO9 lAs5V/T25+Z5q+LEfqoHhACdgG6xv9+UklSVCj/ddxJgAaAFsBXwOGAfwEqVwLB4E0SlqJQLxAKp ILsnDHg8pQadPDVKr8iJ0sSs0qSq9XICwjSBHgdIDHkChjwBU70g5YETSJ0COgQ4DjgJ0ANegGAU IBgFmGAB6hcYXmbD7wwkDSBpLfBWwOU+emgKMOUC9HWpFV1bCE0h2ixEnUK0V4gwngRmo4Zurwfs ABwC6LaxsO0wcCXwAoBAG2MxA51LAs6TY/tFXFIY8eXpSVXTEPcFABjFdkRzO+K2Xc8QRA+5DUtl zGMH6D6ASQ6iTEApQClEGYviRHGg5KHkYvV2ouxAuQ9lO8o2lF6sRuo+9yG3aClbW7a1bEfZ42X7 yg6VWQ6KVpSQCHnjKS0Ne2JKsjWryi4UaiYb/8XAew283sBeA6d7s5ptnzfbftdse6TZ9rNmW6DZ Nr/ZVttsm9RsC3ObN91t+9ht2+m2LXbbprptZW7bZLdtgttWlcxBXkI2etnA1QYuNfBYA+fwkn4b xb3E15LTiozngv3O2/K+cIYV7s+7wxm2gtwela6Nkhm68sW8EufKvKKoZnyUjHP+q4IWqImfJwu7 vUWWo5YWi9dyteVKS7Gl0FJgcVnyLKnWFKvdOsqaaI23Wq1mq2IVVrKmhrVTXnxOmFLNdp2Y8dli UgzeLnQeCBhfLquguaSOlnWirqGa69ShZVTX5lC/b3CFOX7hUtXkqmY1pY7qGqsz1GnuurBFW6SW u+vUuPprA33M9wUhqeKeMFNjIMyarrozW02pCQwSc9Gd27NjNBjU6wT6FN6+PUhpmyozKlMqkq+u 9f0NFDKUIZ/70pNxiXW79ZHkqA/VNQTUZ3OCaqnOaDnBOsS5wdEcGBTlYqrfNyim6SQYGIzvFuX+ Rbo+vtuHgVzwIwf0vkFy6sTwI4fuR44f+OWKabpfvk6ifrmGX+4Iv76ZTr+vzwkU9Zlp+Mwc6bNy pM9Kw2dlzEca4zeauNCO5RQ5DR+n5ZQx9st9cqN9/V2f/L/pc1k426svE/6K5UGayyf6ajb7213+ kMvfDgipvZs6MtTuNodjkGr4hG5yqHJ8qG1Zh05b28N8wtXuU2tcPkffXKPqSLu6WTfPdfn6aLO/ MdC32dvu65/rnet3tfqCA7NaJ+4d0d29F7rrm9j6152prXpjE/W+Zhn1ftDXXt08S+9rr97XXr2v Wd5ZRl9G1iMtrVQdrGmO0gGREI8EDmU7g9Vp9s4KI5tnODO2ZB9QiJ+mBHdQTXRVqzaAnujFVcVV uglvmW4aBXVSzJSxZYYz+wA/HTPZoU52VVOGf5UPf11dMSYq/kPc1dW14fqu60G6Nhh/XRs2gupr Rl2EkytmUJVofN/ysBvre3MvYJuxR8uuruAGMta3ayPpvW/Q0cVOL3Eb0Th3XZ4JpHc54oGV3RQF NNe1kTEGfRgbo/W4i2FEM6i6IabDnqN8CXiAskFzZRu+2KSdjMFnkS1Re2RY08QHcG6MAYjBNdLP oEPheVFKy+k9WkP308+hm8xv0jPkpSTY3iPJhBO7hx6kn9D71KT9CVonPUFnqIiupg4tQsm0lSJ8 Kz3BQo8UldO71E47hUe6la+xOU7kEvkc307FaKWRHqJ0Oo4WJ2rxkAdEjvCgViO9LlusRVqJ9mce Uo5qbfRL9ogTygv0Bp3msQpF7tB6tV3abhpF38mc4Ve1q7Q1qNVEIdpIt2AE3fQYHeOgmCkOafdi TAGMYSv9ml5nNxIqhBPdInj/Ez1Mg/QyHaff0xfMnMSF3M3v8nsmGj4SOaLN0dq0teSn+VRP3bDm cD5XiaVyqdwrPxj+z8gpLRdtN9ImupFuph20k56jD+hD+piliBeNoknupWyaSUupDdF8EGN6ho7S SbbyFJ7OXr6LnxebFDl8BF94hcYggrPR2nL47kJMn6R9dITeorfR5p8QU8mZWPwmbuZb+U6+j3/K T/Lz/AJ/LUzi91LK25TfKF9HTmjx2qPaM+g3m64gB866RViDa7Cex+grzG8iF3ElvyPcokiykjgc iUzWZmlbtde0D8hFBfCdiXOtn+bREoz6Jty/DtJvUPcYvUn/Rf+LKEmO5xTEwsEuXsQNvBGj2Mtn eFikYf3KxWrRL96TbnlMWaK8MLw/MibSHzkT0bTnNFV7VXvDWN+p6KcGK3AddeIV01fsV+jnNfqc /kBn0YeZ8zDW2VyH+T6M9k/yeaSTVWwRzwsNp9+d8qiSqTwcmR9ZE3k4MqBN0eYhtyQOXZk0BWU6 sqmJgmj7dkTzCXoWKzOA7DlB33AG53IJz+HFHOAQd/Ba7uR1fDPfgqg+w/v5IJ/gj/kboQizGIM4 ucUycbt4UOwXR8QJ8bkk2YA7zDp5s3xQ7pdvyf9W7EqRUqLMU0LKTcpmE45k5jTrG+fTz68Zbht+ dPjVyJURX+RHkd7I4ciJyGdagnZI+4LMVIIxBmklxngr5n8X3UePIz+exRg/pS/pa6z5nxELyXGc hRHnGetWg3HPw8iX4Mi0AqWDb0D8u/k57ueXeIgP81F+nd/hT/iMYIz+SpQZeAuaxArM4VHxnFDF hyhnxf/J8Tj1l8rJuFWEMJu75T2Yz8/lJ/ILRShjlKuUBmWr8luTNC03PWTaZTpi+p3pK7PdfC0y NFqi+4eB5RvisFIhV9Me3A6k/Eq8Izx8qzjH/yJy+DB6y5H1sl7UiBk4Gx1Elq+hVMsus9PsFKlk t4T0RsQjolguUcbLRNqA943EUnGXCNFT/BKdE7ORaZvkMbFHtMhdygNKBX+A+8Vh/BRg4++piqq4 Amv3Lq3DChXLfcqbeosmqzxvWiNs2t3KlyYh38E+OJOF/Ddeyqe5XqQhWjPEfeSCbOfToHPwBn6I zB/EsbNcOSW3ibniY+hW04N8GHM8SKvFQf4l1qUc7+N6rufd8irawusQkavpBvFTGis6xVjkcxP9 D9/OY/DmnsPajBMrSJE2sYzeE0Gs+lucIq7kLcjTNdTLPVTEwzxEb4j7aSq3y5fPZw4XCj5/mvvk bOrjc8pR5SgO3+cQyRxkrpW9yJAnsEc04c10yvHImnIyCdzj8D6F8K4ni7N8i1hNq/hh+Qd+UlTR AmqXXaKWH4qcVarkZETsAHaTGvPVVjJ5TDnKFKz4l1SBbFyJX0g6lJOm23Veviu/04KaM9JiGhX5 hDYjOrOxu/XiXZpNH3EaX88LFU3UKZq2mJ4T+5RPtHROZCe9reENi/yKPTxOc/A6LYEXIsOv1397 UXqVO5WNyi34Pp3DrnkXPUCP0iv4mvwzvlsFiOM1iGYz9p5V+EaU4BeDMsyugqqxK82BrZ4WYz8N YZdcQT+mddh5f0HPUx++UHWIx/Wot4JugL4LX6ibaQve/7tpG/aAh+gpels8Kx7HHfce8ZrYJFbR R/SR/K308mJ6T7lX2UoNuAMv5NHoeRpWKQ/1tmnvorcJlI3dfwreUmS+9rV2Qnt6+Djaewpjf8Bc TV+ba6iQFvD3ShabvFWN3sqKmZ4Z068un1Y2ZXLpVSWTriwuck+cUFgwPn+ca6zTkZebc0V2VmZG etqY1NEpyfakUbbEhPg4q8VsUqRgKvK7akMOdXxIVca7Zs8u1mVXKxStlylCqgOq2pE+qkOv1wrT CE8vPFf8wNMb9fRe9GS7w0Oe4iKH3+VQj/lcjjAvXRgAv93nCjrU0wY/z+B3GrwNvNOJCg5/RofP oXLI4VdrN3X0+EO+4iLuS4ivcdW0xxcXUV98AtgEcGq6q7OP0yvYYES6f3qfIKsNU1SzXD6/mulC VTQj8/2ty9X6hQG/L9vpDBYXqVyzzNWmkn4KdBsuVGN0o5prVIvRjWOVitlQr6OvaKhnW9hObSF3 4nLX8tbmgCpb0YZfTXajX5+avvnzjEsiGsd58+7Lrdmyx5+xyqE79/Tc7VD3LAxcVjfbqbcQDKIN 1BX5taGeWnS9DStVp9+UVHFnMKDynegSZ+Z8Y1bR+UVP9PmhGxxqnKva1dFzQwhLk9Wj0qKbnP1Z Wd5B7RRl+R09jQGXU63MdgVbfVf0pVLPopsGMr2OzJGW4qI+e3I0sH2jkmJMou1yph1Bj9oMznDX ubpFFyPL+hhdc1QvMmqZAyMJuDCnch21l1PPsnIsAJ4go5a6HCuySo2rCfXYp+t6TJFVU77d5eg5 S8gA1+k/jtS0xjTmfPtZ0o16nlxMNZVbL/Cq261OnKiniKUGa4oxVhhyWXHRprBY5eq0O0BwIaJ6 xLY1OH0Swu906gvcG/ZSGwS1e2EgKjuoLbufvJNwbxAh3TJ0wTKmSbd0X7BcrB5yIZP34xBBNEa1 jr/4l2RPG+3vmK5y2t8xt0ftdQ2uuoVLAw5/TyiWtXWNI6SoXQ8o4gZbjFNH1wRktoBO50S2NKxI yualF10gBBJVJR9/ZiOpl4ctVmSloWFHrWoPzY7iYLzTGXtn/lGlsPatXssgl6rFpqFOd8cGGh22 OmOEPGJ4iT2yrhFbjqhrXNrTEz/CVovNrKen1uWo7Qn1tIa17jaXw+7qGcQBZHxPpx/bUHRFw9qB 3my1dlsQU+ng6chbQdV9Lr5nYZ+X72lYGhjELy2OexoD/Tja1ISqg8Fi5RitBNyPRcPFBJjwHxEz gGjtRQ3RNDZBI/Rvm7ISrCQL1faZLWFO3I/t1qTojKR4swnMi1KKrDiLrnuRKdO64OYM93z7d555 w5759u898+zD+LHVM+zR4aqSycnO5HxnsnOlQucdcui810TnyKEMobf7tZOKR3ZTAqXzbG95SpqS lpqeJo/y0YT3xcemf7e8n2D+kWVVsmgX7coq66r4G2yrk9tHr0i3jnHKJGecTIizJDoprA0NJGVW GnRUukG9tjFlKrEdn8cQJhMWd3szUpxmL9zMXvisNR8yHzefMn9rNpnD/NlAxsS9GWH8auS2f38d LpSnh69bh1uk+zRVVtpP209fVUJ1akJDnToOyXuQ0rTvKFX7br89dVRq+gHtMxqtfTZgy03OLY89 QbqO111H65CR3oS0VHt2ZaqOksPa997RSbmVCalA1nggi46g/6M3JyWh0pKakAIjUFpqcnpFqo5G pyal6h5HvClg4uMT7agJJGRSnke/Co98gpxKrrFUNoUml5JlynjXWPOY1LTJpVMVT+T0K0ci33DK kVd4dNOne/Z8qgPvG4p8y8mHhjg58u3hx/7j5C92n8LNGKtjPBEXvuh67vzw0e2LDCXjrhi1m3FD I391df2sJe6atRvXr2pfP7/9J/UN8xrp/wETRNciCmVuZHN0cmVhbQplbmRvYmoKNzQgMCBvYmoK NDczNAplbmRvYmoKNzUgMCBvYmoKKDA0NDIwQnJpZWYyMG9uMjBDeWJlcnNlY3VyaXR5MjBTdHJh dGVneTIwYW5kKQplbmRvYmoKNzYgMCBvYmoKKE1hYyBPUyBYIDEwLjguMiBRdWFydHogUERGQ29u dGV4dCkKZW5kb2JqCjc3IDAgb2JqCihPbGFmIE0uIEtvbGttYW4pCmVuZG9iago3OCAwIG9iagoo TGlicmVPZmZpY2UpCmVuZG9iago3OSAwIG9iagooRDoyMDEzMDEyODEyMjM0MVowMCcwMCcpCmVu ZG9iago4MCAwIG9iagooKQplbmRvYmoKODEgMCBvYmoKWyBdCmVuZG9iagoxIDAgb2JqCjw8IC9U aXRsZSA3NSAwIFIgL0F1dGhvciA3NyAwIFIgL1Byb2R1Y2VyIDc2IDAgUiAvQ3JlYXRvciA3OCAw IFIgL0NyZWF0aW9uRGF0ZQo3OSAwIFIgL01vZERhdGUgNzkgMCBSIC9LZXl3b3JkcyA4MCAwIFIg L0FBUEw6S2V5d29yZHMgODEgMCBSID4+CmVuZG9iagp4cmVmCjAgODIKMDAwMDAwMDAwMCA2NTUz NSBmIAowMDAwMTMzNDgxIDAwMDAwIG4gCjAwMDAwMDE5MzQgMDAwMDAgbiAKMDAwMDAyNTU5NSAw MDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDE5MTQgMDAwMDAgbiAKMDAwMDAwMjAz OCAwMDAwMCBuIAowMDAwMDAzNTIzIDAwMDAwIG4gCjAwMDAwMDYyOTUgMDAwMDAgbiAKMDAwMDA2 MjQ3OSAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwNDIwNzkgMDAwMDAgbiAKMDAw MDAwMDAwMCAwMDAwMCBuIAowMDAwMDkzNDU0IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAK MDAwMDAyODMzMiAwMDAwMCBuIAowMDAwMDAwMDAwIDAwMDAwIG4gCjAwMDAwNTUwNjYgMDAwMDAg biAKMDAwMDAwMjI0NSAwMDAwMCBuIAowMDAwMDAyMjk5IDAwMDAwIG4gCjAwMDAwMDIzNTIgMDAw MDAgbiAKMDAwMDAwMzUwMiAwMDAwMCBuIAowMDAwMDAzNTU5IDAwMDAwIG4gCjAwMDAwMDYyNzQg MDAwMDAgbiAKMDAwMDAxNjQxMCAwMDAwMCBuIAowMDAwMDA2MzMxIDAwMDAwIG4gCjAwMDAwMTYz ODkgMDAwMDAgbiAKMDAwMDAxNjUxNyAwMDAwMCBuIAowMDAwMTA0MDc3IDAwMDAwIG4gCjAwMDAw MjU3NDIgMDAwMDAgbiAKMDAwMDAyNTI5MiAwMDAwMCBuIAowMDAwMDE2NjQ1IDAwMDAwIG4gCjAw MDAwMjUyNzEgMDAwMDAgbiAKMDAwMDAyNTM5OSAwMDAwMCBuIAowMDAwMTI3OTUyIDAwMDAwIG4g CjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAzMDc0MyAwMDAwMCBuIAowMDAwMDI1NjkyIDAwMDAw IG4gCjAwMDAwMjU5MTYgMDAwMDAgbiAKMDAwMDAyNjE2MyAwMDAwMCBuIAowMDAwMDI4MzExIDAw MDAwIG4gCjAwMDAwMjg4MTcgMDAwMDAgbiAKMDAwMDAyODQ5NyAwMDAwMCBuIAowMDAwMDI4Nzk3 IDAwMDAwIG4gCjAwMDAwMjkwNTEgMDAwMDAgbiAKMDAwMDAzMDcyMiAwMDAwMCBuIAowMDAwMDMx NDQ5IDAwMDAwIG4gCjAwMDAwMzA5ODYgMDAwMDAgbiAKMDAwMDAzMTQyOSAwMDAwMCBuIAowMDAw MDMxNjg0IDAwMDAwIG4gCjAwMDAwNDIwNTcgMDAwMDAgbiAKMDAwMDA0Mjk2OCAwMDAwMCBuIAow MDAwMDQyNDAzIDAwMDAwIG4gCjAwMDAwNDI5NDggMDAwMDAgbiAKMDAwMDA0MzIwOCAwMDAwMCBu IAowMDAwMDU1MDQ0IDAwMDAwIG4gCjAwMDAwNTU2MzQgMDAwMDAgbiAKMDAwMDA1NTI2MiAwMDAw MCBuIAowMDAwMDU1NjE0IDAwMDAwIG4gCjAwMDAwNTU4NzQgMDAwMDAgbiAKMDAwMDA2MjQ1OCAw MDAwMCBuIAowMDAwMDYyOTU2IDAwMDAwIG4gCjAwMDAwNjMyMjYgMDAwMDAgbiAKMDAwMDA5MzQz MiAwMDAwMCBuIAowMDAwMDk0MTQ3IDAwMDAwIG4gCjAwMDAwOTM2ODkgMDAwMDAgbiAKMDAwMDA5 NDEyNyAwMDAwMCBuIAowMDAwMDk0MzgyIDAwMDAwIG4gCjAwMDAxMDQwNTYgMDAwMDAgbiAKMDAw MDEwNDU0NSAwMDAwMCBuIAowMDAwMTA0ODIxIDAwMDAwIG4gCjAwMDAxMjc5MzAgMDAwMDAgbiAK MDAwMDEyODEzNCAwMDAwMCBuIAowMDAwMTI4Mzc2IDAwMDAwIG4gCjAwMDAxMzMyMDAgMDAwMDAg biAKMDAwMDEzMzIyMSAwMDAwMCBuIAowMDAwMTMzMjg0IDAwMDAwIG4gCjAwMDAxMzMzMzYgMDAw MDAgbiAKMDAwMDEzMzM3MCAwMDAwMCBuIAowMDAwMTMzNDAwIDAwMDAwIG4gCjAwMDAxMzM0NDIg MDAwMDAgbiAKMDAwMDEzMzQ2MSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDgyIC9Sb290IDM3 IDAgUiAvSW5mbyAxIDAgUiAvSUQgWyA8MDdmM2ExMzVmNjBkOTY4ZmU0N2QyOWMwOGZmYmFmY2M+ CjwwN2YzYTEzNWY2MGQ5NjhmZTQ3ZDI5YzA4ZmZiYWZjYz4gXSA+PgpzdGFydHhyZWYKMTMzNjQw CiUlRU9GCg== --Apple-Mail=_AB0279E2-98E2-4C55-B90F-9BC33E361CD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_AB0279E2-98E2-4C55-B90F-9BC33E361CD3-- --Apple-Mail=_E4B6C245-88C1-483F-8C1E-DC5ED54D9261-- --Apple-Mail=_9890420E-9C0C-45DF-9404-CDA4A1436592 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJRBnIjAAoJEFRqER47aqpkLDwP+wf9jcPh7RO32NDgSmQkA1tn 9rcHpxp1MgT97o6+nuMJV2qVmZbktXYBijpTjR31h0YcO12rJUAMmJhx9HU513Km Kof5xJeqMIQLeN5I4tsvBJQ2IMcIRONrqWOaKZkrkFcW6oHM8Ebll651UmjrK4Pi Mk6yM9DhDfuE8SYkVyfuRXNUP3Ly22YqhVXgZNUvrJnb2RMrcl9DuScgzrnBMciK F+81Pp3tjo8Rzqn7WBhoTbdaonP8WX9ghDoC/HTkdTlNK1wV324yhDbiJodUfInn IbKV50UebZ+zaBb+NscEF9ZtafFS81kG+HKTJ8FbsqPIxd756vodvD6IqXXGj3Kt ST/5sp9UXOkZdCzCFS/nBUW72wqZjGcLriFev1UTFK3H3/geUw2SVnQamlubWHxk 4VepWLdUS+xV9eihlNlUEnWMQl5dsYXuvjAAH56QnSq7Uw4mJIZwbExt5U/AHvv+ YSl2dzexwuhW3WbxN8Jcgkq1EDPkjw7Z1RRnj3DvXQPIcPlbM3XC8rkS8YrD3oLJ 62F3Jdpk4A5EtkLAsb+c2zFQbS8Jt3huvENB3MuELiQCFsuV7pqYAnXw4h8SGk/C 1cJllOXHlew2fz5OfXfhuqDYnXPtcvzqR7Cbuw5IUncV83Vqfi0FCgc0T+Bo5SsN SwfTQ+1xyV+jR2ME/uk/ =/VRs -----END PGP SIGNATURE----- --Apple-Mail=_9890420E-9C0C-45DF-9404-CDA4A1436592-- From hannes.tschofenig@gmx.net Mon Jan 28 05:13:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E7F21F87C3 for ; Mon, 28 Jan 2013 05:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zXYW+wU1gNP for ; Mon, 28 Jan 2013 05:13:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77A21F86FF for ; Mon, 28 Jan 2013 05:13:29 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ljwk3-1UbcBN0k3N-00bvth for ; Mon, 28 Jan 2013 14:13:28 +0100 Received: (qmail invoked by alias); 28 Jan 2013 13:13:27 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.219.140] by mail.gmx.net (mp017) with SMTP; 28 Jan 2013 14:13:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mjO8cAm3mgCTKcIldL9yrsDyHilEu2yN2c/bPFF q8NCeOP3imC1jx Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 28 Jan 2013 15:13:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44FD19C9-D570-4086-BA03-62BAF7AC632F@gmx.net> References: To: Olaf Kolkman X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig , IAB IAB , secdir@ietf.org Subject: Re: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:13:30 -0000 The challenge with CyberSecurity (or Internet Security as I call it) is = the unclear scope. Depending on your scope pretty much every security = specification in the IETF is relevant.=20 Of course there are other factors that matter for security that are = outside the scope of the IETF. For example, the best security protocol = will not help when the software implementation is buggy.=20 As an example, you could call RFC 3552 a document that provides = "security-by-design guidelines". You could also call the documents from = the Messaging Abuse Reporting Format (marf) working group "standards = related to information exchange".=20 Ciao Hannes On Jan 28, 2013, at 2:42 PM, Olaf Kolkman wrote: >=20 > Folk, >=20 > This mail is FYI, it may be of business/personal interest to some of = you.=20 > I have a specific question. >=20 > Context: MSP for ICT St. >=20 > You may or may not be aware that the EU has a Multi Stakeholder = Platform for ICT standardization. One of the stakeholders at the table = is the IETF/IAB and your truly is, with Hannes Tschofenig as backup, the = representative for the IETF/IAB. >=20 > The platform is chartered to give the Commission advise on all matters = standard and to identify standards, developed by fora and consortia, = that can be used in public procurement (formally RFCs can not be = reference in EU procurement: when these folk talk about standards they = think ISO, ITU, ETSI etc etc.) >=20 >=20 > Specific: EU Cyber Sec Strat. >=20 > What is attached is part on the advise on all matters standard aspect. = The document gives a short executive level overview of what the EU = intends with its cyber security strategy. The document is FYI mainly. >=20 > However I have one particular bit of information that I need. See the = section on "Where do standards come in". I do not think there is any = relevant IETF work in this area (info exchange and such) and would like = to get guidance if that is a misunderstanding. >=20 >=20 > The platform is having its 3rd meeting 7 Feb. >=20 >=20 > <04420Brief20on20Cybersecurity20Strategy20and.pdf> >=20 >=20 > NLnet > Labs > Olaf M. Kolkman >=20 > www.NLnetLabs.nl > olaf@NLnetLabs.nl >=20 > Science Park 400, 1098 XH Amsterdam, The Netherlands >=20 >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From olaf@NLnetLabs.nl Mon Jan 28 05:42:24 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAC721F8446; Mon, 28 Jan 2013 05:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-E47Z+YNEsn; Mon, 28 Jan 2013 05:42:23 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F4D21F8444; Mon, 28 Jan 2013 05:42:22 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id r0SDgDIu035433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 14:42:14 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl r0SDgDIu035433 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1359380535; bh=LHgJ4gZ7ycQcIXZPAg80lNDxLiX6t3f48nKKtDk2FSA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=j0uNxcJ5TKPn3sA9VgzAQgYtOYSVCKVkA/wGsSnqdOkoOnFyJ6+mTTwc/gCxyQry5 XRdGC8G8iaHfF4U/9lgeXhJcmKum5koT5AMTtXPTgWvKT7l9OJjtfaWD9H5ndPFYY+ q+ipDS+ZrIgwOT3/l7IeF6nzEHAIqpVjUOAZ0iqU= Content-Type: multipart/alternative; boundary="Apple-Mail=_E45C2ECD-5468-411E-8ECC-1677D8AFD645" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Olaf Kolkman In-Reply-To: <44FD19C9-D570-4086-BA03-62BAF7AC632F@gmx.net> Date: Mon, 28 Jan 2013 14:42:19 +0100 Message-Id: <1A76671C-FD64-47DD-8821-BC34060128CF@NLnetLabs.nl> References: <44FD19C9-D570-4086-BA03-62BAF7AC632F@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Mon, 28 Jan 2013 14:42:15 +0100 (CET) Cc: IAB IAB , Hannes Tschofenig , secdir@ietf.org Subject: Re: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:42:24 -0000 --Apple-Mail=_E45C2ECD-5468-411E-8ECC-1677D8AFD645 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 28, 2013, at 2:13 PM, Hannes Tschofenig = wrote: > As an example, you could call RFC 3552 a document that provides = "security-by-design guidelines". You could also call the documents from = the Messaging Abuse Reporting Format (marf) working group "standards = related to information exchange".=20 Thanks... exactly the type of info I was looking for. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_E45C2ECD-5468-411E-8ECC-1677D8AFD645 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hannes.tschofenig@gmx.net>= ; wrote:
 


Thanks... exactly the type of info I was = looking for.

--Olaf


Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_E45C2ECD-5468-411E-8ECC-1677D8AFD645-- From vincent.roca@inria.fr Mon Jan 28 05:57:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC6921F8507; Mon, 28 Jan 2013 05:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHKFZ+-xNqN7; Mon, 28 Jan 2013 05:57:24 -0800 (PST) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 40ACC21F8464; Mon, 28 Jan 2013 05:57:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,551,1355094000"; d="scan'208";a="191646072" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 28 Jan 2013 14:57:10 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <5103D12D.8060906@gmail.com> Date: Mon, 28 Jan 2013 14:57:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <71CC8695-F92F-43ED-A9C3-6B5C02195172@inria.fr> References: <939DADEE-28DB-4A4B-AD0D-057AEB863250@inria.fr> <50FF9D1C.9070501@cisco.com> <5103D12D.8060906@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1085) Cc: Benoit Claise , IESG IESG , draft-ietf-dime-erp.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-dime-erp-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:57:25 -0000 Hi Glen and others, > I responded to Vincent's original review some time ago (see below); I = am interested in hearing my co-authors' opinion. Oups, I've just found it. Sorry. So let me answer. [...] >>> One more point. In introduction, the authors say: >>> " Security considerations for this key distribution are detailed in = Salowey, et al. [RFC5295]." >>> This reference is not mentioned in the Security Section! I don't think you've answered here. [...] >>>> The security section of this document is pretty simple as it refers = to >>>> the security section of 4 related documents and that's all. On the >>>> opposite, each of these 4 documents includes a very detailed = security >>>> analysis. The contrast is extremely important! >>>=20 >>> Why? >>>=20 >>>>=20 >>>> This is all the more annoying as draft-ietf-dime-erp-14 introduces = new >>>> mechanisms, and thereby new potential threats and issues (it's = usually >>>> the case). >>>=20 >>> =46rom a Diameter POV, a Diameter ERP "server" is actually just a = form of Diameter agent and the Diameter ERP client is just a standard = Diameter client; a new application is only required to ensure the = correct routing of Diameter messages. So I'm not sure what the new = mechanisms you refer to are; perhaps you can elucidate? I'm not an expert and didn't hear about ERP before this. I must admit I have no clue on how all these things work, and I cannot judge whether there are security issues or not. But when I read the abstract, I understand that a certain number of things are introduced:=20 - extensions to EAP,=20 - a new Diameter ERP application, - a set of new AVPs. This is what I mean by "new mechanisms".=20 If you say that it's more a specialization of existing components (if I = understand correctly) than new mechanisms, then I believe you. >>>> What should I understand? Is the proposal guaranteed to be secure? >>>=20 >>> There are no guarantees in life, let alone security . >>>=20 >>>> Or have all the potential weaknesses been already addressed in the >>>> 4 related documents? >>>=20 >>> It would seem that that is the very strong implication. >>>=20 >>>> I can not conclude after reading this security section >>>> and this is a problem. >>>=20 >>> It seems as if the big problem is that the draft doesn't tell you = what to think about the security properties of the protocol but I don't = think that is really a problem with the document. As I mentioned above, = it appears to me that the authors believe that security-related issues = are dealt with in the Security Considerations sections of RFCs 4072, = 6696, 6733 and 6734. Is that the case? If not, please point out a = security problem with this protocol that is not covered by those texts. You got my point.=20 You introduce new things (I called them mechanisms, but it's perhaps=20 inappropriate) without telling me **explicitly** whether or not you = believe they introduce new risks. And it's not obvious to me whether the = security sections of these 4 RFCs also encompass the new things introduced here. If you add a sentence saying that the authors believe that all security = aspects are already dealt with the above 4 RFCs, plus another sentence = explaining why you believe so, then I'll be happy. That's the kind of things to discuss = in a security section. Does it make sense? In any case, I don't want to annoy anybody. I'm just = trying to provide a complementary view. Cheers, Vincent From stephen.farrell@cs.tcd.ie Mon Jan 28 13:02:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E68E21F8763 for ; Mon, 28 Jan 2013 13:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+V4-R7MP7Wi for ; Mon, 28 Jan 2013 13:02:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EDD6E21F86E4 for ; Mon, 28 Jan 2013 13:02:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BE1A2BE62; Mon, 28 Jan 2013 21:02:29 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmnXMtUb11Pb; Mon, 28 Jan 2013 21:02:27 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.73.174]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 496B1BE35; Mon, 28 Jan 2013 21:02:27 +0000 (GMT) Message-ID: <5106E763.6020306@cs.tcd.ie> Date: Mon, 28 Jan 2013 21:02:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Olaf Kolkman References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IAB IAB , Hannes Tschofenig , secdir@ietf.org Subject: Re: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 21:02:55 -0000 Hi Olaf, I think Hannes' answer was right, and there are more security related BCPs (e.g. BCP107). Would it help to make a list or can you just say there's a bunch of those and here're some examples? If the former we can get you a longer list I guess;-) And I've a question back to you: might it be useful to have some kind of engagement between the IETF security area and ENISA and would that be something to bring up in this context? If a very light form of that was useful we'd be happy to invite some ENISA person(s) to come to a secdir lunch or give a talk at a saag session whenever. (Note: I don't mean from some known IETFer who's done stuff with ENISA but rather someone from ENISA who's not been to an IETF but might usefully inhale our fumes;-) S. On 01/28/2013 12:42 PM, Olaf Kolkman wrote: > > Folk, > > This mail is FYI, it may be of business/personal interest to some of you. > I have a specific question. > > Context: MSP for ICT St. > > You may or may not be aware that the EU has a Multi Stakeholder Platform for ICT > standardization. One of the stakeholders at the table is the IETF/IAB and your > truly is, with Hannes Tschofenig as backup, the representative for the IETF/IAB. > > The platform is chartered to give the Commission advise on all matters standard > and to identify standards, developed by fora and consortia, that can be used in > public procurement (formally RFCs can not be reference in EU procurement: when > these folk talk about standards they think ISO, ITU, ETSI etc etc.) > > > Specific: EU Cyber Sec Strat. > > What is attached is part on the advise on all matters standard aspect. The > document gives a short executive level overview of what the EU intends with its > cyber security strategy. The document is FYI mainly. > > However I have one particular bit of information that I need. See the section on > "Where do standards come in". I do not think there is any relevant IETF work in > this area (info exchange and such) and would like to get guidance if that is a > misunderstanding. > > > The platform is having its 3rd meeting 7 Feb. > > > > > > > *NLnet > *Labs > > Olaf M. Kolkman > > > www.NLnetLabs.nl > olaf@NLnetLabs.nl > > > Science Park 400, 1098 XH Amsterdam, The Netherlands > > > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > From Jeff.Hodges@KingsMountain.com Mon Jan 28 14:55:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4F21E8040 for ; Mon, 28 Jan 2013 14:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmHtufSHpnio for ; Mon, 28 Jan 2013 14:55:42 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id D02DE21E8030 for ; Mon, 28 Jan 2013 14:55:42 -0800 (PST) Received: (qmail 22376 invoked by uid 0); 28 Jan 2013 22:55:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy11.bluehost.com with SMTP; 28 Jan 2013 22:55:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=KLWohKHxodUw9UvGXIoN09RVJJX+SNKZVoM8bIN7u0w=; b=tnfiBswo+skm/o3Uff6Bg8dpsKiNBzDrpF/uz2ksWGf50fhlRnA4IlcPDtCcvwS6ZFJFxPd1qnbFKFyC+EdZA5gwWfNwO81yTHjhLNEkqyJjcwZN4HNQVdB+aUsU0ew9; Received: from [70.199.81.220] (port=63696 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TzxbX-000739-VA; Mon, 28 Jan 2013 15:55:08 -0700 Message-ID: <510701C9.50305@KingsMountain.com> Date: Mon, 28 Jan 2013 14:55:05 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeffrey Hutzelman , "therightkey@ietf.org" , The IESG , secdir@ietf.org, draft-laurie-pki-sunlight.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.199.81.220 authed with jeff.hodges+kingsmountain.com} X-Mailman-Approved-At: Mon, 28 Jan 2013 14:57:23 -0800 Subject: Re: [secdir] [therightkey] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 22:55:44 -0000 benl replied: > jhutz noted >> I'm concerned that this document attempts to specify operational policy, >> particularly for operators of logs. As the saying goes, "MUST is for >> implementors"; statements like "Anyone can submit a certificate to any >> log" are inappropriate for protocol specifications. > > This is not a MUST, however - in any case, we've changed this language > in the next version. AFAIK, draft-laurie-pki-sunlight isn't strictly a "protocol spec" in that it's documenting protocols, algorithms, and operational aspects of a (grand :) experiment. (and not all RFCs are protocol specs...) HTH, =JeffH From olaf@NLnetLabs.nl Tue Jan 29 01:37:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62A421F85BC; Tue, 29 Jan 2013 01:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiSVNWptJNkW; Tue, 29 Jan 2013 01:37:06 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 172EE21F84DC; Tue, 29 Jan 2013 01:37:05 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id r0T9ZVHw030171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jan 2013 10:35:32 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Filter: OpenDKIM Filter v2.7.3 open.nlnetlabs.nl r0T9ZVHw030171 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1359452136; bh=GnvgStwm0c0OApQ6UYi+VrhoQ4jNbA1FntpUt+PzhZ0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=v0I0YvkDYLEiaU5XdOpb18SatbE9x44aGp/S5WqLpXmwNA5Ij5vF4SwJF64uUpt0H 4asTPVSGhUoV5fW9iqHY3azcdAcwbtYzcLscBzZlAXbHFpULNECmV+S760FIeTj+Rj 2w6WBl/iolK0rImSXbe1WXt8X4sxkGUXpRNwYC9I= Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F1AA8A0-3CEB-4737-BE84-241146AAFE82" From: Olaf Kolkman In-Reply-To: <5106E763.6020306@cs.tcd.ie> Date: Tue, 29 Jan 2013 10:35:36 +0100 Message-Id: <2468E427-C103-42DF-B72B-FA72B12FEA95@NLnetLabs.nl> References: <5106E763.6020306@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1499) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Tue, 29 Jan 2013 10:35:36 +0100 (CET) Cc: IAB IAB , Hannes Tschofenig , secdir@ietf.org Subject: Re: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:37:07 -0000 --Apple-Mail=_4F1AA8A0-3CEB-4737-BE84-241146AAFE82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Jan 28, 2013, at 10:02 PM, Stephen Farrell = wrote: >=20 > Hi Olaf, >=20 > I think Hannes' answer was right, and there are more security > related BCPs (e.g. BCP107). Would it help to make a list or > can you just say there's a bunch of those and here're some > examples? If the former we can get you a longer list I guess;-) I am not quite sure what the dynamics in the MSP will be on topics like = this and given that the agenda for the Feb 7 meeting is challengingly = long I am afraid not much detail will be discussed. Anyhow, the answer = from you and Hannes are useful bagage to have in the back pocket. > And I've a question back to you: might it be useful to have > some kind of engagement between the IETF security area and > ENISA and would that be something to bring up in this context? >=20 > If a very light form of that was useful we'd be happy to > invite some ENISA person(s) to come to a secdir lunch or give > a talk at a saag session whenever. (Note: I don't mean from > some known IETFer who's done stuff with ENISA but rather > someone from ENISA who's not been to an IETF but might > usefully inhale our fumes;-) Yes, I think so. But the MSP is not affiliated with ENISA, Enisa is clearly a different = channel.=20 That said, with the IETF being in Berlin in summer we have just = sufficient time to try and organize something. I think that it is useful = to try and engage in conversation if you have a clear goal in mind of = what you want to achieve. For me: Establishing informal contacts and informing about the going ons = in the IETF is a reasonable idea. As for making that go: We have at least one channel into ENISA, but that = is at a rather high level that I wouldn't like to use unless there is a = solid a plan and some draft agenda (My co-worker knows one of the guys = in the management boards). A brain-fart along the same lines; maybe we could do something = 'regional' by inviting members of the MultiStakeHolder platform for a = one day tour. With as sole goal to expose them to the IETF and possibly = introduce them to some key leadership figures. The impact of such could = be a lot of goodwill, although they might also walk away in suprise :-). = It would be a way to get a lot of key Standardization people, especially = from all countries, exposed to the IETF. Maybe organizing for Berlin is = a bit of a challenge (If we were to do it there I think we should gauge = interest during the 7 Feb meeting, and I don't think we have a solid = idea by then). But London next year? Perhaps linked to an IAB plenary = (deadly boring, but probably of relevance). The last paragraph was me thinking out loud, not thinking things = through. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_4F1AA8A0-3CEB-4737-BE84-241146AAFE82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 stephen.farrell@cs.tcd.ie>= ; wrote:

Hi Olaf,

I think Hannes' answer was right, and = there are more security
related BCPs (e.g. BCP107). Would it help to = make a list or
can you just say there's a bunch of those and here're = some
examples? If the former we can get you a longer list I = guess;-)

I am not quite sure what = the dynamics in the MSP will be on topics like this and given that the = agenda for the Feb 7 meeting is challengingly long I am afraid not much = detail will be discussed. Anyhow, the answer from you and Hannes are = useful bagage to have in the back = pocket.


And = I've a question back to you: might it be useful to have
some kind of = engagement between the IETF security area and
ENISA and would that be = something to bring up in this context?

If a very light form of = that was useful we'd be happy to
invite some ENISA person(s) to come = to a secdir lunch or give
a talk at a saag session whenever. (Note: I = don't mean from
some known IETFer who's done stuff with ENISA but = rather
someone from ENISA who's not been to an IETF but = might
usefully inhale our = fumes;-)


Yes, I = think so.

But the MSP is not affiliated with ENISA, = Enisa is clearly a different = channel. 

That said, with the IETF being = in Berlin in summer we have just sufficient time to try and organize = something. I think that it is useful to try and engage in conversation = if you have a clear goal in mind of what you want to = achieve.

For me: Establishing informal contacts = and informing about the going ons in the IETF is a reasonable = idea.

As for making that go: We have at least = one channel into ENISA, but that is at a rather high level that I = wouldn't like to use unless there is a solid a plan and some draft = agenda (My co-worker knows one of the guys in the management = boards).

A brain-fart along the same lines; = maybe we could do something 'regional' by inviting members of the = MultiStakeHolder platform for a one day tour. With as sole goal to = expose them to the IETF and possibly introduce them to some key = leadership figures. The impact of such could be a lot of goodwill, = although they might also walk away in suprise :-). It would be a way to = get a lot of key Standardization people, especially from all countries, = exposed to the IETF. Maybe organizing for Berlin is a bit of a challenge = (If we were to do it there I think we should gauge interest during the 7 = Feb meeting, and I don't think we have a solid idea by then). But London = next year? Perhaps linked to an IAB plenary (deadly boring, but probably = of relevance).

The last paragraph was me = thinking out loud, not thinking things = through.


--Olaf





Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_4F1AA8A0-3CEB-4737-BE84-241146AAFE82-- From benl@google.com Tue Jan 29 03:35:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9972F21F85D9 for ; Tue, 29 Jan 2013 03:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laY5izqsznf1 for ; Tue, 29 Jan 2013 03:35:38 -0800 (PST) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by ietfa.amsl.com (Postfix) with ESMTP id DBADB21F8487 for ; Tue, 29 Jan 2013 03:35:37 -0800 (PST) Received: by mail-bk0-f53.google.com with SMTP id j10so188850bkw.26 for ; Tue, 29 Jan 2013 03:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GoutLKhBj4ZW6z95Y1Pf684KniIeJ6+Nr+c0G8K/+Zg=; b=nfu3gbZGyY2j+EnxDY3J5IYjD8mzSmpqtEPjFLiTWkFe35ii0TkVKru+YkDfGCexPJ nhtq5baQ1f0S6JFvND+49U78nBujhKDPLzQUtgYC9ZHxU+aeFCeFVyvsr0f/TjkVNjkf 9tIF8wMGAtuLpW82UBEQ6PkLl0p+GDTCnu19hfAUUgwIN4QrsGLtMw2UuZDVOpLA6dix neVQ6T85embwGr8aeBG4xWAJK50jQhoakQrp5ZQvmit0l9o38rttXZNEHc7OyVGi6Yf/ fEOeOdBx61ihXCKwOWKo1JDPI0kR3jr/zxFh8E0rExym17pUo+2ZScl3l+1So+1sMzSt jsGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=GoutLKhBj4ZW6z95Y1Pf684KniIeJ6+Nr+c0G8K/+Zg=; b=SIMVGBRcNCa8rCtxq8WFz+nSvKU6m8uJbx0Se3ZDoYnOAJZfhGjnWJJnNJr5Av2NZM jp599gz6lwV06JDeia0Q9rREF57qHNo9mI591EopEYlC17djX4tB2Y2GsIvc99kpw0es xo+AplSkPHeuwh/20Vqr4Xvc2ZrjGjxN2Eq1/jkifkRE3kyCkROZwZ/Su1z6ROETa/p0 jX3VXtg6OTeqvDF5NPi3d+fSMdf7Qkpu+CVpnxpEt5128JlTDxxrnLTuK+n+wF82JX+e usOtByeMb8ai0vvXFG9PidTtCqAs07Bo0WkONHsWxGlYiTN7n/ZXhDu88uMWhgAyjVUf P5EA== MIME-Version: 1.0 X-Received: by 10.204.150.205 with SMTP id z13mr251689bkv.16.1359459336847; Tue, 29 Jan 2013 03:35:36 -0800 (PST) Received: by 10.204.38.198 with HTTP; Tue, 29 Jan 2013 03:35:36 -0800 (PST) In-Reply-To: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> Date: Tue, 29 Jan 2013 11:35:36 +0000 Message-ID: From: Ben Laurie To: Jeffrey Hutzelman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlhGnJxcyNhPf2b6v7Pj2tEZobSj8rS3cozAOishkyzaR7NfgfPcBqI1TzcXip251PN3ZO+ZoK9AIDJiQXoZAJFDzcD0N7hMYjCwngwcUotMF2w+wyO9q9p2RFezCsZwa86SrwhoT0qDD2u0vrlUZ1ASuXw9eYLc7thV+x8mERzgpJGnJnjTDaVu07SPRj046AdNw4j Cc: The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 11:35:38 -0000 On 24 January 2013 19:06, Jeffrey Hutzelman wrote: > Similarly, as an anti-spam measure, this document proposes that logs accept > only certificates which chain back to a known CA, and requires that logs > validate each submitted certificate before appending it to the log. This > sounds good, but it's not the only possible mechanism, and so I think MUST > is too strong here. Additionally, there is no discussion of the security > implications if a client depends on a log to do this and the log does not > actually do so. Rather than requiring that logs validate every submitted > certificate, the document should only RECOMMEND that they do so, and make > clear that clients MUST NOT depend on such validation having been done. On second thoughts, whilst that is an effective anti-spam measure, it is also part of the functionality of CT: i.e. to identify misissue and give some means to do something about it. The CA check ensures we have someone to blame for misissue. I am not averse to suggestions that achieve the overall aim, but I don't see the virtue of leaving it vague in the description of the experiment we are actually running. From kivinen@iki.fi Tue Jan 29 06:44:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5221F8901; Tue, 29 Jan 2013 06:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0CX44264qMT; Tue, 29 Jan 2013 06:44:10 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0426921F88A9; Tue, 29 Jan 2013 06:44:09 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0TEi0pk019331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2013 16:44:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0TEhwq9022160; Tue, 29 Jan 2013 16:43:58 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20743.57390.456600.844778@fireball.kivinen.iki.fi> Date: Tue, 29 Jan 2013 16:43:58 +0200 From: Tero Kivinen To: Michael Tuexen In-Reply-To: <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 40 min X-Total-Time: 40 min Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:44:11 -0000 Michael Tuexen writes: > > The document should note that firewalls needs to be updated to > > specifically inspect / filter also UDP encapsulated SCTP if they do > > normal SCTP inspection / filtering. > > I agree. What about adding the following to the Security Considerations: > Firewalls inspecting SCTP packets must also be aware of the encapsulation > and apply corresponding rules to the encapsulated packets. That is good enough. > > It is not clear for me how the initiator host finds the port where to > > connect, when it is doing initial connection. I.e. if a host A wants > > to connect to host B, which port it should use if it needs to use UDP > > encapsulated SCTP? Is it assumed that 9899 will be used always? What > > about connecting to the hosts which are behind NAT, i.e. if host B is > > behind NAT, how does host A find the port number to use (which host B > > hopefully somehow already configred to the NAT to be passed to him)? > > The method for finding the remote port number for the initial packets > is not in the scope of this document. This is something you would do > outside of the SCTP stack. The described API provides the required > interface for the application to set the remote encapsulation > port. It might be good to say that in the document, i.e. that it is out of scope of this document. > > Also what if host A and B already have one SCTP connection, and now > > host B wants to create another, do host B reuse the same UDP > > destination port number for host A that was used for the already > > existing SCTP connection between them? The section 4.1 says that UDP > > port numbers are stored per destination address per SCTP association, > > so that would indicate no. > > As stated in the document, each stack uses a single port number > as the destination address of all incoming packets. The document also says: Using a single UDP encapsulation port number per host is not possible if the SCTP stack is implemented as part of an application. which indicates that using multiple UDP port numbers is also an option. Or is implementing SCTP stack as appliction out of scope too? Section 3.1 seems to indicate that it is not out of scope. >From the section 3.1 and 4.1 it is not really clear what needs to be supported. If I have understood correctly that if SCTP is implemented in kernel then we use one UDP port for the whole host, but if SCTP is implemented by the application then each application might have different UDP port, i.e. there will be multiple UDP SCTP encapsulation ports in the host. I.e. if host A is connected to two different applications on host B. Host B is such host that it does not support SCTP on kernel, the SCTP is implemented on the application itself, and that means each application has separate UDP encapsulation port. Now what you said before I assume that it is outside the scope of this document for host A know how to connect to host B, i.e. how to get the UDP port numbers where to connect, and also whether to use the UDP encapsulation at all? Is there any work ongoing on this? I.e. how is this going to be solved in practice? Or is it assumed that the SCTP applications which do not have direct access to IP-layer, which need to use UDP encapsulation because of that, are always only initiators, i.e. nobody ever connects to them, they always initiate the connection to the known services? > > The draft seems to be doing dynamic port number updating based on > > finding SCTP association (which includes checking the very weak > > verification tag). The current section 4.4 only mentions that port > > number is updated. > > Correct. > > In some cases also the IP-address might change, > > i.e. if the NAT box is rebooted or its connection table is cleared, > > and the NAT box have multiple IP-addresses, it is completly possible > > that the NAT mapping changes so that IP-address and UDP port number > > both change. I am not familiar enough with SCTP to know whether this > > causes problem with SCTP, i.e. whether it is default SCTP rules to use > > the last seen IP-address when sending reply or what. > > The method described in the document does NOT cover changing the > address. If you want to handle that, you need to use the address > reconfiguration extension (RFC 5061). Then you need to say that in the draft. Note, that hosts A and B do not have any way of knowing when the IP-address changes, or whether it is going to change. For normal TCP (and most likely also SCTP) this IP-address change will usually result the connection to be reset, as the NAT box does not have the mapping for the connection anymore, but for UDP that does not happen. The NAT box will just create new mapping. I.e. the situation is as follows. Host A is behind NAT, and talks to host B using UDP encapsulated SCTP. Now the NAT box is rebooted, and it looses state. When Host A sends next UDP encapsulated SCTP packet to Host B that UDP packet might get new source IP address by the NAT box. What should happen at that point? Should the SCTP implementation notice that IP-address of the association has changed, and send some kind of reset or what? Or does the SCTP implementation just drop all packets because they do not match association and then connection is dropped after timeout? How do you plan to use RFC 5061 to solve that situation? I do not know enough of RFC 5061 to say how it can be used to solve this kind of situation, where the peer A whose IP-address was changed does not even know that his IP-address was changed. > > The section 3.2 do say that if multiple addresses are used, then > > RFC5061 (SCTP Dynamic Address Reconfiguration) with RFC4895 > > (Authentication Chunks for SCTP) MUST be used. With dynamic update for > > the UDP port number, the similar hijacking attack described in the > > RFC5061 security considerations section is applicable here too. The > > RFC5061 requires (without using RFC2119 language) using of > > authentication chunks to prevent that attack, so should we require > > authentication chunks here too to prevent same attacks even when using > > only one IP-address, as we do update the UDP ports based on the > > received packets? Also perhaps the requirement of using authentication > > I don't think so. The reasoning is the SCTP/UDP/IP does not need > to be more secure than SCTP/IP. SCTP/IP is protected against blind > attackers by the V-tag mechanism. The same applies to SCTP/UDP/IP. > This is described in the second paragraph of the Security Considerations. > > The situation is different from changing the IP address. > Assume that there is an association between endpoints A and B. > If A owns IP.A while establishing the association, then looses > it and a node C gets it, B sends packets to C. So C could take > over the association. And that same thing can happen with UDP encapsulation when NAT box is rebooted. I.e host A owns IP.NAT.port-X, and then nat box is rebooted and that port-X is given to host C, now packets sent by host B to IP.NAT.port-X end up to host C who will be able to take over the association. Of course as the NAT mappings are usually remote IP + remote port + protocol + NAT IP + NAT port, this means that changes for host C to get exactly same 5-tuple are small... On the other hand host C can most likely know remote IP and remote port as they are well known based on the service. The NAT IP is most likely going to be same all the time, so only thing host C needs to be doing is to cause NAT to loose state (i.e. cause it to either reboot, or run out of mappings), and then start filling up the NAT mappings until it gets the NAT port host A used earlier. One way to cause NAT to loose state, is to start flooding NAT with new UDP packets each destinationed to remote host + port and having UDP different source port. NAT will allocate new NAT port for each of them until it runs out of port numbers, in which case it starts reusing port numbers. Now depending on the NAT implementation, flood guarding, SCTP heartbeat intervals etc NAT might reuse the host A's port in which case host C managed to get the session. > > chunks should be also mentioned in the security considerations > > section, as it is very important for the security point of view of the > > protocol. > > > > The section 4.1 "Architectural Considerations" says correctly that > > implementations needs to store remote UDP port per destination address > > for each SCTP association, i.e. different SCTP associations can have > > different port numbers for same destination address. This is required, > > because there might be multiple SCTP clients behind the same NAT box > > (having same IP-address), just using different ports. Unfortunately, > > And there might be multiple peer addresses and the port might be > different. It is even possible that some peer addresses need encapsulation > and some don't. > > > section 4.3 "Encapsulation Procedure" does not have the "for each SCTP > > association" part, so it would be better to clarify this also in 4.3 > > that the UDP port number is per destination address per SCTP > > association. > > What about: > When inserting the UDP header, the source port MUST be the local UDP > encapsulation port number of the SCTP stack, > the destination port MUST be the remote UDP encapsulation port number > stored for the association and the destination address to which the > packet is sent (see ). That seems to be ok. > > The current draft also does not comment anything about NAT keepalives. > > For example the RFC3948 (UDP encapsulation for IPsec) does specify > > special NAT keepalive packets which are sent by the host behind the > > NAT to keep the NAT mapping alive, as quite often NAT boxes remove > > mappings after certain time. If the NAT mapping disappears, then > > packets might not pass NAT box anymore depending on the direction of > > packets and type of NAT box (see RFC2663 for different types of NATs). > SCTP sends on each idle path HEARTBEAT messages which would keep the > NAT state alive. Which ways those HEARTBEAT messages are sent? For NAT mappings to stay alive, the messages quite often needs to be coming from inside of the NAT, i.e. from the host which is behind the NAT, and if both ends are behind NAT, they need to be coming from both ends. Do HEARTBEATs cover that possibility. Also some NAT boxes are known to require as small keepalive intervals as 20 seconds... How often do you send HEARTBEATS? For example RFC3948 section 4 recommends that default value for keepalive interval is 20 seconds for UDP Encapsulation of ESP connections. > What about adding the following to section 3.2: > > SCTP sends periodically HEARTBEAT chunks on all idle paths. These can > be used to keep the NAT state alive. That is ok, provided HEARTBEATS are able to solve this issue. > > The current draft does not seem to answer any of the UNSAF (IAB > > Considerations for UNilateral Self-Address Fixing (UNSAF) Across > > Network Address Translation, RFC3424) questions. > > That is correct. However, the document describes how you encapsulate > SCTP in UDP, not how you build a complete NAT traversal solution > where both ends might be behind NATs. So finding the remote > encapsulation port is not within the scope of the document. So is having both ends behind NAT out of scope? This should then be mentioned in section 3.2. Note, that similar problems also arise when you need to connect to host which is behind NAT, i.e. even if it is only one host behind NAT, but if the connection is coming from the outside, you have similar problems than what you have when both ends are behind NAT. So if the scope only covers the case where the SCTP initiator is behind NAT, then that needs to be mentioned in this document. Also RFC3424 do also cover other cases than just those where both ends are behind NAT... -- kivinen@iki.fi From Quittek@neclab.eu Tue Jan 29 08:41:37 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF0A21F8933; Tue, 29 Jan 2013 08:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p46vBa+1xMcQ; Tue, 29 Jan 2013 08:41:36 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4D21F892C; Tue, 29 Jan 2013 08:41:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 18AAC102F82; Tue, 29 Jan 2013 17:41:36 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9RtOQRBM74Z; Tue, 29 Jan 2013 17:41:35 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id B68C8102F85; Tue, 29 Jan 2013 17:41:15 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.175]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 29 Jan 2013 17:40:46 +0100 From: Juergen Quittek To: =?iso-8859-1?Q?Magnus_Nystr=F6m?= , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-eman-requirements@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-eman-requirements-10 Thread-Index: AQHN94ylUZYZCHg9G0an9myQqW0GSphgjuWA Date: Tue, 29 Jan 2013 16:40:46 +0000 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7EF3404CFCEA7646B6625E72193B08C6@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [secdir] Secdir review of draft-ietf-eman-requirements-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 16:41:37 -0000 Hi Magnus, Many thanks for the review. As you suggested, I extended the paragraph in the Security Considerations section: OLD Monitoring energy-related quantities of an entity addressed in Sections 5 - 8 can be used to derive more information than just the received and provided energy, so monitored data requires privacy protection. Monitored data may be used as input to control, accounting, and other actions, so integrity of transmitted information and authentication of the origin may be needed. NEW Monitoring energy-related quantities of an entity addressed in Sections 5 - 8 can be used to derive more information than just the received and provided energy, so monitored data requires protection. This protection includes authentication and authorization of entities requesting access to monitored data as well as privacy protection during transmission of monitored data. Monitored data may be used as input to control, accounting, and other actions, so integrity of transmitted information and authentication of the origin may be needed. Does this look OK for you? Thanks, Juergen On 21.01.13 05:05, "Magnus Nystr=F6m" wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >This standards-track document describes requirements on standards for >managing power entities over networks. > As stated in the Security Considerations section, controlling power >state and power supply of networked energy entities are highly sensitive >actions and thus authorization, privacy etc. may be required. Similarly, >the date provided by those entities will often require integrity and >sometimes authenticity. The document may gain by also making clear the >potential need for the energy entities to identify, authenticate and >authorize the entities requesting access to power data. I would suggest >to add some text around this - because I assume some requirements on >standards will be present for that. > > From magnusn@gmail.com Tue Jan 29 10:26:58 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF84A21F8ADB; Tue, 29 Jan 2013 10:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+-JOdXomm22; Tue, 29 Jan 2013 10:26:57 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id E7B0421F8ACA; Tue, 29 Jan 2013 10:26:56 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn17so2785962wib.6 for ; Tue, 29 Jan 2013 10:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8i5v1QCyozphBDVowHMS+53xRS6dQoseCUX8KBAYbO4=; b=fzJ74UWKPCtCjpkaNuvn539To3WOVwAeCa1O94UHfQy+NZj+GSxTOHNdPZEHkt14y+ Ihr0QRW+rzIjuIrsu6zZKiOPC60k/1flVPMAGaEAG53XaOinQkDSmsz0/wRaYWedYFY3 e/Cy2yRcb1mO41zAOV/qGq5YpzkAvcy3dHrmpharfyFIwXnuXUPaVwK7Fwkx/pGT77RC c8XovSD/JFa52yFX1daPdh0OtAQu1McgTAQStIp2/9x0SUN//0f99XOACTUiwMgWzB7A tZIxRxJ3FCm+RVwHQXvtIp7ykjkn0Du40hd21F6bMZu+K+9YHHHj1pGMUwO0xmJM65WL KAsw== MIME-Version: 1.0 X-Received: by 10.180.109.10 with SMTP id ho10mr4421959wib.9.1359484016133; Tue, 29 Jan 2013 10:26:56 -0800 (PST) Received: by 10.180.144.77 with HTTP; Tue, 29 Jan 2013 10:26:55 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Jan 2013 10:26:55 -0800 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: Juergen Quittek Content-Type: multipart/alternative; boundary=e89a8f3bae49dc068f04d4718931 Cc: "draft-ietf-eman-requirements@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-eman-requirements-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:26:58 -0000 --e89a8f3bae49dc068f04d4718931 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks; yes this addresses my concern. Thank you! /M On Tue, Jan 29, 2013 at 8:40 AM, Juergen Quittek wrote: > Hi Magnus, > > Many thanks for the review. > > As you suggested, I extended the paragraph in the Security > Considerations section: > > OLD > Monitoring energy-related quantities of an entity addressed in > Sections 5 - 8 can be used to derive more information than just the > received and provided energy, so monitored data requires privacy > protection. Monitored data may be used as input to control, > accounting, and other actions, so integrity of transmitted > information and authentication of the origin may be needed. > > NEW > Monitoring energy-related quantities of an entity addressed in > Sections 5 - 8 can be used to derive more information than just the > received and provided energy, so monitored data requires protection. > This protection includes authentication and authorization of entities > requesting access to monitored data as well as privacy protection > during transmission of monitored data. Monitored data may be used as > input to control, accounting, and other actions, so integrity of > transmitted information and authentication of the origin may be > needed. > > > Does this look OK for you? > > Thanks, > Juergen > > > On 21.01.13 05:05, "Magnus Nystr=F6m" wrote: > > >I have reviewed this document as part of the security directorate's > >ongoing effort to review all IETF documents being processed by the > >IESG. These comments were written primarily for the benefit of the > >security area directors. Document editors and WG chairs should treat > >these comments just like any other last call comments. > > > >This standards-track document describes requirements on standards for > >managing power entities over networks. > > As stated in the Security Considerations section, controlling power > >state and power supply of networked energy entities are highly sensitive > >actions and thus authorization, privacy etc. may be required. Similarly, > >the date provided by those entities will often require integrity and > >sometimes authenticity. The document may gain by also making clear the > >potential need for the energy entities to identify, authenticate and > >authorize the entities requesting access to power data. I would suggest > >to add some text around this - because I assume some requirements on > >standards will be present for that. > > > > > > --=20 -- Magnus --e89a8f3bae49dc068f04d4718931 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks; yes this addresses my concern. Thank you!
/M


On Tue, Jan 29, 2013 at 8:40 AM, Juergen Quittek = <Quittek@neclab.e= u> wrote:
Hi Magnus,

Many thanks for the review.

As you suggested, I extended the paragraph in the Security
Considerations section:

OLD
=A0 =A0Monitoring energy-related quantities of an entity addressed in
=A0 =A0Sections 5 - 8 can be used to derive more information than just the<= br> =A0 =A0received and provided energy, so monitored data requires privacy
=A0 =A0protection. =A0Monitored data may be used as input to control,
=A0 =A0accounting, and other actions, so integrity of transmitted
=A0 =A0information and authentication of the origin may be needed.

NEW
=A0 =A0Monitoring energy-related quantities of an entity addressed in
=A0 =A0Sections 5 - 8 can be used to derive more information than just the<= br> =A0 =A0received and provided energy, so monitored data requires protection.=
=A0 =A0This protection includes authentication and authorization of entitie= s
=A0 =A0requesting access to monitored data as well as privacy protection =A0 =A0during transmission of monitored data. =A0Monitored data may be used= as
=A0 =A0input to control, accounting, and other actions, so integrity of
=A0 =A0transmitted information and authentication of the origin may be
=A0 =A0needed.


Does this look OK for you?

Thanks,
=A0 =A0 Juergen


On 21.01.13 05:05, "Magnus Nystr=F6m" <magnusn@gmail.com> wrote:

>I have reviewed this document as part of the security directorate's=
>ongoing effort to review all IETF documents being processed by the
>IESG. =A0These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments.
>
>This standards-track document describes requirements on standards for >managing power entities over networks.
> As stated in the Security Considerations section, controlling power >state and power supply of networked energy entities are highly sensitiv= e
>actions and thus authorization, privacy etc. may be required. Similarly= ,
>the date provided by those entities will often require integrity and >sometimes authenticity. The document may gain by also making clear the<= br> >potential need for the energy entities to identify, authenticate and >authorize the entities requesting access to power data. I would suggest=
>to add some text around this - because I assume some requirements on >standards will be present for that.
>
>




--
-- Magnus
--e89a8f3bae49dc068f04d4718931-- From jhutz@cmu.edu Tue Jan 29 13:28:43 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D0E21F87DF; Tue, 29 Jan 2013 13:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp8HU1u8XB5U; Tue, 29 Jan 2013 13:28:43 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id 36F1A21F87D5; Tue, 29 Jan 2013 13:28:43 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r0TLSdi9022872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 29 Jan 2013 16:28:40 -0500 (EST) Message-ID: <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Ben Laurie Date: Tue, 29 Jan 2013 16:28:39 -0500 In-Reply-To: <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: secdir@ietf.org, The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, jhutz@cmu.edu Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:28:43 -0000 On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: > On 24 January 2013 19:06, Jeffrey Hutzelman wrote: > > Similarly, as an anti-spam measure, this document proposes that logs accept > > only certificates which chain back to a known CA, and requires that logs > > validate each submitted certificate before appending it to the log. This > > sounds good, but it's not the only possible mechanism, and so I think MUST > > is too strong here. Additionally, there is no discussion of the security > > implications if a client depends on a log to do this and the log does not > > actually do so. Rather than requiring that logs validate every submitted > > certificate, the document should only RECOMMEND that they do so, and make > > clear that clients MUST NOT depend on such validation having been done. > > On second thoughts, whilst that is an effective anti-spam measure, it > is also part of the functionality of CT: i.e. to identify misissue and > give some means to do something about it. The CA check ensures we have > someone to blame for misissue. Hrm. I sort of thought the idea was for the logs to be untrusted repositories, able to be audited but not themselves expected to detect problems. If logs are expected to do validation of this sort, is there a way for a third party to discover whether they are doing so (or at least, whether they are accepting certificates they shouldn't)? > I am not averse to suggestions that achieve the overall aim, but I > don't see the virtue of leaving it vague in the description of the > experiment we are actually running. I'm not suggesting vagueness; rather, I'm merely suggesting downgrading a MUST to a SHOULD, which is still quite strong. What happens if someone wants to start logging certs issued by a private CA, or self-signed certs they have observed, or...? I'm suppose I'm OK with keeping the scope narrower than that for purposes of the experiment, as long as it is possible to relax the requirement later without breaking the system. Hence the importance of making it clear that clients must not rely on logs to have done validation (on which point I think we've already reached agreement). -- Jeff From stephen.farrell@cs.tcd.ie Tue Jan 29 16:31:25 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB59921F884C for ; Tue, 29 Jan 2013 16:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XdCz-C8yvZV for ; Tue, 29 Jan 2013 16:31:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C3CA421F86FF for ; Tue, 29 Jan 2013 16:31:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 383FEBE60; Wed, 30 Jan 2013 00:31:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7VffmWwFdLk; Wed, 30 Jan 2013 00:31:01 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.59.84]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9B452BE62; Wed, 30 Jan 2013 00:31:00 +0000 (GMT) Message-ID: <510869C4.9060706@cs.tcd.ie> Date: Wed, 30 Jan 2013 00:31:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "secdir@ietf.org" References: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> In-Reply-To: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: FW: draft-ietf-roll-applicability-template X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:31:26 -0000 Hi all, The roll folks are looking for a review of this I-D. If someone feels the love, can you let Tero know and he'll capture that. If nobody does, then Tero, can you pick whoever's next in the rotation. Thanks, S. -------- Original Message -------- Subject: FW: draft-ietf-roll-applicability-template Date: Tue, 29 Jan 2013 17:59:36 -0000 From: Adrian Farrel Reply-To: To: CC: , Copying Sean in just in case he is inclined to say something. A > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael > Richardson > Sent: 27 January 2013 20:46 > To: stephen.farrell@cs.tcd.ie > Cc: Adrian Farrel; jpv@cisco.com > Subject: draft-ietf-roll-applicability-template > > > I'm still looking for SEC Directorate review of the ROLL applicability > template. > > The idea is to make sure that security question will get addressed > earlier in the process, rather than at SEC Directorate review time. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > From benl@google.com Wed Jan 30 02:00:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558DF21F87F5 for ; Wed, 30 Jan 2013 02:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv3PpAsrmwCh for ; Wed, 30 Jan 2013 02:00:10 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4117121F87AA for ; Wed, 30 Jan 2013 02:00:09 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id j4so715088bkw.3 for ; Wed, 30 Jan 2013 02:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dudy863wOL19pgxJd9FSpEUKle7RINr6353d1R+isL0=; b=ASs6bCAEAXP4/amuOt7azwBx42fXRUFVzutbJqkCBpzmPoIY20TIhe0bU4h3qKFH8j Ml7qw7oSP7leras7b/s8YL1wGpbcKOgQr+qVvWJW2m4swpLIEXjDVbhXNwhUoi7PIL0O 6k5OnNeW3OQwitprAu+QBFs9jMi5FUoG3cQkgfW4k2D28RVDJef4Q+TFNDbUTl3d3Zua kwEFXV6YRxJD2YXgDkPYYB6Kzs9QiAYVuRXFNbtT2hidSKoX5lOyXTfDmzhnXenMImUm 6G3Qtzka5ofrfQfRpn6uMf2u12t/2Q5xB1eM21d9d+tTowOKnuMlQb47HgUcXghYsDKh AKLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=dudy863wOL19pgxJd9FSpEUKle7RINr6353d1R+isL0=; b=ifIp3K7jqMic74UqklvjjZZ33KoxcUdz1x6mbFJtxO4Ptxtih/ZuqWVg4i/mdJFCwy 1yALMudTYay6vwTYHo8nabQ0dpN76t3t2D6kYXG6sHO+BD/uRsyqbXD19glk7O696ron Mmhm+GlyXR+QjeguRgHFx/9CNTFfc3XDuQiYEdbSmiOFdql3m1XwP4IWnu9ONnedUaFP p5E3stRWt7K8ApFqCTil/7S9aStF/M9NnkK8Hmd8pVpVbyZJyRVOxgg9yWvbSaSGBhZs 5+5xszvZ5zQUsl4xQ16VCmjFlsm+aaSZRdPdq6/f+YF3qxbD78v/wNmDEv1Q1DMxfaPC wxcQ== MIME-Version: 1.0 X-Received: by 10.204.12.3 with SMTP id v3mr1090335bkv.10.1359540009074; Wed, 30 Jan 2013 02:00:09 -0800 (PST) Received: by 10.204.38.198 with HTTP; Wed, 30 Jan 2013 02:00:08 -0800 (PST) In-Reply-To: <510869C4.9060706@cs.tcd.ie> References: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> <510869C4.9060706@cs.tcd.ie> Date: Wed, 30 Jan 2013 10:00:08 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmUBVkStifku92PSKVmjGwCbx5ZlCR8++fpBfKRNxqXV09GT6/SGTIbQ8G6jR82VEWBnv6aSccnhLEn3cnn0oibKoLf8TZ50z+OYVtJPAcg627miSG4abrF9L+fl0LnqTfamJoBLjZigpDW45wU9JL/RHWByxRquqHK1eDNnR7/Z+rE7GJc/JCvLgcSGDsOq9bbhh23 Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: FW: draft-ietf-roll-applicability-template X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:00:11 -0000 On 30 January 2013 00:31, Stephen Farrell wrote: > > Hi all, > > The roll folks are looking for a review of this I-D. > If someone feels the love, can you let Tero know and > he'll capture that. If nobody does, then Tero, can > you pick whoever's next in the rotation. Do you mean https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/?include_text=1? There doesn't appear to be a draft-ietf- If so, there's no info in it to base a security review on. > > Thanks, > S. > > > -------- Original Message -------- > Subject: FW: draft-ietf-roll-applicability-template > Date: Tue, 29 Jan 2013 17:59:36 -0000 > From: Adrian Farrel > Reply-To: > To: > CC: , > > Copying Sean in just in case he is inclined to say something. > > A > >> -----Original Message----- >> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael >> Richardson >> Sent: 27 January 2013 20:46 >> To: stephen.farrell@cs.tcd.ie >> Cc: Adrian Farrel; jpv@cisco.com >> Subject: draft-ietf-roll-applicability-template >> >> >> I'm still looking for SEC Directorate review of the ROLL applicability >> template. >> >> The idea is to make sure that security question will get addressed >> earlier in the process, rather than at SEC Directorate review time. >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks [ >> ] Michael Richardson, Sandelman Software Works | network architect [ >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >> >> > > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From benl@google.com Wed Jan 30 02:15:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30E921F8840 for ; Wed, 30 Jan 2013 02:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.918 X-Spam-Level: X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKAJSZZEqvdv for ; Wed, 30 Jan 2013 02:15:11 -0800 (PST) Received: from mail-bk0-f51.google.com (mail-bk0-f51.google.com [209.85.214.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEE121F872D for ; Wed, 30 Jan 2013 02:15:10 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id ik5so724428bkc.24 for ; Wed, 30 Jan 2013 02:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3NtOB0u9oRCxkF9LsNc441hsSxOpUYhgrTCUaFz7SDs=; b=cs7kEDGvBTHI55iPKNdumiV0Ek0f/QXLUcp3/As5f14ahG5X3zqDGAPvYqOYMvJ4F9 3x2F/7W8hxyXFo3EEGUOxsQJwvUe89VLUsfDiSoHcJVXDDeVaBlKS9VRLmfSDwm+G5Ep S9CZUfh1eI6gfbmWeAncVnhsOMved7V4ccM68D4kDwJaiGTBkfE0X5pyPPmKnR/1YouK PUCRToGFYC1gUPvFi5gA0lDJkrgDNp8WPap0R17yMMc3YbL7urCMIRQ/n/Ra7WMuI4VV 1Nw3VgHga6GbLSpA8b44YzYAi89Zrv78yoVbmUtnBQ80o5kxNuKQNh2hUkF0xqzdf/HT NGvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=3NtOB0u9oRCxkF9LsNc441hsSxOpUYhgrTCUaFz7SDs=; b=mtS9Xp+qaOQnJjZcwJXxGX4yuDleA6VGqkRSJhUzMs/S48gFiLM7rbC8XD2m/9O7S4 jNCkPfxfWu7AX+JHp/kcgnTfC4WRnDYLoyu+5A5R6fVG5mLL3czdEYlRpeYQbtPGcNJq mPPDYuX1483L3jUCvjUALfOaFvZTZ4HxYraQ1d1TkJvwwIpn9zcU7NaL5FvrKppJ1GiV hnjIYM5K/K++pJohywziNK63ClQ0GNFZpoeCs3rX8bPPqu0wx2wHmCOF4ivREWpW1bCG ezEAkNjfYc7LkZlQWJFzoZ8eqeRMpt/C/Mh/HpdIXY08L3ed7dvQNfwfHTK9XxSqmg15 +QpA== MIME-Version: 1.0 X-Received: by 10.204.13.28 with SMTP id z28mr1113813bkz.83.1359540909932; Wed, 30 Jan 2013 02:15:09 -0800 (PST) Received: by 10.204.38.198 with HTTP; Wed, 30 Jan 2013 02:15:09 -0800 (PST) In-Reply-To: <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> References: <1359054393.10945.15.camel@minbar.fac.cs.cmu.edu> <26550_1359459340_r0TBZdV2026657_CABrd9STdUzPok8bcAUJddcQ0iWkk=VhP6SZOF-Tv8NFf1fUDFQ@mail.gmail.com> <1359494919.17745.12.camel@minbar.fac.cs.cmu.edu> Date: Wed, 30 Jan 2013 10:15:09 +0000 Message-ID: From: Ben Laurie To: Jeffrey Hutzelman Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnCVg9HVSgutt7zpMKt+UETDN5wUXXkqyR7RVl9r8BccDgI6NysKnuUzRsONLmdhTw1BOmeuUDdbkfo9BiDO0tMj2Sl1x0UTxLN6T708Lv2LoOU8qQAwm0jauEfYXReOpuzA0Vog0O9rohW3M/0WdwxbBckYw+fg3BpKxqsuo/G2TcjisIjO56jYBoPj6gkzyjrnnY5 Cc: The IESG , draft-laurie-pki-sunlight.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] dir review of draft-laurie-pki-sunlight-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:15:12 -0000 On 29 January 2013 21:28, Jeffrey Hutzelman wrote: > On Tue, 2013-01-29 at 11:35 +0000, Ben Laurie wrote: >> On 24 January 2013 19:06, Jeffrey Hutzelman wrote: >> > Similarly, as an anti-spam measure, this document proposes that logs accept >> > only certificates which chain back to a known CA, and requires that logs >> > validate each submitted certificate before appending it to the log. This >> > sounds good, but it's not the only possible mechanism, and so I think MUST >> > is too strong here. Additionally, there is no discussion of the security >> > implications if a client depends on a log to do this and the log does not >> > actually do so. Rather than requiring that logs validate every submitted >> > certificate, the document should only RECOMMEND that they do so, and make >> > clear that clients MUST NOT depend on such validation having been done. >> >> On second thoughts, whilst that is an effective anti-spam measure, it >> is also part of the functionality of CT: i.e. to identify misissue and >> give some means to do something about it. The CA check ensures we have >> someone to blame for misissue. > > Hrm. I sort of thought the idea was for the logs to be untrusted > repositories, able to be audited but not themselves expected to detect > problems. If logs are expected to do validation of this sort, is there > a way for a third party to discover whether they are doing so (or at > least, whether they are accepting certificates they shouldn't)? A third party can indeed verify this - they just watch the log like any monitor does. >> I am not averse to suggestions that achieve the overall aim, but I >> don't see the virtue of leaving it vague in the description of the >> experiment we are actually running. > > I'm not suggesting vagueness; rather, I'm merely suggesting downgrading > a MUST to a SHOULD, which is still quite strong. What happens if > someone wants to start logging certs issued by a private CA, or > self-signed certs they have observed, or...? I don't see an issue with logging certs from a private CA. As for self-signed certs, I don't see the point, but I guess if someone figures out a point we can relax it in the next version. > I'm suppose I'm OK with keeping the scope narrower than that for > purposes of the experiment, as long as it is possible to relax the > requirement later without breaking the system. Hence the importance of > making it clear that clients must not rely on logs to have done > validation (on which point I think we've already reached agreement). Cool. From stephen.farrell@cs.tcd.ie Wed Jan 30 02:30:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6F421F8837 for ; Wed, 30 Jan 2013 02:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvEDr4eo-SdK for ; Wed, 30 Jan 2013 02:30:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5421F86E6 for ; Wed, 30 Jan 2013 02:30:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 22F8DBE39; Wed, 30 Jan 2013 10:30:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YZrRgFQctSQ; Wed, 30 Jan 2013 10:30:01 +0000 (GMT) Received: from [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82] (unknown [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A5278BE6E; Wed, 30 Jan 2013 10:30:00 +0000 (GMT) Message-ID: <5108F629.2090306@cs.tcd.ie> Date: Wed, 30 Jan 2013 10:30:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Laurie References: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> <510869C4.9060706@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: FW: draft-ietf-roll-applicability-template X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:30:28 -0000 Ah, apologies for even asking if its that non-draft. (I didn't look;-) I'll go back and beat 'em up if so. S. On 01/30/2013 10:00 AM, Ben Laurie wrote: > On 30 January 2013 00:31, Stephen Farrell wrote: >> >> Hi all, >> >> The roll folks are looking for a review of this I-D. >> If someone feels the love, can you let Tero know and >> he'll capture that. If nobody does, then Tero, can >> you pick whoever's next in the rotation. > > Do you mean https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/?include_text=1? > There doesn't appear to be a draft-ietf- > > If so, there's no info in it to base a security review on. > >> >> Thanks, >> S. >> >> >> -------- Original Message -------- >> Subject: FW: draft-ietf-roll-applicability-template >> Date: Tue, 29 Jan 2013 17:59:36 -0000 >> From: Adrian Farrel >> Reply-To: >> To: >> CC: , >> >> Copying Sean in just in case he is inclined to say something. >> >> A >> >>> -----Original Message----- >>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael >>> Richardson >>> Sent: 27 January 2013 20:46 >>> To: stephen.farrell@cs.tcd.ie >>> Cc: Adrian Farrel; jpv@cisco.com >>> Subject: draft-ietf-roll-applicability-template >>> >>> >>> I'm still looking for SEC Directorate review of the ROLL applicability >>> template. >>> >>> The idea is to make sure that security question will get addressed >>> earlier in the process, rather than at SEC Directorate review time. >>> >>> -- >>> ] Never tell me the odds! | ipv6 mesh networks [ >>> ] Michael Richardson, Sandelman Software Works | network architect [ >>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >>> >>> >> >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From stephen.farrell@cs.tcd.ie Wed Jan 30 02:35:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7F321F87B9 for ; Wed, 30 Jan 2013 02:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJuuzokT4m-f for ; Wed, 30 Jan 2013 02:35:55 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B5DD221F878F for ; Wed, 30 Jan 2013 02:35:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DB6E8BE3E; Wed, 30 Jan 2013 10:35:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY2CQwV2FyYZ; Wed, 30 Jan 2013 10:35:31 +0000 (GMT) Received: from [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82] (unknown [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F1558BE39; Wed, 30 Jan 2013 10:35:30 +0000 (GMT) Message-ID: <5108F774.20804@cs.tcd.ie> Date: Wed, 30 Jan 2013 10:35:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Laurie References: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> <510869C4.9060706@cs.tcd.ie> <5108F629.2090306@cs.tcd.ie> In-Reply-To: <5108F629.2090306@cs.tcd.ie> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: FW: draft-ietf-roll-applicability-template X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:35:56 -0000 On 01/30/2013 10:30 AM, Stephen Farrell wrote: > > Ah, apologies for even asking if its that non-draft. > (I didn't look;-) > > I'll go back and beat 'em up if so. Sorry again. Now I remember. So this is really a template. Their plan is that they'll have a bunch of other RPL applicability statement drafts that say how to use the protocol in building control, etc. Each will use this template. Their question to us is what other things should those drafts be required (by this template) to say about security. So I guess we might say e.g. automated key management (BCP 107) needs to be well-defined and mandatory to implement. S. > > S. > > On 01/30/2013 10:00 AM, Ben Laurie wrote: >> On 30 January 2013 00:31, Stephen Farrell wrote: >>> >>> Hi all, >>> >>> The roll folks are looking for a review of this I-D. >>> If someone feels the love, can you let Tero know and >>> he'll capture that. If nobody does, then Tero, can >>> you pick whoever's next in the rotation. >> >> Do you mean https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/?include_text=1? >> There doesn't appear to be a draft-ietf- >> >> If so, there's no info in it to base a security review on. >> >>> >>> Thanks, >>> S. >>> >>> >>> -------- Original Message -------- >>> Subject: FW: draft-ietf-roll-applicability-template >>> Date: Tue, 29 Jan 2013 17:59:36 -0000 >>> From: Adrian Farrel >>> Reply-To: >>> To: >>> CC: , >>> >>> Copying Sean in just in case he is inclined to say something. >>> >>> A >>> >>>> -----Original Message----- >>>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael >>>> Richardson >>>> Sent: 27 January 2013 20:46 >>>> To: stephen.farrell@cs.tcd.ie >>>> Cc: Adrian Farrel; jpv@cisco.com >>>> Subject: draft-ietf-roll-applicability-template >>>> >>>> >>>> I'm still looking for SEC Directorate review of the ROLL applicability >>>> template. >>>> >>>> The idea is to make sure that security question will get addressed >>>> earlier in the process, rather than at SEC Directorate review time. >>>> >>>> -- >>>> ] Never tell me the odds! | ipv6 mesh networks [ >>>> ] Michael Richardson, Sandelman Software Works | network architect [ >>>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> >> > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From benl@google.com Wed Jan 30 02:44:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF7C21F87D1 for ; Wed, 30 Jan 2013 02:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5UNIn6NKtKi for ; Wed, 30 Jan 2013 02:44:41 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2921F87CC for ; Wed, 30 Jan 2013 02:44:41 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id j4so734037bkw.3 for ; Wed, 30 Jan 2013 02:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iQn2KFljzwVENLNIV+F04/YZXccwgZ3V7nhlyhPwCxE=; b=ERtPVbbd+Im188c/p4vDMqSn0m6BrMaXWS6rXVAGHEq0Hmxj0skJWqa/4dga1Gh8EL KNjXsiiMWehYuLWA0sx4Wx46e5107kIMUC+lt0mYS/h2C5VIyDy4VwyGJdOMDqyL9RU6 GJVmVkk03CYAIgvCnhAW6WmV/XH6BmpdIKolJMWjL/gZQBI8N5TfRnGBXBQYtRgNfRn4 VE3rwwpSEkIxOhlbRGeYyuNgxYcwv0e+DwJ+3qQAgJysY+HO0kjhKHrVfoJM8IS8hamx vuOp+zl+7uaceYclun1+S4JbvomYdCtzzGu0zCPFOPVjROhenKfbC/vME9CrI7pLBdyK Px6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=iQn2KFljzwVENLNIV+F04/YZXccwgZ3V7nhlyhPwCxE=; b=FspnZhTSyoIcqzOSSq/T5XppUyoCvAfzv2Tx3ndMFw+CRE8U0BpKXLdGqAo3uKhq0F uGFai2tiPZVpxrPGO6F21Qj9ivXe2J4JGX9nz83Brs04aXiAXUSLpSDJ2urUui6KtV3A iKgpyoliqdL0TS2qAZwZyc7xtE6rxLSV2OioD+nC+TAciIvBzv6cPbB9SLzArYho3Boy We1Y1nht7E2WbLqsQsXMp4PkuUVS/ZYubVUTlhLqHCbqL1x1UGXde68oEAFVoLfxuJV2 6HxfuuBR5vN/HzjNbAYY2CGm/pBhnKd+a1K7tQAZ+sIkuPREgjt39gcV877FttRPRV33 /p1A== MIME-Version: 1.0 X-Received: by 10.204.129.70 with SMTP id n6mr1121781bks.60.1359542680215; Wed, 30 Jan 2013 02:44:40 -0800 (PST) Received: by 10.204.38.198 with HTTP; Wed, 30 Jan 2013 02:44:39 -0800 (PST) In-Reply-To: <5108F774.20804@cs.tcd.ie> References: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> <510869C4.9060706@cs.tcd.ie> <5108F629.2090306@cs.tcd.ie> <5108F774.20804@cs.tcd.ie> Date: Wed, 30 Jan 2013 10:44:39 +0000 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk1DWyRSMbljUQ+wUUnut7DqXcIAFEaSiLMbIFXv2hNaWjlddV2Vatm1u3++5n5wQb/enoyMQKoYGqNFL2gZGcbyJCSOrXsKD1ej7nTXJyPetO7j0EZy5SxiKaZCXMmm5QeX1RH8dMzEkCPvAw5zyl+oyIHQ58yPSCDW4IzYfvGjzTCWxvUP/vq17W6YVW3JESJqSfc Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: FW: draft-ietf-roll-applicability-template X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:44:42 -0000 On 30 January 2013 10:35, Stephen Farrell wrote: > > > On 01/30/2013 10:30 AM, Stephen Farrell wrote: >> >> Ah, apologies for even asking if its that non-draft. >> (I didn't look;-) >> >> I'll go back and beat 'em up if so. > > Sorry again. Now I remember. > > So this is really a template. Their plan is that they'll > have a bunch of other RPL applicability statement > drafts that say how to use the protocol in building > control, etc. Each will use this template. > > Their question to us is what other things should those > drafts be required (by this template) to say about > security. So I guess we might say e.g. automated key > management (BCP 107) needs to be well-defined and > mandatory to implement. I got that, but it seems impossible to answer without knowing a lot more about ROLL than that doc says. Or RPL, whatever that is (not defined in the doc). > > S. > >> >> S. >> >> On 01/30/2013 10:00 AM, Ben Laurie wrote: >>> On 30 January 2013 00:31, Stephen Farrell wrote: >>>> >>>> Hi all, >>>> >>>> The roll folks are looking for a review of this I-D. >>>> If someone feels the love, can you let Tero know and >>>> he'll capture that. If nobody does, then Tero, can >>>> you pick whoever's next in the rotation. >>> >>> Do you mean https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/?include_text=1? >>> There doesn't appear to be a draft-ietf- >>> >>> If so, there's no info in it to base a security review on. >>> >>>> >>>> Thanks, >>>> S. >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: FW: draft-ietf-roll-applicability-template >>>> Date: Tue, 29 Jan 2013 17:59:36 -0000 >>>> From: Adrian Farrel >>>> Reply-To: >>>> To: >>>> CC: , >>>> >>>> Copying Sean in just in case he is inclined to say something. >>>> >>>> A >>>> >>>>> -----Original Message----- >>>>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael >>>>> Richardson >>>>> Sent: 27 January 2013 20:46 >>>>> To: stephen.farrell@cs.tcd.ie >>>>> Cc: Adrian Farrel; jpv@cisco.com >>>>> Subject: draft-ietf-roll-applicability-template >>>>> >>>>> >>>>> I'm still looking for SEC Directorate review of the ROLL applicability >>>>> template. >>>>> >>>>> The idea is to make sure that security question will get addressed >>>>> earlier in the process, rather than at SEC Directorate review time. >>>>> >>>>> -- >>>>> ] Never tell me the odds! | ipv6 mesh networks [ >>>>> ] Michael Richardson, Sandelman Software Works | network architect [ >>>>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >>> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> >> From stephen.farrell@cs.tcd.ie Wed Jan 30 03:04:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDC621F86D8 for ; Wed, 30 Jan 2013 03:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az1495luaYUb for ; Wed, 30 Jan 2013 03:04:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E41821F86C8 for ; Wed, 30 Jan 2013 03:04:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19CADBE5B; Wed, 30 Jan 2013 11:03:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM9ce3kuNqN1; Wed, 30 Jan 2013 11:03:34 +0000 (GMT) Received: from [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82] (unknown [IPv6:2001:770:10:203:75b2:48e:2a5f:bc82]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90EB8BDC7; Wed, 30 Jan 2013 11:03:34 +0000 (GMT) Message-ID: <5108FE07.60904@cs.tcd.ie> Date: Wed, 30 Jan 2013 11:03:35 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Laurie References: <003e01cdfe4a$6af134c0$40d39e40$@olddog.co.uk> <510869C4.9060706@cs.tcd.ie> <5108F629.2090306@cs.tcd.ie> <5108F774.20804@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "secdir@ietf.org" Subject: Re: [secdir] Fwd: FW: draft-ietf-roll-applicability-template X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 11:04:02 -0000 On 01/30/2013 10:44 AM, Ben Laurie wrote: > I got that, but it seems impossible to answer without knowing a lot > more about ROLL than that doc says. Or RPL, whatever that is (not > defined in the doc). True enough. Don't volunteer so:-) If we have someone who knows RPL, (and its a bit of a monster) it'd make more sense for them to take this. The background here is that I inherited a DISCUSS from Tim on a RPL document to the effect that they had no automated key management (AKM) defined which BCP107 says they need. They argued (fairly I think) that the method for AKM that you'd make mandatory to implement might well differ for different applications using RPL but eventually that draft ended up back in the WG. So now they're trying to make sure they don't hit that problem again via this template for applicability statements. So I hope any review we do says at least: "Add a requirement that applicability statements MUST specify an AKM method as MTI." Given how complex RPL is though, there could well be more to say, hence their request. S. > >> >> S. >> >>> >>> S. >>> >>> On 01/30/2013 10:00 AM, Ben Laurie wrote: >>>> On 30 January 2013 00:31, Stephen Farrell wrote: >>>>> >>>>> Hi all, >>>>> >>>>> The roll folks are looking for a review of this I-D. >>>>> If someone feels the love, can you let Tero know and >>>>> he'll capture that. If nobody does, then Tero, can >>>>> you pick whoever's next in the rotation. >>>> >>>> Do you mean https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/?include_text=1? >>>> There doesn't appear to be a draft-ietf- >>>> >>>> If so, there's no info in it to base a security review on. >>>> >>>>> >>>>> Thanks, >>>>> S. >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: FW: draft-ietf-roll-applicability-template >>>>> Date: Tue, 29 Jan 2013 17:59:36 -0000 >>>>> From: Adrian Farrel >>>>> Reply-To: >>>>> To: >>>>> CC: , >>>>> >>>>> Copying Sean in just in case he is inclined to say something. >>>>> >>>>> A >>>>> >>>>>> -----Original Message----- >>>>>> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael >>>>>> Richardson >>>>>> Sent: 27 January 2013 20:46 >>>>>> To: stephen.farrell@cs.tcd.ie >>>>>> Cc: Adrian Farrel; jpv@cisco.com >>>>>> Subject: draft-ietf-roll-applicability-template >>>>>> >>>>>> >>>>>> I'm still looking for SEC Directorate review of the ROLL applicability >>>>>> template. >>>>>> >>>>>> The idea is to make sure that security question will get addressed >>>>>> earlier in the process, rather than at SEC Directorate review time. >>>>>> >>>>>> -- >>>>>> ] Never tell me the odds! | ipv6 mesh networks [ >>>>>> ] Michael Richardson, Sandelman Software Works | network architect [ >>>>>> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> secdir mailing list >>>>> secdir@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/secdir >>>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>>> >>>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >>> >>> > > From tuexen@fh-muenster.de Wed Jan 30 03:59:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B3921F8867; Wed, 30 Jan 2013 03:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+8MVCNMn0Bb; Wed, 30 Jan 2013 03:59:56 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CF55721F8778; Wed, 30 Jan 2013 03:59:54 -0800 (PST) Received: from [10.0.1.109] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 698EE1C0C069E; Wed, 30 Jan 2013 12:59:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: <20743.57390.456600.844778@fireball.kivinen.iki.fi> Date: Wed, 30 Jan 2013 12:59:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1283) Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 11:59:58 -0000 On Jan 29, 2013, at 3:43 PM, Tero Kivinen wrote: > Michael Tuexen writes: >>> The document should note that firewalls needs to be updated to >>> specifically inspect / filter also UDP encapsulated SCTP if they do >>> normal SCTP inspection / filtering. >>=20 >> I agree. What about adding the following to the Security = Considerations: >> Firewalls inspecting SCTP packets must also be aware of the = encapsulation >> and apply corresponding rules to the encapsulated packets. >=20 > That is good enough. Included in revision -09. >=20 >>> It is not clear for me how the initiator host finds the port where = to >>> connect, when it is doing initial connection. I.e. if a host A wants >>> to connect to host B, which port it should use if it needs to use = UDP >>> encapsulated SCTP? Is it assumed that 9899 will be used always? What >>> about connecting to the hosts which are behind NAT, i.e. if host B = is >>> behind NAT, how does host A find the port number to use (which host = B >>> hopefully somehow already configred to the NAT to be passed to him)? >>=20 >> The method for finding the remote port number for the initial packets >> is not in the scope of this document. This is something you would do >> outside of the SCTP stack. The described API provides the required >> interface for the application to set the remote encapsulation >> port. >=20 > It might be good to say that in the document, i.e. that it is out of > scope of this document.=20 What about adding Please note that this document does not provide all techniques = necessary for building a complete NAT-capable application using SCTP. This = document focuses on the functionality required within the SCTP stack and making this available via an API. to the Abstract? >=20 >>> Also what if host A and B already have one SCTP connection, and now >>> host B wants to create another, do host B reuse the same UDP >>> destination port number for host A that was used for the already >>> existing SCTP connection between them? The section 4.1 says that UDP >>> port numbers are stored per destination address per SCTP = association, >>> so that would indicate no. >>=20 >> As stated in the document, each stack uses a single port number >> as the destination address of all incoming packets. >=20 > The document also says: >=20 > Using a single UDP encapsulation port number per host is not > possible if the SCTP stack is implemented as part of an > application. >=20 > which indicates that using multiple UDP port numbers is also an > option. Or is implementing SCTP stack as appliction out of scope too? > Section 3.1 seems to indicate that it is not out of scope. No, you can implement SCTP in the kernel (which means that the stack is unique on the host) or in the application (which means there can me multiple, one stack per association for example). >=20 > =46rom the section 3.1 and 4.1 it is not really clear what needs to be > supported. If I have understood correctly that if SCTP is implemented > in kernel then we use one UDP port for the whole host, but if SCTP is > implemented by the application then each application might have > different UDP port, i.e. there will be multiple UDP SCTP encapsulation > ports in the host. Correct. >=20 > I.e. if host A is connected to two different applications on host B. > Host B is such host that it does not support SCTP on kernel, the SCTP > is implemented on the application itself, and that means each > application has separate UDP encapsulation port. Now what you said > before I assume that it is outside the scope of this document for host > A know how to connect to host B, i.e. how to get the UDP port numbers > where to connect, and also whether to use the UDP encapsulation at > all? Correct. Finding the remote UDP number for the initial packets is out of scope. >=20 > Is there any work ongoing on this? I.e. how is this going to be solved > in practice? Or is it assumed that the SCTP applications which do not > have direct access to IP-layer, which need to use UDP encapsulation > because of that, are always only initiators, i.e. nobody ever connects > to them, they always initiate the connection to the known services? As said above, a complete solution is out of scope of this document. >=20 >>> The draft seems to be doing dynamic port number updating based on >>> finding SCTP association (which includes checking the very weak >>> verification tag). The current section 4.4 only mentions that port >>> number is updated.=20 >>=20 >> Correct. >=20 >>> In some cases also the IP-address might change, >>> i.e. if the NAT box is rebooted or its connection table is cleared, >>> and the NAT box have multiple IP-addresses, it is completly possible >>> that the NAT mapping changes so that IP-address and UDP port number >>> both change. I am not familiar enough with SCTP to know whether this >>> causes problem with SCTP, i.e. whether it is default SCTP rules to = use >>> the last seen IP-address when sending reply or what. >>=20 >> The method described in the document does NOT cover changing the >> address. If you want to handle that, you need to use the address >> reconfiguration extension (RFC 5061). >=20 > Then you need to say that in the draft. Note, that hosts A and B do It is mentioned in the last paragraph of section 4.7 > not have any way of knowing when the IP-address changes, or whether it > is going to change. For normal TCP (and most likely also SCTP) this Well, that depends. If the address change is local on the host, SCTP kernel implementations = (at least FreeBSD and Linux) will get notified when addresses are added or removed. For example, on FreeBSD you can add an address using ifconfig and the address changes will happen on all association which = use a wildcard bound SCTP socket, it is allowed system-wide via the net.inet.sctp.auto_asconf sysctl and the application didn't disabled it via the SCTP_AUTO_ASCONF socket option. On the other hand, if the address change is not local, the peer will respond to a packet with an ABORT chunk having the T-bit set. This could be interpreted as an indication of an address change.=20 > IP-address change will usually result the connection to be reset, as > the NAT box does not have the mapping for the connection anymore, but > for UDP that does not happen. The NAT box will just create new > mapping. Which is fine. >=20 > I.e. the situation is as follows. Host A is behind NAT, and talks to > host B using UDP encapsulated SCTP. Now the NAT box is rebooted, and > it looses state. When Host A sends next UDP encapsulated SCTP packet > to Host B that UDP packet might get new source IP address by the NAT > box. What should happen at that point? As described above, host B will respond with an ABORT chunk and host A can use this as an indication that it has to update its address. So it can send a ASCONF chunk adding the wildcard address and removing the wildcard address which will result in the possibility to continue the association. >=20 > Should the SCTP implementation notice that IP-address of the > association has changed, and send some kind of reset or what? Or does > the SCTP implementation just drop all packets because they do not > match association and then connection is dropped after timeout? >=20 > How do you plan to use RFC 5061 to solve that situation? I do not know > enough of RFC 5061 to say how it can be used to solve this kind of > situation, where the peer A whose IP-address was changed does not even > know that his IP-address was changed. I hope the above makes it clearer. We can add at the end of section 4.7 text like: If an SCTP end-point receives an ABORT with the T-bit set, it MAY use this as an indication that the addresses seen by the peer might have changed. >=20 >>> The section 3.2 do say that if multiple addresses are used, then >>> RFC5061 (SCTP Dynamic Address Reconfiguration) with RFC4895 >>> (Authentication Chunks for SCTP) MUST be used. With dynamic update = for >>> the UDP port number, the similar hijacking attack described in the >>> RFC5061 security considerations section is applicable here too. The >>> RFC5061 requires (without using RFC2119 language) using of >>> authentication chunks to prevent that attack, so should we require >>> authentication chunks here too to prevent same attacks even when = using >>> only one IP-address, as we do update the UDP ports based on the >>> received packets? Also perhaps the requirement of using = authentication >>=20 >> I don't think so. The reasoning is the SCTP/UDP/IP does not need >> to be more secure than SCTP/IP. SCTP/IP is protected against blind >> attackers by the V-tag mechanism. The same applies to SCTP/UDP/IP. >> This is described in the second paragraph of the Security = Considerations. >>=20 >> The situation is different from changing the IP address. >> Assume that there is an association between endpoints A and B. >> If A owns IP.A while establishing the association, then looses >> it and a node C gets it, B sends packets to C. So C could take >> over the association. >=20 > And that same thing can happen with UDP encapsulation when NAT box is > rebooted. I.e host A owns IP.NAT.port-X, and then nat box is rebooted > and that port-X is given to host C, now packets sent by host B to > IP.NAT.port-X end up to host C who will be able to take over the > association. Sure, this can happen. >=20 > Of course as the NAT mappings are usually remote IP + remote port + > protocol + NAT IP + NAT port, this means that changes for host C to > get exactly same 5-tuple are small... On the other hand host C can > most likely know remote IP and remote port as they are well known > based on the service. The NAT IP is most likely going to be same all > the time, so only thing host C needs to be doing is to cause NAT to > loose state (i.e. cause it to either reboot, or run out of mappings), > and then start filling up the NAT mappings until it gets the NAT port > host A used earlier. >=20 > One way to cause NAT to loose state, is to start flooding NAT with new > UDP packets each destinationed to remote host + port and having > UDP different source port. NAT will allocate new NAT port for each of > them until it runs out of port numbers, in which case it starts > reusing port numbers. Now depending on the NAT implementation, flood > guarding, SCTP heartbeat intervals etc NAT might reuse the host A's > port in which case host C managed to get the session. Yes, that is possible. What can the attacker do? The attacker can't insert any DATA or SACK chunks, since it would have to guess the V-tag. However, the attacker can ABORT the association with sending an ABORT = with the V-tag set. But this is not better or worse than attacking the NAT box. So most likely the attacker can receive an RWND of user data. If sent unprotected, I would assume that his is acceptable. Using DTLS/SCTP would protect against it. >=20 >>> chunks should be also mentioned in the security considerations >>> section, as it is very important for the security point of view of = the >>> protocol.=20 >>>=20 >>> The section 4.1 "Architectural Considerations" says correctly that >>> implementations needs to store remote UDP port per destination = address >>> for each SCTP association, i.e. different SCTP associations can have >>> different port numbers for same destination address. This is = required, >>> because there might be multiple SCTP clients behind the same NAT box >>> (having same IP-address), just using different ports. Unfortunately, >>=20 >> And there might be multiple peer addresses and the port might be >> different. It is even possible that some peer addresses need = encapsulation >> and some don't. >>=20 >>> section 4.3 "Encapsulation Procedure" does not have the "for each = SCTP >>> association" part, so it would be better to clarify this also in 4.3 >>> that the UDP port number is per destination address per SCTP >>> association. >>=20 >> What about: >> When inserting the UDP header, the source port MUST be the local = UDP >> encapsulation port number of the SCTP stack, >> the destination port MUST be the remote UDP encapsulation port number >> stored for the association and the destination address to which the >> packet is sent (see ). >=20 > That seems to be ok. Included in rev-09. >=20 >>> The current draft also does not comment anything about NAT = keepalives. >>> For example the RFC3948 (UDP encapsulation for IPsec) does specify >>> special NAT keepalive packets which are sent by the host behind the >>> NAT to keep the NAT mapping alive, as quite often NAT boxes remove >>> mappings after certain time. If the NAT mapping disappears, then >>> packets might not pass NAT box anymore depending on the direction of >>> packets and type of NAT box (see RFC2663 for different types of = NATs). >> SCTP sends on each idle path HEARTBEAT messages which would keep the >> NAT state alive. >=20 > Which ways those HEARTBEAT messages are sent? For NAT mappings to stay > alive, the messages quite often needs to be coming from inside of the > NAT, i.e. from the host which is behind the NAT, and if both ends are > behind NAT, they need to be coming from both ends. Do HEARTBEATs cover > that possibility. Also some NAT boxes are known to require as small > keepalive intervals as 20 seconds... How often do you send HEARTBEATS? Both sides send HEARTBEATs, the standard time between them is 30 seconds plus RTO plus/minus 50%. However, the application can change the 30 = seconds to other values using the standard socket API. >=20 > For example RFC3948 section 4 recommends that default value for > keepalive interval is 20 seconds for UDP Encapsulation of ESP > connections.=20 >=20 >> What about adding the following to section 3.2: >>=20 >> SCTP sends periodically HEARTBEAT chunks on all idle paths. These = can >> be used to keep the NAT state alive. >=20 > That is ok, provided HEARTBEATS are able to solve this issue. Included in rev -09. >=20 >>> The current draft does not seem to answer any of the UNSAF (IAB >>> Considerations for UNilateral Self-Address Fixing (UNSAF) Across >>> Network Address Translation, RFC3424) questions.=20 >>=20 >> That is correct. However, the document describes how you encapsulate >> SCTP in UDP, not how you build a complete NAT traversal solution >> where both ends might be behind NATs. So finding the remote >> encapsulation port is not within the scope of the document. >=20 > So is having both ends behind NAT out of scope? This should then be > mentioned in section 3.2. Note, that similar problems also arise when > you need to connect to host which is behind NAT, i.e. even if it is > only one host behind NAT, but if the connection is coming from the > outside, you have similar problems than what you have when both ends > are behind NAT. I think the point is that finding the remote port number for initial packets is out of scope of the this document. >=20 > So if the scope only covers the case where the SCTP initiator is > behind NAT, then that needs to be mentioned in this document. Again finding the remote port for initial packets is out of scope. = However, in this scenario the initiator could try 9899... >=20 > Also RFC3424 do also cover other cases than just those where both ends > are behind NAT...=20 > --=20 > kivinen@iki.fi >=20 From kathleen.moriarty@emc.com Wed Jan 30 14:03:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF31821F877B; Wed, 30 Jan 2013 14:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNgW9OMhVjCt; Wed, 30 Jan 2013 14:03:36 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id A242721F877A; Wed, 30 Jan 2013 14:03:35 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0UM3XFu007085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jan 2013 17:03:34 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 30 Jan 2013 17:03:14 -0500 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0UM3Bfk007353; Wed, 30 Jan 2013 17:03:12 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 30 Jan 2013 17:03:11 -0500 From: "Moriarty, Kathleen" To: Olaf Kolkman , "secdir@ietf.org" Date: Wed, 30 Jan 2013 17:03:10 -0500 Thread-Topic: [secdir] EU Cyber Security Strategy. Thread-Index: Ac39Vcq0A1u5Kb98QIG93zkkljDXsQB3sdog Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F24CE9E25B2MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: IAB IAB , Hannes Tschofenig Subject: Re: [secdir] EU Cyber Security Strategy. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:03:36 -0000 --_000_F5063677821E3B4F81ACFB7905573F24CE9E25B2MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for sending out the information. The IETF working group called M= anaged incident Lightweight Exchange (MILE) has standards that can be used = and referenced in this space. We are just about to begin work on revising = RFC5070 to update the data model to meet current use cases. It would be gr= eat to have their input to ensure their use cases are met as a number of ve= ndors are interested in using international standards to enable information= sharing. If they need to reference ISO or ITU-T standards, there are actually ITU-T = Recommendations that point to several of the key RFCs: x.1540 is reference to RFC5070 x.1580 is a reference to RFC6545 x.1581 is a reference to RFC6546 I am involved in several efforts using the standards and am happy to help w= ith more information or connection points that are possible now or in the f= uture. Best regards, Kathleen From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of= Olaf Kolkman Sent: Monday, January 28, 2013 7:42 AM To: secdir@ietf.org Cc: IAB IAB; Hannes Tschofenig Subject: [secdir] EU Cyber Security Strategy. Folk, This mail is FYI, it may be of business/personal interest to some of you. I have a specific question. Context: MSP for ICT St. You may or may not be aware that the EU has a Multi Stakeholder Platform fo= r ICT standardization. One of the stakeholders at the table is the IETF/IAB= and your truly is, with Hannes Tschofenig as backup, the representative fo= r the IETF/IAB. The platform is chartered to give the Commission advise on all matters stan= dard and to identify standards, developed by fora and consortia, that can b= e used in public procurement (formally RFCs can not be reference in EU proc= urement: when these folk talk about standards they think ISO, ITU, ETSI etc= etc.) Specific: EU Cyber Sec Strat. What is attached is part on the advise on all matters standard aspect. The = document gives a short executive level overview of what the EU intends with= its cyber security strategy. The document is FYI mainly. However I have one particular bit of information that I need. See the secti= on on "Where do standards come in". I do not think there is any relevant IE= TF work in this area (info exchange and such) and would like to get guidanc= e if that is a misunderstanding. The platform is having its 3rd meeting 7 Feb. --_000_F5063677821E3B4F81ACFB7905573F24CE9E25B2MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you= for sending out the information.  The IETF working group called Manag= ed incident Lightweight Exchange (MILE) has standards that can be used and = referenced in this space.  We are just about to begin work on revising= RFC5070 to update the data model to meet current use cases.  It would= be great to have their input to ensure their use cases are met as a number= of vendors are interested in using international standards to enable infor= mation sharing.

 = ;

If they need to reference ISO= or ITU-T standards, there are actually ITU-T Recommendations that point to= several of the key RFCs:

= x.1540  is reference to RFC5070

x.1580 is a reference to RFC6545

x.1581 is a reference to  RFC6546

 

I am involved in several efforts using the standards and am h= appy to help with more information or connection points that are possible n= ow or in the future.

 

Best regards,

Kathleen

 

 

From:<= /b> secd= ir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of Ol= af Kolkman
Sent: Monday, January 28, 2013 7:42 AM
To: s= ecdir@ietf.org
Cc: IAB IAB; Hannes Tschofenig
Subject: = [secdir] EU Cyber Security Strategy.

 

 <= /o:p>

Folk,

 

This= mail is FYI, it may be of business/personal interest to some of you. =

I have a specific question.<= o:p>

 

Context: MSP for ICT St.

<= p class=3DMsoNormal> 

Yo= u may or may not be aware that the EU has a Multi Stakeholder Platform for = ICT standardization. One of the stakeholders at the table is the IETF/IAB a= nd your truly is, with Hannes Tschofenig as backup, the representative for = the IETF/IAB.

 

The platform is chartered to give the= Commission advise on all matters standard and to identify standards, devel= oped by fora and consortia, that can be used in public procurement (formall= y RFCs can not be reference in EU procurement: when these folk talk ab= out standards they think ISO, ITU, ETSI etc etc.)

=

 

<= o:p> 

Specific: EU Cyber Sec = Strat.

 

<= /div>

What is attached is part on the advise on al= l matters standard aspect. The document gives a short executive level overv= iew of what the EU intends with its cyber security strategy. The document i= s FYI mainly.

 

However I have one particular bit of = information that I need. See the section on "Where do standards come i= n". I do not think there is any relevant IETF work in this area (info = exchange and such) and would like to get guidance if that is a misunderstan= ding.

 

 

The platform is having its 3rd meeting 7 Feb.

<= div>

 

 

= --_000_F5063677821E3B4F81ACFB7905573F24CE9E25B2MX15Acorpemccom_-- From jsalowey@cisco.com Wed Jan 30 21:26:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB39E21F86B6; Wed, 30 Jan 2013 21:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zxTjZ8VII54; Wed, 30 Jan 2013 21:26:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DF10C21F86B3; Wed, 30 Jan 2013 21:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=616; q=dns/txt; s=iport; t=1359610007; x=1360819607; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MwQZ4HtfLK+7iwChK8XkYQTWQNu0pNQ71DpIf0QhK3I=; b=coCr6A9EwhfJt8wrV2jOF7W30a3drfc8jRnaYiAkKxg87PKpj2zxiN0q 093hpXLpcgwINp3766S6jSXStl3JNGbrtQc/Q4VGfTc5bllTnKdR1wmdK ytxR8ZtfBVeRsTDEuTVV9uHaya1T7fOCk8vev8uTyLCBgWPruuiR/hFxm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMv/CVGtJV2d/2dsb2JhbABFvyAWc4IgAQQ6UQEqFEInBAEaiAnBdZArYQOmWIJ3giQ X-IronPort-AV: E=Sophos;i="4.84,574,1355097600"; d="scan'208";a="170901442" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jan 2013 05:26:46 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r0V5Qkbj005873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 05:26:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 23:26:46 -0600 From: "Joseph Salowey (jsalowey)" To: "secdir@ietf.org" , The IESG , "draft-ietf-storm-iscsimib.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-storm-iscsimib-03 Thread-Index: AQHN/3OP19Gx39ZRhkmgq0bp5Gbt/g== Date: Thu, 31 Jan 2013 05:26:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <051EEDC1C1CD694CB3B8B752267F29E3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-ietf-storm-iscsimib-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 05:26:49 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I found that the security considerations section had the appropriate inform= ation for SNMP MIBs and pointed out the specific objects that are most sens= itive of modification and disclosure. I think the document is ready for p= ublication. =20 Cheers, Joe From kivinen@iki.fi Thu Jan 31 02:37:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C621F85ED; Thu, 31 Jan 2013 02:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVWD-Z-Hm0Tq; Thu, 31 Jan 2013 02:37:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5CD21F8619; Thu, 31 Jan 2013 02:37:49 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0VAbdoL023340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 12:37:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0VAbc5q013624; Thu, 31 Jan 2013 12:37:38 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20746.18802.364266.587982@fireball.kivinen.iki.fi> Date: Thu, 31 Jan 2013 12:37:38 +0200 From: Tero Kivinen To: Michael Tuexen In-Reply-To: <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> References: <20718.54159.713629.567812@fireball.kivinen.iki.fi> <8D58A3AD-A276-4AA6-B454-E3D07AB7C90A@fh-muenster.de> <20743.57390.456600.844778@fireball.kivinen.iki.fi> <2D128C1C-ADE8-43CB-990C-56CB7E0C327C@fh-muenster.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 32 min X-Total-Time: 38 min Cc: draft-ietf-tsvwg-sctp-udp-encaps.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tsvwg-sctp-udp-encaps-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:37:52 -0000 Michael Tuexen writes: > > It might be good to say that in the document, i.e. that it is out of > > scope of this document. > > What about adding > Please note that this document does not provide all techniques necessary > for building a complete NAT-capable application using SCTP. This document > focuses on the functionality required within the SCTP stack and making > this available via an API. > to the Abstract? I think it would be better to add more explicit notice what is left outside of the scope. > >>> Also what if host A and B already have one SCTP connection, and now > >>> host B wants to create another, do host B reuse the same UDP > >>> destination port number for host A that was used for the already > >>> existing SCTP connection between them? The section 4.1 says that UDP > >>> port numbers are stored per destination address per SCTP association, > >>> so that would indicate no. > >> > >> As stated in the document, each stack uses a single port number > >> as the destination address of all incoming packets. > > > > The document also says: > > > > Using a single UDP encapsulation port number per host is not > > possible if the SCTP stack is implemented as part of an > > application. > > > > which indicates that using multiple UDP port numbers is also an > > option. Or is implementing SCTP stack as appliction out of scope too? > > Section 3.1 seems to indicate that it is not out of scope. > > No, you can implement SCTP in the kernel (which means that the stack > is unique on the host) or in the application (which means there > can me multiple, one stack per association for example). That was my understanding, and thats why it was bit odd to see text that says that you have one UDP port only, and it is not possible to do that if SCTP stack is in the application. This seems to give bit mixed signals what is supported and what is not. > > From the section 3.1 and 4.1 it is not really clear what needs to be > > supported. If I have understood correctly that if SCTP is implemented > > in kernel then we use one UDP port for the whole host, but if SCTP is > > implemented by the application then each application might have > > different UDP port, i.e. there will be multiple UDP SCTP encapsulation > > ports in the host. > Correct. > > > > I.e. if host A is connected to two different applications on host B. > > Host B is such host that it does not support SCTP on kernel, the SCTP > > is implemented on the application itself, and that means each > > application has separate UDP encapsulation port. Now what you said > > before I assume that it is outside the scope of this document for host > > A know how to connect to host B, i.e. how to get the UDP port numbers > > where to connect, and also whether to use the UDP encapsulation at > > all? > Correct. Finding the remote UDP number for the initial packets is > out of scope. Which is again one thing that should be explictly mentioned. It makes hard to understand what this document is for, as you would expect this kind of things to be solved here, or at least pointed to a pointer telling where they are solved, but this document is silent about the issue. > > Is there any work ongoing on this? I.e. how is this going to be solved > > in practice? Or is it assumed that the SCTP applications which do not > > have direct access to IP-layer, which need to use UDP encapsulation > > because of that, are always only initiators, i.e. nobody ever connects > > to them, they always initiate the connection to the known services? > As said above, a complete solution is out of scope of this document. That is fine, but it should mention what is out of scope. > >>> In some cases also the IP-address might change, > >>> i.e. if the NAT box is rebooted or its connection table is cleared, > >>> and the NAT box have multiple IP-addresses, it is completly possible > >>> that the NAT mapping changes so that IP-address and UDP port number > >>> both change. I am not familiar enough with SCTP to know whether this > >>> causes problem with SCTP, i.e. whether it is default SCTP rules to use > >>> the last seen IP-address when sending reply or what. > >> > >> The method described in the document does NOT cover changing the > >> address. If you want to handle that, you need to use the address > >> reconfiguration extension (RFC 5061). > > > > Then you need to say that in the draft. Note, that hosts A and B do > > It is mentioned in the last paragraph of section 4.7 I would be very suprised if someone can really combine RFC5061 and this document to get interoperable implementation with just that one reference, in the cases where the NAT box is rebooted and the outer IP-addresses change because of that. > > not have any way of knowing when the IP-address changes, or whether it > > is going to change. For normal TCP (and most likely also SCTP) this > > Well, that depends. No, it really does not. We are not talking about local IP address changes, we are talking the NAT box rebooting and loosing state, and allocating new IP address for the UDP encapsulated SCTP packets. The local host does not know anything about that. > If the address change is local on the host, SCTP kernel implementations (at > least FreeBSD and Linux) will get notified when addresses are added or > removed. For example, on FreeBSD you can add an address using > ifconfig and the address changes will happen on all association which use > a wildcard bound SCTP socket, it is allowed system-wide via the > net.inet.sctp.auto_asconf sysctl and the application didn't disabled > it via the SCTP_AUTO_ASCONF socket option. We are not talking about local changes. > On the other hand, if the address change is not local, the peer will > respond to a packet with an ABORT chunk having the T-bit set. This > could be interpreted as an indication of an address change. Ok, so this is already handled in the SCTP internally, i.e. remote node notices that other end changed IP-address and indicates that to the other end. Mentioning this in the draft would most likely help for implementors to understand what they need to do in this cases. NAT boxes loosing state is something that should be explained in the draft, as that is quite common situation and if this is supposed to work on environments where there are NATs, then what happens when NAT box looses state should be explained. > > IP-address change will usually result the connection to be reset, as > > the NAT box does not have the mapping for the connection anymore, but > > for UDP that does not happen. The NAT box will just create new > > mapping. > Which is fine. > > > > I.e. the situation is as follows. Host A is behind NAT, and talks to > > host B using UDP encapsulated SCTP. Now the NAT box is rebooted, and > > it looses state. When Host A sends next UDP encapsulated SCTP packet > > to Host B that UDP packet might get new source IP address by the NAT > > box. What should happen at that point? > As described above, host B will respond with an ABORT chunk and host A > can use this as an indication that it has to update its address. > So it can send a ASCONF chunk adding the wildcard address and removing > the wildcard address which will result in the possibility to continue > the association. Adding section explaining the thing above would most likely help to understand that this issue needs to be handled in the implementations. This for example makes it quite clear that using udp encapsulation through NAT without supporting RFC 5061 is just not going to work. > > Should the SCTP implementation notice that IP-address of the > > association has changed, and send some kind of reset or what? Or does > > the SCTP implementation just drop all packets because they do not > > match association and then connection is dropped after timeout? > > > > How do you plan to use RFC 5061 to solve that situation? I do not know > > enough of RFC 5061 to say how it can be used to solve this kind of > > situation, where the peer A whose IP-address was changed does not even > > know that his IP-address was changed. > I hope the above makes it clearer. We can add at the end of section 4.7 > text like: > > If an SCTP end-point receives an ABORT with the T-bit set, it MAY > use this as an indication that the addresses seen by the peer might > have changed. I would like think it would be better to add new section explaining how this is supposed to interact with NAT boxes loosing state. I.e. the text what you explained above to me. Until now I had only assumed that if I would be implementing that, I do not need to care about RFC5061 unless I want to support IP-addresses changing. After your explination it is clear that all implementations who want to work through NATs do need to support it. > > Of course as the NAT mappings are usually remote IP + remote port + > > protocol + NAT IP + NAT port, this means that changes for host C to > > get exactly same 5-tuple are small... On the other hand host C can > > most likely know remote IP and remote port as they are well known > > based on the service. The NAT IP is most likely going to be same all > > the time, so only thing host C needs to be doing is to cause NAT to > > loose state (i.e. cause it to either reboot, or run out of mappings), > > and then start filling up the NAT mappings until it gets the NAT port > > host A used earlier. > > > > One way to cause NAT to loose state, is to start flooding NAT with new > > UDP packets each destinationed to remote host + port and having > > UDP different source port. NAT will allocate new NAT port for each of > > them until it runs out of port numbers, in which case it starts > > reusing port numbers. Now depending on the NAT implementation, flood > > guarding, SCTP heartbeat intervals etc NAT might reuse the host A's > > port in which case host C managed to get the session. > > Yes, that is possible. What can the attacker do? The attacker can't > insert any DATA or SACK chunks, since it would have to guess the > V-tag. However, the attacker can ABORT the association with sending > an ABORT with the V-tag set. But this is not better or worse than > attacking the NAT box. So most likely the attacker can receive an > RWND of user data. If sent unprotected, I would assume that his is > acceptable. Using DTLS/SCTP would protect against it. It can do exactly same things it can do in the other case where the IP address got reused. It will receive all packets that were supposed to be received by original host A, so it can see all traffic going to host A. As there is no cryptographic checksums there, it can add data to the packets it receive and might send them to host A depending on the network layout. At least as far as I know. > > Which ways those HEARTBEAT messages are sent? For NAT mappings to stay > > alive, the messages quite often needs to be coming from inside of the > > NAT, i.e. from the host which is behind the NAT, and if both ends are > > behind NAT, they need to be coming from both ends. Do HEARTBEATs cover > > that possibility. Also some NAT boxes are known to require as small > > keepalive intervals as 20 seconds... How often do you send HEARTBEATS? > Both sides send HEARTBEATs, the standard time between them is 30 seconds > plus RTO plus/minus 50%. However, the application can change the 30 seconds > to other values using the standard socket API. Ok, so that is ok. > > So is having both ends behind NAT out of scope? This should then be > > mentioned in section 3.2. Note, that similar problems also arise when > > you need to connect to host which is behind NAT, i.e. even if it is > > only one host behind NAT, but if the connection is coming from the > > outside, you have similar problems than what you have when both ends > > are behind NAT. > > I think the point is that finding the remote port number for initial > packets is out of scope of the this document. The dynamic port fixup is UNSAF operation, already described in the draft. The use if RFC5061 with wildcard addresses is similar operation. Both of those are solutions which get around the fact that peers do not know the actual addresses, i.e. are trying to "determine or fix the addresses by which it is known to another endpoint". UNSAF operations are not only the cases where you try to find out the initial address, it covers also all cases where the protocol tries to fix things caused by NATs. From RFC3424: o proposed workarounds include the use of "ping"-like address discovery requests sent from the UNSAF client (initiator) to the UNSAF server (listener), to which the listener responds with the transport address of the initiator - in the address realm of the listener. However, with connection-less transports, e.g. UDP, IPsec ESP, etc., an UNSAF process must take care to react to changes in NAT bindings for a given application flow, since it may change unpredictably. just covers this loosing NAT bindings and the: o limiting the scope to outbound requests for service (or service initiation) in order to prevent unacceptable security exposures. Is just what this document does, i.e. limits the scope so that only outbound ocnnections are allowed or similar constraints, but does not mention what those constraints are. What you are trying to say is that UNSAF considerations do not apply as you have scoped them out, but that is exactly one UNSAF consideration. In real world case those problems do need to be solved, and this document is not really that useful if it cannot be used in real world... -- kivinen@iki.fi From kivinen@iki.fi Thu Jan 31 02:50:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8802D21F851E for ; Thu, 31 Jan 2013 02:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExCwTwl9GE6T for ; Thu, 31 Jan 2013 02:50:38 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41FE21F86BE for ; Thu, 31 Jan 2013 02:50:37 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r0VAnHSO016926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Jan 2013 12:49:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r0VAnHOU002518; Thu, 31 Jan 2013 12:49:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20746.19501.325505.840149@fireball.kivinen.iki.fi> Date: Thu, 31 Jan 2013 12:49:17 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:50:39 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Rob Austein is next in the rotation. For telechat 2013-02-07 Reviewer LC end Draft Shawn Emery TR2012-12-24 draft-ietf-oauth-assertions-10 Phillip Hallam-Baker T 2013-01-03 draft-ietf-roll-p2p-rpl-15 Tero Kivinen TR2013-01-22 draft-ietf-tsvwg-sctp-udp-encaps-09 Julien Laganier T 2013-01-21 draft-ietf-ccamp-lmp-behavior-negotiation-10 Matt Lepinski T 2013-01-25 draft-ietf-radext-radius-extensions-09 Chris Lonvick TR2012-06-14 draft-ietf-geopriv-dhcp-lbyr-uri-option-17 Alexey Melnikov T 2013-01-21 draft-ietf-roll-p2p-measurement-08 Yaron Sheffer T 2013-01-31 draft-ietf-rtgwg-ipfrr-notvia-addresses-10 Ondrej Sury T 2013-01-31 draft-ietf-rtgwg-ordered-fib-08 Brian Weis TR2013-02-07 draft-ietf-sidr-algorithm-agility-11 For telechat 2013-02-21 Hilarie Orman T 2013-02-11 draft-leiba-urnbis-ietf-namespace-01 Tina TSOU T 2013-02-14 draft-gp-obsolete-icmp-types-iana-01 Carl Wallace T 2013-02-05 draft-ietf-behave-nat64-discovery-heuristic-13 David Waltermire T 2013-02-20 draft-shafranovich-mime-sql-03 Last calls and special requests: Derek Atkins 2013-02-11 draft-ietf-forces-lfb-lib-10 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-08 Kathleen Moriarty 2013-02-08 draft-farrell-ft-03 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Sandy Murphy 2013-01-29 draft-ietf-6man-nd-extension-headers-03 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-01 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-03 Vincent Roca 2013-01-25 draft-ietf-eman-rfc4133bis-05 Sam Weiler 2013-02-01 draft-ietf-mmusic-sdp-cs-17 Brian Weis 2013-02-06 draft-ietf-mpls-tp-security-framework-07 Klaas Wierenga 2013-02-01 draft-ietf-xrblock-rtcp-xr-summary-stat-06 Nico Williams - draft-ietf-httpbis-p5-range-21 Nico Williams 2013-02-18 draft-templin-ironbis-12 Tom Yu 2013-02-11 draft-ietf-ospf-rfc3137bis-03 Glen Zorn 2012-06-27 draft-hoffman-tao4677bis-16 Glen Zorn 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-06 -- kivinen@iki.fi From yaronf.ietf@gmail.com Thu Jan 31 09:43:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E0B21F86EA; Thu, 31 Jan 2013 09:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf3A8bW5U3nn; Thu, 31 Jan 2013 09:43:05 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id CDE4121F87AB; Thu, 31 Jan 2013 09:43:04 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so1606187eek.15 for ; Thu, 31 Jan 2013 09:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SQWqWx6hmUqKqOb8wJOc3JR4+N6HSAIfFc0qpKwtz+U=; b=Cb0KqyVa+cubhNea11DblsvEhvsVe5rHygTR/RLceojq55QxRDLHD81HPI9CoW7DdQ oTonWtawctRdL2muD4ZxcLtQh55XnXntpiHh5/70LA9IYO2gEWWhUHYLlRx59QvY6UUv 4CIoaPhXqn2YdXtL3gooxUD859PZOyMoo9ajm8bcOoI9q6DvS5tVabQAR72LLbVx8/Pm 966Jlo0TjR15ARVlssFg/9vB9M4qL9Cc+fpj/d9wDhtr6gwgpLK1TpJ7RahDyM16YiBc fH6m0CQ3IcSGeM56FC0S5TAdwoALgWtKzsn0C0N5niKJMJjCU72sPVzd2eDsmIqyM6Jz 9g0g== X-Received: by 10.14.4.194 with SMTP id 42mr29633836eej.35.1359654183988; Thu, 31 Jan 2013 09:43:03 -0800 (PST) Received: from [10.0.0.5] ([109.67.127.19]) by mx.google.com with ESMTPS id 44sm8451184eek.5.2013.01.31.09.43.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 09:43:02 -0800 (PST) Message-ID: <510AAD22.1010601@gmail.com> Date: Thu, 31 Jan 2013 19:42:58 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF Security Directorate , draft-ietf-rtgwg-ipfrr-notvia-addresses.all@tools.ietf.org, The IESG References: <4FBFAE5F.8010305@gmail.com> In-Reply-To: <4FBFAE5F.8010305@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-rtgwg-ipfrr-notvia-addresses-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:43:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a method to protect a network from router/link failures by encapsulating packets in an envelope that denotes what nodes it should *not* be routed through. This is not a protocol definition (despite a few stray MUSTs), it is only an informational summary of design issues and a framework. Summary The document is good to go. In fact, a SecDir review is not applicable. Details The document does contain a Security Considerations section that goes through 3 potential security issues. But since the document in general is a high-level discussion, it is impossible to analyze whether all pertinent security issues are covered. If the not-via mechanism is ever specified as a protocol, the security analysis will need to be done from scratch. Thanks, Yaron From derek@ihtfp.com Thu Jan 31 14:04:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505BD21F8C2A; Thu, 31 Jan 2013 14:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhNib-BHozVN; Thu, 31 Jan 2013 14:04:12 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id F176F21F8440; Thu, 31 Jan 2013 14:04:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 37FDA260239; Thu, 31 Jan 2013 17:04:11 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 11270-04; Thu, 31 Jan 2013 17:04:09 -0500 (EST) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 3C89E260023; Thu, 31 Jan 2013 17:04:09 -0500 (EST) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id r0VM3xoh006128; Thu, 31 Jan 2013 17:03:59 -0500 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 31 Jan 2013 17:03:58 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: ogawa.kentaro@lab.ntt.co.jp, chuanhuang_li@zjsu.edu.cn, ehalep@ece.upatras.gr, forces-chairs@tools.ietf.org, wmwang@zjsu.edu.cn, joel.halpern@ericsson.com Subject: [secdir] sec-dir review of draft-ietf-forces-lfb-lib-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 22:04:15 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. The Security Considerations section offloads itself to RFC3746. It is unclear to me if any of the new functions defined in the LFB need any additional authentication or authorization, and if so I do not see how that would be added. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From kathleen.moriarty@emc.com Thu Jan 31 18:35:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4447421F856D for ; Thu, 31 Jan 2013 18:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=1.329, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viiUxde4jVED for ; Thu, 31 Jan 2013 18:35:58 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 46ED421F8480 for ; Thu, 31 Jan 2013 18:35:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r112ZsEe018556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jan 2013 21:35:54 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 31 Jan 2013 21:35:34 -0500 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r112ZXlF018823; Thu, 31 Jan 2013 21:35:33 -0500 Received: from mxhub38.corp.emc.com (128.222.70.105) by mxhub16.corp.emc.com (128.222.70.237) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 Jan 2013 21:35:33 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Thu, 31 Jan 2013 21:35:33 -0500 From: "Moriarty, Kathleen" To: "iesg@ietg.org" , "secdir@ietf.org" , "draft-farrell-ft.all@tools.ietf.org" Date: Thu, 31 Jan 2013 21:34:15 -0500 Thread-Topic: SecDir review of draft-farrell-ft-03 Thread-Index: AQHOACSgBSbJvNzxgEuAal4Y5/4w5Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [secdir] SecDir review of draft-farrell-ft-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 02:35:59 -0000 Hi, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. Summary: =20 This memo describes an optional, fast-track way to progress a working group document to IESG review. It is provided as a process experiment as defined in RFC 3933 for use when working group chairs believe that there is running code that implements a working group Internet-Draft. Review: I think the draft is well written and just see one nit and one security loo= p hole that should be addressed or noted as such in the security considerat= ions section. Nit: Can you clarify if in Section 3, step #7, "some" AD is from that area = or from any area? I think you mean any AD, but would think this would be a= requirement from the Area of the WG. Consideration: I don't agree with the document going forward unless one of = the Area ADs has looked at the document. If this were in my WG, I would co= ordinate the two week period with the AD on a time frame that will be possi= ble for them to perform the review. Sometimes a few days makes a differenc= e. I think changing #3 of step 4 to require coordination could prevent the pro= blem of scheduling during a period that will not work for an AD. This is a= loop hole if the time period is not coordinated. I could have gotten a lo= t of documents through during Sean's honeymoon if I wanted to (if he actual= ly went offline ;-) ). This is the one loop hole I see as important to add to the security conside= rations if it is not changed. Best regards, Kathleen=