From internet-drafts@ietf.org Tue Jan 3 08:32:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADDC21F84A9; Tue, 3 Jan 2012 08:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSzQRxHmyf4X; Tue, 3 Jan 2012 08:32:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2801E21F847A; Tue, 3 Jan 2012 08:32:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103163224.2370.61840.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 08:32:24 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:32:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-04.txt Pages : 63 Date : 2012-01-02 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-04.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-04.t= xt From radext-bounces@ietf.org Tue Jan 3 08:32:27 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4258311E8079; Tue, 3 Jan 2012 08:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325608347; bh=RFfg/klhy2xJG9+LNbgRdOxW6rct4qKSx0WHeQbhzVU=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=AH6xOnIaNZvL0F5rdAJYlQjLYZb8qcJhzEW1JS/KYFbINNE0IgU/rq57vtUOUYj3v vmAYkabQ/xIdQloS3eld2vfOm0L5yI6Zfs5dyeYQciPkbY0InnB91v7BKoKKBlb827 BfoYWXSlwK+Mf3yTjfzQj7WXM/tszBFlowGibKLQ= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADDC21F84A9; Tue, 3 Jan 2012 08:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSzQRxHmyf4X; Tue, 3 Jan 2012 08:32:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2801E21F847A; Tue, 3 Jan 2012 08:32:24 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120103163224.2370.61840.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2012 08:32:24 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Remote Authentication Dial In User Service (RADIUS) Protocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-04.txt Pages : 63 Date : 2012-01-02 The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radius-extensions-04.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Jan 3 08:43:27 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3421F8539 for ; Tue, 3 Jan 2012 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eaksu-OYZRSi for ; Tue, 3 Jan 2012 08:43:27 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D82A621F8504 for ; Tue, 3 Jan 2012 08:43:26 -0800 (PST) Message-ID: <4F033012.6050103@deployingradius.com> Date: Tue, 03 Jan 2012 11:42:58 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20120103163224.2370.61840.idtracker@ietfa.amsl.com> In-Reply-To: <20120103163224.2370.61840.idtracker@ietfa.amsl.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-extensions-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:43:27 -0000 A diff is at: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-radext-radius-extensions-04.txt The diff is a little confused by the addition of Section 2.7. Major changes are to Section 6 (Guidelines), and Section 9 (IANA considerations) Alan DeKok. From radext-bounces@ietf.org Tue Jan 3 08:43:28 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A547A21F8539; Tue, 3 Jan 2012 08:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325609008; bh=rn7/NEW1y7Y093ZeRarj/cHW8yRvNE6bt4rQtlxkNWY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mQldX9sSCvVBTZ8kKA8Lzo6Be14JHEY+6sSAdG0hvVToV8rNp9HxsClMk+nC5Td3w dnL2yWFzy4K4j/yyKNHbVJl1ndNgv1hQpyZfOLiTDEZcgCtrg5N18uvnT6JWKS+cnI Ca+qdA3L2LcbNRmacaIGTeVxsE0P3kM7ABqSrDUw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3421F8539 for ; Tue, 3 Jan 2012 08:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=0.870, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eaksu-OYZRSi for ; Tue, 3 Jan 2012 08:43:27 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D82A621F8504 for ; Tue, 3 Jan 2012 08:43:26 -0800 (PST) Message-ID: <4F033012.6050103@deployingradius.com> Date: Tue, 03 Jan 2012 11:42:58 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: radext@ietf.org References: <20120103163224.2370.61840.idtracker@ietfa.amsl.com> In-Reply-To: <20120103163224.2370.61840.idtracker@ietfa.amsl.com> X-Enigmail-Version: 0.96.0 Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-extensions-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A diff is at: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-radext-radius-extensions-04.txt The diff is a little confused by the addition of Section 2.7. Major changes are to Section 6 (Guidelines), and Section 9 (IANA considerations) Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Wed Jan 4 01:34:05 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF25B21F86E0 for ; Wed, 4 Jan 2012 01:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tFM5C-AjCsu for ; Wed, 4 Jan 2012 01:34:05 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4E21F86DC for ; Wed, 4 Jan 2012 01:34:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 8B8F05D4C5 for ; Wed, 4 Jan 2012 10:34:03 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZL0ARHEMbhRp for ; Wed, 4 Jan 2012 10:34:03 +0100 (CET) Received: from [192.168.1.130] (165.247.221.87.dynamic.jazztel.es [87.221.247.165]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 07E915D480 for ; Wed, 4 Jan 2012 10:34:01 +0100 (CET) Message-ID: <4F041D09.2060905@um.es> Date: Wed, 04 Jan 2012 10:34:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> In-Reply-To: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020206010606020307070708" Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:34:05 -0000 This is a multi-part message in MIME format. --------------020206010606020307070708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB, thus a mechanism to fragment them is required. -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Fecha: Wed, 04 Jan 2012 01:21:53 -0800 De: internet-drafts@ietf.org Para: alex@um.es A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 00 Title: Fragmentation support across RADIUS packets Creation date: 2012-01-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes a mechanism providing fragmentation support of RADIUS attributes across several RADIUS packets. This is intended to support attributes that exceed the 4 KB limit per RADIUS packet. The IETF Secretariat --------------020206010606020307070708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.

This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB, thus a mechanism to fragment them is required.

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed, 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 

A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                                  


The IETF Secretariat
--------------020206010606020307070708-- From radext-bounces@ietf.org Wed Jan 4 01:34:06 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33B21F86E0; Wed, 4 Jan 2012 01:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325669646; bh=cfER0JZljU2+YDgBaFnlYiLlUA83kPKz9WWZs39W8yY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=uCO2cETLCcwMJWGX7OCQuSFebzx3LqqUYR8Vgm9EIiJxjZUw9+JGb0T8H/Qm5Zjqj Lz4MMKe3IxhMIXUCF7S4x0Ak9Y3aLXdZsnxf7ihBsE14bOrXpc5ZFSreAEGZE6PLpX dK6W+OTjvddyIBFv0bCxMyz06TJzojnFDdyFjAKw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF25B21F86E0 for ; Wed, 4 Jan 2012 01:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tFM5C-AjCsu for ; Wed, 4 Jan 2012 01:34:05 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4E21F86DC for ; Wed, 4 Jan 2012 01:34:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 8B8F05D4C5 for ; Wed, 4 Jan 2012 10:34:03 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZL0ARHEMbhRp for ; Wed, 4 Jan 2012 10:34:03 +0100 (CET) Received: from [192.168.1.130] (165.247.221.87.dynamic.jazztel.es [87.221.247.165]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 07E915D480 for ; Wed, 4 Jan 2012 10:34:01 +0100 (CET) Message-ID: <4F041D09.2060905@um.es> Date: Wed, 04 Jan 2012 10:34:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> In-Reply-To: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1288536531841092057==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============1288536531841092057== Content-Type: multipart/alternative; boundary="------------020206010606020307070708" This is a multi-part message in MIME format. --------------020206010606020307070708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI. This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB, thus a mechanism to fragment them is required. -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Fecha: Wed, 04 Jan 2012 01:21:53 -0800 De: internet-drafts@ietf.org Para: alex@um.es A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 00 Title: Fragmentation support across RADIUS packets Creation date: 2012-01-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes a mechanism providing fragmentation support of RADIUS attributes across several RADIUS packets. This is intended to support attributes that exceed the 4 KB limit per RADIUS packet. The IETF Secretariat --------------020206010606020307070708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI.

This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB, thus a mechanism to fragment them is required.

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed, 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 

A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                                  


The IETF Secretariat
--------------020206010606020307070708-- --===============1288536531841092057== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1288536531841092057==-- From aland@deployingradius.com Wed Jan 4 06:19:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92421F876F; Wed, 4 Jan 2012 06:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.874 X-Spam-Level: X-Spam-Status: No, score=-101.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3EnszwjXE0T; Wed, 4 Jan 2012 06:19:45 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7422821F875D; Wed, 4 Jan 2012 06:19:45 -0800 (PST) Message-ID: <4F045FE2.8070804@deployingradius.com> Date: Wed, 04 Jan 2012 09:19:14 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> In-Reply-To: <4F041D09.2060905@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, "abfab@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 14:19:46 -0000 Alejandro Perez Mendez wrote: > This motivation of this document comes from the necessity in the ABFAB > WG of sending SAML Messages transported into RADIUS attributes. These > SAML Messages can potentially be bigger than 4 KB, thus a mechanism to > fragment them is required. My $0.02 after a quick read, this stood out: --- Chunked-Attribute attribute. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBA) | Length | Ext-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total-Attribute-Length | Start-Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Ext-Type Type of the attribute that is being chunked. This field is encoded as an Ext-Type value, as described in [I-D.ietf-radext-extended-attributes], to be compatible with extended attributes. ---- That won't work. The type/ext-type is used to uniquely identify an attribute. As the RFC6158 says, the interpretation of the attribute is based solely on the type code(s). What you're doing above is changing the meaning of the attribute based on its length. That's difficult, if not impossible, to do correctly. Attributes can also occur multiple times in a packet, with different values. e.g. Proxy-State. The chunked encoding method should support that, too. Perhaps another solution would be to leverage the "flags" field. If a particular bit is 1, then the attribute contains 4 32-bit fields immediately after the "flags" field: identifier for this attribute. Allows multi-values total length of the fragments with "identifier" start as per above end as per above If this document is published soon after the extensions document, then it has a better likelihood of being implemented. Alan DeKok. From radext-bounces@ietf.org Wed Jan 4 06:19:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E796221F876F; Wed, 4 Jan 2012 06:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325686787; bh=N/q9d5n1EPXwpkiGZRed7Wzi0XlrGYh0+qv7rLSweVM=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hWz3aaOQMkSdMyl1k9bpPml2oJPgeh9z5PJM9J5/Y2Y5JuPhFOkabld4P3TlxZtGd pQ/hSHfXKVtDdeekFdNg6QNZzFMlW/0+8eFAwu1OVOc8VAf6CrNUxa8jLRcWe7avqx TTLdHJR0OAcfp+Z6gq+1fCL6OmccAE88btZWO1x8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92421F876F; Wed, 4 Jan 2012 06:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.874 X-Spam-Level: X-Spam-Status: No, score=-101.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3EnszwjXE0T; Wed, 4 Jan 2012 06:19:45 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7422821F875D; Wed, 4 Jan 2012 06:19:45 -0800 (PST) Message-ID: <4F045FE2.8070804@deployingradius.com> Date: Wed, 04 Jan 2012 09:19:14 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> In-Reply-To: <4F041D09.2060905@um.es> X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, "abfab@ietf.org" Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alejandro Perez Mendez wrote: > This motivation of this document comes from the necessity in the ABFAB > WG of sending SAML Messages transported into RADIUS attributes. These > SAML Messages can potentially be bigger than 4 KB, thus a mechanism to > fragment them is required. My $0.02 after a quick read, this stood out: --- Chunked-Attribute attribute. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBA) | Length | Ext-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total-Attribute-Length | Start-Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-Position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Ext-Type Type of the attribute that is being chunked. This field is encoded as an Ext-Type value, as described in [I-D.ietf-radext-extended-attributes], to be compatible with extended attributes. ---- That won't work. The type/ext-type is used to uniquely identify an attribute. As the RFC6158 says, the interpretation of the attribute is based solely on the type code(s). What you're doing above is changing the meaning of the attribute based on its length. That's difficult, if not impossible, to do correctly. Attributes can also occur multiple times in a packet, with different values. e.g. Proxy-State. The chunked encoding method should support that, too. Perhaps another solution would be to leverage the "flags" field. If a particular bit is 1, then the attribute contains 4 32-bit fields immediately after the "flags" field: identifier for this attribute. Allows multi-values total length of the fragments with "identifier" start as per above end as per above If this document is published soon after the extensions document, then it has a better likelihood of being implemented. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From diego@tid.es Wed Jan 4 10:21:09 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D777411E807A; Wed, 4 Jan 2012 10:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZTqNF0XRIij; Wed, 4 Jan 2012 10:21:08 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5362221F86AE; Wed, 4 Jan 2012 10:21:07 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXA000LVDN5RJ@tid.hi.inet>; Wed, 04 Jan 2012 19:21:05 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 69.D1.02643.198940F4; Wed, 04 Jan 2012 19:21:05 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXA000LQDN4RJ@tid.hi.inet>; Wed, 04 Jan 2012 19:21:05 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Wed, 04 Jan 2012 19:21:04 +0100 Date: Wed, 04 Jan 2012 19:21:02 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F045FE2.8070804@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczLDZ68FEBzPaJTQLyqwDFJVlqgrg== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-07-4f049891004f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXCFe9nqDtxBou/wYFjwhYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZt75fZSvYIlXRdeQZYwPjHckuRk4OCQETiT8/H7NA 2GISF+6tZ+ti5OIQEtjGKHH/8Qso5ymjxOKLH1ghnEZGiQ0z7jB1MXJwsAioSiw/GwHSzSag LtFy9BvYJGGBZIm7/7exgdicAsYSPz89YAWxRQS0JBasX8QC0sosUCgx9YIOSJhXwFLi+JoV bBC2oMSPyfegStQlpkzJBQkzC4hLNLfeZIGwFSWmLWpgBLEZgW7+fmoNE8T0FIlNd+axQdh6 ErO+LoOqEZW4076eEeJHAYkle84zQ9iiEi8f/4P6qolRYvnOvawTGMVnITljFsIZs5CcMQvJ GQsYWVYxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREU+YOxuU7VQ4xCnAwKvHwerxj9Bdi TSwrrsw9xCjJwaQkysvTx+IvxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3VTtQjjclsbIqtSgf JiXDwaEkwftkOlBKsCg1PbUiLTMHmDJg0kwcnCDtPEDtD0FqeIsLEnOLM9Mh8qcYJaXEeTeD JARAEhmleXC9rxjFgY4U5l0CkuUBJje4rldAA5mABkaJgA0sSURISTUwLjsl1JC0+Nop246H es+mPs8I2ja55kr/I+avPhxsH25svu7hcFKJO0g38JftusnfTON79NiZ/xnsKNzJ2XrzfPlk tYnM91d0bPjkcPT74kbxY3rrZ6zbfDPevIVT+LaHpdZ3V5FPj3wDPsjPTvXjkVJ4VBYTMIE/ rbhs8f+84yYuJV8M5x/XUGIpzkg01GIuKk4EAAhEcjQrAwAA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:21:10 -0000 SGkgQWxhbiwNCg0KT24gNCBKYW4gMjAxMiwgYXQgMTU6MTkgLCBBbGFuIERlS29rIHdyb3RlOg0K PiAgVGhhdCB3b24ndCB3b3JrLiAgVGhlIHR5cGUvZXh0LXR5cGUgaXMgdXNlZCB0byB1bmlxdWVs eSBpZGVudGlmeSBhbg0KPiBhdHRyaWJ1dGUuICBBcyB0aGUgUkZDNjE1OCBzYXlzLCB0aGUgaW50 ZXJwcmV0YXRpb24gb2YgdGhlIGF0dHJpYnV0ZSBpcw0KPiBiYXNlZCBzb2xlbHkgb24gdGhlIHR5 cGUgY29kZShzKS4gIFdoYXQgeW91J3JlIGRvaW5nIGFib3ZlIGlzIGNoYW5naW5nDQo+IHRoZSBt ZWFuaW5nIG9mIHRoZSBhdHRyaWJ1dGUgYmFzZWQgb24gaXRzIGxlbmd0aC4NCj4NCj4gIFRoYXQn cyBkaWZmaWN1bHQsIGlmIG5vdCBpbXBvc3NpYmxlLCB0byBkbyBjb3JyZWN0bHkuDQoNCkknbSBh ZnJhaWQgdGhlcmUgaXMgYSBtaXN1bmRlcnN0YW5kaW5nLiBUaGUgQ2h1bmtlZC1BdHJyaWJ1dGUg aXMgYW4gYXR0cmlidXRlIG9uIGl0cyBvd24gdGhhdCBjb250YWlucyBvbmx5IGEgcmVmZXJlbmNl IHRvIHRoZSBhdHRyaWJ1dGUgYmVpbmcgY2h1bmtlZC4gSXQgaGFzIHRvIGFwcGVhciBpbiBhbGwg dGhlIHBhY2tldHMgY29udGFpbmluZyBjaHVua3Mgb2YgYXR0cmlidXRlcywgYXMgbWFueSBhcyBh dHRyaWJ1dGVzIHRoZXkgcmVmZXIgdG8uIENodW5rcyBhcmUgaW50ZW5kZWQgdG8gYmUgZW5jb2Rl ZCBmb2xsb3dpbmcgdGhlIHVzdWFsIGVuY29kaW5nIG1ldGhvZHMuDQoNCkl0IGlzIHRydWUgdGhh dCB0aGUgbGF5b3V0IGFuZCB0aGUgZmllbGQgbmFtZXMgdXNlZCBpbiBpdCBhcmUgbWlzbGVhZGlu ZyAoaW5zdGVhZCBvZiAiRXh0LVR5cGUiIHdlIHNob3VsZCBjYWxsIGl0ICJUeXBlLUlEIiBvciAi QXR0cmlidXRlLUlEIiBvciBzb21ldGhpbmcgc2ltaWxhciksIGFuZCB5b3UgYXJlIHJpZ2h0IGlu IHRoYXQgdGhlIHdheSBvZiBzcGVjaWZ5aW5nIHRoaXMgaWRlbnRpZmllciBzaG91bGQgYmUgYmV0 dGVyIGFsaWduZWQgd2l0aCB0aGUgd2F5IG9mIGNvZGluZyB0eXBlcyBhbmQgZXh0ZW5kZWQgdHlw ZXMuDQoNCj4gIEF0dHJpYnV0ZXMgY2FuIGFsc28gb2NjdXIgbXVsdGlwbGUgdGltZXMgaW4gYSBw YWNrZXQsIHdpdGggZGlmZmVyZW50DQo+IHZhbHVlcy4gIGUuZy4gUHJveHktU3RhdGUuDQoNCllv dSBhcmUgcmlnaHQuIFRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZC4gQSBzaW1wbGUgcHJvcG9zYWwg Y291bGQgZm9sbG93IHRoZXNlIHJ1bGVzOg0KDQoqIENodW5rZWQtQXR0cmlidXRlIG11c3QgYXBw ZWFyIGJlZm9yZSB0aGUgYXR0cmlidXRlIGl0IHJlZmVycyB0byBpbiB0aGUgcGFja2V0DQoNCiog SWYgYW4gYXR0cmlidXRlIG9jY3VycyBtdWx0aXBsZSB0aW1lcyBpbiBhIHJlcXVlc3QvcmVzcG9u c2UgKHdlIGNhbm5vdCBzcGVhayBoZXJlIG9mICJhIHBhY2tldCIpIGNodW5rcyBmb3Igb25seSBv bmUgb2YgdGhlIG9jY3VycmVuY2VzLCBhc3NvY2lhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIENo dW5rZWQtQXR0cmlidXRlLCBhcmUgYWxsb3dlZCBpbiBhIGdpdmVuIHBhY2tldA0KDQoqIE5vbi1m cmFnbWVudGVkIHZhbHVlcyBmb3IgdGhpcyBhdHRyaWJ1dGUgY2FuIGFwcGVhciBpbiBhbnkgcGFj a2V0LCBidXQgYWx3YXlzIGJlZm9yZSB0aGUgQ2h1bmtlZC1BdHRyaWJ1dGUgdGhhdCByZWZlcnMg dG8gaXQNCg0KKiBBcyBtYW55IENodW5rZWQtQXR0cmlidXRlIChhbmQgcmVmZXJyZWQgYXR0cmli dXRlcykgbWF5IGFwcGVhciBpbiBhIGdpdmVuIHBhY2tldCBhcyBuZWNlc3NhcnkuDQoNCj4gIElm IHRoaXMgZG9jdW1lbnQgaXMgcHVibGlzaGVkIHNvb24gYWZ0ZXIgdGhlIGV4dGVuc2lvbnMgZG9j dW1lbnQsIHRoZW4NCj4gaXQgaGFzIGEgYmV0dGVyIGxpa2VsaWhvb2Qgb2YgYmVpbmcgaW1wbGVt ZW50ZWQuDQoNCkdvb2QgcG9pbnQhDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZh bGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25p Y2EgSStEDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICAgKzM0IDkxMyAxMjkgMDQx DQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52 w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1 YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9y IGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFT L2Rpc2NsYWltZXIuYXNweA0K From radext-bounces@ietf.org Wed Jan 4 10:21:12 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CE111E807A; Wed, 4 Jan 2012 10:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325701272; bh=xe7NrTD+V4iUyaWmESV69gFNF/bVkvnptfbFNqVkAhA=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=GiYRFar9etWANUm/8KX62leEUqqXIrZkTj7JXC/8i8ejjcYxXDeegE7wJxOze1+L4 pEOtfBvEvfAYc0eO0Z5aSsU9C4DGG5LVvah5JnapScBEbAOBOEgkmjsXk5LSsSsV7r aRdgyZYExjruIqp9ve4fuNTdXPApEwu0r/eDt6WU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D777411E807A; Wed, 4 Jan 2012 10:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZTqNF0XRIij; Wed, 4 Jan 2012 10:21:08 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5362221F86AE; Wed, 4 Jan 2012 10:21:07 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXA000LVDN5RJ@tid.hi.inet>; Wed, 04 Jan 2012 19:21:05 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 69.D1.02643.198940F4; Wed, 04 Jan 2012 19:21:05 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXA000LQDN4RJ@tid.hi.inet>; Wed, 04 Jan 2012 19:21:05 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Wed, 04 Jan 2012 19:21:04 +0100 Date: Wed, 04 Jan 2012 19:21:02 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F045FE2.8070804@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: en-US Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczLDZ68FEBzPaJTQLyqwDFJVlqgrg== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-07-4f049891004f X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBKsWRmVeSWpSXmKPExsXCFe9nqDtxBou/wYFjwhYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZt75fZSvYIlXRdeQZYwPjHckuRk4OCQETiT8/H7NA 2GISF+6tZ+ti5OIQEtjGKHH/8Qso5ymjxOKLH1ghnEZGiQ0z7jB1MXJwsAioSiw/GwHSzSag LtFy9BvYJGGBZIm7/7exgdicAsYSPz89YAWxRQS0JBasX8QC0sosUCgx9YIOSJhXwFLi+JoV bBC2oMSPyfegStQlpkzJBQkzC4hLNLfeZIGwFSWmLWpgBLEZgW7+fmoNE8T0FIlNd+axQdh6 ErO+LoOqEZW4076eEeJHAYkle84zQ9iiEi8f/4P6qolRYvnOvawTGMVnITljFsIZs5CcMQvJ GQsYWVYxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREU+YOxuU7VQ4xCnAwKvHwerxj9Bdi TSwrrsw9xCjJwaQkysvTx+IvxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3VTtQjjclsbIqtSgf JiXDwaEkwftkOlBKsCg1PbUiLTMHmDJg0kwcnCDtPEDtD0FqeIsLEnOLM9Mh8qcYJaXEeTeD JARAEhmleXC9rxjFgY4U5l0CkuUBJje4rldAA5mABkaJgA0sSURISTUwLjsl1JC0+Nop246H es+mPs8I2ja55kr/I+avPhxsH25svu7hcFKJO0g38JftusnfTON79NiZ/xnsKNzJ2XrzfPlk tYnM91d0bPjkcPT74kbxY3rrZ6zbfDPevIVT+LaHpdZ3V5FPj3wDPsjPTvXjkVJ4VBYTMIE/ rbhs8f+84yYuJV8M5x/XUGIpzkg01GIuKk4EAAhEcjQrAwAA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org SGkgQWxhbiwNCg0KT24gNCBKYW4gMjAxMiwgYXQgMTU6MTkgLCBBbGFuIERlS29rIHdyb3RlOg0K PiAgVGhhdCB3b24ndCB3b3JrLiAgVGhlIHR5cGUvZXh0LXR5cGUgaXMgdXNlZCB0byB1bmlxdWVs eSBpZGVudGlmeSBhbg0KPiBhdHRyaWJ1dGUuICBBcyB0aGUgUkZDNjE1OCBzYXlzLCB0aGUgaW50 ZXJwcmV0YXRpb24gb2YgdGhlIGF0dHJpYnV0ZSBpcw0KPiBiYXNlZCBzb2xlbHkgb24gdGhlIHR5 cGUgY29kZShzKS4gIFdoYXQgeW91J3JlIGRvaW5nIGFib3ZlIGlzIGNoYW5naW5nDQo+IHRoZSBt ZWFuaW5nIG9mIHRoZSBhdHRyaWJ1dGUgYmFzZWQgb24gaXRzIGxlbmd0aC4NCj4NCj4gIFRoYXQn cyBkaWZmaWN1bHQsIGlmIG5vdCBpbXBvc3NpYmxlLCB0byBkbyBjb3JyZWN0bHkuDQoNCkknbSBh ZnJhaWQgdGhlcmUgaXMgYSBtaXN1bmRlcnN0YW5kaW5nLiBUaGUgQ2h1bmtlZC1BdHJyaWJ1dGUg aXMgYW4gYXR0cmlidXRlIG9uIGl0cyBvd24gdGhhdCBjb250YWlucyBvbmx5IGEgcmVmZXJlbmNl IHRvIHRoZSBhdHRyaWJ1dGUgYmVpbmcgY2h1bmtlZC4gSXQgaGFzIHRvIGFwcGVhciBpbiBhbGwg dGhlIHBhY2tldHMgY29udGFpbmluZyBjaHVua3Mgb2YgYXR0cmlidXRlcywgYXMgbWFueSBhcyBh dHRyaWJ1dGVzIHRoZXkgcmVmZXIgdG8uIENodW5rcyBhcmUgaW50ZW5kZWQgdG8gYmUgZW5jb2Rl ZCBmb2xsb3dpbmcgdGhlIHVzdWFsIGVuY29kaW5nIG1ldGhvZHMuDQoNCkl0IGlzIHRydWUgdGhh dCB0aGUgbGF5b3V0IGFuZCB0aGUgZmllbGQgbmFtZXMgdXNlZCBpbiBpdCBhcmUgbWlzbGVhZGlu ZyAoaW5zdGVhZCBvZiAiRXh0LVR5cGUiIHdlIHNob3VsZCBjYWxsIGl0ICJUeXBlLUlEIiBvciAi QXR0cmlidXRlLUlEIiBvciBzb21ldGhpbmcgc2ltaWxhciksIGFuZCB5b3UgYXJlIHJpZ2h0IGlu IHRoYXQgdGhlIHdheSBvZiBzcGVjaWZ5aW5nIHRoaXMgaWRlbnRpZmllciBzaG91bGQgYmUgYmV0 dGVyIGFsaWduZWQgd2l0aCB0aGUgd2F5IG9mIGNvZGluZyB0eXBlcyBhbmQgZXh0ZW5kZWQgdHlw ZXMuDQoNCj4gIEF0dHJpYnV0ZXMgY2FuIGFsc28gb2NjdXIgbXVsdGlwbGUgdGltZXMgaW4gYSBw YWNrZXQsIHdpdGggZGlmZmVyZW50DQo+IHZhbHVlcy4gIGUuZy4gUHJveHktU3RhdGUuDQoNCllv dSBhcmUgcmlnaHQuIFRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZC4gQSBzaW1wbGUgcHJvcG9zYWwg Y291bGQgZm9sbG93IHRoZXNlIHJ1bGVzOg0KDQoqIENodW5rZWQtQXR0cmlidXRlIG11c3QgYXBw ZWFyIGJlZm9yZSB0aGUgYXR0cmlidXRlIGl0IHJlZmVycyB0byBpbiB0aGUgcGFja2V0DQoNCiog SWYgYW4gYXR0cmlidXRlIG9jY3VycyBtdWx0aXBsZSB0aW1lcyBpbiBhIHJlcXVlc3QvcmVzcG9u c2UgKHdlIGNhbm5vdCBzcGVhayBoZXJlIG9mICJhIHBhY2tldCIpIGNodW5rcyBmb3Igb25seSBv bmUgb2YgdGhlIG9jY3VycmVuY2VzLCBhc3NvY2lhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIENo dW5rZWQtQXR0cmlidXRlLCBhcmUgYWxsb3dlZCBpbiBhIGdpdmVuIHBhY2tldA0KDQoqIE5vbi1m cmFnbWVudGVkIHZhbHVlcyBmb3IgdGhpcyBhdHRyaWJ1dGUgY2FuIGFwcGVhciBpbiBhbnkgcGFj a2V0LCBidXQgYWx3YXlzIGJlZm9yZSB0aGUgQ2h1bmtlZC1BdHRyaWJ1dGUgdGhhdCByZWZlcnMg dG8gaXQNCg0KKiBBcyBtYW55IENodW5rZWQtQXR0cmlidXRlIChhbmQgcmVmZXJyZWQgYXR0cmli dXRlcykgbWF5IGFwcGVhciBpbiBhIGdpdmVuIHBhY2tldCBhcyBuZWNlc3NhcnkuDQoNCj4gIElm IHRoaXMgZG9jdW1lbnQgaXMgcHVibGlzaGVkIHNvb24gYWZ0ZXIgdGhlIGV4dGVuc2lvbnMgZG9j dW1lbnQsIHRoZW4NCj4gaXQgaGFzIGEgYmV0dGVyIGxpa2VsaWhvb2Qgb2YgYmVpbmcgaW1wbGVt ZW50ZWQuDQoNCkdvb2QgcG9pbnQhDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZh bGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25p Y2EgSStEDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICAgKzM0IDkxMyAxMjkgMDQx DQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52 w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1 YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9y IGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFz aXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFT L2Rpc2NsYWltZXIuYXNweA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KcmFkZXh0IG1haWxpbmcgbGlzdApyYWRleHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQK From radext-bounces@ietf.org Wed Jan 4 11:28:06 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495C621F8757; Wed, 4 Jan 2012 11:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325705286; bh=QAbAwrLYDNPBNe5vgaLhDOWS0K9d2SFDYN9mbYJaiyQ=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=moFqMA9oJvQdGJ8J5Nc5ZUzyCYQGLycaHoG7chdof/1OIE0pXiuAtOJHifIFn0y3X AJ7NJ70y9ksLLNk586IVLI4yheQTqi0RwQCTk5Z3EP6n36c/cwzben2iNPznUEgN7S DFICmuGOJ/KWsP+uSiQ0TSLN7LxEwx4HvtLWeS8o= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7AB21F8758 for ; Wed, 4 Jan 2012 11:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GudVmYoif0W3 for ; Wed, 4 Jan 2012 11:28:04 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0721F8757 for ; Wed, 4 Jan 2012 11:28:03 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 4 Jan 2012 11:28:02 -0800 Date: Wed, 4 Jan 2012 11:28:01 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4EF1DC0A.1070004@deployingradius.com> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: 'radext mailing list' Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Wed, 21 Dec 2011, Alan DeKok wrote: > I haven't seen any comments on the latest draft. > There were some typos from Leaf, and IANA comments from Bernard. Have > they been addressed to the WGs satisfaction? > Having the document move forward would be a wonderful xmas present. Still have a serious concern with data corruption in long attribute not addressed in the latest drafts. The necessary ordering constraints do not seem to be there in existing RFCS to prevent long attributes from being corrupted. This is important since a design goal was to allow attributes to be forwarded by systems not supporting this draft. RFC 2138.3 " Many Attributes may have multiple instances, in such a case the order of Attributes of the same Type SHOULD be preserved. The order of Attributes of different Types is not required to be preserved." There are two problems with this: 1. SHOULD is not enough. 2. Preserving order is not enough. To show the problem example below uses two extended flag attributes 'Gear' and 'Cog' each of the extended flag attributes are using the same basic RADIUS attribute type. 'M' represents More flag set '.' No flags are set 1. An implementation decides to ignore the advice of RFC 2138 jumbling the order of attributes of the same type: OK: [Gear M.1][Gear M.2][GEAR .3] NOT OK: [Gear M.2][Gear M.1][GEAR .3] This not only corrupts the data but also corrupts the attributes extended type. This can be dangerous in the wrong hands as the *payload* now has a say over the selection of extended type. If this were a VSA it would corrupt both the vendor id and the vendors type. 2. An implementation follows the advice of RFC 2138 to the letter. Unfortunately preservation of order does not preclude insertion of Cogs into the middle of Gears as the outer RADIUS type is the same for both. OK: [Gear M.1][Gear M.2][GEAR .3][Cog .1] NOT OK: [Gear M.1][Gear M.2][Cog .1][GEAR .3] - Gear is truncated - Cog is appended to the truncated Gear further corrupting Gear - Cog never appears as an attribute - The *payload* of the last gear fragment determines a corrupt extended type (Or Vendor id and vendors type) and whats left over of Gear.3's data.. as with the previous example being able to control extended type via payload can be dangerous in the wrong hands. Some ideas for solving the problems: 1. Use reserved field as a counter to allow attribute order to be verified. 2. Change the fragment format of extended flag attributes to include the inner extended type or vendorid/type fields in subsequent fragments. 3. Add a constraint requiring that at least on the granularity of the same outer basic RADIUS type if there are any long attributes which fail to fully validate all "successfully" decoded attributes MUST also be treated as invalid. Examples of this would be a case of a counter field in the wrong order or an attribute with more flag set without a follow on ending fragment. Other thoughts.. The system does not have to work with existing implementations that for whatever reason are not willing to impose rational ordering of attributes. At the same time a failure mode of silent data corruption is not something I would expect anyone to be willing to accept. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Wed Jan 4 11:28:04 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7AB21F8758 for ; Wed, 4 Jan 2012 11:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GudVmYoif0W3 for ; Wed, 4 Jan 2012 11:28:04 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0721F8757 for ; Wed, 4 Jan 2012 11:28:03 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 4 Jan 2012 11:28:02 -0800 Date: Wed, 4 Jan 2012 11:28:01 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4EF1DC0A.1070004@deployingradius.com> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: 'radext mailing list' Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:28:04 -0000 On Wed, 21 Dec 2011, Alan DeKok wrote: > I haven't seen any comments on the latest draft. > There were some typos from Leaf, and IANA comments from Bernard. Have > they been addressed to the WGs satisfaction? > Having the document move forward would be a wonderful xmas present. Still have a serious concern with data corruption in long attribute not addressed in the latest drafts. The necessary ordering constraints do not seem to be there in existing RFCS to prevent long attributes from being corrupted. This is important since a design goal was to allow attributes to be forwarded by systems not supporting this draft. RFC 2138.3 " Many Attributes may have multiple instances, in such a case the order of Attributes of the same Type SHOULD be preserved. The order of Attributes of different Types is not required to be preserved." There are two problems with this: 1. SHOULD is not enough. 2. Preserving order is not enough. To show the problem example below uses two extended flag attributes 'Gear' and 'Cog' each of the extended flag attributes are using the same basic RADIUS attribute type. 'M' represents More flag set '.' No flags are set 1. An implementation decides to ignore the advice of RFC 2138 jumbling the order of attributes of the same type: OK: [Gear M.1][Gear M.2][GEAR .3] NOT OK: [Gear M.2][Gear M.1][GEAR .3] This not only corrupts the data but also corrupts the attributes extended type. This can be dangerous in the wrong hands as the *payload* now has a say over the selection of extended type. If this were a VSA it would corrupt both the vendor id and the vendors type. 2. An implementation follows the advice of RFC 2138 to the letter. Unfortunately preservation of order does not preclude insertion of Cogs into the middle of Gears as the outer RADIUS type is the same for both. OK: [Gear M.1][Gear M.2][GEAR .3][Cog .1] NOT OK: [Gear M.1][Gear M.2][Cog .1][GEAR .3] - Gear is truncated - Cog is appended to the truncated Gear further corrupting Gear - Cog never appears as an attribute - The *payload* of the last gear fragment determines a corrupt extended type (Or Vendor id and vendors type) and whats left over of Gear.3's data.. as with the previous example being able to control extended type via payload can be dangerous in the wrong hands. Some ideas for solving the problems: 1. Use reserved field as a counter to allow attribute order to be verified. 2. Change the fragment format of extended flag attributes to include the inner extended type or vendorid/type fields in subsequent fragments. 3. Add a constraint requiring that at least on the granularity of the same outer basic RADIUS type if there are any long attributes which fail to fully validate all "successfully" decoded attributes MUST also be treated as invalid. Examples of this would be a case of a counter field in the wrong order or an attribute with more flag set without a follow on ending fragment. Other thoughts.. The system does not have to work with existing implementations that for whatever reason are not willing to impose rational ordering of attributes. At the same time a failure mode of silent data corruption is not something I would expect anyone to be willing to accept. regards, Peter From bernard_aboba@hotmail.com Wed Jan 4 11:52:22 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BD221F85BD for ; Wed, 4 Jan 2012 11:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+nNwVwJhh0A for ; Wed, 4 Jan 2012 11:52:21 -0800 (PST) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB5A21F85BA for ; Wed, 4 Jan 2012 11:52:21 -0800 (PST) Received: from BLU152-W42 ([65.55.111.73]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 11:52:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_46753c07-83fa-4232-8210-c5eb252df4c2_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 4 Jan 2012 11:52:20 -0800 Importance: Normal In-Reply-To: <4F041D09.2060905@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2012 19:52:20.0703 (UTC) FILETIME=[5ECDB6F0:01CCCB1A] Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:52:22 -0000 --_46753c07-83fa-4232-8210-c5eb252df4c2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 6158 Section 3.1 lays out the potential alternatives for solving this p= roblem. An example of approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which enable= EAP frames larger than the MTU to be split across RADIUS packets. This would not nece= ssarily require a change to the attribute format=2C just a mechanism that would define a SAML= encapsulation handling fragmentation/reassembly=2C as EAP methods such as EAP-TLS do. After all= =2C the EAP-Method attribute did not require definition of a new data type or attribute format= .=20 Approach #2 could involve using a URL to enable retrieval of SAML out-of-ba= nd. This approach=20 has been used with other protocols encountering fragmentation issues=2C suc= h as IKE=2C and has worked well.=20 Approach #3 cannot be guaranteed to work in all circumstances=2C so that it= needs to be used alongside approaches #1 or #2.=20 The Length field in the RADIUS packet header is defined in [RFC2865] Section 3. It is noted there that the maximum length of a RADIUS packet is 4096 octets. As a result=2C attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 octets. Even when packets are less than 4096 octets=2C they may be larger than the Path Maximum Transmission Unit (PMTU). Any packet larger than the PMTU will be fragmented=2C making communications more brittle as firewalls and filtering devices often discard fragments. Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets=2C making it difficult to deploy RADIUS in a network where those devices are deployed. We RECOMMEND that RADIUS messages be kept as small possible. If a situation is envisaged where it may be necessary to carry authentication=2C authorization=2C or accounting data in a packet larger than 4096 octets=2C then one of the following approaches is RECOMMENDED: 1. Utilization of a sequence of packets. For RADIUS authentication=2C a sequence of Access- Request/Access-Challenge packets would be used. For this to be feasible=2C attribute designers need to enable inclusion of attributes that can consume considerable space within Access- Challenge packets. To maintain compatibility with existing NASes=2C either the use of Access-Challenge packets needs to be permissible (as with RADIUS/EAP=2C defined in [RFC3579]) or support for receipt of an Access-Challenge needs to be indicated by the NAS (as in RADIUS Location [RFC5580]). Also=2C the specification needs to clearly describe how attribute splitting is to be signaled and how attributes included within the sequence are to be interpreted=2C without requiring stateful operation. Unfortunately=2C previous specifications have not always exhibited the required foresight. For example=2C even though very large filter rules are conceivable=2C the NAS- Filter-Rule Attribute defined in [RFC4849] is not permitted in an Access-Challenge packet=2C nor is a mechanism specified to allow a set of NAS-Filter-Rule Attributes to be split across an Access-Request/Access-Challenge sequence. In the case of RADIUS accounting=2C transporting large amounts of data would require a sequence of Accounting-Request packets. This is a non-trivial change to RADIUS=2C since RADIUS accounting clients would need to be modified to split the attribute stream across multiple Accounting-Requests=2C and billing servers would need to be modified to reassemble and interpret the attribute stream. 2. Utilization of names rather than values. Where an attribute relates to a policy that could conceivably be pre-provisioned on the NAS=2C then the name of the pre- provisioned policy can be transmitted in an attribute rather than the policy itself=2C which could be quite large. An example of this is the Filter-Id Attribute defined in [RFC2865]=2C Section 5.11=2C which enables a set of pre- provisioned filter rules to be referenced by name. 3. Utilization of Packetization Layer Path MTU Discovery techniques=2C as specified in [RFC4821]. As a last resort=2C where the above techniques cannot be made to work=2C it may be possible to apply the techniques described in [RFC4821] to discover the maximum supported RADIUS packet size on the path between a RADIUS client and a home server. While such an approach can avoid the complexity of utilization of a sequence of packets=2C dynamic discovery is likely to be time consuming and cannot be guaranteed to work with existing RADIUS implementations. As a result=2C this technique is not generally applicable. Date: Wed=2C 4 Jan 2012 10:34:01 +0100 From: alex@um.es To: radext@ietf.org Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radi= us-fragmentation-00.txt =20 =20 =20 =20 FYI.=20 =20 This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB=2C thus a mechanism to fragment them is required. =20 -------- Mensaje original -------- =20 =20 =20 Asunto:=20 New Version Notification for draft-perez-radext-radius-fragmentation-00.txt =20 =20 Fecha:=20 Wed=2C 04 Jan 2012 01:21:53 -0800 =20 =20 De:=20 internet-drafts@ietf.org =20 =20 Para:=20 alex@um.es =20 =20 =20 =20 A new version of I-D=2C draft-perez-radext-radius-fragmentation-00.txt = has been successfully submitted by Alejandro Perez-Mendez and posted to the= IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 00 Title: Fragmentation support across RADIUS packets Creation date: 2012-01-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes a mechanism providing fragmentation support of RADIUS attributes across several RADIUS packets. This is intended to support attributes that exceed the 4 KB limit per RADIUS packet. = =20 The IETF Secretariat =20 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext = --_46753c07-83fa-4232-8210-c5eb252df4c2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC 6158 Section 3.1 lays out the potential alternatives for solving this p= roblem. =3B An example of
approach #1 is taken by EAP methods such a= s EAP TLS (RFC 5716) which enable EAP frames
larger than the MTU to be s= plit across RADIUS packets. =3B This would not necessarily require achange to the attribute format=2C just a mechanism that would define a SAM= L encapsulation handling
fragmentation/reassembly=2C as EAP methods such= as EAP-TLS do. =3B After all=2C the EAP-Method
attribute did not re= quire definition of a new data type or attribute format.

Approach #= 2 could involve using a URL to enable retrieval of SAML out-of-band. = =3B This approach
has been used with other protocols encountering fragm= entation issues=2C such as IKE=2C =3B and has worked
well.

A= pproach #3 cannot be guaranteed to work in all circumstances=2C so that it = needs to be used
alongside approaches #1 or #2. 

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section =3B3.  It is noted there that the maximum length of a RA=
DIUS
   packet is 4096 octets.  As a result=2C attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.

   Even when packets are less than 4096 octets=2C they may be larger than
   the Path Maximum Transmission Unit (PMTU).  Any packet larger than
   the PMTU will be fragmented=2C making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears to be a poorly tested code path on
   network devices.  Some devices appear to be incapable of transporting
   fragmented UDP packets=2C making it difficult to deploy RADIUS in a
   network where those devices are deployed.  We RECOMMEND that RADIUS
   messages be kept as small possible.

   If a situation is envisaged where it may be necessary to carry
   authentication=2C authorization=2C or accounting data in a packet larger
   than 4096 octets=2C then one of the following approaches is
   RECOMMENDED:

      1.  Utilization of a sequence of packets.
          For RADIUS authentication=2C a sequence of Access-
          Request/Access-Challenge packets would be used.  For this to
          be feasible=2C attribute designers need to enable inclusion of
          attributes that can consume considerable space within Access-
          Challenge packets.  To maintain compatibility with existing
          NASes=2C either the use of Access-Challenge packets needs to be
          permissible (as with RADIUS/EAP=2C defined in [RFC3579]) or
          support for receipt of an Access-Challenge needs to be
          indicated by the NAS (as in RADIUS Location [RFC5580]).  Also=2C
          the specification needs to clearly describe how attribute
          splitting is to be signaled and how attributes included within
          the sequence are to be interpreted=2C without requiring stateful
          operation.  Unfortunately=2C previous specifications have not
          always exhibited the required foresight.  For example=2C even
          though very large filter rules are conceivable=2C the NAS-
          Filter-Rule Attribute defined in [RFC4=
849] is not permitted in
          an Access-Challenge packet=2C nor is a mechanism specified to
          allow a set of NAS-Filter-Rule Attributes to be split across
          an Access-Request/Access-Challenge sequence.

          In the case of RADIUS accounting=2C transporting large amounts
          of data would require a sequence of Accounting-Request
          packets.  This is a non-trivial change to RADIUS=2C since RADIUS
          accounting clients would need to be modified to split the
          attribute stream across multiple Accounting-Requests=2C and
          billing servers would need to be modified to reassemble and
          interpret the attribute stream.

      2.  Utilization of names rather than values.
          Where an attribute relates to a policy that could conceivably
          be pre-provisioned on the NAS=2C then the name of the pre-
          provisioned policy can be transmitted in an attribute rather
          than the policy itself=2C which could be quite large.  An
          example of this is the Filter-Id Attribute defined in
          [RFC2=
865]=2C Section =3B5.11=2C which enables a set of pre-
          provisioned filter rules to be referenced by name.

      3.  Utilization of Packetization Layer Path MTU Discovery
          techniques=2C as specified in [RFC4821].
          As a last resort=2C where the above techniques cannot be made to
          work=2C it may be possible to apply the techniques described in
          [RFC4821] to discover th=
e maximum supported RADIUS packet size
          on the path between a RADIUS client and a home server.  While
          such an approach can avoid the complexity of utilization of a
          sequence of packets=2C dynamic discovery is likely to be time
          consuming and cannot be guaranteed to work with existing
          RADIUS implementations.  As a result=2C this technique is not
          generally applicable.


Date: Wed=2C 4 Jan 2012 10:34:01 +0100
From: alex@um.es
To: rad= ext@ietf.org
Subject: [radext] Fwd: New Version Notification for draft-p= erez-radext-radius-fragmentation-00.txt

=20 =20 =20 =20 FYI.

This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB=2C thus a mechanism to fragment them is required.

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed=2C 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 

A new version of I-D=2C draft-perez-radext-radius-fragmentation-00=
.txt has been successfully submitted by Alejandro Perez-Mendez and posted t=
o the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                           =
      =20


The IETF Secretariat
=20
_______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
= --_46753c07-83fa-4232-8210-c5eb252df4c2_-- From radext-bounces@ietf.org Wed Jan 4 11:52:24 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361B21F85BF; Wed, 4 Jan 2012 11:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325706744; bh=piT/yF9wBesSzH49xQFP/c8xezXsEHteGqYbN6t+PL8=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Vx3+jWQHmzfI2d4W+Y2Eqm8j6eUTQMuwaBGXIOZULh0ii7Qa1Cqj/TZrvadIwEGiW PboCgHUd6fG+pvKlmJhQ80fXBrevHl7CadcrZgBBXa2iw67SoOGEtdoRR/9j2zJpQ4 ADdL0HLMweIZHv/eBkqYWkPzb21qVIYVwLQopKCU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BD221F85BD for ; Wed, 4 Jan 2012 11:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+nNwVwJhh0A for ; Wed, 4 Jan 2012 11:52:21 -0800 (PST) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB5A21F85BA for ; Wed, 4 Jan 2012 11:52:21 -0800 (PST) Received: from BLU152-W42 ([65.55.111.73]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jan 2012 11:52:20 -0800 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 4 Jan 2012 11:52:20 -0800 Importance: Normal In-Reply-To: <4F041D09.2060905@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> MIME-Version: 1.0 X-OriginalArrivalTime: 04 Jan 2012 19:52:20.0703 (UTC) FILETIME=[5ECDB6F0:01CCCB1A] Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4805047329324685304==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============4805047329324685304== Content-Type: multipart/alternative; boundary="_46753c07-83fa-4232-8210-c5eb252df4c2_" --_46753c07-83fa-4232-8210-c5eb252df4c2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 6158 Section 3.1 lays out the potential alternatives for solving this p= roblem. An example of approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which enable= EAP frames larger than the MTU to be split across RADIUS packets. This would not nece= ssarily require a change to the attribute format=2C just a mechanism that would define a SAML= encapsulation handling fragmentation/reassembly=2C as EAP methods such as EAP-TLS do. After all= =2C the EAP-Method attribute did not require definition of a new data type or attribute format= .=20 Approach #2 could involve using a URL to enable retrieval of SAML out-of-ba= nd. This approach=20 has been used with other protocols encountering fragmentation issues=2C suc= h as IKE=2C and has worked well.=20 Approach #3 cannot be guaranteed to work in all circumstances=2C so that it= needs to be used alongside approaches #1 or #2.=20 The Length field in the RADIUS packet header is defined in [RFC2865] Section 3. It is noted there that the maximum length of a RADIUS packet is 4096 octets. As a result=2C attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 octets. Even when packets are less than 4096 octets=2C they may be larger than the Path Maximum Transmission Unit (PMTU). Any packet larger than the PMTU will be fragmented=2C making communications more brittle as firewalls and filtering devices often discard fragments. Transport of fragmented UDP packets appears to be a poorly tested code path on network devices. Some devices appear to be incapable of transporting fragmented UDP packets=2C making it difficult to deploy RADIUS in a network where those devices are deployed. We RECOMMEND that RADIUS messages be kept as small possible. If a situation is envisaged where it may be necessary to carry authentication=2C authorization=2C or accounting data in a packet larger than 4096 octets=2C then one of the following approaches is RECOMMENDED: 1. Utilization of a sequence of packets. For RADIUS authentication=2C a sequence of Access- Request/Access-Challenge packets would be used. For this to be feasible=2C attribute designers need to enable inclusion of attributes that can consume considerable space within Access- Challenge packets. To maintain compatibility with existing NASes=2C either the use of Access-Challenge packets needs to be permissible (as with RADIUS/EAP=2C defined in [RFC3579]) or support for receipt of an Access-Challenge needs to be indicated by the NAS (as in RADIUS Location [RFC5580]). Also=2C the specification needs to clearly describe how attribute splitting is to be signaled and how attributes included within the sequence are to be interpreted=2C without requiring stateful operation. Unfortunately=2C previous specifications have not always exhibited the required foresight. For example=2C even though very large filter rules are conceivable=2C the NAS- Filter-Rule Attribute defined in [RFC4849] is not permitted in an Access-Challenge packet=2C nor is a mechanism specified to allow a set of NAS-Filter-Rule Attributes to be split across an Access-Request/Access-Challenge sequence. In the case of RADIUS accounting=2C transporting large amounts of data would require a sequence of Accounting-Request packets. This is a non-trivial change to RADIUS=2C since RADIUS accounting clients would need to be modified to split the attribute stream across multiple Accounting-Requests=2C and billing servers would need to be modified to reassemble and interpret the attribute stream. 2. Utilization of names rather than values. Where an attribute relates to a policy that could conceivably be pre-provisioned on the NAS=2C then the name of the pre- provisioned policy can be transmitted in an attribute rather than the policy itself=2C which could be quite large. An example of this is the Filter-Id Attribute defined in [RFC2865]=2C Section 5.11=2C which enables a set of pre- provisioned filter rules to be referenced by name. 3. Utilization of Packetization Layer Path MTU Discovery techniques=2C as specified in [RFC4821]. As a last resort=2C where the above techniques cannot be made to work=2C it may be possible to apply the techniques described in [RFC4821] to discover the maximum supported RADIUS packet size on the path between a RADIUS client and a home server. While such an approach can avoid the complexity of utilization of a sequence of packets=2C dynamic discovery is likely to be time consuming and cannot be guaranteed to work with existing RADIUS implementations. As a result=2C this technique is not generally applicable. Date: Wed=2C 4 Jan 2012 10:34:01 +0100 From: alex@um.es To: radext@ietf.org Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radi= us-fragmentation-00.txt =20 =20 =20 =20 FYI.=20 =20 This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB=2C thus a mechanism to fragment them is required. =20 -------- Mensaje original -------- =20 =20 =20 Asunto:=20 New Version Notification for draft-perez-radext-radius-fragmentation-00.txt =20 =20 Fecha:=20 Wed=2C 04 Jan 2012 01:21:53 -0800 =20 =20 De:=20 internet-drafts@ietf.org =20 =20 Para:=20 alex@um.es =20 =20 =20 =20 A new version of I-D=2C draft-perez-radext-radius-fragmentation-00.txt = has been successfully submitted by Alejandro Perez-Mendez and posted to the= IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 00 Title: Fragmentation support across RADIUS packets Creation date: 2012-01-04 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes a mechanism providing fragmentation support of RADIUS attributes across several RADIUS packets. This is intended to support attributes that exceed the 4 KB limit per RADIUS packet. = =20 The IETF Secretariat =20 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext = --_46753c07-83fa-4232-8210-c5eb252df4c2_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC 6158 Section 3.1 lays out the potential alternatives for solving this p= roblem. =3B An example of
approach #1 is taken by EAP methods such a= s EAP TLS (RFC 5716) which enable EAP frames
larger than the MTU to be s= plit across RADIUS packets. =3B This would not necessarily require achange to the attribute format=2C just a mechanism that would define a SAM= L encapsulation handling
fragmentation/reassembly=2C as EAP methods such= as EAP-TLS do. =3B After all=2C the EAP-Method
attribute did not re= quire definition of a new data type or attribute format.

Approach #= 2 could involve using a URL to enable retrieval of SAML out-of-band. = =3B This approach
has been used with other protocols encountering fragm= entation issues=2C such as IKE=2C =3B and has worked
well.

A= pproach #3 cannot be guaranteed to work in all circumstances=2C so that it = needs to be used
alongside approaches #1 or #2. 

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section =3B3.  It is noted there that the maximum length of a RA=
DIUS
   packet is 4096 octets.  As a result=2C attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.

   Even when packets are less than 4096 octets=2C they may be larger than
   the Path Maximum Transmission Unit (PMTU).  Any packet larger than
   the PMTU will be fragmented=2C making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears to be a poorly tested code path on
   network devices.  Some devices appear to be incapable of transporting
   fragmented UDP packets=2C making it difficult to deploy RADIUS in a
   network where those devices are deployed.  We RECOMMEND that RADIUS
   messages be kept as small possible.

   If a situation is envisaged where it may be necessary to carry
   authentication=2C authorization=2C or accounting data in a packet larger
   than 4096 octets=2C then one of the following approaches is
   RECOMMENDED:

      1.  Utilization of a sequence of packets.
          For RADIUS authentication=2C a sequence of Access-
          Request/Access-Challenge packets would be used.  For this to
          be feasible=2C attribute designers need to enable inclusion of
          attributes that can consume considerable space within Access-
          Challenge packets.  To maintain compatibility with existing
          NASes=2C either the use of Access-Challenge packets needs to be
          permissible (as with RADIUS/EAP=2C defined in [RFC3579]) or
          support for receipt of an Access-Challenge needs to be
          indicated by the NAS (as in RADIUS Location [RFC5580]).  Also=2C
          the specification needs to clearly describe how attribute
          splitting is to be signaled and how attributes included within
          the sequence are to be interpreted=2C without requiring stateful
          operation.  Unfortunately=2C previous specifications have not
          always exhibited the required foresight.  For example=2C even
          though very large filter rules are conceivable=2C the NAS-
          Filter-Rule Attribute defined in [RFC4=
849] is not permitted in
          an Access-Challenge packet=2C nor is a mechanism specified to
          allow a set of NAS-Filter-Rule Attributes to be split across
          an Access-Request/Access-Challenge sequence.

          In the case of RADIUS accounting=2C transporting large amounts
          of data would require a sequence of Accounting-Request
          packets.  This is a non-trivial change to RADIUS=2C since RADIUS
          accounting clients would need to be modified to split the
          attribute stream across multiple Accounting-Requests=2C and
          billing servers would need to be modified to reassemble and
          interpret the attribute stream.

      2.  Utilization of names rather than values.
          Where an attribute relates to a policy that could conceivably
          be pre-provisioned on the NAS=2C then the name of the pre-
          provisioned policy can be transmitted in an attribute rather
          than the policy itself=2C which could be quite large.  An
          example of this is the Filter-Id Attribute defined in
          [RFC2=
865]=2C Section =3B5.11=2C which enables a set of pre-
          provisioned filter rules to be referenced by name.

      3.  Utilization of Packetization Layer Path MTU Discovery
          techniques=2C as specified in [RFC4821].
          As a last resort=2C where the above techniques cannot be made to
          work=2C it may be possible to apply the techniques described in
          [RFC4821] to discover th=
e maximum supported RADIUS packet size
          on the path between a RADIUS client and a home server.  While
          such an approach can avoid the complexity of utilization of a
          sequence of packets=2C dynamic discovery is likely to be time
          consuming and cannot be guaranteed to work with existing
          RADIUS implementations.  As a result=2C this technique is not
          generally applicable.


Date: Wed=2C 4 Jan 2012 10:34:01 +0100
From: alex@um.es
To: rad= ext@ietf.org
Subject: [radext] Fwd: New Version Notification for draft-p= erez-radext-radius-fragmentation-00.txt

=20 =20 =20 =20 FYI.

This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB=2C thus a mechanism to fragment them is required.

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed=2C 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 

A new version of I-D=2C draft-perez-radext-radius-fragmentation-00=
.txt has been successfully submitted by Alejandro Perez-Mendez and posted t=
o the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                           =
      =20


The IETF Secretariat
=20
_______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
= --_46753c07-83fa-4232-8210-c5eb252df4c2_-- --===============4805047329324685304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4805047329324685304==-- From alex@um.es Thu Jan 5 00:29:02 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1D21F8757; Thu, 5 Jan 2012 00:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZG2PX1jc7nS; Thu, 5 Jan 2012 00:29:01 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4421F86B4; Thu, 5 Jan 2012 00:29:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id A37565D44E; Thu, 5 Jan 2012 09:28:59 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U6o9xokgmptp; Thu, 5 Jan 2012 09:28:59 +0100 (CET) Received: from [192.168.1.133] (178.246.221.87.dynamic.jazztel.es [87.221.246.178]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 3C99C5D446; Thu, 5 Jan 2012 09:28:54 +0100 (CET) Message-ID: <4F055F44.2010606@um.es> Date: Thu, 05 Jan 2012 09:28:52 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alan DeKok Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 08:29:02 -0000 Hi Alan, Diego, > Hi Alan, > > On 4 Jan 2012, at 15:19 , Alan DeKok wrote: >> That won't work. The type/ext-type is used to uniquely identify an >> attribute. As the RFC6158 says, the interpretation of the attribute is >> based solely on the type code(s). What you're doing above is changing >> the meaning of the attribute based on its length. >> >> That's difficult, if not impossible, to do correctly. > I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods. > > It is true that the layout and the field names used in it are misleading (instead of "Ext-Type" we should call it "Type-ID" or "Attribute-ID" or something similar), and you are right in that the way of specifying this identifier should be better aligned with the way of coding types and extended types. You are right. Maybe the name was not the best. We gave it 2 bytes in order to be able to refer not only to "standard" RADIUS attributes, but also to extended attributes. But after your explanation, I think that we could either include both references (Type/Ext-Type, 3 bytes in total) or just refer only to the Type (1 byte). From the point of view of fragmentation, it could be enough to know that the attribute (e.g. Vendor-Specific) is fragmented, no matter the kind of Vendor Specific attribute we are dealing with. > >> Attributes can also occur multiple times in a packet, with different >> values. e.g. Proxy-State. > You are right. That should be addressed. A simple proposal could follow these rules: > > * Chunked-Attribute must appear before the attribute it refers to in the packet Right. > > * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, X, X) you can easily assumed that the first [X,X,X] is one attribute (X1) and the second [X,X] a different one (X2), as the five Xs do not appear in sequence. Note that this situation can only occur in the packet where the last CHUNK of the first attribute coincide with the first CHUNK of the second attribute. In the example, X1 and X2 are different attributes of type X. PACKET1: CHUNCKED, X1, X1, X1, X1, X1, X1, X1, X1, X1 PACKET2: CHUNCKED, X1, X1, CHUNCKED, X2, X2, X2, X2 PACKET3: CHUNCKED, X2, X2 > > * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it I kinda don't like this one. We could force the inclusion of the CHUNCKED attribute in these situations, even when no needed. Example: CHUNCKED(type=X, total_length=200, start_pos=0, end_pos=199). As explained above, this would insert an attribute (the CHUNCKED attribute) between both occurrences of attribute X, thus breaking the misleading sequence. > > * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary. Right, as depicted in the examples above. Best regards, Alejandro > >> If this document is published soon after the extensions document, then >> it has a better likelihood of being implemented. > Good point! > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx From radext-bounces@ietf.org Thu Jan 5 00:29:03 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47F21F875B; Thu, 5 Jan 2012 00:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325752143; bh=I8fGYeUb9WopTA5yfWa50WA6qmVCCIHc17uNnRHtR+g=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=g34A78pMggll8WXOFzrxNxriTiVr3Aj2wPbV33dX75ezBgU4H9C67EtxC74KmmL+H 6Zzj4QVKiTkB34a+n+amdri3/KMSX2QN0WrHA7RapYghcQbsJ+Ufc+c0vjhJxcr7Yz TSpKatuZl56OCuygkMPhpiurWy6MtGkgII/96X6w= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1D21F8757; Thu, 5 Jan 2012 00:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZG2PX1jc7nS; Thu, 5 Jan 2012 00:29:01 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 01B4421F86B4; Thu, 5 Jan 2012 00:29:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id A37565D44E; Thu, 5 Jan 2012 09:28:59 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id U6o9xokgmptp; Thu, 5 Jan 2012 09:28:59 +0100 (CET) Received: from [192.168.1.133] (178.246.221.87.dynamic.jazztel.es [87.221.246.178]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 3C99C5D446; Thu, 5 Jan 2012 09:28:54 +0100 (CET) Message-ID: <4F055F44.2010606@um.es> Date: Thu, 05 Jan 2012 09:28:52 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> In-Reply-To: Cc: "radext@ietf.org" , "abfab@ietf.org" , Alan DeKok Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org CkhpIEFsYW4sIERpZWdvLAoKPiBIaSBBbGFuLAo+Cj4gT24gNCBKYW4gMjAxMiwgYXQgMTU6MTkg LCBBbGFuIERlS29rIHdyb3RlOgo+PiAgIFRoYXQgd29uJ3Qgd29yay4gIFRoZSB0eXBlL2V4dC10 eXBlIGlzIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYW4KPj4gYXR0cmlidXRlLiAgQXMgdGhl IFJGQzYxNTggc2F5cywgdGhlIGludGVycHJldGF0aW9uIG9mIHRoZSBhdHRyaWJ1dGUgaXMKPj4g YmFzZWQgc29sZWx5IG9uIHRoZSB0eXBlIGNvZGUocykuICBXaGF0IHlvdSdyZSBkb2luZyBhYm92 ZSBpcyBjaGFuZ2luZwo+PiB0aGUgbWVhbmluZyBvZiB0aGUgYXR0cmlidXRlIGJhc2VkIG9uIGl0 cyBsZW5ndGguCj4+Cj4+ICAgVGhhdCdzIGRpZmZpY3VsdCwgaWYgbm90IGltcG9zc2libGUsIHRv IGRvIGNvcnJlY3RseS4KPiBJJ20gYWZyYWlkIHRoZXJlIGlzIGEgbWlzdW5kZXJzdGFuZGluZy4g VGhlIENodW5rZWQtQXRycmlidXRlIGlzIGFuIGF0dHJpYnV0ZSBvbiBpdHMgb3duIHRoYXQgY29u dGFpbnMgb25seSBhIHJlZmVyZW5jZSB0byB0aGUgYXR0cmlidXRlIGJlaW5nIGNodW5rZWQuIEl0 IGhhcyB0byBhcHBlYXIgaW4gYWxsIHRoZSBwYWNrZXRzIGNvbnRhaW5pbmcgY2h1bmtzIG9mIGF0 dHJpYnV0ZXMsIGFzIG1hbnkgYXMgYXR0cmlidXRlcyB0aGV5IHJlZmVyIHRvLiBDaHVua3MgYXJl IGludGVuZGVkIHRvIGJlIGVuY29kZWQgZm9sbG93aW5nIHRoZSB1c3VhbCBlbmNvZGluZyBtZXRo b2RzLgo+Cj4gSXQgaXMgdHJ1ZSB0aGF0IHRoZSBsYXlvdXQgYW5kIHRoZSBmaWVsZCBuYW1lcyB1 c2VkIGluIGl0IGFyZSBtaXNsZWFkaW5nIChpbnN0ZWFkIG9mICJFeHQtVHlwZSIgd2Ugc2hvdWxk IGNhbGwgaXQgIlR5cGUtSUQiIG9yICJBdHRyaWJ1dGUtSUQiIG9yIHNvbWV0aGluZyBzaW1pbGFy KSwgYW5kIHlvdSBhcmUgcmlnaHQgaW4gdGhhdCB0aGUgd2F5IG9mIHNwZWNpZnlpbmcgdGhpcyBp ZGVudGlmaWVyIHNob3VsZCBiZSBiZXR0ZXIgYWxpZ25lZCB3aXRoIHRoZSB3YXkgb2YgY29kaW5n IHR5cGVzIGFuZCBleHRlbmRlZCB0eXBlcy4KCllvdSBhcmUgcmlnaHQuIE1heWJlIHRoZSBuYW1l IHdhcyBub3QgdGhlIGJlc3QuIFdlIGdhdmUgaXQgMiBieXRlcyBpbiAKb3JkZXIgdG8gYmUgYWJs ZSB0byByZWZlciAgbm90IG9ubHkgdG8gInN0YW5kYXJkIiBSQURJVVMgYXR0cmlidXRlcywgYnV0 IAphbHNvIHRvIGV4dGVuZGVkIGF0dHJpYnV0ZXMuIEJ1dCBhZnRlciB5b3VyIGV4cGxhbmF0aW9u LCBJIHRoaW5rIHRoYXQgd2UgCmNvdWxkIGVpdGhlciBpbmNsdWRlIGJvdGggcmVmZXJlbmNlcyAo VHlwZS9FeHQtVHlwZSwgMyBieXRlcyBpbiB0b3RhbCkgCm9yIGp1c3QgcmVmZXIgb25seSB0byB0 aGUgVHlwZSAoMSBieXRlKS4gRnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiAKZnJhZ21lbnRhdGlv biwgaXQgY291bGQgYmUgZW5vdWdoIHRvIGtub3cgdGhhdCB0aGUgYXR0cmlidXRlIChlLmcuIApW ZW5kb3ItU3BlY2lmaWMpIGlzIGZyYWdtZW50ZWQsIG5vIG1hdHRlciB0aGUga2luZCBvZiBWZW5k b3IgU3BlY2lmaWMgCmF0dHJpYnV0ZSB3ZSBhcmUgZGVhbGluZyB3aXRoLgoKPgo+PiAgIEF0dHJp YnV0ZXMgY2FuIGFsc28gb2NjdXIgbXVsdGlwbGUgdGltZXMgaW4gYSBwYWNrZXQsIHdpdGggZGlm ZmVyZW50Cj4+IHZhbHVlcy4gIGUuZy4gUHJveHktU3RhdGUuCj4gWW91IGFyZSByaWdodC4gVGhh dCBzaG91bGQgYmUgYWRkcmVzc2VkLiBBIHNpbXBsZSBwcm9wb3NhbCBjb3VsZCBmb2xsb3cgdGhl c2UgcnVsZXM6Cj4KPiAqIENodW5rZWQtQXR0cmlidXRlIG11c3QgYXBwZWFyIGJlZm9yZSB0aGUg YXR0cmlidXRlIGl0IHJlZmVycyB0byBpbiB0aGUgcGFja2V0ClJpZ2h0LgoKPgo+ICogSWYgYW4g YXR0cmlidXRlIG9jY3VycyBtdWx0aXBsZSB0aW1lcyBpbiBhIHJlcXVlc3QvcmVzcG9uc2UgKHdl IGNhbm5vdCBzcGVhayBoZXJlIG9mICJhIHBhY2tldCIpIGNodW5rcyBmb3Igb25seSBvbmUgb2Yg dGhlIG9jY3VycmVuY2VzLCBhc3NvY2lhdGVkIHRvIHRoZSBjb3JyZXNwb25kaW5nIENodW5rZWQt QXR0cmlidXRlLCBhcmUgYWxsb3dlZCBpbiBhIGdpdmVuIHBhY2tldAoKSSBkb24ndCBzZWUgd2h5 LiBJZiB5b3UgZmluZCBzb21ldGhpbmcgbGluZSAoQ0hVTktFRCwgWCwgWCwgWCwgQ0hVTkNLRUQs IApYLCBYKSB5b3UgY2FuIGVhc2lseSBhc3N1bWVkIHRoYXQgdGhlIGZpcnN0IFtYLFgsWF0gaXMg b25lIGF0dHJpYnV0ZSAKKFgxKSBhbmQgdGhlIHNlY29uZCBbWCxYXSBhIGRpZmZlcmVudCBvbmUg KFgyKSwgYXMgdGhlIGZpdmUgWHMgZG8gbm90IAphcHBlYXIgaW4gc2VxdWVuY2UuCgpOb3RlIHRo YXQgdGhpcyBzaXR1YXRpb24gY2FuIG9ubHkgb2NjdXIgaW4gdGhlIHBhY2tldCB3aGVyZSB0aGUg bGFzdCAKQ0hVTksgb2YgdGhlIGZpcnN0IGF0dHJpYnV0ZSBjb2luY2lkZSB3aXRoIHRoZSBmaXJz dCBDSFVOSyBvZiB0aGUgc2Vjb25kIAphdHRyaWJ1dGUuCkluIHRoZSBleGFtcGxlLCBYMSBhbmQg WDIgYXJlIGRpZmZlcmVudCBhdHRyaWJ1dGVzIG9mIHR5cGUgWC4KClBBQ0tFVDE6IENIVU5DS0VE LCBYMSwgWDEsIFgxLCBYMSwgWDEsIFgxLCBYMSwgWDEsIFgxClBBQ0tFVDI6IENIVU5DS0VELCBY MSwgWDEsIENIVU5DS0VELCBYMiwgWDIsIFgyLCBYMgpQQUNLRVQzOiBDSFVOQ0tFRCwgWDIsIFgy Cgo+Cj4gKiBOb24tZnJhZ21lbnRlZCB2YWx1ZXMgZm9yIHRoaXMgYXR0cmlidXRlIGNhbiBhcHBl YXIgaW4gYW55IHBhY2tldCwgYnV0IGFsd2F5cyBiZWZvcmUgdGhlIENodW5rZWQtQXR0cmlidXRl IHRoYXQgcmVmZXJzIHRvIGl0CgpJIGtpbmRhIGRvbid0IGxpa2UgdGhpcyBvbmUuIFdlIGNvdWxk IGZvcmNlIHRoZSBpbmNsdXNpb24gb2YgdGhlIApDSFVOQ0tFRCBhdHRyaWJ1dGUgaW4gdGhlc2Ug c2l0dWF0aW9ucywgZXZlbiB3aGVuIG5vIG5lZWRlZC4gRXhhbXBsZTogCkNIVU5DS0VEKHR5cGU9 WCwgdG90YWxfbGVuZ3RoPTIwMCwgc3RhcnRfcG9zPTAsIGVuZF9wb3M9MTk5KS4gQXMgCmV4cGxh aW5lZCBhYm92ZSwgdGhpcyB3b3VsZCBpbnNlcnQgYW4gYXR0cmlidXRlICh0aGUgQ0hVTkNLRUQg YXR0cmlidXRlKSAKYmV0d2VlbiBib3RoIG9jY3VycmVuY2VzIG9mIGF0dHJpYnV0ZSBYLCB0aHVz IGJyZWFraW5nIHRoZSBtaXNsZWFkaW5nIApzZXF1ZW5jZS4KCj4KPiAqIEFzIG1hbnkgQ2h1bmtl ZC1BdHRyaWJ1dGUgKGFuZCByZWZlcnJlZCBhdHRyaWJ1dGVzKSBtYXkgYXBwZWFyIGluIGEgZ2l2 ZW4gcGFja2V0IGFzIG5lY2Vzc2FyeS4KClJpZ2h0LCBhcyBkZXBpY3RlZCBpbiB0aGUgZXhhbXBs ZXMgYWJvdmUuCgpCZXN0IHJlZ2FyZHMsCkFsZWphbmRybwoKPgo+PiAgIElmIHRoaXMgZG9jdW1l bnQgaXMgcHVibGlzaGVkIHNvb24gYWZ0ZXIgdGhlIGV4dGVuc2lvbnMgZG9jdW1lbnQsIHRoZW4K Pj4gaXQgaGFzIGEgYmV0dGVyIGxpa2VsaWhvb2Qgb2YgYmVpbmcgaW1wbGVtZW50ZWQuCj4gR29v ZCBwb2ludCEKPgo+IEJlIGdvb2RlLAo+Cj4gLS0KPiAiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywg RG9jdG9yIEluZmllcm5vIgo+Cj4gRHIgRGllZ28gUi4gTG9wZXoKPiBUZWxlZm9uaWNhIEkrRAo+ Cj4gZS1tYWlsOiBkaWVnb0B0aWQuZXMKPiBUZWw6ICAgICAgKzM0IDkxMyAxMjkgMDQxCj4gTW9i aWxlOiArMzQgNjgyIDA1MSAwOTEKPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQo+Cj4KPiBFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRv IG3DoXMgYWJham8uCj4gVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBp dHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lz IG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Lgo+IGh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMv ZGlzY2xhaW1lci5hc3B4Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QKcmFkZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0Cg== From radext-bounces@ietf.org Thu Jan 5 08:06:12 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02E721F87EB; Thu, 5 Jan 2012 08:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325779572; bh=mVfUAnHK+n0gIOMelZKxewlfGVn3PNrukpLcx7o44Nw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=A42H3pFuhHWkgw+2M3La0Z+fuvkDz6H5AFI04cJVZs11tQXR6tJN6wc5WO/uSbyLg MNaafHVgGmUW/AaCLKvYcsX3jyjucRKwDcITuCJQgQK7HmpDjKrJIIupJhFfBaw1w7 z1dVJU2o5Cv3ucAowP2yiHAR28ym7vgDEsGT4fQY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6921F87B8; Thu, 5 Jan 2012 08:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+G2dF9mKRDc; Thu, 5 Jan 2012 08:06:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B121F8688; Thu, 5 Jan 2012 08:06:10 -0800 (PST) Message-ID: <4F05CA5A.2030602@deployingradius.com> Date: Thu, 05 Jan 2012 17:05:46 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org DIEGO LOPEZ GARCIA wrote: > I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods. IMHO, that kind of solution should be avoided. > * Chunked-Attribute must appear before the attribute it refers to in the packet RADIUS doesn't impose ordering on attributes of different type. That's a strong reason to integrate chunking inside of the attribute format. > * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet Why? RADIUS allows for multiple attributes of the same type, with different value. > * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it See comment about attribute ordering. > * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary. I think this document is intended to solve one *very* limited use-case. It doesn't address any more general case. It relies on fixed attribute ordering, which is explicitly not required. I gave comments on your approach. Do you have any comments on my proposed alternative? It would seem to (a) solve the same problem, and (b) have none of the limitations. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Jan 5 08:06:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6921F87B8; Thu, 5 Jan 2012 08:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+G2dF9mKRDc; Thu, 5 Jan 2012 08:06:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B121F8688; Thu, 5 Jan 2012 08:06:10 -0800 (PST) Message-ID: <4F05CA5A.2030602@deployingradius.com> Date: Thu, 05 Jan 2012 17:05:46 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:06:11 -0000 DIEGO LOPEZ GARCIA wrote: > I'm afraid there is a misunderstanding. The Chunked-Atrribute is an attribute on its own that contains only a reference to the attribute being chunked. It has to appear in all the packets containing chunks of attributes, as many as attributes they refer to. Chunks are intended to be encoded following the usual encoding methods. IMHO, that kind of solution should be avoided. > * Chunked-Attribute must appear before the attribute it refers to in the packet RADIUS doesn't impose ordering on attributes of different type. That's a strong reason to integrate chunking inside of the attribute format. > * If an attribute occurs multiple times in a request/response (we cannot speak here of "a packet") chunks for only one of the occurrences, associated to the corresponding Chunked-Attribute, are allowed in a given packet Why? RADIUS allows for multiple attributes of the same type, with different value. > * Non-fragmented values for this attribute can appear in any packet, but always before the Chunked-Attribute that refers to it See comment about attribute ordering. > * As many Chunked-Attribute (and referred attributes) may appear in a given packet as necessary. I think this document is intended to solve one *very* limited use-case. It doesn't address any more general case. It relies on fixed attribute ordering, which is explicitly not required. I gave comments on your approach. Do you have any comments on my proposed alternative? It would seem to (a) solve the same problem, and (b) have none of the limitations. Alan DeKok. From radext-bounces@ietf.org Thu Jan 5 08:08:13 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CDE21F8680; Thu, 5 Jan 2012 08:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325779693; bh=+pBAnoALOifW8V4LVLfkFg1ktURsGJNwETJg7I7FKeY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ObXMzbrJx+ag6xCjGNZE8m3MDtflFOpyUqZwPm1R6nTc8QXg98jN+vKjEwRlTft/F bYkmnjG3a/PutEOY5z4y+rZeprzNx98C/T1+7gmDyLUJlTViWIhZeyuCNJeWZ3C5CL s6tLrJoo4DbYlsgWL2upG9Qw8sgwRpRlH+X+NulE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4A21F8680 for ; Thu, 5 Jan 2012 08:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF1VwUL+rjE9 for ; Thu, 5 Jan 2012 08:08:12 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9675321F8655 for ; Thu, 5 Jan 2012 08:08:12 -0800 (PST) Message-ID: <4F05CAD1.1010101@deployingradius.com> Date: Thu, 05 Jan 2012 17:07:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, alex@um.es Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > RFC 6158 Section 3.1 lays out the potential alternatives for solving > this problem. An example of > approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which > enable EAP frames > larger than the MTU to be split across RADIUS packets. This would not > necessarily require a > change to the attribute format, just a mechanism that would define a > SAML encapsulation handling > fragmentation/reassembly, as EAP methods such as EAP-TLS do. After all, > the EAP-Method > attribute did not require definition of a new data type or attribute > format. Another alternative would be to leverage the use of "Authorize Only". I think I've pointed that out previously on this list. i.e. after authentication, use State && Access-Request + Authorize-Only, and Access-Challenge to get as much additional data as you want. That doesn't solve the ">4K length attribute" problem, but it does take one slice out of the problem space. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Jan 5 08:08:13 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD4A21F8680 for ; Thu, 5 Jan 2012 08:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.622, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF1VwUL+rjE9 for ; Thu, 5 Jan 2012 08:08:12 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9675321F8655 for ; Thu, 5 Jan 2012 08:08:12 -0800 (PST) Message-ID: <4F05CAD1.1010101@deployingradius.com> Date: Thu, 05 Jan 2012 17:07:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, alex@um.es Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:08:13 -0000 Bernard Aboba wrote: > RFC 6158 Section 3.1 lays out the potential alternatives for solving > this problem. An example of > approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which > enable EAP frames > larger than the MTU to be split across RADIUS packets. This would not > necessarily require a > change to the attribute format, just a mechanism that would define a > SAML encapsulation handling > fragmentation/reassembly, as EAP methods such as EAP-TLS do. After all, > the EAP-Method > attribute did not require definition of a new data type or attribute > format. Another alternative would be to leverage the use of "Authorize Only". I think I've pointed that out previously on this list. i.e. after authentication, use State && Access-Request + Authorize-Only, and Access-Challenge to get as much additional data as you want. That doesn't solve the ">4K length attribute" problem, but it does take one slice out of the problem space. Alan DeKok. From radext-bounces@ietf.org Thu Jan 5 08:10:32 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CFF21F8719; Thu, 5 Jan 2012 08:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325779832; bh=J1Or7cQIOBKQ9IaLP+tZ8jaAL/peSLVQWw+0EPUXlc8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LDfHkOscsbXc20c1u65M1SCD4fCm9lhhYB2dovFYz3TOKk/sEkAL+TQltjjfoC1Dm IVXfORT8IZXWrYsBqgHulwGUd/7WyuszA9NPtN/gbRa20a1aQMiGdJyEq8V5SqHS6i D/Cq9GCwEYk11lh11lLuqWj+gdvCYVie1fndcHjA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1121F878E; Thu, 5 Jan 2012 08:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxc9Ckk6GsCk; Thu, 5 Jan 2012 08:10:30 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 091DF21F8719; Thu, 5 Jan 2012 08:10:30 -0800 (PST) Message-ID: <4F05CB4F.9010104@deployingradius.com> Date: Thu, 05 Jan 2012 17:09:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F055F44.2010606@um.es> In-Reply-To: <4F055F44.2010606@um.es> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alejandro Perez Mendez wrote: > But after your explanation, I think that we > could either include both references (Type/Ext-Type, 3 bytes in total) > or just refer only to the Type (1 byte). From the point of view of > fragmentation, it could be enough to know that the attribute (e.g. > Vendor-Specific) is fragmented, no matter the kind of Vendor Specific > attribute we are dealing with. I don't understand how that would work. My previous proposal to use a flag field could potentially work for the new extended VSA format, too. > I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, > X, X) you can easily assumed that the first [X,X,X] is one attribute > (X1) and the second [X,X] a different one (X2), as the five Xs do not > appear in sequence. Which relies on attribute ordering. That's a fatal flaw for any proposal. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Jan 5 08:10:31 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1121F878E; Thu, 5 Jan 2012 08:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxc9Ckk6GsCk; Thu, 5 Jan 2012 08:10:30 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 091DF21F8719; Thu, 5 Jan 2012 08:10:30 -0800 (PST) Message-ID: <4F05CB4F.9010104@deployingradius.com> Date: Thu, 05 Jan 2012 17:09:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F055F44.2010606@um.es> In-Reply-To: <4F055F44.2010606@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:10:31 -0000 Alejandro Perez Mendez wrote: > But after your explanation, I think that we > could either include both references (Type/Ext-Type, 3 bytes in total) > or just refer only to the Type (1 byte). From the point of view of > fragmentation, it could be enough to know that the attribute (e.g. > Vendor-Specific) is fragmented, no matter the kind of Vendor Specific > attribute we are dealing with. I don't understand how that would work. My previous proposal to use a flag field could potentially work for the new extended VSA format, too. > I don't see why. If you find something line (CHUNKED, X, X, X, CHUNCKED, > X, X) you can easily assumed that the first [X,X,X] is one attribute > (X1) and the second [X,X] a different one (X2), as the five Xs do not > appear in sequence. Which relies on attribute ordering. That's a fatal flaw for any proposal. Alan DeKok. From alex@um.es Thu Jan 5 08:34:04 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804B921F8801 for ; Thu, 5 Jan 2012 08:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG6U3AIhQ59i for ; Thu, 5 Jan 2012 08:34:03 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id A05FD21F87FE for ; Thu, 5 Jan 2012 08:34:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 745625D4B8; Thu, 5 Jan 2012 17:34:00 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KTPFeQRnLAed; Thu, 5 Jan 2012 17:33:59 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 4BC785D462; Thu, 5 Jan 2012 17:33:57 +0100 (CET) Message-ID: <4F05D0F4.8090901@um.es> Date: Thu, 05 Jan 2012 17:33:56 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Bernard Aboba References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020208030908090608050406" Cc: radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:34:04 -0000 This is a multi-part message in MIME format. --------------020208030908090608050406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Bernard, thanks for your response. Sadly, none of them work for our purposes. Approach #1 does not work for us since we are looking for a generic fragmentation, valid for any attribute, not a fragmentation specific for the SAML attribute. Approach #2 does not work for us since out-of-band protocols were already discussed in ABFAB group and rejected to be used for this specific matter. The SAML attribute must be transported over the RADIUS protocol, to avoid relaying on a different trust infrastructure. (see the discussion http://www.ietf.org/mail-archive/web/abfab/current/msg01116.html) Best regards, Alejandro > RFC 6158 Section 3.1 lays out the potential alternatives for solving > this problem. An example of > approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which > enable EAP frames > larger than the MTU to be split across RADIUS packets. This would not > necessarily require a > change to the attribute format, just a mechanism that would define a > SAML encapsulation handling > fragmentation/reassembly, as EAP methods such as EAP-TLS do. After > all, the EAP-Method > attribute did not require definition of a new data type or attribute > format. > > Approach #2 could involve using a URL to enable retrieval of SAML > out-of-band. This approach > has been used with other protocols encountering fragmentation issues, > such as IKE, and has worked > well. > > Approach #3 cannot be guaranteed to work in all circumstances, so that > it needs to be used > alongside approaches #1 or #2. > > The Length field in the RADIUS packet header is defined in[RFC2865] > Section 3 . It is noted there that the maximum length of a RADIUS > packet is 4096 octets. As a result, attribute designers SHOULD NOT > assume that a RADIUS implementation can successfully process RADIUS > packets larger than 4096 octets. > > Even when packets are less than 4096 octets, they may be larger than > the Path Maximum Transmission Unit (PMTU). Any packet larger than > the PMTU will be fragmented, making communications more brittle as > firewalls and filtering devices often discard fragments. Transport > of fragmented UDP packets appears to be a poorly tested code path on > network devices. Some devices appear to be incapable of transporting > fragmented UDP packets, making it difficult to deploy RADIUS in a > network where those devices are deployed. We RECOMMEND that RADIUS > messages be kept as small possible. > > If a situation is envisaged where it may be necessary to carry > authentication, authorization, or accounting data in a packet larger > than 4096 octets, then one of the following approaches is > RECOMMENDED: > > 1. Utilization of a sequence of packets. > For RADIUS authentication, a sequence of Access- > Request/Access-Challenge packets would be used. For this to > be feasible, attribute designers need to enable inclusion of > attributes that can consume considerable space within Access- > Challenge packets. To maintain compatibility with existing > NASes, either the use of Access-Challenge packets needs to be > permissible (as with RADIUS/EAP, defined in [RFC3579 ]) or > support for receipt of an Access-Challenge needs to be > indicated by the NAS (as in RADIUS Location [RFC5580 ]). Also, > the specification needs to clearly describe how attribute > splitting is to be signaled and how attributes included within > the sequence are to be interpreted, without requiring stateful > operation. Unfortunately, previous specifications have not > always exhibited the required foresight. For example, even > though very large filter rules are conceivable, the NAS- > Filter-Rule Attribute defined in [RFC4849 ] is not permitted in > an Access-Challenge packet, nor is a mechanism specified to > allow a set of NAS-Filter-Rule Attributes to be split across > an Access-Request/Access-Challenge sequence. > > In the case of RADIUS accounting, transporting large amounts > of data would require a sequence of Accounting-Request > packets. This is a non-trivial change to RADIUS, since RADIUS > accounting clients would need to be modified to split the > attribute stream across multiple Accounting-Requests, and > billing servers would need to be modified to reassemble and > interpret the attribute stream. > > 2. Utilization of names rather than values. > Where an attribute relates to a policy that could conceivably > be pre-provisioned on the NAS, then the name of the pre- > provisioned policy can be transmitted in an attribute rather > than the policy itself, which could be quite large. An > example of this is the Filter-Id Attribute defined in > [RFC2865], Section 5.11 , which enables a set of pre- > provisioned filter rules to be referenced by name. > > 3. Utilization of Packetization Layer Path MTU Discovery > techniques, as specified in [RFC4821 ]. > As a last resort, where the above techniques cannot be made to > work, it may be possible to apply the techniques described in > [RFC4821 ] to discover the maximum supported RADIUS packet size > on the path between a RADIUS client and a home server. While > such an approach can avoid the complexity of utilization of a > sequence of packets, dynamic discovery is likely to be time > consuming and cannot be guaranteed to work with existing > RADIUS implementations. As a result, this technique is not > generally applicable. > > > ------------------------------------------------------------------------ > Date: Wed, 4 Jan 2012 10:34:01 +0100 > From: alex@um.es > To: radext@ietf.org > Subject: [radext] Fwd: New Version Notification for > draft-perez-radext-radius-fragmentation-00.txt > > FYI. > > This motivation of this document comes from the necessity in the ABFAB > WG of sending SAML Messages transported into RADIUS attributes. These > SAML Messages can potentially be bigger than 4 KB, thus a mechanism to > fragment them is required. > > -------- Mensaje original -------- > Asunto: New Version Notification for > draft-perez-radext-radius-fragmentation-00.txt > Fecha: Wed, 04 Jan 2012 01:21:53 -0800 > De: internet-drafts@ietf.org > Para: alex@um.es > > > A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. > > Filename: draft-perez-radext-radius-fragmentation > Revision: 00 > Title: Fragmentation support across RADIUS packets > Creation date: 2012-01-04 > WG ID: Individual Submission > Number of pages: 10 > > Abstract: > This document describes a mechanism providing fragmentation support > of RADIUS attributes across several RADIUS packets. This is intended > to support attributes that exceed the 4 KB limit per RADIUS packet. > > > > > The IETF Secretariat > > _______________________________________________ radext mailing list > radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --------------020208030908090608050406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Bernard,

thanks for your response. Sadly, none of them work for our purposes.

Approach #1 does not work for us since we are looking for a generic fragmentation, valid for any attribute, not a fragmentation specific for the SAML attribute.

Approach #2 does not work for us since out-of-band protocols were already discussed in ABFAB group and rejected to be used for this specific matter. The SAML attribute must be transported over the RADIUS protocol, to avoid relaying on a different trust infrastructure. (see the discussion http://www.ietf.org/mail-archive/web/abfab/current/msg01116.html)

Best regards,
Alejandro


RFC 6158 Section 3.1 lays out the potential alternatives for solving this problem.  An example of
approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which enable EAP frames
larger than the MTU to be split across RADIUS packets.  This would not necessarily require a
change to the attribute format, just a mechanism that would define a SAML encapsulation handling
fragmentation/reassembly, as EAP methods such as EAP-TLS do.  After all, the EAP-Method
attribute did not require definition of a new data type or attribute format.

Approach #2 could involve using a URL to enable retrieval of SAML out-of-band.  This approach
has been used with other protocols encountering fragmentation issues, such as IKE,  and has worked
well.

Approach #3 cannot be guaranteed to work in all circumstances, so that it needs to be used
alongside approaches #1 or #2. 

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.

   Even when packets are less than 4096 octets, they may be larger than
   the Path Maximum Transmission Unit (PMTU).  Any packet larger than
   the PMTU will be fragmented, making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears to be a poorly tested code path on
   network devices.  Some devices appear to be incapable of transporting
   fragmented UDP packets, making it difficult to deploy RADIUS in a
   network where those devices are deployed.  We RECOMMEND that RADIUS
   messages be kept as small possible.

   If a situation is envisaged where it may be necessary to carry
   authentication, authorization, or accounting data in a packet larger
   than 4096 octets, then one of the following approaches is
   RECOMMENDED:

      1.  Utilization of a sequence of packets.
          For RADIUS authentication, a sequence of Access-
          Request/Access-Challenge packets would be used.  For this to
          be feasible, attribute designers need to enable inclusion of
          attributes that can consume considerable space within Access-
          Challenge packets.  To maintain compatibility with existing
          NASes, either the use of Access-Challenge packets needs to be
          permissible (as with RADIUS/EAP, defined in [RFC3579]) or
          support for receipt of an Access-Challenge needs to be
          indicated by the NAS (as in RADIUS Location [RFC5580]).  Also,
          the specification needs to clearly describe how attribute
          splitting is to be signaled and how attributes included within
          the sequence are to be interpreted, without requiring stateful
          operation.  Unfortunately, previous specifications have not
          always exhibited the required foresight.  For example, even
          though very large filter rules are conceivable, the NAS-
          Filter-Rule Attribute defined in [RFC4849] is not permitted in
          an Access-Challenge packet, nor is a mechanism specified to
          allow a set of NAS-Filter-Rule Attributes to be split across
          an Access-Request/Access-Challenge sequence.

          In the case of RADIUS accounting, transporting large amounts
          of data would require a sequence of Accounting-Request
          packets.  This is a non-trivial change to RADIUS, since RADIUS
          accounting clients would need to be modified to split the
          attribute stream across multiple Accounting-Requests, and
          billing servers would need to be modified to reassemble and
          interpret the attribute stream.

      2.  Utilization of names rather than values.
          Where an attribute relates to a policy that could conceivably
          be pre-provisioned on the NAS, then the name of the pre-
          provisioned policy can be transmitted in an attribute rather
          than the policy itself, which could be quite large.  An
          example of this is the Filter-Id Attribute defined in
          [RFC2865], Section 5.11, which enables a set of pre-
          provisioned filter rules to be referenced by name.

      3.  Utilization of Packetization Layer Path MTU Discovery
          techniques, as specified in [RFC4821].
          As a last resort, where the above techniques cannot be made to
          work, it may be possible to apply the techniques described in
          [RFC4821] to discover the maximum supported RADIUS packet size
          on the path between a RADIUS client and a home server.  While
          such an approach can avoid the complexity of utilization of a
          sequence of packets, dynamic discovery is likely to be time
          consuming and cannot be guaranteed to work with existing
          RADIUS implementations.  As a result, this technique is not
          generally applicable.


Date: Wed, 4 Jan 2012 10:34:01 +0100
From: alex@um.es
To: radext@ietf.org
Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt

FYI.

This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB, thus a mechanism to fragment them is required.

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed, 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 

A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                                  


The IETF Secretariat

_______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
--------------020208030908090608050406-- From radext-bounces@ietf.org Thu Jan 5 08:34:05 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EC621F87FF; Thu, 5 Jan 2012 08:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325781245; bh=aTNJqNMweN0jVhP88xpYYum8wYKMtsvIZcXxUDCpcw4=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=pqVF/e3HmKzsaQUx6Sq7DlvvmiHIATShzs64JNko1DS1yH7m/piydHQZeJM9l6lvl lwY9Es/LWSH6Vc7Qa9j8nPhZr9b0eKVP2LcQT/xxBYxUY2CBxZjb8QW6WffK1Gypmu A9kfQqrCqVfbbBOpT1huJ5D3RYuXNIFzq1GNc/y4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804B921F8801 for ; Thu, 5 Jan 2012 08:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG6U3AIhQ59i for ; Thu, 5 Jan 2012 08:34:03 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id A05FD21F87FE for ; Thu, 5 Jan 2012 08:34:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 745625D4B8; Thu, 5 Jan 2012 17:34:00 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KTPFeQRnLAed; Thu, 5 Jan 2012 17:33:59 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 4BC785D462; Thu, 5 Jan 2012 17:33:57 +0100 (CET) Message-ID: <4F05D0F4.8090901@um.es> Date: Thu, 05 Jan 2012 17:33:56 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Bernard Aboba References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> In-Reply-To: Cc: radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0389448548970563291==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============0389448548970563291== Content-Type: multipart/alternative; boundary="------------020208030908090608050406" This is a multi-part message in MIME format. --------------020208030908090608050406 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Bernard, thanks for your response. Sadly, none of them work for our purposes. Approach #1 does not work for us since we are looking for a generic fragmentation, valid for any attribute, not a fragmentation specific for the SAML attribute. Approach #2 does not work for us since out-of-band protocols were already discussed in ABFAB group and rejected to be used for this specific matter. The SAML attribute must be transported over the RADIUS protocol, to avoid relaying on a different trust infrastructure. (see the discussion http://www.ietf.org/mail-archive/web/abfab/current/msg01116.html) Best regards, Alejandro > RFC 6158 Section 3.1 lays out the potential alternatives for solving > this problem. An example of > approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which > enable EAP frames > larger than the MTU to be split across RADIUS packets. This would not > necessarily require a > change to the attribute format, just a mechanism that would define a > SAML encapsulation handling > fragmentation/reassembly, as EAP methods such as EAP-TLS do. After > all, the EAP-Method > attribute did not require definition of a new data type or attribute > format. > > Approach #2 could involve using a URL to enable retrieval of SAML > out-of-band. This approach > has been used with other protocols encountering fragmentation issues, > such as IKE, and has worked > well. > > Approach #3 cannot be guaranteed to work in all circumstances, so that > it needs to be used > alongside approaches #1 or #2. > > The Length field in the RADIUS packet header is defined in[RFC2865] > Section 3 . It is noted there that the maximum length of a RADIUS > packet is 4096 octets. As a result, attribute designers SHOULD NOT > assume that a RADIUS implementation can successfully process RADIUS > packets larger than 4096 octets. > > Even when packets are less than 4096 octets, they may be larger than > the Path Maximum Transmission Unit (PMTU). Any packet larger than > the PMTU will be fragmented, making communications more brittle as > firewalls and filtering devices often discard fragments. Transport > of fragmented UDP packets appears to be a poorly tested code path on > network devices. Some devices appear to be incapable of transporting > fragmented UDP packets, making it difficult to deploy RADIUS in a > network where those devices are deployed. We RECOMMEND that RADIUS > messages be kept as small possible. > > If a situation is envisaged where it may be necessary to carry > authentication, authorization, or accounting data in a packet larger > than 4096 octets, then one of the following approaches is > RECOMMENDED: > > 1. Utilization of a sequence of packets. > For RADIUS authentication, a sequence of Access- > Request/Access-Challenge packets would be used. For this to > be feasible, attribute designers need to enable inclusion of > attributes that can consume considerable space within Access- > Challenge packets. To maintain compatibility with existing > NASes, either the use of Access-Challenge packets needs to be > permissible (as with RADIUS/EAP, defined in [RFC3579 ]) or > support for receipt of an Access-Challenge needs to be > indicated by the NAS (as in RADIUS Location [RFC5580 ]). Also, > the specification needs to clearly describe how attribute > splitting is to be signaled and how attributes included within > the sequence are to be interpreted, without requiring stateful > operation. Unfortunately, previous specifications have not > always exhibited the required foresight. For example, even > though very large filter rules are conceivable, the NAS- > Filter-Rule Attribute defined in [RFC4849 ] is not permitted in > an Access-Challenge packet, nor is a mechanism specified to > allow a set of NAS-Filter-Rule Attributes to be split across > an Access-Request/Access-Challenge sequence. > > In the case of RADIUS accounting, transporting large amounts > of data would require a sequence of Accounting-Request > packets. This is a non-trivial change to RADIUS, since RADIUS > accounting clients would need to be modified to split the > attribute stream across multiple Accounting-Requests, and > billing servers would need to be modified to reassemble and > interpret the attribute stream. > > 2. Utilization of names rather than values. > Where an attribute relates to a policy that could conceivably > be pre-provisioned on the NAS, then the name of the pre- > provisioned policy can be transmitted in an attribute rather > than the policy itself, which could be quite large. An > example of this is the Filter-Id Attribute defined in > [RFC2865], Section 5.11 , which enables a set of pre- > provisioned filter rules to be referenced by name. > > 3. Utilization of Packetization Layer Path MTU Discovery > techniques, as specified in [RFC4821 ]. > As a last resort, where the above techniques cannot be made to > work, it may be possible to apply the techniques described in > [RFC4821 ] to discover the maximum supported RADIUS packet size > on the path between a RADIUS client and a home server. While > such an approach can avoid the complexity of utilization of a > sequence of packets, dynamic discovery is likely to be time > consuming and cannot be guaranteed to work with existing > RADIUS implementations. As a result, this technique is not > generally applicable. > > > ------------------------------------------------------------------------ > Date: Wed, 4 Jan 2012 10:34:01 +0100 > From: alex@um.es > To: radext@ietf.org > Subject: [radext] Fwd: New Version Notification for > draft-perez-radext-radius-fragmentation-00.txt > > FYI. > > This motivation of this document comes from the necessity in the ABFAB > WG of sending SAML Messages transported into RADIUS attributes. These > SAML Messages can potentially be bigger than 4 KB, thus a mechanism to > fragment them is required. > > -------- Mensaje original -------- > Asunto: New Version Notification for > draft-perez-radext-radius-fragmentation-00.txt > Fecha: Wed, 04 Jan 2012 01:21:53 -0800 > De: internet-drafts@ietf.org > Para: alex@um.es > > > A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. > > Filename: draft-perez-radext-radius-fragmentation > Revision: 00 > Title: Fragmentation support across RADIUS packets > Creation date: 2012-01-04 > WG ID: Individual Submission > Number of pages: 10 > > Abstract: > This document describes a mechanism providing fragmentation support > of RADIUS attributes across several RADIUS packets. This is intended > to support attributes that exceed the 4 KB limit per RADIUS packet. > > > > > The IETF Secretariat > > _______________________________________________ radext mailing list > radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --------------020208030908090608050406 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Bernard,

thanks for your response. Sadly, none of them work for our purposes.

Approach #1 does not work for us since we are looking for a generic fragmentation, valid for any attribute, not a fragmentation specific for the SAML attribute.

Approach #2 does not work for us since out-of-band protocols were already discussed in ABFAB group and rejected to be used for this specific matter. The SAML attribute must be transported over the RADIUS protocol, to avoid relaying on a different trust infrastructure. (see the discussion http://www.ietf.org/mail-archive/web/abfab/current/msg01116.html)

Best regards,
Alejandro


RFC 6158 Section 3.1 lays out the potential alternatives for solving this problem.  An example of
approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which enable EAP frames
larger than the MTU to be split across RADIUS packets.  This would not necessarily require a
change to the attribute format, just a mechanism that would define a SAML encapsulation handling
fragmentation/reassembly, as EAP methods such as EAP-TLS do.  After all, the EAP-Method
attribute did not require definition of a new data type or attribute format.

Approach #2 could involve using a URL to enable retrieval of SAML out-of-band.  This approach
has been used with other protocols encountering fragmentation issues, such as IKE,  and has worked
well.

Approach #3 cannot be guaranteed to work in all circumstances, so that it needs to be used
alongside approaches #1 or #2. 

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT
   assume that a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.

   Even when packets are less than 4096 octets, they may be larger than
   the Path Maximum Transmission Unit (PMTU).  Any packet larger than
   the PMTU will be fragmented, making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears to be a poorly tested code path on
   network devices.  Some devices appear to be incapable of transporting
   fragmented UDP packets, making it difficult to deploy RADIUS in a
   network where those devices are deployed.  We RECOMMEND that RADIUS
   messages be kept as small possible.

   If a situation is envisaged where it may be necessary to carry
   authentication, authorization, or accounting data in a packet larger
   than 4096 octets, then one of the following approaches is
   RECOMMENDED:

      1.  Utilization of a sequence of packets.
          For RADIUS authentication, a sequence of Access-
          Request/Access-Challenge packets would be used.  For this to
          be feasible, attribute designers need to enable inclusion of
          attributes that can consume considerable space within Access-
          Challenge packets.  To maintain compatibility with existing
          NASes, either the use of Access-Challenge packets needs to be
          permissible (as with RADIUS/EAP, defined in [RFC3579]) or
          support for receipt of an Access-Challenge needs to be
          indicated by the NAS (as in RADIUS Location [RFC5580]).  Also,
          the specification needs to clearly describe how attribute
          splitting is to be signaled and how attributes included within
          the sequence are to be interpreted, without requiring stateful
          operation.  Unfortunately, previous specifications have not
          always exhibited the required foresight.  For example, even
          though very large filter rules are conceivable, the NAS-
          Filter-Rule Attribute defined in [RFC4849] is not permitted in
          an Access-Challenge packet, nor is a mechanism specified to
          allow a set of NAS-Filter-Rule Attributes to be split across
          an Access-Request/Access-Challenge sequence.

          In the case of RADIUS accounting, transporting large amounts
          of data would require a sequence of Accounting-Request
          packets.  This is a non-trivial change to RADIUS, since RADIUS
          accounting clients would need to be modified to split the
          attribute stream across multiple Accounting-Requests, and
          billing servers would need to be modified to reassemble and
          interpret the attribute stream.

      2.  Utilization of names rather than values.
          Where an attribute relates to a policy that could conceivably
          be pre-provisioned on the NAS, then the name of the pre-
          provisioned policy can be transmitted in an attribute rather
          than the policy itself, which could be quite large.  An
          example of this is the Filter-Id Attribute defined in
          [RFC2865], Section 5.11, which enables a set of pre-
          provisioned filter rules to be referenced by name.

      3.  Utilization of Packetization Layer Path MTU Discovery
          techniques, as specified in [RFC4821].
          As a last resort, where the above techniques cannot be made to
          work, it may be possible to apply the techniques described in
          [RFC4821] to discover the maximum supported RADIUS packet size
          on the path between a RADIUS client and a home server.  While
          such an approach can avoid the complexity of utilization of a
          sequence of packets, dynamic discovery is likely to be time
          consuming and cannot be guaranteed to work with existing
          RADIUS implementations.  As a result, this technique is not
          generally applicable.


Date: Wed, 4 Jan 2012 10:34:01 +0100
From: alex@um.es
To: radext@ietf.org
Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt

FYI.

This motivation of this document comes from the necessity in the ABFAB WG of sending SAML Messages transported into RADIUS attributes. These SAML Messages can potentially be bigger than 4 KB, thus a mechanism to fragment them is required.

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt
Fecha: Wed, 04 Jan 2012 01:21:53 -0800
De: internet-drafts@ietf.org
Para: alex@um.es 

A new version of I-D, draft-perez-radext-radius-fragmentation-00.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 00
Title:		 Fragmentation support across RADIUS packets
Creation date:	 2012-01-04
WG ID:		 Individual Submission
Number of pages: 10

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS attributes across several RADIUS packets.  This is intended
   to support attributes that exceed the 4 KB limit per RADIUS packet.

                                                                                  


The IETF Secretariat

_______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
--------------020208030908090608050406-- --===============0389448548970563291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0389448548970563291==-- From alex@um.es Thu Jan 5 08:35:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A380621F87C8 for ; Thu, 5 Jan 2012 08:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEQ1bxtb2c12 for ; Thu, 5 Jan 2012 08:35:46 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id F16C421F870F for ; Thu, 5 Jan 2012 08:35:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 86DEA4BB06; Thu, 5 Jan 2012 17:35:44 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zHPljbGAd81k; Thu, 5 Jan 2012 17:35:44 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id B3DE64B93E; Thu, 5 Jan 2012 17:35:38 +0100 (CET) Message-ID: <4F05D15A.9080400@um.es> Date: Thu, 05 Jan 2012 17:35:38 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> <4F05CAD1.1010101@deployingradius.com> In-Reply-To: <4F05CAD1.1010101@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:35:46 -0000 > Bernard Aboba wrote: >> RFC 6158 Section 3.1 lays out the potential alternatives for solving >> this problem. An example of >> approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which >> enable EAP frames >> larger than the MTU to be split across RADIUS packets. This would not >> necessarily require a >> change to the attribute format, just a mechanism that would define a >> SAML encapsulation handling >> fragmentation/reassembly, as EAP methods such as EAP-TLS do. After all, >> the EAP-Method >> attribute did not require definition of a new data type or attribute >> format. > Another alternative would be to leverage the use of "Authorize Only". > I think I've pointed that out previously on this list. Yes, you did. And I agree that would help for authorization data, but not for a generic attribute fragmentation solution. Anyway, as you pointed out, that does not solve the >4K problem. Best regards, Alejandro > > i.e. after authentication, use State&& Access-Request + > Authorize-Only, and Access-Challenge to get as much additional data as > you want. > > That doesn't solve the ">4K length attribute" problem, but it does > take one slice out of the problem space. > > Alan DeKok. From radext-bounces@ietf.org Thu Jan 5 08:35:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6C21F87C8; Thu, 5 Jan 2012 08:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325781348; bh=JmKNrYbV0rONomlwWvtXpI7iSnybEplrhtAX1I4J8y8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=FwZMZ5CvwDgiJdqFEBD4th4QiwLX/pVJNIyly5D8faTIy5Pljz3NysmhEtAx4qbOs dLSM9MQVK3+aVuHHjqAlTPG5/UGDk6r4lAitHF7ju50yKG8fG2aSl3jVBVzFha1eAa qIpYBttKhSHRfuLqMS/YeFmoBTr6rZ92/8nwZCSo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A380621F87C8 for ; Thu, 5 Jan 2012 08:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEQ1bxtb2c12 for ; Thu, 5 Jan 2012 08:35:46 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id F16C421F870F for ; Thu, 5 Jan 2012 08:35:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 86DEA4BB06; Thu, 5 Jan 2012 17:35:44 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zHPljbGAd81k; Thu, 5 Jan 2012 17:35:44 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id B3DE64B93E; Thu, 5 Jan 2012 17:35:38 +0100 (CET) Message-ID: <4F05D15A.9080400@um.es> Date: Thu, 05 Jan 2012 17:35:38 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com>, <4F041D09.2060905@um.es> <4F05CAD1.1010101@deployingradius.com> In-Reply-To: <4F05CAD1.1010101@deployingradius.com> Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org > Bernard Aboba wrote: >> RFC 6158 Section 3.1 lays out the potential alternatives for solving >> this problem. An example of >> approach #1 is taken by EAP methods such as EAP TLS (RFC 5716) which >> enable EAP frames >> larger than the MTU to be split across RADIUS packets. This would not >> necessarily require a >> change to the attribute format, just a mechanism that would define a >> SAML encapsulation handling >> fragmentation/reassembly, as EAP methods such as EAP-TLS do. After all, >> the EAP-Method >> attribute did not require definition of a new data type or attribute >> format. > Another alternative would be to leverage the use of "Authorize Only". > I think I've pointed that out previously on this list. Yes, you did. And I agree that would help for authorization data, but not for a generic attribute fragmentation solution. Anyway, as you pointed out, that does not solve the >4K problem. Best regards, Alejandro > > i.e. after authentication, use State&& Access-Request + > Authorize-Only, and Access-Challenge to get as much additional data as > you want. > > That doesn't solve the ">4K length attribute" problem, but it does > take one slice out of the problem space. > > Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Jan 5 08:54:30 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9BE21F8804 for ; Thu, 5 Jan 2012 08:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTIFcqG9RrwW for ; Thu, 5 Jan 2012 08:54:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D37CD21F881F for ; Thu, 5 Jan 2012 08:54:26 -0800 (PST) Message-ID: <4F05D5A7.5070501@deployingradius.com> Date: Thu, 05 Jan 2012 17:53:59 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'radext mailing list' Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:54:30 -0000 Peter Deacon wrote: > The necessary ordering constraints do not seem to be there in existing > RFCS to prevent long attributes from being corrupted. This is important > since a design goal was to allow attributes to be forwarded by systems > not supporting this draft. .. > 1. SHOULD is not enough. > 2. Preserving order is not enough. I agree with (1). However, most implementations *do* preserve ordering. Maybe the document could be updated to say implementations MUST preserve ordering. > This not only corrupts the data but also corrupts the attributes > extended type. This can be dangerous in the wrong hands as the > *payload* now has a say over the selection of extended type. Yes. > 2. An implementation follows the advice of RFC 2138 to the letter. > Unfortunately preservation of order does not preclude insertion of Cogs > into the middle of Gears as the outer RADIUS type is the same for both. Hmm... that's allowed, yes. > Some ideas for solving the problems: > > 1. Use reserved field as a counter to allow attribute order to be verified. A counter would help address, but not prevent the insertion problem. > 2. Change the fragment format of extended flag attributes to include the > inner extended type or vendorid/type fields in subsequent fragments. That works, but is less efficient. > 3. Add a constraint requiring that at least on the granularity of the > same outer basic RADIUS type if there are any long attributes which fail > to fully validate all "successfully" decoded attributes MUST also be > treated as invalid. That worries me. > The system does not have to work with existing implementations that for > whatever reason are not willing to impose rational ordering of > attributes. At the same time a failure mode of silent data corruption is > not something I would expect anyone to be willing to accept. I agree. Alan DeKok. From radext-bounces@ietf.org Thu Jan 5 08:54:39 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08F21F881D; Thu, 5 Jan 2012 08:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1325782477; bh=LHHENPtyaalf/bsQtMvZj2cEe1twnbXYMjEvgFw/jy0=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Zgj1y20P0sBblVKJFA+T1iwQXi/bCleguKZvlDA5H2/+Pvae9oLKasCvyXxgHvKy+ gdqQIYgUI3P42qWIc3IDK7pd62uE0CPsjBrImBv+8FuhY2O7V4MLJkf7istlq/yY1S 5dg0/UWdBUaLpbb+oo/9J2E1yKvx1puyRyRgkmxU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9BE21F8804 for ; Thu, 5 Jan 2012 08:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.055 X-Spam-Level: X-Spam-Status: No, score=-103.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTIFcqG9RrwW for ; Thu, 5 Jan 2012 08:54:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id D37CD21F881F for ; Thu, 5 Jan 2012 08:54:26 -0800 (PST) Message-ID: <4F05D5A7.5070501@deployingradius.com> Date: Thu, 05 Jan 2012 17:53:59 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: 'radext mailing list' Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > The necessary ordering constraints do not seem to be there in existing > RFCS to prevent long attributes from being corrupted. This is important > since a design goal was to allow attributes to be forwarded by systems > not supporting this draft. .. > 1. SHOULD is not enough. > 2. Preserving order is not enough. I agree with (1). However, most implementations *do* preserve ordering. Maybe the document could be updated to say implementations MUST preserve ordering. > This not only corrupts the data but also corrupts the attributes > extended type. This can be dangerous in the wrong hands as the > *payload* now has a say over the selection of extended type. Yes. > 2. An implementation follows the advice of RFC 2138 to the letter. > Unfortunately preservation of order does not preclude insertion of Cogs > into the middle of Gears as the outer RADIUS type is the same for both. Hmm... that's allowed, yes. > Some ideas for solving the problems: > > 1. Use reserved field as a counter to allow attribute order to be verified. A counter would help address, but not prevent the insertion problem. > 2. Change the fragment format of extended flag attributes to include the > inner extended type or vendorid/type fields in subsequent fragments. That works, but is less efficient. > 3. Add a constraint requiring that at least on the granularity of the > same outer basic RADIUS type if there are any long attributes which fail > to fully validate all "successfully" decoded attributes MUST also be > treated as invalid. That worries me. > The system does not have to work with existing implementations that for > whatever reason are not willing to impose rational ordering of > attributes. At the same time a failure mode of silent data corruption is > not something I would expect anyone to be willing to accept. I agree. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From diego@tid.es Mon Jan 9 00:55:09 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6021F8690; Mon, 9 Jan 2012 00:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-2.135, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdfasL4t6qib; Mon, 9 Jan 2012 00:55:08 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCF21F85E9; Mon, 9 Jan 2012 00:55:07 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXI00MPIWRT35@tid.hi.inet>; Mon, 09 Jan 2012 09:55:05 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 3A.42.02893.D4BAA0F4; Mon, 09 Jan 2012 09:54:37 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXI00MPAWRT35@tid.hi.inet>; Mon, 09 Jan 2012 09:55:05 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 09 Jan 2012 09:55:05 +0100 Date: Mon, 09 Jan 2012 09:55:05 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F05CA5A.2030602@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczOrGGit0VEh0T2SFGTBoWgI0jhFQ== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-b1-4f0aab4d537e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXCFe/Apeu7msvf4MAbfYuP198wWrS8msnm wOSxZMlPpgDGKC6blNSczLLUIn27BK6MBx3H2AoaxCvufprP3MB4UKiLkZNDQsBE4tGTR4wQ tpjEhXvr2boYuTiEBDYwSnxqu8oI4TxllFh6ZjU7hNPIKHHl0WcWkBYWAVWJrSumsYHYbALq Ei1Hv4HFhQWSJe7+3wYW5xQwlrj48TsriC0ioCWxYP0ioBoODmaBQompF3RAwrwClhIvbx1j g7AFJX5Mvgc2hllAT+Ljn9uMELa4RHPrTai4tsSTdxfARjICXf391BomiPEpEpvuzGODsPUk tn7+yQxRIypxp3091JcCEkv2nGeGsEUlXj7+xwrx121GiTU3ZjNNYBSfheSOWUjumIXkjllI 7ljAyLKKUaw4qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMkpjJ2MC7fqXKIUYCDUYmHd0YGl78Q a2JZcWXuIUZJDiYlUV7WlUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryVfUA53pTEyqrUonyY lAwHh5IE77JVQCnBotT01Iq0zBxg4oBJM3FwgrTzALUvBqnhLS5IzC3OTIfIn2JU5bjeOPcc oxBLXn5eqpQ4bwNIkQBIUUZpHtycV4ziQAcL8yaBZHmAqQ9uwiug4UxAwx/8YQcZXpKIkJJq YBR7WLgudF1m30zlphrm/xZcB9vKF1dUqlXZvEhjNetXcrzSFRHRxdy0ZLLX3L2maz53HDxx 6O5j7al7mzjiz7nJHfbcdKI0R23tw5nhewMWeRrG7JymvsZwfY9a/1yuORs6Y94FPfROjGY6 +GXXVtvcuZWhe33exHeVGM2fHTqXfcLJ+NVxD5VYijMSDbWYi4oTARB27cY6AwAA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 08:55:09 -0000 On 5 Jan 2012, at 17:05 , Alan DeKok wrote: >> * Chunked-Attribute must appear before the attribute it refers to in the= packet > > RADIUS doesn't impose ordering on attributes of different type. > That's a strong reason to integrate chunking inside of the attribute form= at. Ordering constraints here are applied to related attributes. I don't see wh= y this would go beyond the requirements imposed by the current document on = extended attributes, as the recent discussion on it shows. >> * If an attribute occurs multiple times in a request/response (we cannot= speak here of "a packet") chunks for only one of the occurrences, associat= ed to the corresponding Chunked-Attribute, are allowed in a given packet > > Why? RADIUS allows for multiple attributes of the same type, with > different value. > >> * Non-fragmented values for this attribute can appear in any packet, but= always before the Chunked-Attribute that refers to it > > See comment about attribute ordering. On these issues, I agree with the latest proposal from Alejandro, that rath= er simplifies ordering constraints. >> * As many Chunked-Attribute (and referred attributes) may appear in a gi= ven packet as necessary. > > I think this document is intended to solve one *very* limited > use-case. It doesn't address any more general case. The use case is that of an AuthN/AuthZ infrastructure that requires the exc= hange of data longer that the one that fits in a RADIUS packet, and intende= d to rely on a single trust infrastructure. I do think it is general enough= . > It relies on fixed attribute ordering, which is explicitly not required. It relies in the usage of an specific attribute that defines the interpreta= tion of the values of another attribute. Ordering rules probably could be r= elaxed, but at the price of more complicated processing rules. > I gave comments on your approach. Do you have any comments on my > proposed alternative? It would seem to (a) solve the same problem, and > (b) have none of the limitations. One of the main goals of the proposal was to be compatible with current mec= hanisms for attribute encoding inside the packet (EAP-style, extended attri= butes=85) and deal only with values spanning more than one packet. Using yo= ur alternative would break this compatibility. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From radext-bounces@ietf.org Mon Jan 9 00:55:10 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1904821F8690; Mon, 9 Jan 2012 00:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326099310; bh=3RblTHDq48/cno896rN2lKKwGOBXs2yzD0mkI4/ecc0=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hzzQxRpgWlISbArbdgxQ2l8wuklwg2hjO3fAHLRRR8xwHnDTnayTOAOMACUaShn6B QYA2048JGWsM2wdJb0+V3tzc4oianANSgbJXYflSSBoyWiZvNX5Arm1KlPhuyiTiMS 4A4JCYqCJIt46w3Fs9xqpXvEXuJvsSrKq5sejSo4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA6021F8690; Mon, 9 Jan 2012 00:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-2.135, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdfasL4t6qib; Mon, 9 Jan 2012 00:55:08 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4FCF21F85E9; Mon, 9 Jan 2012 00:55:07 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXI00MPIWRT35@tid.hi.inet>; Mon, 09 Jan 2012 09:55:05 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 3A.42.02893.D4BAA0F4; Mon, 09 Jan 2012 09:54:37 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXI00MPAWRT35@tid.hi.inet>; Mon, 09 Jan 2012 09:55:05 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 09 Jan 2012 09:55:05 +0100 Date: Mon, 09 Jan 2012 09:55:05 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F05CA5A.2030602@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: en-US Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczOrGGit0VEh0T2SFGTBoWgI0jhFQ== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-b1-4f0aab4d537e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsXCFe/Apeu7msvf4MAbfYuP198wWrS8msnm wOSxZMlPpgDGKC6blNSczLLUIn27BK6MBx3H2AoaxCvufprP3MB4UKiLkZNDQsBE4tGTR4wQ tpjEhXvr2boYuTiEBDYwSnxqu8oI4TxllFh6ZjU7hNPIKHHl0WcWkBYWAVWJrSumsYHYbALq Ei1Hv4HFhQWSJe7+3wYW5xQwlrj48TsriC0ioCWxYP0ioBoODmaBQompF3RAwrwClhIvbx1j g7AFJX5Mvgc2hllAT+Ljn9uMELa4RHPrTai4tsSTdxfARjICXf391BomiPEpEpvuzGODsPUk tn7+yQxRIypxp3091JcCEkv2nGeGsEUlXj7+xwrx121GiTU3ZjNNYBSfheSOWUjumIXkjllI 7ljAyLKKUaw4qSgzPaMkNzEzJ93AUC8jUy8zL7VkEyMkpjJ2MC7fqXKIUYCDUYmHd0YGl78Q a2JZcWXuIUZJDiYlUV7WlUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryVfUA53pTEyqrUonyY lAwHh5IE77JVQCnBotT01Iq0zBxg4oBJM3FwgrTzALUvBqnhLS5IzC3OTIfIn2JU5bjeOPcc oxBLXn5eqpQ4bwNIkQBIUUZpHtycV4ziQAcL8yaBZHmAqQ9uwiug4UxAwx/8YQcZXpKIkJJq YBR7WLgudF1m30zlphrm/xZcB9vKF1dUqlXZvEhjNetXcrzSFRHRxdy0ZLLX3L2maz53HDxx 6O5j7al7mzjiz7nJHfbcdKI0R23tw5nhewMWeRrG7JymvsZwfY9a/1yuORs6Y94FPfROjGY6 +GXXVtvcuZWhe33exHeVGM2fHTqXfcLJ+NVxD5VYijMSDbWYi4oTARB27cY6AwAA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 5 Jan 2012, at 17:05 , Alan DeKok wrote: >> * Chunked-Attribute must appear before the attribute it refers to in the= packet > > RADIUS doesn't impose ordering on attributes of different type. > That's a strong reason to integrate chunking inside of the attribute form= at. Ordering constraints here are applied to related attributes. I don't see wh= y this would go beyond the requirements imposed by the current document on = extended attributes, as the recent discussion on it shows. >> * If an attribute occurs multiple times in a request/response (we cannot= speak here of "a packet") chunks for only one of the occurrences, associat= ed to the corresponding Chunked-Attribute, are allowed in a given packet > > Why? RADIUS allows for multiple attributes of the same type, with > different value. > >> * Non-fragmented values for this attribute can appear in any packet, but= always before the Chunked-Attribute that refers to it > > See comment about attribute ordering. On these issues, I agree with the latest proposal from Alejandro, that rath= er simplifies ordering constraints. >> * As many Chunked-Attribute (and referred attributes) may appear in a gi= ven packet as necessary. > > I think this document is intended to solve one *very* limited > use-case. It doesn't address any more general case. The use case is that of an AuthN/AuthZ infrastructure that requires the exc= hange of data longer that the one that fits in a RADIUS packet, and intende= d to rely on a single trust infrastructure. I do think it is general enough. > It relies on fixed attribute ordering, which is explicitly not required. It relies in the usage of an specific attribute that defines the interpreta= tion of the values of another attribute. Ordering rules probably could be r= elaxed, but at the price of more complicated processing rules. > I gave comments on your approach. Do you have any comments on my > proposed alternative? It would seem to (a) solve the same problem, and > (b) have none of the limitations. One of the main goals of the proposal was to be compatible with current mec= hanisms for attribute encoding inside the packet (EAP-style, extended attri= butes=85) and deal only with values spanning more than one packet. Using yo= ur alternative would break this compatibility. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Jan 9 01:59:32 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDF021F8468; Mon, 9 Jan 2012 01:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326103172; bh=6u4OVNfkOuGg5wcFr6L3uy5o2vRTeJRrhz6REjuMgIE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=k9sIjUZEhF/egmAbS5YM4B9PMcmxxFPFDa4RWnyOLQT33+Sx5+zm/ERWsu+yoN92F phEpy83H8zs0oIe2ciIEzs7pvbBUn67fXhRBTtgk9qPJHyI/F1JPjHIlT7ZhvonWlO KoaJSqPbHChOb3vOu675mav7o0kE86WUpTMhsyjc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533421F843A; Mon, 9 Jan 2012 01:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq-j42xcIMA4; Mon, 9 Jan 2012 01:59:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BB6D121F842C; Mon, 9 Jan 2012 01:59:27 -0800 (PST) Message-ID: <4F0ABA62.3040008@deployingradius.com> Date: Mon, 09 Jan 2012 10:58:58 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org DIEGO LOPEZ GARCIA wrote: > Ordering constraints here are applied to related attributes. RADIUS doesn't work that way. There are hundreds of thousands of deployments which assume that ordering constraints do NOT apply to related attributes. Changing such a fundamental part of the protocol is impossible. > I don't see why this would go beyond the requirements imposed by the curr= ent document on extended attributes, as the recent discussion on it shows. I pointed you to RFC 2865, and explained why that restriction is impossible. Please go read those messages again. > It relies in the usage of an specific attribute that defines the interpre= tation of the values of another attribute. Ordering rules probably could be= relaxed, but at the price of more complicated processing rules. It relies on behavior which is mandated as NOT being part of RADIUS. >> I gave comments on your approach. Do you have any comments on my >> proposed alternative? It would seem to (a) solve the same problem, and >> (b) have none of the limitations. > = > One of the main goals of the proposal was to be compatible with current m= echanisms for attribute encoding inside the packet (EAP-style, extended att= ributes=85) and deal only with values spanning more than one packet. Using = your alternative would break this compatibility. Nonsense. It is incompatible with existing methods like EAP-Message. Those *already* have semantics defined. Changing them by adding a "Chunked Attribute" is impossible. The extended format hasn't been deployed, so compatibility with it is impossible. My proposal was to allow *new* attributes to span multiple packets. Changing the rules on attribute ordering is impossible. Don't even try. Changing the meaning of existing attributes to allow more than 253 octets of data is impossible. Don't even try. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Jan 9 01:59:30 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533421F843A; Mon, 9 Jan 2012 01:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.146 X-Spam-Level: X-Spam-Status: No, score=-102.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sq-j42xcIMA4; Mon, 9 Jan 2012 01:59:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BB6D121F842C; Mon, 9 Jan 2012 01:59:27 -0800 (PST) Message-ID: <4F0ABA62.3040008@deployingradius.com> Date: Mon, 09 Jan 2012 10:58:58 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:59:30 -0000 DIEGO LOPEZ GARCIA wrote: > Ordering constraints here are applied to related attributes. RADIUS doesn't work that way. There are hundreds of thousands of deployments which assume that ordering constraints do NOT apply to related attributes. Changing such a fundamental part of the protocol is impossible. > I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows. I pointed you to RFC 2865, and explained why that restriction is impossible. Please go read those messages again. > It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules. It relies on behavior which is mandated as NOT being part of RADIUS. >> I gave comments on your approach. Do you have any comments on my >> proposed alternative? It would seem to (a) solve the same problem, and >> (b) have none of the limitations. > > One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility. Nonsense. It is incompatible with existing methods like EAP-Message. Those *already* have semantics defined. Changing them by adding a "Chunked Attribute" is impossible. The extended format hasn't been deployed, so compatibility with it is impossible. My proposal was to allow *new* attributes to span multiple packets. Changing the rules on attribute ordering is impossible. Don't even try. Changing the meaning of existing attributes to allow more than 253 octets of data is impossible. Don't even try. Alan DeKok. From aland@deployingradius.com Mon Jan 9 02:03:28 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416E021F8421; Mon, 9 Jan 2012 02:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW2l2NeXnY4U; Mon, 9 Jan 2012 02:03:27 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A019321F869C; Mon, 9 Jan 2012 02:03:27 -0800 (PST) Message-ID: <4F0ABB54.1040401@deployingradius.com> Date: Mon, 09 Jan 2012 11:03:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> In-Reply-To: <4F0ABA62.3040008@deployingradius.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 10:03:28 -0000 Alan DeKok wrote: > There are hundreds of thousands of deployments which assume that > ordering constraints do NOT apply to related attributes. Make that "UNrelated attributes" Alan DeKok. From radext-bounces@ietf.org Mon Jan 9 02:03:29 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6193A21F8697; Mon, 9 Jan 2012 02:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326103409; bh=R/tTvwwY6wDS9jt/EQchL1NezanIDjIeEF/msTvrzto=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=WZCOGICFKSpUgEVoC6BHGq6JaRoUOp5MrNTqZepE579Hlxx8WjP++2zJhrug1cLkk Y7SGk3rBWaLV18tbWBQQvrm71NXZjpYTRloNIPyPftDADloxeSpb/3mGNr/Ew1woZD g25qw18dUYSZEV5Md/pkOcloatryjmFYhR/tEpS0= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416E021F8421; Mon, 9 Jan 2012 02:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.171 X-Spam-Level: X-Spam-Status: No, score=-102.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW2l2NeXnY4U; Mon, 9 Jan 2012 02:03:27 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A019321F869C; Mon, 9 Jan 2012 02:03:27 -0800 (PST) Message-ID: <4F0ABB54.1040401@deployingradius.com> Date: Mon, 09 Jan 2012 11:03:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> In-Reply-To: <4F0ABA62.3040008@deployingradius.com> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan DeKok wrote: > There are hundreds of thousands of deployments which assume that > ordering constraints do NOT apply to related attributes. Make that "UNrelated attributes" Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From diego@tid.es Mon Jan 9 03:05:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF621F86C4; Mon, 9 Jan 2012 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI9C74SaMbxg; Mon, 9 Jan 2012 03:05:15 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id D26A221F86D7; Mon, 9 Jan 2012 03:05:14 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXJ00MDI2SOZ3@tid.hi.inet>; Mon, 09 Jan 2012 12:05:12 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 09.A4.02893.8E9CA0F4; Mon, 09 Jan 2012 12:05:12 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXJ00MDD2SOZ3@tid.hi.inet>; Mon, 09 Jan 2012 12:05:12 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 09 Jan 2012 12:05:12 +0100 Date: Mon, 09 Jan 2012 12:05:11 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F0ABA62.3040008@deployingradius.com> To: Alan DeKok Message-id: <85F68FE3-7E36-4166-A3BD-01C55EE19E08@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczOvo7Vdry86SWSTkqyDztKByxwkw== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-95-4f0ac9e8fd6d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXCFe/ApfviJJe/wc0pRhYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ289eYy/o4qw4fPU6UwPjHPYuRg4OCQETiduzq7oY OYFMMYkL99azdTFycQgJbGCU+PN7OZTzlFHi38zrjBBOI6NE88xdTCAtLAKqEmdunWABsdkE 1CVajn4Ds4UFkiX+bNrLBLKBU8BYYuV3VpCwiICWxIL1i8BKmAUKJTa9ng82hlfAUmLC33eM ELagxI/J96Bq9CQ+/rnNCGGLSzS33oSKa0s8eXcBbCYj0NXfT61hgpifIvF+RScjhK0nMWvt fhaIGlGJO+3rGSG+FJBYsuc8M4QtKvHy8T+wOUICW5gkTkwXmsAoPgvJGbOQnDELyRmzkJyx gJFlFaNYcVJRZnpGSW5iZk66gaFeRqZeZl5qySZGSDxl7GBcvlPlEKMAB6MSD++MDC5/IdbE suLK3EOMkhxMSqK80UeBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4K/uAcrwpiZVVqUX5MCkZ Dg4lCd5oYOwLCRalpqdWpGXmAJMGTJqJgxOknQeoPQqkhre4IDG3ODMdIn+KUVJKnDcJJCEA ksgozYPrfcUoDnSkMG8wSJYHmN7gul4BDWQCGvjgDzvIwJJEhJRUA6PjzCQvIX8bVsVZr1O5 1n1q0z5gsrU1w82qdJXv9HdnbNddNG2+rc+19amo6JuJ7neVd3dNfcCc8D57kQenx5OueIeD 05maa/KeZmTKHFGcLil/gjPjVvy5sh8y/9P5WLPWHGVV+roxafVRzUJeiy3Lfb3ldz8+ME3i n/C5PV9bet4v5SvYskiJpTgj0VCLuag4EQAmRrbPLAMAAA== References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:05:19 -0000 On 9 Jan 2012, at 10:58 , Alan DeKok wrote: > Changing the rules on attribute ordering is impossible. Don't even try= . Nodoby is trying to do so. We've probably not explained well the rules for = CHUNKED and the related attribute. Let us get back to it with a (hopefully)= clearer proposal. > Changing the meaning of existing attributes to allow more than 253 > octets of data is impossible. Don't even try. Nobody is trying to do so either, but to achieve the goal of allowing attri= butes to span several packets in the simplest and cleanest way possible. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From radext-bounces@ietf.org Mon Jan 9 03:05:21 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F94021F86D7; Mon, 9 Jan 2012 03:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326107121; bh=vNQyge2qOEilnJsmqjkbMMaou3eKK42CrRErxUKxZvA=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=N5dJVp7S9hwblLCB4qyzudIf5fKOC2vO3Bz66gW7D4vekc1e2i9bwvglIUHnw7Dr8 Dplu0mvZMUraa8mbXjBfk+7y1LRfjDjLgGzU9exH7N2ABmhECfOBQO4Xdx9ewhjGLE uhW51rkZ9RYU4erB4bIXk5goXyZiLR1HRNLJEtZ8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDF621F86C4; Mon, 9 Jan 2012 03:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI9C74SaMbxg; Mon, 9 Jan 2012 03:05:15 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id D26A221F86D7; Mon, 9 Jan 2012 03:05:14 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXJ00MDI2SOZ3@tid.hi.inet>; Mon, 09 Jan 2012 12:05:12 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 09.A4.02893.8E9CA0F4; Mon, 09 Jan 2012 12:05:12 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXJ00MDD2SOZ3@tid.hi.inet>; Mon, 09 Jan 2012 12:05:12 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 09 Jan 2012 12:05:12 +0100 Date: Mon, 09 Jan 2012 12:05:11 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F0ABA62.3040008@deployingradius.com> To: Alan DeKok Message-id: <85F68FE3-7E36-4166-A3BD-01C55EE19E08@tid.es> MIME-version: 1.0 Content-language: en-US Accept-Language: en-US Thread-topic: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczOvo7Vdry86SWSTkqyDztKByxwkw== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-95-4f0ac9e8fd6d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsXCFe/ApfviJJe/wc0pRhYfr79htGh5NZPN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ289eYy/o4qw4fPU6UwPjHPYuRg4OCQETiduzq7oY OYFMMYkL99azdTFycQgJbGCU+PN7OZTzlFHi38zrjBBOI6NE88xdTCAtLAKqEmdunWABsdkE 1CVajn4Ds4UFkiX+bNrLBLKBU8BYYuV3VpCwiICWxIL1i8BKmAUKJTa9ng82hlfAUmLC33eM ELagxI/J96Bq9CQ+/rnNCGGLSzS33oSKa0s8eXcBbCYj0NXfT61hgpifIvF+RScjhK0nMWvt fhaIGlGJO+3rGSG+FJBYsuc8M4QtKvHy8T+wOUICW5gkTkwXmsAoPgvJGbOQnDELyRmzkJyx gJFlFaNYcVJRZnpGSW5iZk66gaFeRqZeZl5qySZGSDxl7GBcvlPlEKMAB6MSD++MDC5/IdbE suLK3EOMkhxMSqK80UeBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4K/uAcrwpiZVVqUX5MCkZ Dg4lCd5oYOwLCRalpqdWpGXmAJMGTJqJgxOknQeoPQqkhre4IDG3ODMdIn+KUVJKnDcJJCEA ksgozYPrfcUoDnSkMG8wSJYHmN7gul4BDWQCGvjgDzvIwJJEhJRUA6PjzCQvIX8bVsVZr1O5 1n1q0z5gsrU1w82qdJXv9HdnbNddNG2+rc+19amo6JuJ7neVd3dNfcCc8D57kQenx5OueIeD 05maa/KeZmTKHFGcLil/gjPjVvy5sh8y/9P5WLPWHGVV+roxafVRzUJeiy3Lfb3ldz8+ME3i n/C5PV9bet4v5SvYskiJpTgj0VCLuag4EQAmRrbPLAMAAA== References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 9 Jan 2012, at 10:58 , Alan DeKok wrote: > Changing the rules on attribute ordering is impossible. Don't even try. Nodoby is trying to do so. We've probably not explained well the rules for = CHUNKED and the related attribute. Let us get back to it with a (hopefully)= clearer proposal. > Changing the meaning of existing attributes to allow more than 253 > octets of data is impossible. Don't even try. Nobody is trying to do so either, but to achieve the goal of allowing attri= butes to span several packets in the simplest and cleanest way possible. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Mon Jan 9 03:21:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5621F8471; Mon, 9 Jan 2012 03:21:09 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlqiGZhjDVPl; Mon, 9 Jan 2012 03:21:09 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA521F846E; Mon, 9 Jan 2012 03:21:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 794254BA6A; Mon, 9 Jan 2012 12:21:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bhz6-VAQffe6; Mon, 9 Jan 2012 12:21:06 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 068C94BD17; Mon, 9 Jan 2012 12:20:58 +0100 (CET) Message-ID: <4F0ACD9A.4000809@um.es> Date: Mon, 09 Jan 2012 12:20:58 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> In-Reply-To: <4F0ABA62.3040008@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "radext@ietf.org" , "abfab@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 11:21:10 -0000 Hi Alan, thanks for the clarifications and hints. We will think about them and their implications, and try to modify the proposal to make it address all the requirements. Regards, Alejandro El 09/01/12 10:58, Alan DeKok escribió: > DIEGO LOPEZ GARCIA wrote: >> Ordering constraints here are applied to related attributes. > RADIUS doesn't work that way. > > There are hundreds of thousands of deployments which assume that > ordering constraints do NOT apply to related attributes. Changing such > a fundamental part of the protocol is impossible. > >> I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows. > I pointed you to RFC 2865, and explained why that restriction is > impossible. Please go read those messages again. > >> It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules. > It relies on behavior which is mandated as NOT being part of RADIUS. > >>> I gave comments on your approach. Do you have any comments on my >>> proposed alternative? It would seem to (a) solve the same problem, and >>> (b) have none of the limitations. >> One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility. > Nonsense. > > It is incompatible with existing methods like EAP-Message. Those > *already* have semantics defined. Changing them by adding a "Chunked > Attribute" is impossible. The extended format hasn't been deployed, so > compatibility with it is impossible. > > My proposal was to allow *new* attributes to span multiple packets. > > Changing the rules on attribute ordering is impossible. Don't even try. > > Changing the meaning of existing attributes to allow more than 253 > octets of data is impossible. Don't even try. > > Alan DeKok. From radext-bounces@ietf.org Mon Jan 9 03:21:13 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7370921F86F8; Mon, 9 Jan 2012 03:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326108073; bh=+cm4pGbNJB19TE/h29LF5wXhLIbSKnnIGGSn52dayMI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=MkFgDSMc0KBx3S1rKJBSFvFAIF1eCBMUeHIzQkjqPScHuuT4x+LwyPe9rDPrsUpH4 Sa+txixDfGo8JIBbjTYLBGUsMCH3mQyRKdpTrMGZIptfnpsZF0AduwmRuF2GON82VN XqBp4Uy7Y2vF3Qz4e0rkPEJ4HomOJY4DbDpWGmkc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5621F8471; Mon, 9 Jan 2012 03:21:09 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlqiGZhjDVPl; Mon, 9 Jan 2012 03:21:09 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA521F846E; Mon, 9 Jan 2012 03:21:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 794254BA6A; Mon, 9 Jan 2012 12:21:06 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bhz6-VAQffe6; Mon, 9 Jan 2012 12:21:06 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id 068C94BD17; Mon, 9 Jan 2012 12:20:58 +0100 (CET) Message-ID: <4F0ACD9A.4000809@um.es> Date: Mon, 09 Jan 2012 12:20:58 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> In-Reply-To: <4F0ABA62.3040008@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [radext] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org SGkgQWxhbiwKCnRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb25zIGFuZCBoaW50cy4gV2Ugd2ls bCB0aGluayBhYm91dCB0aGVtIGFuZCAKdGhlaXIgaW1wbGljYXRpb25zLCBhbmQgdHJ5IHRvIG1v ZGlmeSB0aGUgcHJvcG9zYWwgdG8gbWFrZSBpdCBhZGRyZXNzIAphbGwgdGhlIHJlcXVpcmVtZW50 cy4KClJlZ2FyZHMsCkFsZWphbmRybwoKRWwgMDkvMDEvMTIgMTA6NTgsIEFsYW4gRGVLb2sgZXNj cmliacOzOgo+IERJRUdPIExPUEVaIEdBUkNJQSB3cm90ZToKPj4gT3JkZXJpbmcgY29uc3RyYWlu dHMgaGVyZSBhcmUgYXBwbGllZCB0byByZWxhdGVkIGF0dHJpYnV0ZXMuCj4gICAgUkFESVVTIGRv ZXNuJ3Qgd29yayB0aGF0IHdheS4KPgo+ICAgIFRoZXJlIGFyZSBodW5kcmVkcyBvZiB0aG91c2Fu ZHMgb2YgZGVwbG95bWVudHMgd2hpY2ggYXNzdW1lIHRoYXQKPiBvcmRlcmluZyBjb25zdHJhaW50 cyBkbyBOT1QgYXBwbHkgdG8gcmVsYXRlZCBhdHRyaWJ1dGVzLiAgQ2hhbmdpbmcgc3VjaAo+IGEg ZnVuZGFtZW50YWwgcGFydCBvZiB0aGUgcHJvdG9jb2wgaXMgaW1wb3NzaWJsZS4KPgo+PiBJIGRv bid0IHNlZSB3aHkgdGhpcyB3b3VsZCBnbyBiZXlvbmQgdGhlIHJlcXVpcmVtZW50cyBpbXBvc2Vk IGJ5IHRoZSBjdXJyZW50IGRvY3VtZW50IG9uIGV4dGVuZGVkIGF0dHJpYnV0ZXMsIGFzIHRoZSBy ZWNlbnQgZGlzY3Vzc2lvbiBvbiBpdCBzaG93cy4KPiAgICBJIHBvaW50ZWQgeW91IHRvIFJGQyAy ODY1LCBhbmQgZXhwbGFpbmVkIHdoeSB0aGF0IHJlc3RyaWN0aW9uIGlzCj4gaW1wb3NzaWJsZS4g IFBsZWFzZSBnbyByZWFkIHRob3NlIG1lc3NhZ2VzIGFnYWluLgo+Cj4+IEl0IHJlbGllcyBpbiB0 aGUgdXNhZ2Ugb2YgYW4gc3BlY2lmaWMgYXR0cmlidXRlIHRoYXQgZGVmaW5lcyB0aGUgaW50ZXJw cmV0YXRpb24gb2YgdGhlIHZhbHVlcyBvZiBhbm90aGVyIGF0dHJpYnV0ZS4gT3JkZXJpbmcgcnVs ZXMgcHJvYmFibHkgY291bGQgYmUgcmVsYXhlZCwgYnV0IGF0IHRoZSBwcmljZSBvZiBtb3JlIGNv bXBsaWNhdGVkIHByb2Nlc3NpbmcgcnVsZXMuCj4gICAgSXQgcmVsaWVzIG9uIGJlaGF2aW9yIHdo aWNoIGlzIG1hbmRhdGVkIGFzIE5PVCBiZWluZyBwYXJ0IG9mIFJBRElVUy4KPgo+Pj4gSSBnYXZl IGNvbW1lbnRzIG9uIHlvdXIgYXBwcm9hY2guICBEbyB5b3UgaGF2ZSBhbnkgY29tbWVudHMgb24g bXkKPj4+IHByb3Bvc2VkIGFsdGVybmF0aXZlPyAgSXQgd291bGQgc2VlbSB0byAoYSkgc29sdmUg dGhlIHNhbWUgcHJvYmxlbSwgYW5kCj4+PiAoYikgaGF2ZSBub25lIG9mIHRoZSBsaW1pdGF0aW9u cy4KPj4gT25lIG9mIHRoZSBtYWluIGdvYWxzIG9mIHRoZSBwcm9wb3NhbCB3YXMgdG8gYmUgY29t cGF0aWJsZSB3aXRoIGN1cnJlbnQgbWVjaGFuaXNtcyBmb3IgYXR0cmlidXRlIGVuY29kaW5nIGlu c2lkZSB0aGUgcGFja2V0IChFQVAtc3R5bGUsIGV4dGVuZGVkIGF0dHJpYnV0ZXPigKYpIGFuZCBk ZWFsIG9ubHkgd2l0aCB2YWx1ZXMgc3Bhbm5pbmcgbW9yZSB0aGFuIG9uZSBwYWNrZXQuIFVzaW5n IHlvdXIgYWx0ZXJuYXRpdmUgd291bGQgYnJlYWsgdGhpcyBjb21wYXRpYmlsaXR5Lgo+ICAgIE5v bnNlbnNlLgo+Cj4gICAgSXQgaXMgaW5jb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgbWV0aG9kcyBs aWtlIEVBUC1NZXNzYWdlLiAgVGhvc2UKPiAqYWxyZWFkeSogaGF2ZSBzZW1hbnRpY3MgZGVmaW5l ZC4gIENoYW5naW5nIHRoZW0gYnkgYWRkaW5nIGEgIkNodW5rZWQKPiBBdHRyaWJ1dGUiIGlzIGlt cG9zc2libGUuICBUaGUgZXh0ZW5kZWQgZm9ybWF0IGhhc24ndCBiZWVuIGRlcGxveWVkLCBzbwo+ IGNvbXBhdGliaWxpdHkgd2l0aCBpdCBpcyBpbXBvc3NpYmxlLgo+Cj4gICAgTXkgcHJvcG9zYWwg d2FzIHRvIGFsbG93ICpuZXcqIGF0dHJpYnV0ZXMgdG8gc3BhbiBtdWx0aXBsZSBwYWNrZXRzLgo+ Cj4gICAgQ2hhbmdpbmcgdGhlIHJ1bGVzIG9uIGF0dHJpYnV0ZSBvcmRlcmluZyBpcyBpbXBvc3Np YmxlLiAgRG9uJ3QgZXZlbiB0cnkuCj4KPiAgICBDaGFuZ2luZyB0aGUgbWVhbmluZyBvZiBleGlz dGluZyBhdHRyaWJ1dGVzIHRvIGFsbG93IG1vcmUgdGhhbiAyNTMKPiBvY3RldHMgb2YgZGF0YSBp cyBpbXBvc3NpYmxlLiAgRG9uJ3QgZXZlbiB0cnkuCj4KPiAgICBBbGFuIERlS29rLgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBs aXN0CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JhZGV4dAo= From internet-drafts@ietf.org Mon Jan 9 07:07:12 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D16711E8080; Mon, 9 Jan 2012 07:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPEYeZb7M04k; Mon, 9 Jan 2012 07:07:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B609911E8071; Mon, 9 Jan 2012 07:07:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 07:07:11 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:07:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : TLS encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-10.txt Pages : 21 Date : 2012-01-09 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt From radext-bounces@ietf.org Mon Jan 9 07:07:15 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3B11E8087; Mon, 9 Jan 2012 07:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326121635; bh=G+qRS0PIvBP0njhaHAl/yX3qPNJTd6tI5bdEjIbAjTc=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Aa6aX9rO/BZaUjRd/nKQXJioo+x1FNGfwIglDjC+dackUZY3YN8jFt6Bfw6cXR67h 6cFK6eRVz+Yy5sCtkfaOWG2zjehCZnQXOUlBha59QkpxHnXrdZ+brYw0NpqAG+ivyF 0CjYosd97BQtxq0cVGoyX7JYV6KbEznJT8Dhe8TM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D16711E8080; Mon, 9 Jan 2012 07:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPEYeZb7M04k; Mon, 9 Jan 2012 07:07:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B609911E8071; Mon, 9 Jan 2012 07:07:11 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 07:07:11 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : TLS encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-10.txt Pages : 21 Date : 2012-01-09 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Mon Jan 9 07:13:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8421F8797 for ; Mon, 9 Jan 2012 07:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCAJAeQ9UJhQ for ; Mon, 9 Jan 2012 07:13:24 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7421F8783 for ; Mon, 9 Jan 2012 07:13:24 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8ABC6106C2 for ; Mon, 9 Jan 2012 16:13:22 +0100 (CET) Received: from [IPv6:2001:a18:1:8:9cf6:28ef:4ac1:34e7] (unknown [IPv6:2001:a18:1:8:9cf6:28ef:4ac1:34e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 78F9110590 for ; Mon, 9 Jan 2012 16:13:22 +0100 (CET) Message-ID: <4F0B049D.5010602@restena.lu> Date: Mon, 09 Jan 2012 16:15:41 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> In-Reply-To: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig071CE008A64318442C167B55" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:13:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig071CE008A64318442C167B55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, this is a mini update as per the document shepherd's request: - updated reference to dynamic-discovery draft - make a more explicit mention of the the fixed "shared secret" in the Security Considerations section Greetings, Stefan Winter On 09.01.2012 16:07, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. >=20 > Title : TLS encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-10.txt > Pages : 21 > Date : 2012-01-09 >=20 > This document specifies security on the transport layer (TLS) for th= e > RADIUS protocol when transmitted over TCP. This enables dynamic > trust relationships between RADIUS servers. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext =09 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig071CE008A64318442C167B55 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8LBJ0ACgkQ+jm90f8eFWZGJgCZAd94fmwD/j3m4swwjA44YbLp Nj8An1ULVh0iCPBVf/rbccf7JY8s9R/r =sr41 -----END PGP SIGNATURE----- --------------enig071CE008A64318442C167B55-- From radext-bounces@ietf.org Mon Jan 9 07:13:25 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796FE21F8797; Mon, 9 Jan 2012 07:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326122005; bh=Dy137+SxX7Ot0FykKZRClDXcpz+r/KxumdQNbqF+G84=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=or2wSYLX7+5iAGlacN/aHYjVM1CG1ZJWo2n/EU3Xu61DDySYI5j/obgQNx7r/vCqA in5nuu7m6TM5WS6A2A89bTJytF6s7AiPto6QGuiW9Nc9dB3PvJFYHNeXnzduF664QY 768zBl/wUUzfwLkg7ZJD2L6iImBP0xNld+ZPbpzc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8421F8797 for ; Mon, 9 Jan 2012 07:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCAJAeQ9UJhQ for ; Mon, 9 Jan 2012 07:13:24 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7421F8783 for ; Mon, 9 Jan 2012 07:13:24 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8ABC6106C2 for ; Mon, 9 Jan 2012 16:13:22 +0100 (CET) Received: from [IPv6:2001:a18:1:8:9cf6:28ef:4ac1:34e7] (unknown [IPv6:2001:a18:1:8:9cf6:28ef:4ac1:34e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 78F9110590 for ; Mon, 9 Jan 2012 16:13:22 +0100 (CET) Message-ID: <4F0B049D.5010602@restena.lu> Date: Mon, 09 Jan 2012 16:15:41 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> In-Reply-To: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2831106717013628961==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2831106717013628961== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig071CE008A64318442C167B55" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig071CE008A64318442C167B55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, this is a mini update as per the document shepherd's request: - updated reference to dynamic-discovery draft - make a more explicit mention of the the fixed "shared secret" in the Security Considerations section Greetings, Stefan Winter On 09.01.2012 16:07, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. >=20 > Title : TLS encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-10.txt > Pages : 21 > Date : 2012-01-09 >=20 > This document specifies security on the transport layer (TLS) for th= e > RADIUS protocol when transmitted over TCP. This enables dynamic > trust relationships between RADIUS servers. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext =09 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig071CE008A64318442C167B55 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8LBJ0ACgkQ+jm90f8eFWZGJgCZAd94fmwD/j3m4swwjA44YbLp Nj8An1ULVh0iCPBVf/rbccf7JY8s9R/r =sr41 -----END PGP SIGNATURE----- --------------enig071CE008A64318442C167B55-- --===============2831106717013628961== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============2831106717013628961==-- From hartmans@painless-security.com Mon Jan 9 12:25:26 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A099E1F0C44 for ; Mon, 9 Jan 2012 12:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqvwG7kFskyY for ; Mon, 9 Jan 2012 12:25:26 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDF1F0C43 for ; Mon, 9 Jan 2012 12:25:25 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1B0082043E; Mon, 9 Jan 2012 15:24:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CE19E4913; Mon, 9 Jan 2012 15:24:43 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F05D0F4.8090901@um.es> Date: Mon, 09 Jan 2012 15:24:43 -0500 In-Reply-To: <4F05D0F4.8090901@um.es> (Alejandro Perez Mendez's message of "Thu, 05 Jan 2012 17:33:56 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:25:26 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> Hello Bernard, thanks for your response. Sadly, none of Alejandro> them work for our purposes. Alejandro> Approach #1 does not work for us since we are looking for Alejandro> a generic fragmentation, valid for any attribute, not a Alejandro> fragmentation specific for the SAML attribute. Why have we decided that we want a generic approach? It seems much harder than something specific to SAML that could be reused in spirit for similar attributes in the future? From radext-bounces@ietf.org Mon Jan 9 12:25:28 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491711F0C44; Mon, 9 Jan 2012 12:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326140728; bh=H4XPkgqLDKfchRyLBMen8CwGwZM+7FnQ/88oL2wk6k8=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=nkEvYQV5zW3c6uYH7AvKmmmzM9e+kiRLZr8amcQR3h0PFEv5zhPl0oJUHAHV3nscU qSadhO2GZdanWyr8IXLGBzfk8+Jy5OFrSiQfOh8amBulPsRUxtE3+08VifbKOzQQJA EDfVzeBO+fKyRJ/+iB5m4xhz3KSm9B7ZImEQuqwM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A099E1F0C44 for ; Mon, 9 Jan 2012 12:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqvwG7kFskyY for ; Mon, 9 Jan 2012 12:25:26 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDF1F0C43 for ; Mon, 9 Jan 2012 12:25:25 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1B0082043E; Mon, 9 Jan 2012 15:24:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CE19E4913; Mon, 9 Jan 2012 15:24:43 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F05D0F4.8090901@um.es> Date: Mon, 09 Jan 2012 15:24:43 -0500 In-Reply-To: <4F05D0F4.8090901@um.es> (Alejandro Perez Mendez's message of "Thu, 05 Jan 2012 17:33:56 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: Bernard Aboba , radext@ietf.org Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> Hello Bernard, thanks for your response. Sadly, none of Alejandro> them work for our purposes. Alejandro> Approach #1 does not work for us since we are looking for Alejandro> a generic fragmentation, valid for any attribute, not a Alejandro> fragmentation specific for the SAML attribute. Why have we decided that we want a generic approach? It seems much harder than something specific to SAML that could be reused in spirit for similar attributes in the future? _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Jan 9 12:47:18 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5411E80A0 for ; Mon, 9 Jan 2012 12:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1jgVPt67xBC for ; Mon, 9 Jan 2012 12:47:18 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 605FE11E8079 for ; Mon, 9 Jan 2012 12:47:18 -0800 (PST) Message-ID: <4F0B5239.40506@deployingradius.com> Date: Mon, 09 Jan 2012 21:46:49 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F05D0F4.8090901@um.es> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:47:19 -0000 Sam Hartman wrote: > Why have we decided that we want a generic approach? I believe that we can come up with a solution which works for SAML and for future attributes. Leveraging one of the unused fields from the extensions document seems logical, and timely. Alan DeKok. From radext-bounces@ietf.org Mon Jan 9 12:47:20 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A869B11E80A0; Mon, 9 Jan 2012 12:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326142040; bh=yL2vUOWDoMHRyFit/5YN3WsMB+rVGiE7uBGizUx2CPI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=xPQmtiHNN0H908INtP+/P+ql3DLYJsQy5WhzIZ+54JrKF4StbRmhg1EEWf+gXyNls MInkWZoyS831cR87IqDDmx7kKGvI+jSHvsDvc3ExtNZUlSs23JSFhFT4DCL0HP42xN SD1Zi3u9LRoyihj+lPxrUyqEE/N4ZD/RUmlmbwYc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD5411E80A0 for ; Mon, 9 Jan 2012 12:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1jgVPt67xBC for ; Mon, 9 Jan 2012 12:47:18 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 605FE11E8079 for ; Mon, 9 Jan 2012 12:47:18 -0800 (PST) Message-ID: <4F0B5239.40506@deployingradius.com> Date: Mon, 09 Jan 2012 21:46:49 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F05D0F4.8090901@um.es> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Bernard Aboba , radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Sam Hartman wrote: > Why have we decided that we want a generic approach? I believe that we can come up with a solution which works for SAML and for future attributes. Leveraging one of the unused fields from the extensions document seems logical, and timely. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Jan 10 03:55:14 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7419F21F8516; Tue, 10 Jan 2012 03:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326196514; bh=w0yx5wZtcOMNr0Krobc9wJMe2bn5qnoif6MdC1w8eR8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=P8zLsWR3N3neEu3E/aryhVZMmLYRAspf2xymgV03NOev7LPt1Ne/kD57hMHiC03hj sEz9Ccwc1ze7vllBnIamiIFAveZZnAMKhq/v6T0lc5UfuxGreMiK49ATdvPlyNMs4x uhVgbeucnJM3Gjl9+MFMZ0nvduvvZe1SC34xKBpY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2B21F8514 for ; Tue, 10 Jan 2012 03:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxduYj3KIFpW for ; Tue, 10 Jan 2012 03:55:12 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBC21F850F for ; Tue, 10 Jan 2012 03:55:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 83EAE5D51D for ; Tue, 10 Jan 2012 12:55:10 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id diOCODW8D0Ds for ; Tue, 10 Jan 2012 12:55:10 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 0470D5D518 for ; Tue, 10 Jan 2012 12:55:08 +0100 (CET) Message-ID: <4F0C271C.2060503@um.es> Date: Tue, 10 Jan 2012 12:55:08 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org > On Wed, 21 Dec 2011, Alan DeKok wrote: > >> I haven't seen any comments on the latest draft. > >> There were some typos from Leaf, and IANA comments from Bernard. Have >> they been addressed to the WGs satisfaction? > >> Having the document move forward would be a wonderful xmas present. > > Still have a serious concern with data corruption in long attribute > not addressed in the latest drafts. > > The necessary ordering constraints do not seem to be there in existing > RFCS to prevent long attributes from being corrupted. This is > important since a design goal was to allow attributes to be forwarded > by systems not supporting this draft. > > RFC 2138.3 > " Many Attributes may have multiple instances, in such a case the order > of Attributes of the same Type SHOULD be preserved. The order of > Attributes of different Types is not required to be preserved." > > There are two problems with this: > > 1. SHOULD is not enough. > 2. Preserving order is not enough. > > > To show the problem example below uses two extended flag attributes > 'Gear' and 'Cog' each of the extended flag attributes are using the > same basic RADIUS attribute type. > > 'M' represents More flag set > '.' No flags are set > > 1. An implementation decides to ignore the advice of RFC 2138 jumbling > the order of attributes of the same type: > > OK: > [Gear M.1][Gear M.2][GEAR .3] > > NOT OK: > [Gear M.2][Gear M.1][GEAR .3] > > This not only corrupts the data but also corrupts the attributes > extended type. This can be dangerous in the wrong hands as the > *payload* now has a say over the selection of extended type. I'm trying to figure it out why extended types are also corrupted, but I don't see a reason. I clearly appreciate how data is corrupted, but headers should not be affected. Could you please elaborate this a little more or refer me to further information on this topic? Thanks and best regards, Alejandro > > If this were a VSA it would corrupt both the vendor id and the vendors > type. > > 2. An implementation follows the advice of RFC 2138 to the letter. > Unfortunately preservation of order does not preclude insertion of > Cogs into the middle of Gears as the outer RADIUS type is the same for > both. > > OK: > [Gear M.1][Gear M.2][GEAR .3][Cog .1] > > NOT OK: > [Gear M.1][Gear M.2][Cog .1][GEAR .3] > > - Gear is truncated > - Cog is appended to the truncated Gear further corrupting Gear > - Cog never appears as an attribute > - The *payload* of the last gear fragment determines a corrupt > extended type (Or Vendor id and vendors type) and whats left over of > Gear.3's data.. as with the previous example being able to control > extended type via payload can be dangerous in the wrong hands. > > Some ideas for solving the problems: > > 1. Use reserved field as a counter to allow attribute order to be > verified. > > 2. Change the fragment format of extended flag attributes to include > the inner extended type or vendorid/type fields in subsequent fragments. > > 3. Add a constraint requiring that at least on the granularity of the > same outer basic RADIUS type if there are any long attributes which > fail to fully validate all "successfully" decoded attributes MUST also > be treated as invalid. > > Examples of this would be a case of a counter field in the wrong order > or an attribute with more flag set without a follow on ending fragment. > > Other thoughts.. > > The system does not have to work with existing implementations that > for whatever reason are not willing to impose rational ordering of > attributes. At the same time a failure mode of silent data corruption > is not something I would expect anyone to be willing to accept. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Tue Jan 10 03:55:13 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2B21F8514 for ; Tue, 10 Jan 2012 03:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxduYj3KIFpW for ; Tue, 10 Jan 2012 03:55:12 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBC21F850F for ; Tue, 10 Jan 2012 03:55:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 83EAE5D51D for ; Tue, 10 Jan 2012 12:55:10 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id diOCODW8D0Ds for ; Tue, 10 Jan 2012 12:55:10 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 0470D5D518 for ; Tue, 10 Jan 2012 12:55:08 +0100 (CET) Message-ID: <4F0C271C.2060503@um.es> Date: Tue, 10 Jan 2012 12:55:08 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 11:55:13 -0000 > On Wed, 21 Dec 2011, Alan DeKok wrote: > >> I haven't seen any comments on the latest draft. > >> There were some typos from Leaf, and IANA comments from Bernard. Have >> they been addressed to the WGs satisfaction? > >> Having the document move forward would be a wonderful xmas present. > > Still have a serious concern with data corruption in long attribute > not addressed in the latest drafts. > > The necessary ordering constraints do not seem to be there in existing > RFCS to prevent long attributes from being corrupted. This is > important since a design goal was to allow attributes to be forwarded > by systems not supporting this draft. > > RFC 2138.3 > " Many Attributes may have multiple instances, in such a case the order > of Attributes of the same Type SHOULD be preserved. The order of > Attributes of different Types is not required to be preserved." > > There are two problems with this: > > 1. SHOULD is not enough. > 2. Preserving order is not enough. > > > To show the problem example below uses two extended flag attributes > 'Gear' and 'Cog' each of the extended flag attributes are using the > same basic RADIUS attribute type. > > 'M' represents More flag set > '.' No flags are set > > 1. An implementation decides to ignore the advice of RFC 2138 jumbling > the order of attributes of the same type: > > OK: > [Gear M.1][Gear M.2][GEAR .3] > > NOT OK: > [Gear M.2][Gear M.1][GEAR .3] > > This not only corrupts the data but also corrupts the attributes > extended type. This can be dangerous in the wrong hands as the > *payload* now has a say over the selection of extended type. I'm trying to figure it out why extended types are also corrupted, but I don't see a reason. I clearly appreciate how data is corrupted, but headers should not be affected. Could you please elaborate this a little more or refer me to further information on this topic? Thanks and best regards, Alejandro > > If this were a VSA it would corrupt both the vendor id and the vendors > type. > > 2. An implementation follows the advice of RFC 2138 to the letter. > Unfortunately preservation of order does not preclude insertion of > Cogs into the middle of Gears as the outer RADIUS type is the same for > both. > > OK: > [Gear M.1][Gear M.2][GEAR .3][Cog .1] > > NOT OK: > [Gear M.1][Gear M.2][Cog .1][GEAR .3] > > - Gear is truncated > - Cog is appended to the truncated Gear further corrupting Gear > - Cog never appears as an attribute > - The *payload* of the last gear fragment determines a corrupt > extended type (Or Vendor id and vendors type) and whats left over of > Gear.3's data.. as with the previous example being able to control > extended type via payload can be dangerous in the wrong hands. > > Some ideas for solving the problems: > > 1. Use reserved field as a counter to allow attribute order to be > verified. > > 2. Change the fragment format of extended flag attributes to include > the inner extended type or vendorid/type fields in subsequent fragments. > > 3. Add a constraint requiring that at least on the granularity of the > same outer basic RADIUS type if there are any long attributes which > fail to fully validate all "successfully" decoded attributes MUST also > be treated as invalid. > > Examples of this would be a case of a counter field in the wrong order > or an attribute with more flag set without a follow on ending fragment. > > Other thoughts.. > > The system does not have to work with existing implementations that > for whatever reason are not willing to impose rational ordering of > attributes. At the same time a failure mode of silent data corruption > is not something I would expect anyone to be willing to accept. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Jan 10 10:45:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E5921F8655; Tue, 10 Jan 2012 10:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326221111; bh=j2IEbmliogG2uYfDOFRyfpSOVNq4fqSkqm/Yp017+zM=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=EwPzHWlwj8CEF0k6qC54/3AZY31R1CNlfIJSFhpgmvKgWSFssjD6tX0pkCspDXJrH FNc3/0EIIQ8OUz6z9YLUlFxoSqjlNuRUu1F4dw8LNOnTBK8SwgcL54s4TI+hY2m3Cr nY7xBG13bABD/K0WXy3TT2/dNT6uov9YLQ0geSsk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC421F8631 for ; Tue, 10 Jan 2012 10:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.896 X-Spam-Level: X-Spam-Status: No, score=-100.896 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhJqXZV7xZ3G for ; Tue, 10 Jan 2012 10:45:09 -0800 (PST) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0D21F8606 for ; Tue, 10 Jan 2012 10:45:09 -0800 (PST) Received: from BLU152-W62 ([65.55.111.72]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 10:45:09 -0800 Message-ID: X-Originating-IP: [131.107.0.87] From: Bernard Aboba To: Date: Tue, 10 Jan 2012 10:45:08 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 18:45:09.0085 (UTC) FILETIME=[FA4020D0:01CCCFC7] Subject: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4726368857938846834==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============4726368857938846834== Content-Type: multipart/alternative; boundary="_ea758c54-9637-4926-ac8b-0998f0dc3b11_" --_ea758c54-9637-4926-ac8b-0998f0dc3b11_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 6158 Section 1.3.1 states:=20 For specifications utilizing attributes within the standard space=2C conformance with the design guidelines in this document is expected unless a good case can be made for an exception. Reviewers SHOULD use the design guidelines as a review checklist. [BA] How do we ensure that these reviews are actually carried out? Curren= tly the O&M Directorate and AAA Doctors are not conducting RFC 6158 reviews= of RADIUS documents on a regular basis. Sometimes such a review is reques= ted of RADEXT=2C and sometimes it is not. =20 If there is no systematic review process=2C in practice the RFC 6158 guidel= ines will be ignored. =20 = --_ea758c54-9637-4926-ac8b-0998f0dc3b11_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC 6158 Section 1.3.1 states:

For specificat= ions utilizing attributes within the standard space=2C conformance with the design guidelines in this document is expected unless a good case can be made for an exception. Reviewers SHOULD use the design guidelines as a review checklist.


[BA] =3B= How do we ensure that these reviews are actually carried out? =3B Curr= ently the O&=3BM Directorate and AAA Doctors are not conducting RFC 6158= reviews of RADIUS documents on a regular basis. =3B Sometimes such a r= eview is requested of RADEXT=2C and sometimes it is not. =3B =3B
If there is no systematic review process=2C in practice the RFC 6158 = guidelines will be ignored. =3B


=
= --_ea758c54-9637-4926-ac8b-0998f0dc3b11_-- --===============4726368857938846834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4726368857938846834==-- From bernard_aboba@hotmail.com Tue Jan 10 10:45:09 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DC421F8631 for ; Tue, 10 Jan 2012 10:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.896 X-Spam-Level: X-Spam-Status: No, score=-100.896 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhJqXZV7xZ3G for ; Tue, 10 Jan 2012 10:45:09 -0800 (PST) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0D21F8606 for ; Tue, 10 Jan 2012 10:45:09 -0800 (PST) Received: from BLU152-W62 ([65.55.111.72]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 10:45:09 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ea758c54-9637-4926-ac8b-0998f0dc3b11_" X-Originating-IP: [131.107.0.87] From: Bernard Aboba To: Date: Tue, 10 Jan 2012 10:45:08 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 18:45:09.0085 (UTC) FILETIME=[FA4020D0:01CCCFC7] Subject: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:45:09 -0000 --_ea758c54-9637-4926-ac8b-0998f0dc3b11_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 6158 Section 1.3.1 states:=20 For specifications utilizing attributes within the standard space=2C conformance with the design guidelines in this document is expected unless a good case can be made for an exception. Reviewers SHOULD use the design guidelines as a review checklist. [BA] How do we ensure that these reviews are actually carried out? Curren= tly the O&M Directorate and AAA Doctors are not conducting RFC 6158 reviews= of RADIUS documents on a regular basis. Sometimes such a review is reques= ted of RADEXT=2C and sometimes it is not. =20 If there is no systematic review process=2C in practice the RFC 6158 guidel= ines will be ignored. =20 = --_ea758c54-9637-4926-ac8b-0998f0dc3b11_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
RFC 6158 Section 1.3.1 states:

For specificat= ions utilizing attributes within the standard space=2C conformance with the design guidelines in this document is expected unless a good case can be made for an exception. Reviewers SHOULD use the design guidelines as a review checklist.


[BA] =3B= How do we ensure that these reviews are actually carried out? =3B Curr= ently the O&=3BM Directorate and AAA Doctors are not conducting RFC 6158= reviews of RADIUS documents on a regular basis. =3B Sometimes such a r= eview is requested of RADEXT=2C and sometimes it is not. =3B =3B
If there is no systematic review process=2C in practice the RFC 6158 = guidelines will be ignored. =3B


=
= --_ea758c54-9637-4926-ac8b-0998f0dc3b11_-- From bernard_aboba@hotmail.com Tue Jan 10 10:45:35 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8C121F8631 for ; Tue, 10 Jan 2012 10:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjk5x31dydra for ; Tue, 10 Jan 2012 10:45:34 -0800 (PST) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id 78B4F21F8606 for ; Tue, 10 Jan 2012 10:45:34 -0800 (PST) Received: from BLU152-W62 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 10:45:34 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_68c256f3-f14f-4c44-8089-5446bd114cc9_" X-Originating-IP: [131.107.0.87] From: Bernard Aboba To: Date: Tue, 10 Jan 2012 10:45:33 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 18:45:34.0273 (UTC) FILETIME=[09438310:01CCCFC8] Subject: [radext] Review of draft-ietf-nextext-radius-pmip6 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:45:35 -0000 --_68c256f3-f14f-4c44-8089-5446bd114cc9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The document appears to contain typos in sections 4.16 and 4.17. =20 In section 4.16=2C it appears that "Home LMA IPv6 address" should be replac= ed by "Home DHCPv6 server address": 4.16. PMIP6-Home-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In Section 4.17=2C it appears that "Visited LMA IPv6 address" should be rep= laced by "Visited DHCPv6 server address": 4.17. PMIP6-Visited-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Table of Attributes The following table provides a guide to attributes that may be found in authentication and authorization RADIUS messages between MAG and the AAA Server. Request Accept Reject Challenge # Attribute 0-1 0-1 0-1 0-1 80 Message-Authenticator [BA] The Message-Authenticator attribute is mandatory-to-implement in a num= ber of=20 RADIUS usages=2C including EAP (RFC 3579). Leaving out Message-Authenticat= or could=20 result in Access-Requests lacking authentication and integrity protection. RFC 6158 Section 3.1 states: While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets=2C subsequent authentication mechanism specifications=2C such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090]=2C have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080]=2C Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets=2C including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice. =20 = --_68c256f3-f14f-4c44-8089-5446bd114cc9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The document appears to contain typos in sections 4.16 and 4.17. =3B&nb= sp=3B

In section 4.16=2C it appears that "Hom= e LMA IPv6 address" should be replaced by "Home DHCPv6 server address":
= 
4.16.  PMIP6-Home-DHCP6-Server-Address


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |  Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Home LMA IPv6 address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In Section 4.17=2C it appears that "Visited LMA IPv6 address" should be rep=
laced by "Visited DHCPv6 server address":

4.17.  PMIP6-Visited-DHCP6-Server-Address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      | Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Visited LMA IPv6 address     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  Ta=
ble of Attributes

   The following table provides a guide to attributes that may be found
   in authentication and authorization RADIUS messages between MAG and
   the AAA Server.

Request Accept Reject Challenge #  Attribute

   0-1     0-1    0-1    0-1      80  Message-Authenticator


[BA]=
 The Message-Authenticator attribute is mandatory-to-implement in a number =
of 
RADIUS usages=2C including EAP (RFC 3579).  Leaving out Message-Auth=
enticator could 
result in Access-Requests lacking authentication andintegrity protection.  RFC 6158 Section 3.1 states:

   While [RFC28=
65] did not require authentication and integrity
   protection of RADIUS Access-Request packets=2C subsequent
   authentication mechanism specifications=2C such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090]=2C have mandated authentication and
   integrity protection for certain RADIUS packets.  [RFC5080]=2C Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets=2C
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice.


=
= --_68c256f3-f14f-4c44-8089-5446bd114cc9_-- From radext-bounces@ietf.org Tue Jan 10 10:45:35 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BF221F8631; Tue, 10 Jan 2012 10:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326221135; bh=BUWE1qGDzJyL9tEwFLObPYksiS94HU/IAfwBUGJ9J1k=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=MHghkWJFj/A10sU5HWicG5n3KiMzefZmCpV1cwfEpGRU2aeU4RrC4VEr6/p4xCypZ nd2S2+ptc/0bGJ80dGLJYtJEaXQcigIrTeMqopihPR2PfUhEZePmsW30jAqfmn9MPC 4yFWX0TvmRlSXHQFvfh6t6af1c4jj/KUygkdLCAY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8C121F8631 for ; Tue, 10 Jan 2012 10:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjk5x31dydra for ; Tue, 10 Jan 2012 10:45:34 -0800 (PST) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by ietfa.amsl.com (Postfix) with ESMTP id 78B4F21F8606 for ; Tue, 10 Jan 2012 10:45:34 -0800 (PST) Received: from BLU152-W62 ([65.55.111.72]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 10:45:34 -0800 Message-ID: X-Originating-IP: [131.107.0.87] From: Bernard Aboba To: Date: Tue, 10 Jan 2012 10:45:33 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 18:45:34.0273 (UTC) FILETIME=[09438310:01CCCFC8] Subject: [radext] Review of draft-ietf-nextext-radius-pmip6 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3801005980884287722==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============3801005980884287722== Content-Type: multipart/alternative; boundary="_68c256f3-f14f-4c44-8089-5446bd114cc9_" --_68c256f3-f14f-4c44-8089-5446bd114cc9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The document appears to contain typos in sections 4.16 and 4.17. =20 In section 4.16=2C it appears that "Home LMA IPv6 address" should be replac= ed by "Home DHCPv6 server address": 4.16. PMIP6-Home-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In Section 4.17=2C it appears that "Visited LMA IPv6 address" should be rep= laced by "Visited DHCPv6 server address": 4.17. PMIP6-Visited-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Table of Attributes The following table provides a guide to attributes that may be found in authentication and authorization RADIUS messages between MAG and the AAA Server. Request Accept Reject Challenge # Attribute 0-1 0-1 0-1 0-1 80 Message-Authenticator [BA] The Message-Authenticator attribute is mandatory-to-implement in a num= ber of=20 RADIUS usages=2C including EAP (RFC 3579). Leaving out Message-Authenticat= or could=20 result in Access-Requests lacking authentication and integrity protection. RFC 6158 Section 3.1 states: While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets=2C subsequent authentication mechanism specifications=2C such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090]=2C have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080]=2C Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets=2C including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice. =20 = --_68c256f3-f14f-4c44-8089-5446bd114cc9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The document appears to contain typos in sections 4.16 and 4.17. =3B&nb= sp=3B

In section 4.16=2C it appears that "Hom= e LMA IPv6 address" should be replaced by "Home DHCPv6 server address":
= 
4.16.  PMIP6-Home-DHCP6-Server-Address


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |  Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Home LMA IPv6 address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In Section 4.17=2C it appears that "Visited LMA IPv6 address" should be rep=
laced by "Visited DHCPv6 server address":

4.17.  PMIP6-Visited-DHCP6-Server-Address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      | Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Visited LMA IPv6 address     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.  Ta=
ble of Attributes

   The following table provides a guide to attributes that may be found
   in authentication and authorization RADIUS messages between MAG and
   the AAA Server.

Request Accept Reject Challenge #  Attribute

   0-1     0-1    0-1    0-1      80  Message-Authenticator


[BA]=
 The Message-Authenticator attribute is mandatory-to-implement in a number =
of 
RADIUS usages=2C including EAP (RFC 3579).  Leaving out Message-Auth=
enticator could 
result in Access-Requests lacking authentication andintegrity protection.  RFC 6158 Section 3.1 states:

   While [RFC28=
65] did not require authentication and integrity
   protection of RADIUS Access-Request packets=2C subsequent
   authentication mechanism specifications=2C such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090]=2C have mandated authentication and
   integrity protection for certain RADIUS packets.  [RFC5080]=2C Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets=2C
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice.


=
= --_68c256f3-f14f-4c44-8089-5446bd114cc9_-- --===============3801005980884287722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3801005980884287722==-- From peterd@iea-software.com Tue Jan 10 11:41:18 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2311E8074 for ; Tue, 10 Jan 2012 11:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCDQKDbvSqcZ for ; Tue, 10 Jan 2012 11:41:17 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id CF77111E8071 for ; Tue, 10 Jan 2012 11:41:17 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 10 Jan 2012 11:41:17 -0800 Date: Tue, 10 Jan 2012 11:41:21 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0C271C.2060503@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:41:18 -0000 On Tue, 10 Jan 2012, Alejandro Perez Mendez wrote: >> OK: >> [Gear M.1][Gear M.2][GEAR .3] >> NOT OK: >> [Gear M.2][Gear M.1][GEAR .3] >> This not only corrupts the data but also corrupts the attributes >> extended type. This can be dangerous in the wrong hands as the >> *payload* now has a say over the selection of extended type. > I'm trying to figure it out why extended types are also corrupted, but I > don't see a reason. I clearly appreciate how data is corrupted, but > headers should not be affected. Could you please elaborate this a little > more or refer me to further information on this topic? Hi Alejandro, There is a difference in the wire format between initial and subsequent fragments of a long attribute (4.5 and 4.6). The initial format look like this: Type + Len + ExtType + M + Flags + VID + VType + Value Subsequent fragments: Type + Len + ExtType + M + Flags + Values If order of initial and subsequent fragment is changed system has no information preventing 'Value' from being interpreted as 'VID + VType + Value'. regards, Peter From radext-bounces@ietf.org Tue Jan 10 11:41:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE71A11E8074; Tue, 10 Jan 2012 11:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326224479; bh=jp6gebH0m6G4g4F5pWIzpHZQywgD4akyM8cASrBD38Y=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=eeyBY4qLJi//URIAg2eFpeTPH8WfUN0lV3rvu6zbgAW3ebS4CEriWsywBcENmOsdz 4b8v1e+6Ui2f0YegW0sJ9Wetop19b4hrVUq8mZiXng1xLOZecicDLuCfklZtAZ8XYo IEZoiy0RQa8dsRQKQSK/tG4M8p66BxLtS2Y9kOBc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD2311E8074 for ; Tue, 10 Jan 2012 11:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.774 X-Spam-Level: X-Spam-Status: No, score=-2.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCDQKDbvSqcZ for ; Tue, 10 Jan 2012 11:41:17 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id CF77111E8071 for ; Tue, 10 Jan 2012 11:41:17 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 10 Jan 2012 11:41:17 -0800 Date: Tue, 10 Jan 2012 11:41:21 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0C271C.2060503@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Tue, 10 Jan 2012, Alejandro Perez Mendez wrote: >> OK: >> [Gear M.1][Gear M.2][GEAR .3] >> NOT OK: >> [Gear M.2][Gear M.1][GEAR .3] >> This not only corrupts the data but also corrupts the attributes >> extended type. This can be dangerous in the wrong hands as the >> *payload* now has a say over the selection of extended type. > I'm trying to figure it out why extended types are also corrupted, but I > don't see a reason. I clearly appreciate how data is corrupted, but > headers should not be affected. Could you please elaborate this a little > more or refer me to further information on this topic? Hi Alejandro, There is a difference in the wire format between initial and subsequent fragments of a long attribute (4.5 and 4.6). The initial format look like this: Type + Len + ExtType + M + Flags + VID + VType + Value Subsequent fragments: Type + Len + ExtType + M + Flags + Values If order of initial and subsequent fragment is changed system has no information preventing 'Value' from being interpreted as 'VID + VType + Value'. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Tue Jan 10 11:47:41 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E79A21F87EF; Tue, 10 Jan 2012 11:47:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326224861; bh=wFdeUF+yuP3DC5BUaYIyjwfyoQwrjW+eiv4nyihJROs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=rnb+ELjSWDvwflVDAdYflpyfc12ztzt+eQQ72zaz0qgQKGemstRP34voStl3jYGKN Dn1bgJjbqdrUuCQEO8mOMypz+3GdmE1+SGxYN7EBIWa9hlQzpoAFrp5Lb4lQoTQSud 0ihIFz7DzTviG4+lmoN6xH8qloWkI29rZZ/5qJG4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0321F8797 for ; Tue, 10 Jan 2012 11:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQtwz-Fxgygn for ; Tue, 10 Jan 2012 11:47:39 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id 644F221F87EF for ; Tue, 10 Jan 2012 11:47:39 -0800 (PST) Received: from mail-vx0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTwyV2rpatpWYIL+1TORIFSIVS73KqcGg@postini.com; Tue, 10 Jan 2012 11:47:39 PST Received: by mail-vx0-f178.google.com with SMTP id fo11so4517800vcb.23 for ; Tue, 10 Jan 2012 11:47:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.8 with SMTP id h8mr4615193vdg.122.1326224858881; Tue, 10 Jan 2012 11:47:38 -0800 (PST) Received: by 10.52.26.68 with HTTP; Tue, 10 Jan 2012 11:47:38 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Jan 2012 14:47:38 -0500 Message-ID: From: Dave Nelson To: Bernard Aboba Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3991529526052185072==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============3991529526052185072== Content-Type: multipart/alternative; boundary=20cf307c9afe9b1cf804b631c9c9 --20cf307c9afe9b1cf804b631c9c9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 10, 2012 at 1:45 PM, Bernard Aboba wrote: > > If there is no systematic review process, in practice the RFC 6158 > guidelines will be ignored. > AFAICT, the only way reviews are ever guaranteed in the IETF is via the diligence of the IESG. All other mechanisms are best effort. --20cf307c9afe9b1cf804b631c9c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2012 at 1:45 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
=A0
If there is no systemati= c review process, in practice the RFC 6158 guidelines will be ignored.=A0

AFAICT, = the only way reviews are ever=A0guaranteed=A0in=A0the=A0IETF is via the=A0d= iligence=A0of the IESG. =A0All other mechanisms are best effort.

--20cf307c9afe9b1cf804b631c9c9-- --===============3991529526052185072== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3991529526052185072==-- From dnelson@elbrys.com Tue Jan 10 11:47:40 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0321F8797 for ; Tue, 10 Jan 2012 11:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQtwz-Fxgygn for ; Tue, 10 Jan 2012 11:47:39 -0800 (PST) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id 644F221F87EF for ; Tue, 10 Jan 2012 11:47:39 -0800 (PST) Received: from mail-vx0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKTwyV2rpatpWYIL+1TORIFSIVS73KqcGg@postini.com; Tue, 10 Jan 2012 11:47:39 PST Received: by mail-vx0-f178.google.com with SMTP id fo11so4517800vcb.23 for ; Tue, 10 Jan 2012 11:47:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.26.8 with SMTP id h8mr4615193vdg.122.1326224858881; Tue, 10 Jan 2012 11:47:38 -0800 (PST) Received: by 10.52.26.68 with HTTP; Tue, 10 Jan 2012 11:47:38 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Jan 2012 14:47:38 -0500 Message-ID: From: Dave Nelson To: Bernard Aboba Content-Type: multipart/alternative; boundary=20cf307c9afe9b1cf804b631c9c9 Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:47:40 -0000 --20cf307c9afe9b1cf804b631c9c9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 10, 2012 at 1:45 PM, Bernard Aboba wrote: > > If there is no systematic review process, in practice the RFC 6158 > guidelines will be ignored. > AFAICT, the only way reviews are ever guaranteed in the IETF is via the diligence of the IESG. All other mechanisms are best effort. --20cf307c9afe9b1cf804b631c9c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2012 at 1:45 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
=A0
If there is no systemati= c review process, in practice the RFC 6158 guidelines will be ignored.=A0

AFAICT, = the only way reviews are ever=A0guaranteed=A0in=A0the=A0IETF is via the=A0d= iligence=A0of the IESG. =A0All other mechanisms are best effort.

--20cf307c9afe9b1cf804b631c9c9-- From radext-bounces@ietf.org Tue Jan 10 11:48:35 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27A121F8803; Tue, 10 Jan 2012 11:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326224915; bh=RlGVU3d16I0bzxtae2C0zVT+WXwGWHxDfDkVGXMw8Hk=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=wXExGlX3mfJ0OURY8p0ox2lW975szVloy9UxurS8T+fVRWuFzruwz7/9Y5gcJFSrh aCVzeCUQAxvR2/vB6emPPjIC1N4oBfwtFsCeI3SBqRX8k522f6n+CGyMvKK0lNOqMJ MHy3IF3xww9M6jVV0VlbPPep8ZmQd0KFlMfX/Fz4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58E411E8071 for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHxmeeAVkElW for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5796221F8797 for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) Received: from BLU152-W28 ([65.55.116.72]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 11:48:30 -0800 Message-ID: X-Originating-IP: [131.107.0.117] From: Bernard Aboba To: Date: Tue, 10 Jan 2012 11:48:29 -0800 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 19:48:30.0511 (UTC) FILETIME=[D413B3F0:01CCCFD0] Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6207724863206981470==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============6207724863206981470== Content-Type: multipart/alternative; boundary="_56ac803a-1acf-4512-b11a-0eb708b9cb8d_" --_56ac803a-1acf-4512-b11a-0eb708b9cb8d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Nelson said: "AFAICT=2C the only way reviews are ever guaranteed in the IETF is via the = diligence of the IESG. All other mechanisms are best effort." [BA] Right. In practice=2C these kind of reviews are often handled by dire= ctorates or "Doctor" groups. I'm just pointing out that there is currently= no process for ensuring that such reviews occur for AAA documents. This i= s not just a problem for RFC 6158=3B other AAA-related RFCs and BCPs are a= lso being routinely ignored.=20 = --_56ac803a-1acf-4512-b11a-0eb708b9cb8d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
David Nelson said:

"AFAICT=2C the only way reviews are ever =3Bguaranteed =3Bin = =3Bthe =3BIETF is via the =3Bdiligence =3Bof the IESG.  =3B= All other mechanisms are best effort."

[BA] Right. =3B In practi= ce=2C these kind of reviews are often handled by directorates or "Doctor" g= roups. =3B I'm just pointing out that there is currently no process for= ensuring that such reviews occur for AAA documents. =3B This is not ju= st a problem for RFC 6158=3B =3B other AAA-related RFCs and BCPs are al= so being routinely ignored.

=
= --_56ac803a-1acf-4512-b11a-0eb708b9cb8d_-- --===============6207724863206981470== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============6207724863206981470==-- From bernard_aboba@hotmail.com Tue Jan 10 11:48:33 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58E411E8071 for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHxmeeAVkElW for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) Received: from blu0-omc3-s32.blu0.hotmail.com (blu0-omc3-s32.blu0.hotmail.com [65.55.116.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5796221F8797 for ; Tue, 10 Jan 2012 11:48:33 -0800 (PST) Received: from BLU152-W28 ([65.55.116.72]) by blu0-omc3-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 11:48:30 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_56ac803a-1acf-4512-b11a-0eb708b9cb8d_" X-Originating-IP: [131.107.0.117] From: Bernard Aboba To: Date: Tue, 10 Jan 2012 11:48:29 -0800 Importance: Normal In-Reply-To: References: , , MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 19:48:30.0511 (UTC) FILETIME=[D413B3F0:01CCCFD0] Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:48:34 -0000 --_56ac803a-1acf-4512-b11a-0eb708b9cb8d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Nelson said: "AFAICT=2C the only way reviews are ever guaranteed in the IETF is via the = diligence of the IESG. All other mechanisms are best effort." [BA] Right. In practice=2C these kind of reviews are often handled by dire= ctorates or "Doctor" groups. I'm just pointing out that there is currently= no process for ensuring that such reviews occur for AAA documents. This i= s not just a problem for RFC 6158=3B other AAA-related RFCs and BCPs are a= lso being routinely ignored.=20 = --_56ac803a-1acf-4512-b11a-0eb708b9cb8d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
David Nelson said:

"AFAICT=2C the only way reviews are ever =3Bguaranteed =3Bin = =3Bthe =3BIETF is via the =3Bdiligence =3Bof the IESG.  =3B= All other mechanisms are best effort."

[BA] Right. =3B In practi= ce=2C these kind of reviews are often handled by directorates or "Doctor" g= roups. =3B I'm just pointing out that there is currently no process for= ensuring that such reviews occur for AAA documents. =3B This is not ju= st a problem for RFC 6158=3B =3B other AAA-related RFCs and BCPs are al= so being routinely ignored.

=
= --_56ac803a-1acf-4512-b11a-0eb708b9cb8d_-- From aland@deployingradius.com Tue Jan 10 11:52:14 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A33E21F86AD for ; Tue, 10 Jan 2012 11:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqEEWzuszuO4 for ; Tue, 10 Jan 2012 11:52:13 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEC521F8692 for ; Tue, 10 Jan 2012 11:52:13 -0800 (PST) Message-ID: <4F0C96D1.4090609@deployingradius.com> Date: Tue, 10 Jan 2012 20:51:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:52:14 -0000 Bernard Aboba wrote: > [BA] How do we ensure that these reviews are actually carried out? cron? $ rsync -avz --delete ftp.rfc-editor.org::internet-drafts . $ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next if /^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if ($_[2] eq "Expired");next if ! -f "$_[0].txt";print $_[0],".txt\n";' < all_id.txt > radius.txt $ for x in `cat radius.txt`; do \ egrep -l RADIUS $x >> radext-review.txt; \ done That gives us a list (below). We could post the list once a month to radext and aaa-doctors. That would at least ensure the documents get noted in IESG review, or IETF last call. draft-ietf-emu-eaptunnel-req-09.txt draft-ietf-mip4-generic-notification-message-16.txt draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt draft-ietf-mip6-hiopt-17.txt draft-ietf-netconf-access-control-07.txt draft-ietf-netext-radius-pmip6-06.txt draft-ietf-softwire-dslite-radius-ext-07.txt draft-ietf-abfab-aaa-saml-02.txt draft-ietf-abfab-arch-00.txt draft-ietf-abfab-gss-eap-04.txt draft-ietf-abfab-gss-eap-naming-01.txt draft-ietf-emu-chbind-12.txt draft-ietf-emu-eap-tunnel-method-01.txt draft-ietf-geopriv-held-measurements-04.txt draft-ietf-hokey-rfc5296bis-06.txt draft-ietf-karp-ops-model-01.txt draft-ietf-nea-pt-tls-01.txt draft-ietf-opsawg-management-stds-03.txt draft-ietf-precis-framework-01.txt draft-ietf-softwire-6rd-radius-attrib-04.txt draft-ietf-softwire-dslite-deployment-01.txt draft-ietf-storm-iscsi-cons-04.txt Alan DeKok. From radext-bounces@ietf.org Tue Jan 10 11:52:15 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CCC11E8088; Tue, 10 Jan 2012 11:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326225135; bh=EBPy79a/ZoHFj7x8PrqofCZxgfqlVPkuAzX713oGHZI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=AMQ82Z/b7x715vtF52nCpsV27vtRzHVYWkWBQgQZVf2DKOyO0RkeTCZj7v9aCVIuZ TMDhC13pQA7lwfbLnRgRs5QdiXIZudxqOCGj0O9fFSkt7IcjJQ+uiYRpGZpbgUY1PN t9uFl0hY/e0SxtSp45l3AxzB4p0xFuWBuo6JDwhI= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A33E21F86AD for ; Tue, 10 Jan 2012 11:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqEEWzuszuO4 for ; Tue, 10 Jan 2012 11:52:13 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEC521F8692 for ; Tue, 10 Jan 2012 11:52:13 -0800 (PST) Message-ID: <4F0C96D1.4090609@deployingradius.com> Date: Tue, 10 Jan 2012 20:51:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > [BA] How do we ensure that these reviews are actually carried out? cron? $ rsync -avz --delete ftp.rfc-editor.org::internet-drafts . $ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next if /^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if ($_[2] eq "Expired");next if ! -f "$_[0].txt";print $_[0],".txt\n";' < all_id.txt > radius.txt $ for x in `cat radius.txt`; do \ egrep -l RADIUS $x >> radext-review.txt; \ done That gives us a list (below). We could post the list once a month to radext and aaa-doctors. That would at least ensure the documents get noted in IESG review, or IETF last call. draft-ietf-emu-eaptunnel-req-09.txt draft-ietf-mip4-generic-notification-message-16.txt draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt draft-ietf-mip6-hiopt-17.txt draft-ietf-netconf-access-control-07.txt draft-ietf-netext-radius-pmip6-06.txt draft-ietf-softwire-dslite-radius-ext-07.txt draft-ietf-abfab-aaa-saml-02.txt draft-ietf-abfab-arch-00.txt draft-ietf-abfab-gss-eap-04.txt draft-ietf-abfab-gss-eap-naming-01.txt draft-ietf-emu-chbind-12.txt draft-ietf-emu-eap-tunnel-method-01.txt draft-ietf-geopriv-held-measurements-04.txt draft-ietf-hokey-rfc5296bis-06.txt draft-ietf-karp-ops-model-01.txt draft-ietf-nea-pt-tls-01.txt draft-ietf-opsawg-management-stds-03.txt draft-ietf-precis-framework-01.txt draft-ietf-softwire-6rd-radius-attrib-04.txt draft-ietf-softwire-dslite-deployment-01.txt draft-ietf-storm-iscsi-cons-04.txt Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dromasca@avaya.com Tue Jan 10 12:03:25 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAA21F882D; Tue, 10 Jan 2012 12:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.312 X-Spam-Level: X-Spam-Status: No, score=-103.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwuH449YB6MC; Tue, 10 Jan 2012 12:03:25 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 80ADF1F0C41; Tue, 10 Jan 2012 12:03:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPyYDE/GmAcF/2dsb2JhbAA5CqxagQWBcgEBAQEDAQEBDwoRAzcHCwwEAgEIDQQEAQEBCgYMDAYBJigIAQEEARIIGodgm0ibJQSIVoJaYwSIB5J2jEo X-IronPort-AV: E=Sophos;i="4.71,489,1320642000"; d="scan'208,217";a="285598778" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jan 2012 15:03:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jan 2012 14:59:02 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCFD2.E67F2165" Date: Tue, 10 Jan 2012 21:03:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RFC 6158 Reviews: how does it work in practice? Thread-Index: AczP0WVUyRyUfU8NT4GUZo2TzzLlNgAAK72m References: <4F0C96D1.4090609@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "Bernard Aboba" Cc: aaa-doctors@ietf.org, radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 20:03:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCFD2.E67F2165 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes.=20 The AAA-Doctors team secretary should scan all documents that enter IETF = Last Call and identify those who have any trace of = RADIUS/Diameter/other_AAA content, and then dispatch them to the = AAA-Doctors team for review according to some algorithm of his own.=20 OPS-DIR use this method and it works pretty well for them.=20 It's still best-effort, as all volunteer work we do in the IETF.=20 Dan -----Original Message----- From: radext-bounces@ietf.org on behalf of Alan DeKok Sent: Tue 1/10/2012 9:51 PM To: Bernard Aboba Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? =20 Bernard Aboba wrote: > [BA] How do we ensure that these reviews are actually carried out? cron? $ rsync -avz --delete ftp.rfc-editor.org::internet-drafts . $ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next if /^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if ($_[2] eq "Expired");next if ! -f "$_[0].txt";print $_[0],".txt\n";' < all_id.txt > radius.txt $ for x in `cat radius.txt`; do \ egrep -l RADIUS $x >> radext-review.txt; \ done That gives us a list (below). We could post the list once a month to radext and aaa-doctors. That would at least ensure the documents get noted in IESG review, or IETF last call. draft-ietf-emu-eaptunnel-req-09.txt draft-ietf-mip4-generic-notification-message-16.txt draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt draft-ietf-mip6-hiopt-17.txt draft-ietf-netconf-access-control-07.txt draft-ietf-netext-radius-pmip6-06.txt draft-ietf-softwire-dslite-radius-ext-07.txt draft-ietf-abfab-aaa-saml-02.txt draft-ietf-abfab-arch-00.txt draft-ietf-abfab-gss-eap-04.txt draft-ietf-abfab-gss-eap-naming-01.txt draft-ietf-emu-chbind-12.txt draft-ietf-emu-eap-tunnel-method-01.txt draft-ietf-geopriv-held-measurements-04.txt draft-ietf-hokey-rfc5296bis-06.txt draft-ietf-karp-ops-model-01.txt draft-ietf-nea-pt-tls-01.txt draft-ietf-opsawg-management-stds-03.txt draft-ietf-precis-framework-01.txt draft-ietf-softwire-6rd-radius-attrib-04.txt draft-ietf-softwire-dslite-deployment-01.txt draft-ietf-storm-iscsi-cons-04.txt Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------_=_NextPart_001_01CCCFD2.E67F2165 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [radext] RFC 6158 Reviews: how does it work in = practice?

Yes.

The AAA-Doctors team secretary should scan all documents that enter IETF = Last Call and identify those who have any trace of = RADIUS/Diameter/other_AAA content, and then dispatch them to the = AAA-Doctors team for review according to some algorithm of his own.

OPS-DIR use this method and it works pretty well for them.

It's still best-effort, as all volunteer work we do in the IETF.

Dan


-----Original Message-----
From: radext-bounces@ietf.org on behalf of Alan DeKok
Sent: Tue 1/10/2012 9:51 PM
To: Bernard Aboba
Cc: radext@ietf.org
Subject: Re: [radext] RFC 6158 Reviews:  how does it work in = practice?

Bernard Aboba wrote:
> [BA]  How do we ensure that these reviews are actually carried = out?

  cron?

$ rsync -avz --delete ftp.rfc-editor.org::internet-drafts .

$ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next = if
/^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if = ($_[2] eq
"Expired");next if ! -f "$_[0].txt";print = $_[0],".txt\n";' < all_id.txt
> radius.txt

$ for x in `cat radius.txt`; do \
            egrep -l = RADIUS $x >> radext-review.txt; \
  done

  That gives us a list (below).  We could post the list once a = month to
radext and aaa-doctors.  That would at least ensure the documents = get
noted in IESG review, or IETF last call.

draft-ietf-emu-eaptunnel-req-09.txt
draft-ietf-mip4-generic-notification-message-16.txt
draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt
draft-ietf-mip6-hiopt-17.txt
draft-ietf-netconf-access-control-07.txt
draft-ietf-netext-radius-pmip6-06.txt
draft-ietf-softwire-dslite-radius-ext-07.txt
draft-ietf-abfab-aaa-saml-02.txt
draft-ietf-abfab-arch-00.txt
draft-ietf-abfab-gss-eap-04.txt
draft-ietf-abfab-gss-eap-naming-01.txt
draft-ietf-emu-chbind-12.txt
draft-ietf-emu-eap-tunnel-method-01.txt
draft-ietf-geopriv-held-measurements-04.txt
draft-ietf-hokey-rfc5296bis-06.txt
draft-ietf-karp-ops-model-01.txt
draft-ietf-nea-pt-tls-01.txt
draft-ietf-opsawg-management-stds-03.txt
draft-ietf-precis-framework-01.txt
draft-ietf-softwire-6rd-radius-attrib-04.txt
draft-ietf-softwire-dslite-deployment-01.txt
draft-ietf-storm-iscsi-cons-04.txt

  Alan DeKok.
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.or= g/mailman/listinfo/radext

------_=_NextPart_001_01CCCFD2.E67F2165-- From radext-bounces@ietf.org Tue Jan 10 12:03:27 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D186611E8071; Tue, 10 Jan 2012 12:03:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326225807; bh=G+h8sZ4ghmworgw9dSNYnWrwiyZsI9jYITFBxYN3r8Q=; h=MIME-Version:Date:Message-ID:References:From:To:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=XBDR0aOkCBUUFkzPIIqjs46riWdjZ+JKvh0e8DhG4M05ELlx8sxF/+MeGN0kU+Rhp +KX/3dhfUd7DBpkzQMnHZzQ+zjbaFCJj4r1ZvfzcS4Z/faEQbbIG/3CniJFHeN5HeT +Ppv2t4+Fo5NcVZu7qa1G6d1H/61Ii/8D22mwTq8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAA21F882D; Tue, 10 Jan 2012 12:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.312 X-Spam-Level: X-Spam-Status: No, score=-103.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwuH449YB6MC; Tue, 10 Jan 2012 12:03:25 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 80ADF1F0C41; Tue, 10 Jan 2012 12:03:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPyYDE/GmAcF/2dsb2JhbAA5CqxagQWBcgEBAQEDAQEBDwoRAzcHCwwEAgEIDQQEAQEBCgYMDAYBJigIAQEEARIIGodgm0ibJQSIVoJaYwSIB5J2jEo X-IronPort-AV: E=Sophos;i="4.71,489,1320642000"; d="scan'208,217";a="285598778" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 10 Jan 2012 15:03:22 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jan 2012 14:59:02 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jan 2012 21:03:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RFC 6158 Reviews: how does it work in practice? Thread-Index: AczP0WVUyRyUfU8NT4GUZo2TzzLlNgAAK72m References: <4F0C96D1.4090609@deployingradius.com> From: "Romascanu, Dan (Dan)" To: "Alan DeKok" , "Bernard Aboba" Cc: aaa-doctors@ietf.org, radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5777086699042138239==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============5777086699042138239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCFD2.E67F2165" This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCFD2.E67F2165 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes.=20 The AAA-Doctors team secretary should scan all documents that enter IETF = Last Call and identify those who have any trace of = RADIUS/Diameter/other_AAA content, and then dispatch them to the = AAA-Doctors team for review according to some algorithm of his own.=20 OPS-DIR use this method and it works pretty well for them.=20 It's still best-effort, as all volunteer work we do in the IETF.=20 Dan -----Original Message----- From: radext-bounces@ietf.org on behalf of Alan DeKok Sent: Tue 1/10/2012 9:51 PM To: Bernard Aboba Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? =20 Bernard Aboba wrote: > [BA] How do we ensure that these reviews are actually carried out? cron? $ rsync -avz --delete ftp.rfc-editor.org::internet-drafts . $ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next if /^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if ($_[2] eq "Expired");next if ! -f "$_[0].txt";print $_[0],".txt\n";' < all_id.txt > radius.txt $ for x in `cat radius.txt`; do \ egrep -l RADIUS $x >> radext-review.txt; \ done That gives us a list (below). We could post the list once a month to radext and aaa-doctors. That would at least ensure the documents get noted in IESG review, or IETF last call. draft-ietf-emu-eaptunnel-req-09.txt draft-ietf-mip4-generic-notification-message-16.txt draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt draft-ietf-mip6-hiopt-17.txt draft-ietf-netconf-access-control-07.txt draft-ietf-netext-radius-pmip6-06.txt draft-ietf-softwire-dslite-radius-ext-07.txt draft-ietf-abfab-aaa-saml-02.txt draft-ietf-abfab-arch-00.txt draft-ietf-abfab-gss-eap-04.txt draft-ietf-abfab-gss-eap-naming-01.txt draft-ietf-emu-chbind-12.txt draft-ietf-emu-eap-tunnel-method-01.txt draft-ietf-geopriv-held-measurements-04.txt draft-ietf-hokey-rfc5296bis-06.txt draft-ietf-karp-ops-model-01.txt draft-ietf-nea-pt-tls-01.txt draft-ietf-opsawg-management-stds-03.txt draft-ietf-precis-framework-01.txt draft-ietf-softwire-6rd-radius-attrib-04.txt draft-ietf-softwire-dslite-deployment-01.txt draft-ietf-storm-iscsi-cons-04.txt Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------_=_NextPart_001_01CCCFD2.E67F2165 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [radext] RFC 6158 Reviews: how does it work in = practice?

Yes.

The AAA-Doctors team secretary should scan all documents that enter IETF = Last Call and identify those who have any trace of = RADIUS/Diameter/other_AAA content, and then dispatch them to the = AAA-Doctors team for review according to some algorithm of his own.

OPS-DIR use this method and it works pretty well for them.

It's still best-effort, as all volunteer work we do in the IETF.

Dan


-----Original Message-----
From: radext-bounces@ietf.org on behalf of Alan DeKok
Sent: Tue 1/10/2012 9:51 PM
To: Bernard Aboba
Cc: radext@ietf.org
Subject: Re: [radext] RFC 6158 Reviews:  how does it work in = practice?

Bernard Aboba wrote:
> [BA]  How do we ensure that these reviews are actually carried = out?

  cron?

$ rsync -avz --delete ftp.rfc-editor.org::internet-drafts .

$ perl -ne 'next if !/^draft-ietf-/;next if /^draft-ietf-radext/;next = if
/^draft-ietf-dime/;chop;split;next if ($_[2] eq "RFC");next if = ($_[2] eq
"Expired");next if ! -f "$_[0].txt";print = $_[0],".txt\n";' < all_id.txt
> radius.txt

$ for x in `cat radius.txt`; do \
            egrep -l = RADIUS $x >> radext-review.txt; \
  done

  That gives us a list (below).  We could post the list once a = month to
radext and aaa-doctors.  That would at least ensure the documents = get
noted in IESG review, or IETF last call.

draft-ietf-emu-eaptunnel-req-09.txt
draft-ietf-mip4-generic-notification-message-16.txt
draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt
draft-ietf-mip6-hiopt-17.txt
draft-ietf-netconf-access-control-07.txt
draft-ietf-netext-radius-pmip6-06.txt
draft-ietf-softwire-dslite-radius-ext-07.txt
draft-ietf-abfab-aaa-saml-02.txt
draft-ietf-abfab-arch-00.txt
draft-ietf-abfab-gss-eap-04.txt
draft-ietf-abfab-gss-eap-naming-01.txt
draft-ietf-emu-chbind-12.txt
draft-ietf-emu-eap-tunnel-method-01.txt
draft-ietf-geopriv-held-measurements-04.txt
draft-ietf-hokey-rfc5296bis-06.txt
draft-ietf-karp-ops-model-01.txt
draft-ietf-nea-pt-tls-01.txt
draft-ietf-opsawg-management-stds-03.txt
draft-ietf-precis-framework-01.txt
draft-ietf-softwire-6rd-radius-attrib-04.txt
draft-ietf-softwire-dslite-deployment-01.txt
draft-ietf-storm-iscsi-cons-04.txt

  Alan DeKok.
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.or= g/mailman/listinfo/radext

------_=_NextPart_001_01CCCFD2.E67F2165-- --===============5777086699042138239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============5777086699042138239==-- From radext-bounces@ietf.org Tue Jan 10 12:27:39 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6C21F885A; Tue, 10 Jan 2012 12:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326227259; bh=XEYzFcYvL7GnLlma3yQOx9O3/KY/gKNtsdTPKEuwWuA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=l4IsstR+3HFA5ZUzOYs8sIKtFfQfAwaLz48R45u3tGmmEY6YsO5bobLFZ16D0u5iD rzjM01WVP4Hlm+GrHL7BlwbnR/gkGbCsOvxkMpxjI+gVgX45clSVMlXdP/60JstAbi oxj1EX6bf53xaCxLG8Nw8qrxDuUhbeLTPnrJY3ko= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2108321F87FC for ; Tue, 10 Jan 2012 11:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkPtPt4lBlVS for ; Tue, 10 Jan 2012 11:26:51 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 5CBEF21F880E for ; Tue, 10 Jan 2012 11:26:51 -0800 (PST) Received: from mail-vx0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTwyQ+hVzHYHMQXGGJUw3+TSX8TQyy6k3@postini.com; Tue, 10 Jan 2012 11:26:51 PST Received: by mail-vx0-f170.google.com with SMTP id n13so3997027vcd.29 for ; Tue, 10 Jan 2012 11:26:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.156.201 with SMTP id y9mr13618237vcw.22.1326223610455; Tue, 10 Jan 2012 11:26:50 -0800 (PST) Received: by 10.52.26.68 with HTTP; Tue, 10 Jan 2012 11:26:50 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Jan 2012 14:26:50 -0500 Message-ID: From: Dave Nelson To: Bernard Aboba X-Mailman-Approved-At: Tue, 10 Jan 2012 12:27:38 -0800 Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7639165992632681980==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============7639165992632681980== Content-Type: multipart/alternative; boundary=f46d042f93ce31a52704b6317fab --f46d042f93ce31a52704b6317fab Content-Type: text/plain; charset=ISO-8859-1 > > If there is no systematic review process, in practice the RFC 6158 > guidelines will be ignored. > AFAICT, the only way reviews are ever guaranteed in the IETF is via the diligence of the IESG. All other mechanisms are best effort. --f46d042f93ce31a52704b6317fab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If there is no systematic review process, in pra= ctice the RFC 6158 guidelines will be ignored.=A0

AFAICT, the only w= ay reviews are ever=A0guaranteed=A0in=A0the=A0IETF is via the=A0diligence= =A0of the IESG. =A0All other mechanisms are best effort.

--f46d042f93ce31a52704b6317fab-- --===============7639165992632681980== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7639165992632681980==-- From dnelson@elbrys.com Tue Jan 10 11:26:53 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2108321F87FC for ; Tue, 10 Jan 2012 11:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkPtPt4lBlVS for ; Tue, 10 Jan 2012 11:26:51 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 5CBEF21F880E for ; Tue, 10 Jan 2012 11:26:51 -0800 (PST) Received: from mail-vx0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTwyQ+hVzHYHMQXGGJUw3+TSX8TQyy6k3@postini.com; Tue, 10 Jan 2012 11:26:51 PST Received: by mail-vx0-f170.google.com with SMTP id n13so3997027vcd.29 for ; Tue, 10 Jan 2012 11:26:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.156.201 with SMTP id y9mr13618237vcw.22.1326223610455; Tue, 10 Jan 2012 11:26:50 -0800 (PST) Received: by 10.52.26.68 with HTTP; Tue, 10 Jan 2012 11:26:50 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Jan 2012 14:26:50 -0500 Message-ID: From: Dave Nelson To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d042f93ce31a52704b6317fab X-Mailman-Approved-At: Tue, 10 Jan 2012 12:27:38 -0800 Cc: radext@ietf.org Subject: Re: [radext] RFC 6158 Reviews: how does it work in practice? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:26:53 -0000 --f46d042f93ce31a52704b6317fab Content-Type: text/plain; charset=ISO-8859-1 > > If there is no systematic review process, in practice the RFC 6158 > guidelines will be ignored. > AFAICT, the only way reviews are ever guaranteed in the IETF is via the diligence of the IESG. All other mechanisms are best effort. --f46d042f93ce31a52704b6317fab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If there is no systematic review process, in pra= ctice the RFC 6158 guidelines will be ignored.=A0

AFAICT, the only w= ay reviews are ever=A0guaranteed=A0in=A0the=A0IETF is via the=A0diligence= =A0of the IESG. =A0All other mechanisms are best effort.

--f46d042f93ce31a52704b6317fab-- From jouni.nospam@gmail.com Tue Jan 10 23:16:55 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F189E21F883D; Tue, 10 Jan 2012 23:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZcZ0VDBefIP; Tue, 10 Jan 2012 23:16:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B249821F883A; Tue, 10 Jan 2012 23:16:53 -0800 (PST) Received: by werb14 with SMTP id b14so351819wer.31 for ; Tue, 10 Jan 2012 23:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wKaB5gqDQcDzbdGm9sz0VfjDQ666OzEOu61LNIJgH+o=; b=mDymZR6Zvq88cs+N1ngDpuR2aPGlgue6UiAjTDnk09YQoXSrHuJxh55vR8i7mI4ky3 /vnVwlcgUxD19cUBxG7cxtosxQR3K2taZnbtBA3yKWXJ6bsOFKG1wqSuq403nO37dLsm HNGqKUadnSVfNWmxhvfAD9YRfWfGRrgKn2hp8= Received: by 10.180.80.162 with SMTP id s2mr8676723wix.10.1326266212856; Tue, 10 Jan 2012 23:16:52 -0800 (PST) Received: from [10.255.132.235] ([192.100.123.77]) by mx.google.com with ESMTPS id di5sm928888wib.3.2012.01.10.23.16.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 23:16:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 11 Jan 2012 09:11:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D26445C-2511-41C9-BFC7-E8881DF0BA96@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: radext@ietf.org, ietf@ietf.org, Frank Xia , "iesg@ietf.org IESG" Subject: Re: [radext] Review of draft-ietf-nextext-radius-pmip6 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 07:16:55 -0000 On Jan 11, 2012, at 9:04 AM, Bernard Aboba wrote: > Message-Authenticator should be mandatory (1 1 1 1). Ack. Thanks Bernard. - Jouni >=20 >=20 > On Jan 10, 2012, at 22:30, "jouni korhonen" = wrote: >=20 >> Bernard, >>=20 >> Thank you for your review. See my comments inline. >>=20 >>=20 >> On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote: >>=20 >>> The document appears to contain typos in sections 4.16 and 4.17. =20= >>>=20 >>> In section 4.16, it appears that "Home LMA IPv6 address" should be = replaced by "Home DHCPv6 server address": >>=20 >> Blimey.. we'll fix this. >>=20 >>> 4.16. PMIP6-Home-DHCP6-Server-Address >>>=20 >>>=20 >>>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home LMA IPv6 address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> In Section 4.17, it appears that "Visited LMA IPv6 address" should = be replaced by "Visited DHCPv6 server address": >>=20 >> And the same here.. >>=20 >>=20 >>>=20 >>> 4.17. PMIP6-Visited-DHCP6-Server-Address >>>=20 >>>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited LMA IPv6 address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>> 5.2. Table of Attributes >>>=20 >>>=20 >>> The following table provides a guide to attributes that may be = found >>> in authentication and authorization RADIUS messages between MAG and >>> the AAA Server. >>>=20 >>>=20 >>> Request Accept Reject Challenge # Attribute >>>=20 >>> 0-1 0-1 0-1 0-1 80 Message-Authenticator >>>=20 >>>=20 >>>=20 >>> [BA] The Message-Authenticator attribute is mandatory-to-implement = in a number of=20 >>> RADIUS usages, including EAP (RFC 3579). Leaving out = Message-Authenticator could=20 >>> result in Access-Requests lacking authentication and >>> integrity protection. RFC 6158 Section 3.1 states: >>=20 >> Good point. So, you are saying that we should have: >>=20 >> 1 0-1 0-1 0-1 80 Message-Authenticator >>=20 >> or would=20 >>=20 >> 1 1 1 1 80 Message-Authenticator >>=20 >> be even better as RFC3759 & 5090 do? >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>> While [RFC2865] did not require authentication and integrity >>> protection of RADIUS Access-Request packets, subsequent >>> authentication mechanism specifications, such as RADIUS/EAP = [RFC3579] >>> and Digest Authentication [RFC5090], have mandated authentication = and >>> integrity protection for certain RADIUS packets. [RFC5080], = Section >>> 2.1.1 makes this behavior RECOMMENDED for all Access-Request = packets, >>> including Access-Request packets performing authorization checks. = It >>> is expected that specifications for new RADIUS authentication >>> mechanisms will continue this practice. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 From radext-bounces@ietf.org Tue Jan 10 23:16:58 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39EE21F8848; Tue, 10 Jan 2012 23:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326266218; bh=g27kwBLa2++jR0CwwCe94A6Svnu/1XaBr3ZO8LeASwg=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Vsxo5l+rHouQUpIYyDvWuDxUvHgtNzuelXvl0HsGvrPw0MU2RBAU2jYQEzhzsnQ8T ENE7whWZ7ijRTC5iw4RayIuNVupXyQRzmuyb7J9moQhjEq3Q32c6/eNDGYODEyL3fN EGpUWevBFKR1Rq0NYCJg5VkwMkOzhB4A5D6CQzZU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F189E21F883D; Tue, 10 Jan 2012 23:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZcZ0VDBefIP; Tue, 10 Jan 2012 23:16:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B249821F883A; Tue, 10 Jan 2012 23:16:53 -0800 (PST) Received: by werb14 with SMTP id b14so351819wer.31 for ; Tue, 10 Jan 2012 23:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wKaB5gqDQcDzbdGm9sz0VfjDQ666OzEOu61LNIJgH+o=; b=mDymZR6Zvq88cs+N1ngDpuR2aPGlgue6UiAjTDnk09YQoXSrHuJxh55vR8i7mI4ky3 /vnVwlcgUxD19cUBxG7cxtosxQR3K2taZnbtBA3yKWXJ6bsOFKG1wqSuq403nO37dLsm HNGqKUadnSVfNWmxhvfAD9YRfWfGRrgKn2hp8= Received: by 10.180.80.162 with SMTP id s2mr8676723wix.10.1326266212856; Tue, 10 Jan 2012 23:16:52 -0800 (PST) Received: from [10.255.132.235] ([192.100.123.77]) by mx.google.com with ESMTPS id di5sm928888wib.3.2012.01.10.23.16.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 23:16:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: jouni korhonen In-Reply-To: Date: Wed, 11 Jan 2012 09:11:47 +0200 Message-Id: References: <5D26445C-2511-41C9-BFC7-E8881DF0BA96@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: radext@ietf.org, ietf@ietf.org, Frank Xia , "iesg@ietf.org IESG" Subject: Re: [radext] Review of draft-ietf-nextext-radius-pmip6 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Jan 11, 2012, at 9:04 AM, Bernard Aboba wrote: > Message-Authenticator should be mandatory (1 1 1 1). Ack. Thanks Bernard. - Jouni > > > On Jan 10, 2012, at 22:30, "jouni korhonen" wrote: > >> Bernard, >> >> Thank you for your review. See my comments inline. >> >> >> On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote: >> >>> The document appears to contain typos in sections 4.16 and 4.17. >>> >>> In section 4.16, it appears that "Home LMA IPv6 address" should be replaced by "Home DHCPv6 server address": >> >> Blimey.. we'll fix this. >> >>> 4.16. PMIP6-Home-DHCP6-Server-Address >>> >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home LMA IPv6 address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> In Section 4.17, it appears that "Visited LMA IPv6 address" should be replaced by "Visited DHCPv6 server address": >> >> And the same here.. >> >> >>> >>> 4.17. PMIP6-Visited-DHCP6-Server-Address >>> >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited LMA IPv6 address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> 5.2. Table of Attributes >>> >>> >>> The following table provides a guide to attributes that may be found >>> in authentication and authorization RADIUS messages between MAG and >>> the AAA Server. >>> >>> >>> Request Accept Reject Challenge # Attribute >>> >>> 0-1 0-1 0-1 0-1 80 Message-Authenticator >>> >>> >>> >>> [BA] The Message-Authenticator attribute is mandatory-to-implement in a number of >>> RADIUS usages, including EAP (RFC 3579). Leaving out Message-Authenticator could >>> result in Access-Requests lacking authentication and >>> integrity protection. RFC 6158 Section 3.1 states: >> >> Good point. So, you are saying that we should have: >> >> 1 0-1 0-1 0-1 80 Message-Authenticator >> >> or would >> >> 1 1 1 1 80 Message-Authenticator >> >> be even better as RFC3759 & 5090 do? >> >> >> - Jouni >> >> >> >>> >>> While [RFC2865] did not require authentication and integrity >>> protection of RADIUS Access-Request packets, subsequent >>> authentication mechanism specifications, such as RADIUS/EAP [RFC3579] >>> and Digest Authentication [RFC5090], have mandated authentication and >>> integrity protection for certain RADIUS packets. [RFC5080], Section >>> 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, >>> including Access-Request packets performing authorization checks. It >>> is expected that specifications for new RADIUS authentication >>> mechanisms will continue this practice. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >> _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jan 11 00:02:22 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D06821F880B; Wed, 11 Jan 2012 00:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326268942; bh=8nSgm6TGdA5zZZkPzoK2aZZOjdtpTNr3v+WkY07L9UE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=NuBAjj7jpV2S0Wfi8oB2wELvbmiMktrLFCT8QbzDujS1NgHN4ftiW7f2QgyR1WqVn A7aWyeHVLKaXZuafIhXSN8yduu4njG2BCoXOpvzZScRaeZOpsDhP+BJNw07759NUPu rB6vKDzsji7oPCWIAAJzQ39j7Fl9eFT3Hi8vnXog= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF8C21F880B for ; Wed, 11 Jan 2012 00:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7wAIrRTbtDm for ; Wed, 11 Jan 2012 00:02:21 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id E94F521F8799 for ; Wed, 11 Jan 2012 00:02:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id BC3F45D4FA; Wed, 11 Jan 2012 09:02:18 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0RKq7lDHZePe; Wed, 11 Jan 2012 09:02:18 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 323C65D47B; Wed, 11 Jan 2012 09:02:15 +0100 (CET) Message-ID: <4F0D4207.1000004@um.es> Date: Wed, 11 Jan 2012 09:02:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> In-Reply-To: Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org CgpFbCAxMC8wMS8xMiAyMDo0MSwgUGV0ZXIgRGVhY29uIGVzY3JpYmnDszoKPiBPbiBUdWUsIDEw IEphbiAyMDEyLCBBbGVqYW5kcm8gUGVyZXogTWVuZGV6IHdyb3RlOgo+Cj4+PiBPSzoKPj4+IFtH ZWFyIE0uMV1bR2VhciBNLjJdW0dFQVIgLjNdCj4KPj4+IE5PVCBPSzoKPj4+IFtHZWFyIE0uMl1b R2VhciBNLjFdW0dFQVIgLjNdCj4KPj4+IFRoaXMgbm90IG9ubHkgY29ycnVwdHMgdGhlIGRhdGEg YnV0IGFsc28gY29ycnVwdHMgdGhlIGF0dHJpYnV0ZXMgCj4+PiBleHRlbmRlZCB0eXBlLiAgVGhp cyBjYW4gYmUgZGFuZ2Vyb3VzIGluIHRoZSB3cm9uZyBoYW5kcyBhcyB0aGUgCj4+PiAqcGF5bG9h ZCogbm93IGhhcyBhIHNheSBvdmVyIHRoZSBzZWxlY3Rpb24gb2YgZXh0ZW5kZWQgdHlwZS4KPgo+ PiBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBpdCBvdXQgd2h5IGV4dGVuZGVkIHR5cGVzIGFyZSBhbHNv IGNvcnJ1cHRlZCwgCj4+IGJ1dCBJIGRvbid0IHNlZSBhIHJlYXNvbi4gSSBjbGVhcmx5IGFwcHJl Y2lhdGUgaG93IGRhdGEgaXMgY29ycnVwdGVkLCAKPj4gYnV0IGhlYWRlcnMgc2hvdWxkIG5vdCBi ZSBhZmZlY3RlZC4gQ291bGQgeW91IHBsZWFzZSBlbGFib3JhdGUgdGhpcyBhIAo+PiBsaXR0bGUg bW9yZSBvciByZWZlciBtZSB0byBmdXJ0aGVyIGluZm9ybWF0aW9uIG9uIHRoaXMgdG9waWM/Cj4K PiBIaSBBbGVqYW5kcm8sCj4KPiBUaGVyZSBpcyBhIGRpZmZlcmVuY2UgaW4gdGhlIHdpcmUgZm9y bWF0IGJldHdlZW4gaW5pdGlhbCBhbmQgCj4gc3Vic2VxdWVudCBmcmFnbWVudHMgb2YgYSBsb25n IGF0dHJpYnV0ZSAoNC41IGFuZCA0LjYpLgo+Cj4gVGhlIGluaXRpYWwgZm9ybWF0IGxvb2sgbGlr ZSB0aGlzOgo+IFR5cGUgKyBMZW4gKyBFeHRUeXBlICsgTSArIEZsYWdzICsgVklEICsgVlR5cGUg KyBWYWx1ZQo+Cj4gU3Vic2VxdWVudCBmcmFnbWVudHM6Cj4gVHlwZSArIExlbiArIEV4dFR5cGUg KyBNICsgRmxhZ3MgKyBWYWx1ZXMKPgo+IElmIG9yZGVyIG9mIGluaXRpYWwgYW5kIHN1YnNlcXVl bnQgZnJhZ21lbnQgaXMgY2hhbmdlZCBzeXN0ZW0gaGFzIG5vIAo+IGluZm9ybWF0aW9uIHByZXZl bnRpbmcgJ1ZhbHVlJyBmcm9tIGJlaW5nIGludGVycHJldGVkIGFzICdWSUQgKyBWVHlwZSAKPiAr IFZhbHVlJy4KCkhpIFBldGVyLAoKeW91J3JlIHJpZ2h0LCBidXQgaXQgc2VlbXMgdGhhdCB0aGlz IHdvdWxkIG9ubHkgYWZmZWN0IHRvIGV4dGVuZGVkIAp2ZW5kb3Igc3BlY2lmaWMgYXR0cmlidXRl cywgYW5kIG5vdCB0byBleHRlbmRlZCAoZmxhZykgYXR0cmlidXRlcyAoMy4qKS4gCkFtIEkgcmln aHQ/CgpSZWdhcmRzLApBbGVqYW5kcm8KCj4KPiByZWdhcmRzLAo+IFBldGVyCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QK cmFkZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFk ZXh0Cg== From alex@um.es Wed Jan 11 00:02:22 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF8C21F880B for ; Wed, 11 Jan 2012 00:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7wAIrRTbtDm for ; Wed, 11 Jan 2012 00:02:21 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id E94F521F8799 for ; Wed, 11 Jan 2012 00:02:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id BC3F45D4FA; Wed, 11 Jan 2012 09:02:18 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0RKq7lDHZePe; Wed, 11 Jan 2012 09:02:18 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 323C65D47B; Wed, 11 Jan 2012 09:02:15 +0100 (CET) Message-ID: <4F0D4207.1000004@um.es> Date: Wed, 11 Jan 2012 09:02:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 08:02:22 -0000 El 10/01/12 20:41, Peter Deacon escribió: > On Tue, 10 Jan 2012, Alejandro Perez Mendez wrote: > >>> OK: >>> [Gear M.1][Gear M.2][GEAR .3] > >>> NOT OK: >>> [Gear M.2][Gear M.1][GEAR .3] > >>> This not only corrupts the data but also corrupts the attributes >>> extended type. This can be dangerous in the wrong hands as the >>> *payload* now has a say over the selection of extended type. > >> I'm trying to figure it out why extended types are also corrupted, >> but I don't see a reason. I clearly appreciate how data is corrupted, >> but headers should not be affected. Could you please elaborate this a >> little more or refer me to further information on this topic? > > Hi Alejandro, > > There is a difference in the wire format between initial and > subsequent fragments of a long attribute (4.5 and 4.6). > > The initial format look like this: > Type + Len + ExtType + M + Flags + VID + VType + Value > > Subsequent fragments: > Type + Len + ExtType + M + Flags + Values > > If order of initial and subsequent fragment is changed system has no > information preventing 'Value' from being interpreted as 'VID + VType > + Value'. Hi Peter, you're right, but it seems that this would only affect to extended vendor specific attributes, and not to extended (flag) attributes (3.*). Am I right? Regards, Alejandro > > regards, > Peter From peterd@iea-software.com Wed Jan 11 09:17:14 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E021F8876 for ; Wed, 11 Jan 2012 09:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWTt41fhiR-h for ; Wed, 11 Jan 2012 09:17:14 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFA021F886F for ; Wed, 11 Jan 2012 09:17:13 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 11 Jan 2012 09:17:13 -0800 Date: Wed, 11 Jan 2012 09:17:12 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0D4207.1000004@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:17:14 -0000 On Wed, 11 Jan 2012, Alejandro Perez Mendez wrote: >> There is a difference in the wire format between initial and >> subsequent fragments of a long attribute (4.5 and 4.6). >> The initial format look like this: >> Type + Len + ExtType + M + Flags + VID + VType + Value >> Subsequent fragments: >> Type + Len + ExtType + M + Flags + Values >> If order of initial and subsequent fragment is changed system has no >> information preventing 'Value' from being interpreted as 'VID + VType >> + Value'. > Hi Peter, > you're right, but it seems that this would only affect to extended > vendor specific attributes, and not to extended (flag) attributes (3.*). > Am I right? Hi Alejandro, Not entirely, TLVs inside of a Value field of a non-VSA extended type can suffer the same fate. This is less of a problem since Value can't escape the non-VSA Extended type container. Solution of making initial + subsequent fragment formats the same does not reach into TLVs. These cases can only be _minimized_ by any machinery intended to prevent data corruption. regards, Peter From radext-bounces@ietf.org Wed Jan 11 09:17:16 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D63E521F8876; Wed, 11 Jan 2012 09:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326302236; bh=y2OeSiuYRFmZkfKRN+5sbEWbGkzG1iN6G2//Y4Iqj1E=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=Rpl6bec6Ne2EdmHwkx5iGOmKaQN3ayPveN8ADuc1I3ZYxoJJmPVpPoWZQT9eat+RX YuJowVN1zazX3IX6Mr26X98/c9o2ye4/rB/j624kJVj4WWEiSIRbetK68Btsm3QdLI Jix61fOYxZHfrs4W/PkNKs/J/Y+W8hl+I8U+bcS8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E021F8876 for ; Wed, 11 Jan 2012 09:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWTt41fhiR-h for ; Wed, 11 Jan 2012 09:17:14 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFA021F886F for ; Wed, 11 Jan 2012 09:17:13 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 11 Jan 2012 09:17:13 -0800 Date: Wed, 11 Jan 2012 09:17:12 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0D4207.1000004@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Wed, 11 Jan 2012, Alejandro Perez Mendez wrote: >> There is a difference in the wire format between initial and >> subsequent fragments of a long attribute (4.5 and 4.6). >> The initial format look like this: >> Type + Len + ExtType + M + Flags + VID + VType + Value >> Subsequent fragments: >> Type + Len + ExtType + M + Flags + Values >> If order of initial and subsequent fragment is changed system has no >> information preventing 'Value' from being interpreted as 'VID + VType >> + Value'. > Hi Peter, > you're right, but it seems that this would only affect to extended > vendor specific attributes, and not to extended (flag) attributes (3.*). > Am I right? Hi Alejandro, Not entirely, TLVs inside of a Value field of a non-VSA extended type can suffer the same fate. This is less of a problem since Value can't escape the non-VSA Extended type container. Solution of making initial + subsequent fragment formats the same does not reach into TLVs. These cases can only be _minimized_ by any machinery intended to prevent data corruption. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jan 11 09:50:09 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98CA21F8629; Wed, 11 Jan 2012 09:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326304209; bh=Bv0ro3emAhqXcXMKIZUQV/rv4SB91dYMB+3YK2qA/L8=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Pc87cED6d10ymMdnBgoRCAhf0tyDc2YiBWEVYfJgkCHR0vs/7y8K8pDOT9Jkduy4q o5w5DlUeCia+BroxexmE/ei4GiOzJM9UWN4Zjo+p7F3XcGGXDqcmluiSYseGiGiPGd 0mWhNIcoeovjfrY9vYt6nxBHtgc2x3PWauJx/mrA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B760221F8616 for ; Wed, 11 Jan 2012 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.298 X-Spam-Level: X-Spam-Status: No, score=-8.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atgk7CXtHqAR for ; Wed, 11 Jan 2012 09:50:06 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4821F8700 for ; Wed, 11 Jan 2012 09:50:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id A2C9C53617; Wed, 11 Jan 2012 18:50:04 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kBVxXgG2IytI; Wed, 11 Jan 2012 18:50:04 +0100 (CET) Received: from [192.168.1.33] (44.Red-79-150-171.dynamicIP.rima-tde.net [79.150.171.44]) (Authenticated sender: pereniguez@um.es) by xenon11.um.es (Postfix) with ESMTPA id 7DD40535FB; Wed, 11 Jan 2012 18:49:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Date: Wed, 11 Jan 2012 18:49:57 +0100 Message-Id: References: <4EF1DC0A.1070004@deployingradius.com> To: radext mailing list X-Mailer: Apple Mail (2.1084) Cc: Peter Deacon , =?iso-8859-1?Q?Fernando_Pere=F1=EDguez?= Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9073659134320388577==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============9073659134320388577== Content-Type: multipart/alternative; boundary=Apple-Mail-1-104646519 --Apple-Mail-1-104646519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Peter, I'm trying to understand the problems you mention regarding the use of = extended attributes and the order preservation. Please, see my comments = inline.=20 >=20 > The necessary ordering constraints do not seem to be there in existing = RFCS to prevent long attributes from being corrupted. This is important = since a design goal was to allow attributes to be forwarded by systems = not supporting this draft. >=20 > RFC 2138.3 > " Many Attributes may have multiple instances, in such a case the = order > of Attributes of the same Type SHOULD be preserved. The order of > Attributes of different Types is not required to be preserved." >=20 > There are two problems with this: >=20 > 1. SHOULD is not enough. > 2. Preserving order is not enough. I'm a bit confused about the preservation of order of attributes of the = same type. Certainly, RFC 2138 does not force the preservation of such = order. Nevertheless, in RFC 2865 it is said that: If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. For this reason, so far I've been assuming that order of attributes of = the same type must be respected. In fact, the RADIUS extensions makes = such assumption with the fragmentation based on bit 'M'. So, my question = is: can we assume order preservation of attributes of the same Type or = not ? >=20 > To show the problem example below uses two extended flag attributes = 'Gear' and 'Cog' each of the extended flag attributes are using the same = basic RADIUS attribute type. >=20 > 'M' represents More flag set > '.' No flags are set >=20 > 1. An implementation decides to ignore the advice of RFC 2138 jumbling = the order of attributes of the same type: >=20 > OK: > [Gear M.1][Gear M.2][GEAR .3] >=20 > NOT OK: > [Gear M.2][Gear M.1][GEAR .3] >=20 > This not only corrupts the data but also corrupts the attributes = extended type. This can be dangerous in the wrong hands as the = *payload* now has a say over the selection of extended type. >=20 > If this were a VSA it would corrupt both the vendor id and the vendors = type. >=20 In this case, as mentioned by Alejandro in a previous e-mail, I think = the corruption in attribute headers only affects to extended VSA.=20 > 2. An implementation follows the advice of RFC 2138 to the letter. = Unfortunately preservation of order does not preclude insertion of Cogs = into the middle of Gears as the outer RADIUS type is the same for both. >=20 > OK: > [Gear M.1][Gear M.2][GEAR .3][Cog .1] >=20 > NOT OK: > [Gear M.1][Gear M.2][Cog .1][GEAR .3] >=20 > - Gear is truncated > - Cog is appended to the truncated Gear further corrupting Gear > - Cog never appears as an attribute > - The *payload* of the last gear fragment determines a corrupt = extended type (Or Vendor id and vendors type) and whats left over of = Gear.3's data.. as with the previous example being able to control = extended type via payload can be dangerous in the wrong hands. >=20 In this situation, assuming the order of attributes of the same type is = preserved, why [Cog.1] is allowed to be inserted between GEAR fragments = 2 and 3 ? This alters the order (examining the outer RADIUS type) of the = sequence [Gear M.1][Gear M.2][GEAR .3].=20 Regards, Fernando. ---=20 ------------------------------------------------------ Fernando Pere=F1=EDguez Garc=EDa, PhD=20 Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science, University of Murcia E-30100, Espinardo, Murcia (Spain) Phone: +34 868 887882 Fax: +34 868884151=20 E-mail: pereniguez@um.es ------------------------------------------------------ --Apple-Mail-1-104646519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

The necessary ordering constraints do not = seem to be there in existing RFCS to prevent long attributes from being = corrupted.  This is important since a design goal was to allow = attributes to be forwarded by systems not supporting this = draft.

RFC 2138.3
"   Many Attributes may have = multiple instances, in such a case the order
  of = Attributes of the same Type SHOULD be preserved.  The order of
=   Attributes of different Types is not required to be = preserved."

There are two problems with this:

1. SHOULD is = not enough.
2. Preserving order is not = enough.

I'm a bit confused = about the preservation of order of attributes of the same type. = Certainly, RFC 2138 does not force the preservation of such order. = Nevertheless, in RFC 2865 it is said that:

If multiple Attributes with the same Type are present, =
the order of
   Attributes with the same Type MUST be preserved by any =
proxies.

For this reason, so far I've been = assuming that order of attributes of the same type must be respected. In = fact, the RADIUS extensions makes such assumption with the fragmentation = based on bit 'M'. So, my question is: can we assume order preservation = of attributes of the same Type or not ?


To show the problem example below uses two = extended flag attributes 'Gear' and 'Cog' each of the extended flag = attributes are using the same basic RADIUS attribute type.

'M' = represents More flag set
'.' No flags are set

1. An = implementation decides to ignore the advice of RFC 2138 jumbling the = order of attributes of the same type:

OK:
[Gear M.1][Gear = M.2][GEAR .3]

NOT OK:
[Gear M.2][Gear M.1][GEAR = .3]

This not only corrupts the data but also corrupts the = attributes extended type.  This can be dangerous in the wrong hands = as the *payload* now has a say over the selection of extended = type.

If this were a VSA it would corrupt both the vendor id and = the vendors type.


In this = case, as mentioned by Alejandro in a previous e-mail, I think the = corruption in attribute headers only affects to extended = VSA. 

2. An implementation = follows the advice of RFC 2138 to the letter. Unfortunately preservation = of order does not preclude insertion of Cogs into the middle of Gears as = the outer RADIUS type is the same for both.

OK:
[Gear = M.1][Gear M.2][GEAR .3][Cog .1]

NOT OK:
[Gear M.1][Gear = M.2][Cog .1][GEAR .3]

- Gear is truncated
- Cog is = appended to the truncated Gear further corrupting Gear
- Cog = never appears as an attribute
- The *payload* of the last gear = fragment determines a corrupt extended type (Or Vendor id and vendors = type) and whats left over of Gear.3's data.. as with the previous = example being able to control extended type via payload can be dangerous = in the wrong hands.


In this = situation, assuming the order of attributes of the same type is = preserved, why [Cog.1] is allowed to be inserted between GEAR fragments = 2 and 3 ? This alters the order (examining the outer RADIUS type) of = the sequence [Gear M.1][Gear M.2][GEAR = .3]. 


Regards,
Fern= ando.


X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B760221F8616 for ; Wed, 11 Jan 2012 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.298 X-Spam-Level: X-Spam-Status: No, score=-8.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atgk7CXtHqAR for ; Wed, 11 Jan 2012 09:50:06 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4821F8700 for ; Wed, 11 Jan 2012 09:50:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id A2C9C53617; Wed, 11 Jan 2012 18:50:04 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kBVxXgG2IytI; Wed, 11 Jan 2012 18:50:04 +0100 (CET) Received: from [192.168.1.33] (44.Red-79-150-171.dynamicIP.rima-tde.net [79.150.171.44]) (Authenticated sender: pereniguez@um.es) by xenon11.um.es (Postfix) with ESMTPA id 7DD40535FB; Wed, 11 Jan 2012 18:49:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-104646519 From: =?iso-8859-1?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Date: Wed, 11 Jan 2012 18:49:57 +0100 Message-Id: References: <4EF1DC0A.1070004@deployingradius.com> To: radext mailing list X-Mailer: Apple Mail (2.1084) Cc: Peter Deacon , =?iso-8859-1?Q?Fernando_Pere=F1=EDguez?= Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:50:07 -0000 --Apple-Mail-1-104646519 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Peter, I'm trying to understand the problems you mention regarding the use of = extended attributes and the order preservation. Please, see my comments = inline.=20 >=20 > The necessary ordering constraints do not seem to be there in existing = RFCS to prevent long attributes from being corrupted. This is important = since a design goal was to allow attributes to be forwarded by systems = not supporting this draft. >=20 > RFC 2138.3 > " Many Attributes may have multiple instances, in such a case the = order > of Attributes of the same Type SHOULD be preserved. The order of > Attributes of different Types is not required to be preserved." >=20 > There are two problems with this: >=20 > 1. SHOULD is not enough. > 2. Preserving order is not enough. I'm a bit confused about the preservation of order of attributes of the = same type. Certainly, RFC 2138 does not force the preservation of such = order. Nevertheless, in RFC 2865 it is said that: If multiple Attributes with the same Type are present, the order of Attributes with the same Type MUST be preserved by any proxies. For this reason, so far I've been assuming that order of attributes of = the same type must be respected. In fact, the RADIUS extensions makes = such assumption with the fragmentation based on bit 'M'. So, my question = is: can we assume order preservation of attributes of the same Type or = not ? >=20 > To show the problem example below uses two extended flag attributes = 'Gear' and 'Cog' each of the extended flag attributes are using the same = basic RADIUS attribute type. >=20 > 'M' represents More flag set > '.' No flags are set >=20 > 1. An implementation decides to ignore the advice of RFC 2138 jumbling = the order of attributes of the same type: >=20 > OK: > [Gear M.1][Gear M.2][GEAR .3] >=20 > NOT OK: > [Gear M.2][Gear M.1][GEAR .3] >=20 > This not only corrupts the data but also corrupts the attributes = extended type. This can be dangerous in the wrong hands as the = *payload* now has a say over the selection of extended type. >=20 > If this were a VSA it would corrupt both the vendor id and the vendors = type. >=20 In this case, as mentioned by Alejandro in a previous e-mail, I think = the corruption in attribute headers only affects to extended VSA.=20 > 2. An implementation follows the advice of RFC 2138 to the letter. = Unfortunately preservation of order does not preclude insertion of Cogs = into the middle of Gears as the outer RADIUS type is the same for both. >=20 > OK: > [Gear M.1][Gear M.2][GEAR .3][Cog .1] >=20 > NOT OK: > [Gear M.1][Gear M.2][Cog .1][GEAR .3] >=20 > - Gear is truncated > - Cog is appended to the truncated Gear further corrupting Gear > - Cog never appears as an attribute > - The *payload* of the last gear fragment determines a corrupt = extended type (Or Vendor id and vendors type) and whats left over of = Gear.3's data.. as with the previous example being able to control = extended type via payload can be dangerous in the wrong hands. >=20 In this situation, assuming the order of attributes of the same type is = preserved, why [Cog.1] is allowed to be inserted between GEAR fragments = 2 and 3 ? This alters the order (examining the outer RADIUS type) of the = sequence [Gear M.1][Gear M.2][GEAR .3].=20 Regards, Fernando. ---=20 ------------------------------------------------------ Fernando Pere=F1=EDguez Garc=EDa, PhD=20 Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science, University of Murcia E-30100, Espinardo, Murcia (Spain) Phone: +34 868 887882 Fax: +34 868884151=20 E-mail: pereniguez@um.es ------------------------------------------------------ --Apple-Mail-1-104646519 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

The necessary ordering constraints do not = seem to be there in existing RFCS to prevent long attributes from being = corrupted.  This is important since a design goal was to allow = attributes to be forwarded by systems not supporting this = draft.

RFC 2138.3
"   Many Attributes may have = multiple instances, in such a case the order
  of = Attributes of the same Type SHOULD be preserved.  The order of
=   Attributes of different Types is not required to be = preserved."

There are two problems with this:

1. SHOULD is = not enough.
2. Preserving order is not = enough.

I'm a bit confused = about the preservation of order of attributes of the same type. = Certainly, RFC 2138 does not force the preservation of such order. = Nevertheless, in RFC 2865 it is said that:

If multiple Attributes with the same Type are present, =
the order of
   Attributes with the same Type MUST be preserved by any =
proxies.

For this reason, so far I've been = assuming that order of attributes of the same type must be respected. In = fact, the RADIUS extensions makes such assumption with the fragmentation = based on bit 'M'. So, my question is: can we assume order preservation = of attributes of the same Type or not ?


To show the problem example below uses two = extended flag attributes 'Gear' and 'Cog' each of the extended flag = attributes are using the same basic RADIUS attribute type.

'M' = represents More flag set
'.' No flags are set

1. An = implementation decides to ignore the advice of RFC 2138 jumbling the = order of attributes of the same type:

OK:
[Gear M.1][Gear = M.2][GEAR .3]

NOT OK:
[Gear M.2][Gear M.1][GEAR = .3]

This not only corrupts the data but also corrupts the = attributes extended type.  This can be dangerous in the wrong hands = as the *payload* now has a say over the selection of extended = type.

If this were a VSA it would corrupt both the vendor id and = the vendors type.


In this = case, as mentioned by Alejandro in a previous e-mail, I think the = corruption in attribute headers only affects to extended = VSA. 

2. An implementation = follows the advice of RFC 2138 to the letter. Unfortunately preservation = of order does not preclude insertion of Cogs into the middle of Gears as = the outer RADIUS type is the same for both.

OK:
[Gear = M.1][Gear M.2][GEAR .3][Cog .1]

NOT OK:
[Gear M.1][Gear = M.2][Cog .1][GEAR .3]

- Gear is truncated
- Cog is = appended to the truncated Gear further corrupting Gear
- Cog = never appears as an attribute
- The *payload* of the last gear = fragment determines a corrupt extended type (Or Vendor id and vendors = type) and whats left over of Gear.3's data.. as with the previous = example being able to control extended type via payload can be dangerous = in the wrong hands.


In this = situation, assuming the order of attributes of the same type is = preserved, why [Cog.1] is allowed to be inserted between GEAR fragments = 2 and 3 ? This alters the order (examining the outer RADIUS type) of = the sequence [Gear M.1][Gear M.2][GEAR = .3]. 


Regards,
Fern= ando.


> case the order >> of Attributes of the same Type SHOULD be preserved. The >> order of >> Attributes of different Types is not required to be >> preserved." >=20 >> There are two problems with this: >> 1. SHOULD is not enough. >> 2. Preserving order is not enough. >=20 >> I'm a bit confused about the preservation of order of attributes of = the >> same type. Certainly, RFC 2138 does not force the preservation of = such >> order. Nevertheless, in RFC 2865 it is said that: >=20 >> If multiple Attributes with the same Type are present, the order of >> Attributes with the same Type MUST be preserved by any proxies. >=20 >> For this reason, so far I've been assuming that order of attributes = of >> the same type must be respected. In fact, the RADIUS extensions makes >> such assumption with the fragmentation based on bit 'M'. So, my = question >> is: can we assume order preservation of attributes of the same Type = or >> not ? >=20 > Hi Fernando, >=20 > Lets assume order is universally respected. What prevents new = attributes from being inserted while respecting order of existing = attributes? =46rom other text (below) my impression this is allowed and = expected. Yes, you are right. I was only thinking about order preservation and = missing the fact that attributes can be continuous or not. Effectively, = the order of a sequence of attributes of the same type is not altered = when inserting new attributes.=20 >=20 > The Gear + Cog example can only fail to detect an error with VSAs when = you assume order is respected however this is not end of story. >=20 > A new example with order preserved not using VSAs.. two gears - Gear-A = and Gear-B. Gear-A and Gear-B are instances of the same extended type. >=20 > OK: > [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] >=20 > NOT OK: > [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] > ^^^^^^^^^^^^^^^^^^^^^^^ >=20 > - Gear-A is truncated > - Gear-B is lost never appearing as a separate attribute > - Gear-B in its entirety is appended to Gear-A further = corrupting Gear-A. > - The last fragment of Gear-A becomes a standalone corrupt = attribute of its own. >=20 Since Gear-A and Gear-B are extended attributes, it is obvious that the = RADIUS implementation generating and inserting these attributes = implements extended attributes. In such case, as stated in the draft, = the new type space is formed by "Type.Extended-Type" so the = implementation should be able to distinguish that Gear-A and Gear-B are = different attributes and, consequently, detect that performing this = insertion of [Gear-B M.1] violates the order preservation of Gear-A = fragments. Is my understanding correct ? >=20 > We already have EAP bless its heart... >=20 > RFC 2865 5 (June 2000) > "A RADIUS server or client MUST NOT require attributes of the same = type to be contiguous." >=20 > RFC 2869 5.13 (June 2000) > "If multiple EAP- > Messages are contained within an Access-Request or Access- > Challenge packet, they MUST be in order and they MUST be > consecutive attributes in the Access-Request or Access-Challenge > packet." >=20 > I think there are important differences between EAP as an example and = extensions. >=20 > 1. If EAP does not work you don't authenticate. The failure mode does = not include silent data corruption / crazy authorization parameters. >=20 > 2. There is only one EAP-Message conduit possible per auth transaction = as far as I know. The scenario I raise above requires two or more to = work. I agree with you that EAP message fragmentation has been specifically = designed according to the particularities of EAP. I think a more general = fragmentation solution should be designed considering all possible = cases.=20 >=20 >> In this case, as mentioned by Alejandro in a previous e-mail, I think = the >> corruption in attribute headers only affects to extended VSA. >=20 > VSAs outnumber standard attributes by at least 15 to 1. It is a big = deal. Yes, the problem with extended VSAs exists and the problems in header = corruption must be addressed regardless the quantity of defined VSAs :-) >=20 > regards, > Peter Regards, Fernando. ---=20 ------------------------------------------------------ Fernando Pere=F1=EDguez Garc=EDa, PhD=20 Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science, University of Murcia E-30100, Espinardo, Murcia (Spain) Phone: +34 868 887882 Fax: +34 868884151=20 E-mail: pereniguez@um.es ------------------------------------------------------ From radext-bounces@ietf.org Wed Jan 11 12:34:16 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39F421F853E; Wed, 11 Jan 2012 12:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326314056; bh=F2sX9BIIcJdMDTzQS4PbVGxc9Z9rcOQFwgX58Ap031w=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=AXKLy6M/2XKhfaUbRxiJU8kNUlbhXW1KYCDKj1gYSHdVfOQ6/LFKkB2qs/ClYvIMA QEHwwHlh3YEXoxGXkN8SCY0kMqrUtV/IDvMzuXJZYkpCpajBbqt0HhUV3fEWBplK1T PoPwOa8D7OtIN7zFqQjiw9FvS3agPEIAkuz95KEI= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0106721F853E for ; Wed, 11 Jan 2012 12:34:16 -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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlLgwyVZXqLA for ; Wed, 11 Jan 2012 12:34:15 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id EA12221F853C for ; Wed, 11 Jan 2012 12:34:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 9527D5D523; Wed, 11 Jan 2012 21:34:12 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zQnza7d5m6Je; Wed, 11 Jan 2012 21:34:12 +0100 (CET) Received: from [192.168.1.33] (unknown [80.30.174.174]) (Authenticated sender: pereniguez@um.es) by xenon13.um.es (Postfix) with ESMTPA id AC25C5D4E4; Wed, 11 Jan 2012 21:34:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) From: =?iso-8859-1?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Date: Wed, 11 Jan 2012 21:34:07 +0100 Message-Id: References: <4EF1DC0A.1070004@deployingradius.com> To: Peter Deacon X-Mailer: Apple Mail (2.1084) Cc: radext mailing list , =?iso-8859-1?Q?Fernando_Pere=F1=EDguez?= Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi Peter, Thanks for your response. I really appreciated your clarifications. El 11/01/2012, a las 19:54, Peter Deacon escribi=F3: > On Wed, 11 Jan 2012, Fernando Pere=F1=EDguez wrote: > = >> I'm trying to understand the problems you mention regarding the use of >> extended attributes and the order preservation. Please, see my comments >> inline. > = >> " Many Attributes may have multiple instances, in such a >> case the order >> of Attributes of the same Type SHOULD be preserved. The >> order of >> Attributes of different Types is not required to be >> preserved." > = >> There are two problems with this: >> 1. SHOULD is not enough. >> 2. Preserving order is not enough. > = >> I'm a bit confused about the preservation of order of attributes of the >> same type. Certainly, RFC 2138 does not force the preservation of such >> order. Nevertheless, in RFC 2865 it is said that: > = >> If multiple Attributes with the same Type are present, the order of >> Attributes with the same Type MUST be preserved by any proxies. > = >> For this reason, so far I've been assuming that order of attributes of >> the same type must be respected. In fact, the RADIUS extensions makes >> such assumption with the fragmentation based on bit 'M'. So, my question >> is: can we assume order preservation of attributes of the same Type or >> not ? > = > Hi Fernando, > = > Lets assume order is universally respected. What prevents new attributes= from being inserted while respecting order of existing attributes? From o= ther text (below) my impression this is allowed and expected. Yes, you are right. I was only thinking about order preservation and missin= g the fact that attributes can be continuous or not. Effectively, the order= of a sequence of attributes of the same type is not altered when inserting= new attributes. = > = > The Gear + Cog example can only fail to detect an error with VSAs when yo= u assume order is respected however this is not end of story. > = > A new example with order preserved not using VSAs.. two gears - Gear-A an= d Gear-B. Gear-A and Gear-B are instances of the same extended type. > = > OK: > [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] > = > NOT OK: > [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] > ^^^^^^^^^^^^^^^^^^^^^^^ > = > - Gear-A is truncated > - Gear-B is lost never appearing as a separate attribute > - Gear-B in its entirety is appended to Gear-A further corrupting Gear-A. > - The last fragment of Gear-A becomes a standalone corrupt attribute of = its own. > = Since Gear-A and Gear-B are extended attributes, it is obvious that the RAD= IUS implementation generating and inserting these attributes implements ext= ended attributes. In such case, as stated in the draft, the new type space = is formed by "Type.Extended-Type" so the implementation should be able to d= istinguish that Gear-A and Gear-B are different attributes and, consequentl= y, detect that performing this insertion of [Gear-B M.1] violates the order= preservation of Gear-A fragments. Is my understanding correct ? > = > We already have EAP bless its heart... > = > RFC 2865 5 (June 2000) > "A RADIUS server or client MUST NOT require attributes of the same type t= o be contiguous." > = > RFC 2869 5.13 (June 2000) > "If multiple EAP- > Messages are contained within an Access-Request or Access- > Challenge packet, they MUST be in order and they MUST be > consecutive attributes in the Access-Request or Access-Challenge > packet." > = > I think there are important differences between EAP as an example and ext= ensions. > = > 1. If EAP does not work you don't authenticate. The failure mode does no= t include silent data corruption / crazy authorization parameters. > = > 2. There is only one EAP-Message conduit possible per auth transaction as= far as I know. The scenario I raise above requires two or more to work. I agree with you that EAP message fragmentation has been specifically desig= ned according to the particularities of EAP. I think a more general fragmen= tation solution should be designed considering all possible cases. = > = >> In this case, as mentioned by Alejandro in a previous e-mail, I think the >> corruption in attribute headers only affects to extended VSA. > = > VSAs outnumber standard attributes by at least 15 to 1. It is a big deal. Yes, the problem with extended VSAs exists and the problems in header corru= ption must be addressed regardless the quantity of defined VSAs :-) > = > regards, > Peter Regards, Fernando. --- = ------------------------------------------------------ Fernando Pere=F1=EDguez Garc=EDa, PhD = Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science, University of Murcia E-30100, Espinardo, Murcia (Spain) Phone: +34 868 887882 Fax: +34 868884151 = E-mail: pereniguez@um.es ------------------------------------------------------ _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Thu Jan 12 00:47:59 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F121F8568 for ; Thu, 12 Jan 2012 00:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.798 X-Spam-Level: X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUZi4PtpIaZD for ; Thu, 12 Jan 2012 00:47:58 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEB821F8562 for ; Thu, 12 Jan 2012 00:47:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8FC845D4CE for ; Thu, 12 Jan 2012 09:47:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xztmc36rOx+P for ; Thu, 12 Jan 2012 09:47:51 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 08DBE5D4E2 for ; Thu, 12 Jan 2012 09:47:49 +0100 (CET) Message-ID: <4F0E9E33.7040701@um.es> Date: Thu, 12 Jan 2012 09:47:47 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080309010203080804010105" Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 08:47:59 -0000 This is a multi-part message in MIME format. --------------080309010203080804010105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 11/01/12 18:17, Peter Deacon escribió: > On Wed, 11 Jan 2012, Alejandro Perez Mendez wrote: > >>> There is a difference in the wire format between initial and >>> subsequent fragments of a long attribute (4.5 and 4.6). > >>> The initial format look like this: >>> Type + Len + ExtType + M + Flags + VID + VType + Value > >>> Subsequent fragments: >>> Type + Len + ExtType + M + Flags + Values > >>> If order of initial and subsequent fragment is changed system has no >>> information preventing 'Value' from being interpreted as 'VID + >>> VType + Value'. > >> Hi Peter, >> you're right, but it seems that this would only affect to extended >> vendor specific attributes, and not to extended (flag) attributes >> (3.*). Am I right? > > Hi Alejandro, > > Not entirely, TLVs inside of a Value field of a non-VSA extended type > can suffer the same fate. > > This is less of a problem since Value can't escape the non-VSA > Extended type container. > > Solution of making initial + subsequent fragment formats the same does > not reach into TLVs. These cases can only be _minimized_ by any > machinery intended to prevent data corruption. Hi Peter, well, but data corruption is always possible. Any proxy in the path could change a header byte, for example, and mess all up. IMHO, it would be simpler to adopt the RADIUS EAP position. RFC 3579 states: If multiple EAP-Message attributes are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. So, Alan's draft could say something similar: If multiple fragments of the same attribute are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. I think RADIUS EAP has been accepted and deployed enough to agree that is a viable solution. What if a RADIUS server decides to omit this recommendation anyway? It should be managed the same way as RADIUS EAP does: let the upper layer application (e.g. EAP stack) to detect the error, not RADIUS. If you re-order the attributes, most probably the result would not make sense at all (TLV length will not match with the actual one, RADIUS packet length will be invalid, checksum will fail...), and thus it will be detected. Am I assuming something wrong? Best regards, Alejandro > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------080309010203080804010105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

El 11/01/12 18:17, Peter Deacon escribió:
On Wed, 11 Jan 2012, Alejandro Perez Mendez wrote:

There is a difference in the wire format between initial and subsequent fragments of a long attribute (4.5 and 4.6).

The initial format look like this:
Type + Len + ExtType + M + Flags + VID + VType + Value

Subsequent fragments:
Type + Len + ExtType + M + Flags + Values

If order of initial and subsequent fragment is changed system has no information preventing 'Value' from being interpreted as 'VID + VType + Value'.

Hi Peter,
you're right, but it seems that this would only affect to extended vendor specific attributes, and not to extended (flag) attributes (3.*). Am I right?

Hi Alejandro,

Not entirely, TLVs inside of a Value field of a non-VSA extended type can suffer the same fate.

This is less of a problem since Value can't escape the non-VSA Extended type container.

Solution of making initial + subsequent fragment formats the same does not reach into TLVs.  These cases can only be _minimized_ by any machinery intended to prevent data corruption.

Hi Peter,

well, but data corruption is always possible. Any proxy in the path could change a header byte, for example, and mess all up.

IMHO, it would be simpler to adopt the RADIUS EAP position. RFC 3579 states:
If multiple
EAP-Message attributes are contained within an Access-Request or
Access-Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet.
So, Alan's draft could say something similar:
If multiple
fragments of the same attribute are contained within an Access-Request or
Access-Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet. 
I think RADIUS EAP has been accepted and deployed enough to agree that is a viable solution.

What if a RADIUS server decides to omit this recommendation anyway? It should be managed the same way as RADIUS EAP does: let the upper layer application (e.g. EAP stack) to detect the error, not RADIUS.

If you re-order the attributes, most probably the result would not make sense at all (TLV length will not match with the actual one, RADIUS packet length will be invalid, checksum will fail...), and thus it will be detected.

Am I assuming something wrong?

Best regards,
Alejandro




regards,
Peter
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext
--------------080309010203080804010105-- From radext-bounces@ietf.org Thu Jan 12 00:48:01 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ABA21F856D; Thu, 12 Jan 2012 00:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326358081; bh=JDBIlQ6lpv4hQ4MvaXdtIMYrUcDptDTw2MUe36NPE/w=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=yuLBclmCicl9Wfq/4tknSnDLYPmuourZNpp2HBz3LwnOWnIG5zgpabIQ8cLKOWSoc tQnU6IpVfVHG4z2/8yumoJOXvlTakGgSd8tA83LkOCPGx81f6Upi5gqc+pn+8hNRe6 Pqm6SnTdxctL8E6kxekaYulhtRA3BVV/ZZmmOwGU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0F121F8568 for ; Thu, 12 Jan 2012 00:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.798 X-Spam-Level: X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUZi4PtpIaZD for ; Thu, 12 Jan 2012 00:47:58 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEB821F8562 for ; Thu, 12 Jan 2012 00:47:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 8FC845D4CE for ; Thu, 12 Jan 2012 09:47:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xztmc36rOx+P for ; Thu, 12 Jan 2012 09:47:51 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 08DBE5D4E2 for ; Thu, 12 Jan 2012 09:47:49 +0100 (CET) Message-ID: <4F0E9E33.7040701@um.es> Date: Thu, 12 Jan 2012 09:47:47 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> In-Reply-To: Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1473235674440318602==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============1473235674440318602== Content-Type: multipart/alternative; boundary="------------080309010203080804010105" This is a multi-part message in MIME format. --------------080309010203080804010105 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit El 11/01/12 18:17, Peter Deacon escribió: > On Wed, 11 Jan 2012, Alejandro Perez Mendez wrote: > >>> There is a difference in the wire format between initial and >>> subsequent fragments of a long attribute (4.5 and 4.6). > >>> The initial format look like this: >>> Type + Len + ExtType + M + Flags + VID + VType + Value > >>> Subsequent fragments: >>> Type + Len + ExtType + M + Flags + Values > >>> If order of initial and subsequent fragment is changed system has no >>> information preventing 'Value' from being interpreted as 'VID + >>> VType + Value'. > >> Hi Peter, >> you're right, but it seems that this would only affect to extended >> vendor specific attributes, and not to extended (flag) attributes >> (3.*). Am I right? > > Hi Alejandro, > > Not entirely, TLVs inside of a Value field of a non-VSA extended type > can suffer the same fate. > > This is less of a problem since Value can't escape the non-VSA > Extended type container. > > Solution of making initial + subsequent fragment formats the same does > not reach into TLVs. These cases can only be _minimized_ by any > machinery intended to prevent data corruption. Hi Peter, well, but data corruption is always possible. Any proxy in the path could change a header byte, for example, and mess all up. IMHO, it would be simpler to adopt the RADIUS EAP position. RFC 3579 states: If multiple EAP-Message attributes are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. So, Alan's draft could say something similar: If multiple fragments of the same attribute are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. I think RADIUS EAP has been accepted and deployed enough to agree that is a viable solution. What if a RADIUS server decides to omit this recommendation anyway? It should be managed the same way as RADIUS EAP does: let the upper layer application (e.g. EAP stack) to detect the error, not RADIUS. If you re-order the attributes, most probably the result would not make sense at all (TLV length will not match with the actual one, RADIUS packet length will be invalid, checksum will fail...), and thus it will be detected. Am I assuming something wrong? Best regards, Alejandro > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------080309010203080804010105 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

El 11/01/12 18:17, Peter Deacon escribió:
On Wed, 11 Jan 2012, Alejandro Perez Mendez wrote:

There is a difference in the wire format between initial and subsequent fragments of a long attribute (4.5 and 4.6).

The initial format look like this:
Type + Len + ExtType + M + Flags + VID + VType + Value

Subsequent fragments:
Type + Len + ExtType + M + Flags + Values

If order of initial and subsequent fragment is changed system has no information preventing 'Value' from being interpreted as 'VID + VType + Value'.

Hi Peter,
you're right, but it seems that this would only affect to extended vendor specific attributes, and not to extended (flag) attributes (3.*). Am I right?

Hi Alejandro,

Not entirely, TLVs inside of a Value field of a non-VSA extended type can suffer the same fate.

This is less of a problem since Value can't escape the non-VSA Extended type container.

Solution of making initial + subsequent fragment formats the same does not reach into TLVs.  These cases can only be _minimized_ by any machinery intended to prevent data corruption.

Hi Peter,

well, but data corruption is always possible. Any proxy in the path could change a header byte, for example, and mess all up.

IMHO, it would be simpler to adopt the RADIUS EAP position. RFC 3579 states:
If multiple
EAP-Message attributes are contained within an Access-Request or
Access-Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet.
So, Alan's draft could say something similar:
If multiple
fragments of the same attribute are contained within an Access-Request or
Access-Challenge packet, they MUST be in order and they MUST be
consecutive attributes in the Access-Request or Access-Challenge
packet. 
I think RADIUS EAP has been accepted and deployed enough to agree that is a viable solution.

What if a RADIUS server decides to omit this recommendation anyway? It should be managed the same way as RADIUS EAP does: let the upper layer application (e.g. EAP stack) to detect the error, not RADIUS.

If you re-order the attributes, most probably the result would not make sense at all (TLV length will not match with the actual one, RADIUS packet length will be invalid, checksum will fail...), and thus it will be detected.

Am I assuming something wrong?

Best regards,
Alejandro




regards,
Peter
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext
--------------080309010203080804010105-- --===============1473235674440318602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1473235674440318602==-- From aland@deployingradius.com Thu Jan 12 00:54:49 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028BA21F84DC for ; Thu, 12 Jan 2012 00:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9l1ASiGKRgO for ; Thu, 12 Jan 2012 00:54:48 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7096F21F84DE for ; Thu, 12 Jan 2012 00:54:48 -0800 (PST) Message-ID: <4F0E9FBC.3050601@deployingradius.com> Date: Thu, 12 Jan 2012 09:54:20 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> <4F0E9E33.7040701@um.es> In-Reply-To: <4F0E9E33.7040701@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 08:54:49 -0000 Alejandro Perez Mendez wrote: > So, Alan's draft could say something similar: It does. See page 11: ... When the More flag is set (1), the attribute SHOULD have a Length field of value 255; it MUST NOT have a length Field of value 4; there MUST be an attribute following this one; and the next attribute MUST have both the same Type and Extended Type. That is, multiple fragments of the same value MUST be in order and MUST be consecutive attributes in the packet, and the last attribute in a packet MUST NOT have the More flag set (1). > What if a RADIUS server decides to omit this recommendation anyway? It > should be managed the same way as RADIUS EAP does: let the upper layer > application (e.g. EAP stack) to detect the error, not RADIUS. Any upper layer will likely detect malformed content, and ignore it. Alan DeKok. From radext-bounces@ietf.org Thu Jan 12 00:54:50 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915F721F84DE; Thu, 12 Jan 2012 00:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326358490; bh=2TGG6VNj+cwMLwWPR+eQmgHv/qwTylNY4NR+50bj/0c=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=umflXphHuYOMIi3efIkMtpXGiX50tGy1WZGD3sZLSBYtImvh3IiOBailiv+g3CnoF 69AtMdgO0iHtgb/MWqpRTRQI0SO/HXjzjt3naB3xGCc/Zlj0a/hIdtgWpkpYmq8NYn jZLBhsqkgBbRrBHLtBPtKU2Pueh7GAzJej6W7hbw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028BA21F84DC for ; Thu, 12 Jan 2012 00:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9l1ASiGKRgO for ; Thu, 12 Jan 2012 00:54:48 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 7096F21F84DE for ; Thu, 12 Jan 2012 00:54:48 -0800 (PST) Message-ID: <4F0E9FBC.3050601@deployingradius.com> Date: Thu, 12 Jan 2012 09:54:20 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> <4F0E9E33.7040701@um.es> In-Reply-To: <4F0E9E33.7040701@um.es> X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alejandro Perez Mendez wrote: > So, Alan's draft could say something similar: It does. See page 11: ... When the More flag is set (1), the attribute SHOULD have a Length field of value 255; it MUST NOT have a length Field of value 4; there MUST be an attribute following this one; and the next attribute MUST have both the same Type and Extended Type. That is, multiple fragments of the same value MUST be in order and MUST be consecutive attributes in the packet, and the last attribute in a packet MUST NOT have the More flag set (1). > What if a RADIUS server decides to omit this recommendation anyway? It > should be managed the same way as RADIUS EAP does: let the upper layer > application (e.g. EAP stack) to detect the error, not RADIUS. Any upper layer will likely detect malformed content, and ignore it. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Thu Jan 12 03:16:32 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA94721F859B for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2hnaFDbw2-6 for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 12CBA21F8527 for ; Thu, 12 Jan 2012 03:16:31 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 11 Jan 2012 13:52:18 -0800 Date: Wed, 11 Jan 2012 13:52:17 -0800 (Pacific Standard Time) From: Peter Deacon To: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="623650257-19661-1326318738=:4088" Cc: radext mailing list Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:16:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --623650257-19661-1326318738=:4088 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 Jan 2012, Fernando Pereñíguez wrote: >> OK: >> [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] >> NOT OK: >> [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] >> ^^^^^^^^^^^^^^^^^^^^^^^ >> - Gear-A is truncated >> - Gear-B is lost never appearing as a separate attribute >> - Gear-B in its entirety is appended to Gear-A further corrupting Gear-A. >> - The last fragment of Gear-A becomes a standalone corrupt attribute of its own. > Since Gear-A and Gear-B are extended attributes, it is obvious that the > RADIUS implementation generating and inserting these attributes > implements extended attributes. In such case, as stated in the draft, > the new type space is formed by "Type.Extended-Type" so the > implementation should be able to distinguish that Gear-A and Gear-B are > different attributes and, consequently, detect that performing this > insertion of [Gear-B M.1] violates the order preservation of Gear-A > fragments. Is my understanding correct ? Hi Fernando, If all systems in the chain support extended types there should be no room for excuses when it comes to mangling attributes. An example of a problem are proxy systems inserting blobs on behalf of a mgmt station. Proxy server does not necessarily need to understand attributes in order to apply policy and forward messages. One of the goals is reasonable level of interop with systems not supporting extended attributes. In the real world is this a problem? What is the risk? I don't have an answer. The only thing I know for sure there are a huge number of sometimes ancient implementations out there. regards, Peter --623650257-19661-1326318738=:4088-- From peterd@iea-software.com Thu Jan 12 03:16:33 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B35C21F8527 for ; Thu, 12 Jan 2012 03:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwopw075gpx7 for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33621F858F for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 11 Jan 2012 10:54:40 -0800 Date: Wed, 11 Jan 2012 10:54:39 -0800 (Pacific Standard Time) From: Peter Deacon To: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="612992101-16276-1326308079=:4088" Cc: radext mailing list Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:16:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --612992101-16276-1326308079=:4088 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 Jan 2012, Fernando Pereñíguez wrote: > I'm trying to understand the problems you mention regarding the use of > extended attributes and the order preservation. Please, see my comments > inline. > "   Many Attributes may have multiple instances, in such a > case the order >   of Attributes of the same Type SHOULD be preserved.  The > order of >   Attributes of different Types is not required to be > preserved." > There are two problems with this: > 1. SHOULD is not enough. > 2. Preserving order is not enough. > I'm a bit confused about the preservation of order of attributes of the > same type. Certainly, RFC 2138 does not force the preservation of such > order. Nevertheless, in RFC 2865 it is said that: > If multiple Attributes with the same Type are present, the order of > Attributes with the same Type MUST be preserved by any proxies. > For this reason, so far I've been assuming that order of attributes of > the same type must be respected. In fact, the RADIUS extensions makes > such assumption with the fragmentation based on bit 'M'. So, my question > is: can we assume order preservation of attributes of the same Type or > not ? Hi Fernando, Lets assume order is universally respected. What prevents new attributes from being inserted while respecting order of existing attributes? From other text (below) my impression this is allowed and expected. The Gear + Cog example can only fail to detect an error with VSAs when you assume order is respected however this is not end of story. A new example with order preserved not using VSAs.. two gears - Gear-A and Gear-B. Gear-A and Gear-B are instances of the same extended type. OK: [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] NOT OK: [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] ^^^^^^^^^^^^^^^^^^^^^^^ - Gear-A is truncated - Gear-B is lost never appearing as a separate attribute - Gear-B in its entirety is appended to Gear-A further corrupting Gear-A. - The last fragment of Gear-A becomes a standalone corrupt attribute of its own. We already have EAP bless its heart... RFC 2865 5 (June 2000) "A RADIUS server or client MUST NOT require attributes of the same type to be contiguous." RFC 2869 5.13 (June 2000) "If multiple EAP- Messages are contained within an Access-Request or Access- Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet." I think there are important differences between EAP as an example and extensions. 1. If EAP does not work you don't authenticate. The failure mode does not include silent data corruption / crazy authorization parameters. 2. There is only one EAP-Message conduit possible per auth transaction as far as I know. The scenario I raise above requires two or more to work. > In this case, as mentioned by Alejandro in a previous e-mail, I think the > corruption in attribute headers only affects to extended VSA. VSAs outnumber standard attributes by at least 15 to 1. It is a big deal. regards, Peter --612992101-16276-1326308079=:4088-- From radext-bounces@ietf.org Thu Jan 12 03:16:34 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD221F858F; Thu, 12 Jan 2012 03:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326366994; bh=6Ke0enZd+71EPD4UK15PUpbR/vfYt1KJZ23eJ0LKgCk=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version: Content-Type:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=k7T61VUeEbe7ELjjvsKFBmhQiwfH9ZFSrDM7wI6mMn47IKCxmX9Qsqs6/FOH6+HAv 6If0XBhzyRQ2JdqtulvVYHTNVNqHsqz043mpQ08cau5SxmU8GNbitzRCU4nRg22T7w FFSrxdgAW9IHa3z8DREfj/U/cW8kmUTu55DFXknw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA94721F859B for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2hnaFDbw2-6 for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 12CBA21F8527 for ; Thu, 12 Jan 2012 03:16:31 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 11 Jan 2012 13:52:18 -0800 Date: Wed, 11 Jan 2012 13:52:17 -0800 (Pacific Standard Time) From: Peter Deacon To: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="623650257-19661-1326318738=:4088" Cc: radext mailing list Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --623650257-19661-1326318738=:4088 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 Jan 2012, Fernando Pereñíguez wrote: >> OK: >> [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] >> NOT OK: >> [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] >> ^^^^^^^^^^^^^^^^^^^^^^^ >> - Gear-A is truncated >> - Gear-B is lost never appearing as a separate attribute >> - Gear-B in its entirety is appended to Gear-A further corrupting Gear-A. >> - The last fragment of Gear-A becomes a standalone corrupt attribute of its own. > Since Gear-A and Gear-B are extended attributes, it is obvious that the > RADIUS implementation generating and inserting these attributes > implements extended attributes. In such case, as stated in the draft, > the new type space is formed by "Type.Extended-Type" so the > implementation should be able to distinguish that Gear-A and Gear-B are > different attributes and, consequently, detect that performing this > insertion of [Gear-B M.1] violates the order preservation of Gear-A > fragments. Is my understanding correct ? Hi Fernando, If all systems in the chain support extended types there should be no room for excuses when it comes to mangling attributes. An example of a problem are proxy systems inserting blobs on behalf of a mgmt station. Proxy server does not necessarily need to understand attributes in order to apply policy and forward messages. One of the goals is reasonable level of interop with systems not supporting extended attributes. In the real world is this a problem? What is the risk? I don't have an answer. The only thing I know for sure there are a huge number of sometimes ancient implementations out there. regards, Peter --623650257-19661-1326318738=:4088 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --623650257-19661-1326318738=:4088-- From radext-bounces@ietf.org Thu Jan 12 03:16:35 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D1521F85A1; Thu, 12 Jan 2012 03:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326366995; bh=axmyZD2OONIgMGT7PXe+PQFGyUtir7kH5c4kCq+Qzgo=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version: Content-Type:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Sender; b=VMP4ET0mOtWVztTX1cx2W3ZdfxK5fkcIrthKFtXcXndYtSOAdoMHyl8G3MSX84I9L zOsSZlPfvXzPfDHA6sfXnQ07C5O9gCb+r/VRvS3M0lDlTSI/2oPhxk1Xm10/1vuCU5 OIU7risPeKjb+0njoDKEN8mkU2XgZCcdjULYef50= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B35C21F8527 for ; Thu, 12 Jan 2012 03:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwopw075gpx7 for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33621F858F for ; Thu, 12 Jan 2012 03:16:32 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 11 Jan 2012 10:54:40 -0800 Date: Wed, 11 Jan 2012 10:54:39 -0800 (Pacific Standard Time) From: Peter Deacon To: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez?= In-Reply-To: Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="612992101-16276-1326308079=:4088" Cc: radext mailing list Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --612992101-16276-1326308079=:4088 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 11 Jan 2012, Fernando Pereñíguez wrote: > I'm trying to understand the problems you mention regarding the use of > extended attributes and the order preservation. Please, see my comments > inline. > "   Many Attributes may have multiple instances, in such a > case the order >   of Attributes of the same Type SHOULD be preserved.  The > order of >   Attributes of different Types is not required to be > preserved." > There are two problems with this: > 1. SHOULD is not enough. > 2. Preserving order is not enough. > I'm a bit confused about the preservation of order of attributes of the > same type. Certainly, RFC 2138 does not force the preservation of such > order. Nevertheless, in RFC 2865 it is said that: > If multiple Attributes with the same Type are present, the order of > Attributes with the same Type MUST be preserved by any proxies. > For this reason, so far I've been assuming that order of attributes of > the same type must be respected. In fact, the RADIUS extensions makes > such assumption with the fragmentation based on bit 'M'. So, my question > is: can we assume order preservation of attributes of the same Type or > not ? Hi Fernando, Lets assume order is universally respected. What prevents new attributes from being inserted while respecting order of existing attributes? From other text (below) my impression this is allowed and expected. The Gear + Cog example can only fail to detect an error with VSAs when you assume order is respected however this is not end of story. A new example with order preserved not using VSAs.. two gears - Gear-A and Gear-B. Gear-A and Gear-B are instances of the same extended type. OK: [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] NOT OK: [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] ^^^^^^^^^^^^^^^^^^^^^^^ - Gear-A is truncated - Gear-B is lost never appearing as a separate attribute - Gear-B in its entirety is appended to Gear-A further corrupting Gear-A. - The last fragment of Gear-A becomes a standalone corrupt attribute of its own. We already have EAP bless its heart... RFC 2865 5 (June 2000) "A RADIUS server or client MUST NOT require attributes of the same type to be contiguous." RFC 2869 5.13 (June 2000) "If multiple EAP- Messages are contained within an Access-Request or Access- Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet." I think there are important differences between EAP as an example and extensions. 1. If EAP does not work you don't authenticate. The failure mode does not include silent data corruption / crazy authorization parameters. 2. There is only one EAP-Message conduit possible per auth transaction as far as I know. The scenario I raise above requires two or more to work. > In this case, as mentioned by Alejandro in a previous e-mail, I think the > corruption in attribute headers only affects to extended VSA. VSAs outnumber standard attributes by at least 15 to 1. It is a big deal. regards, Peter --612992101-16276-1326308079=:4088 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --612992101-16276-1326308079=:4088-- From radext-bounces@ietf.org Thu Jan 12 03:26:20 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B987E21F84B6; Thu, 12 Jan 2012 03:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326367580; bh=9s1Is0Hp772SXhjDLI8kbJy+8lJhU+AfZEUitrby1rs=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hJduPuM4VGe8Nf+65dGm22BCOCGCkmUQqLJ5iEtu++InI815h8Q233IhkFzi4nT0h 4eGIn+a0kJMqlyWZv93y0NfAJpYkQxVuVTDiOTJG/OoRiX+D8kpPR6RrTsLP9xt+fs g5i/YL5bbCEb3OAGzTS115cX3TSutKi+257Ggd7s= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3C121F84B6 for ; Thu, 12 Jan 2012 03:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvyJBinjyT19 for ; Thu, 12 Jan 2012 03:26:19 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE121F849D for ; Thu, 12 Jan 2012 03:26:18 -0800 (PST) Message-ID: <4F0EC33F.30503@deployingradius.com> Date: Thu, 12 Jan 2012 12:25:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext mailing list , =?ISO-8859-1?Q?Fernando_Pere=F1=EDguez?= Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > Lets assume order is universally respected. What prevents new > attributes from being inserted while respecting order of existing > attributes? From other text (below) my impression this is allowed and > expected. Allowed, yes. I'm less sure if it's expected, or widely used. > We already have EAP bless its heart... > > RFC 2865 5 (June 2000) > "A RADIUS server or client MUST NOT require attributes of the same type > to be contiguous." I had forgotten about that. I should update the extensions document to specifically reference this, and over-ride it. From what I've seen, most proxy implementations ensure that attributes of the same type can *remain* contiguous. This goes back to 1999, the Merit server (IIRC). Do you have a proposed change to the extensions document which fixes this issue? Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Jan 12 03:26:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3C121F84B6 for ; Thu, 12 Jan 2012 03:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.314 X-Spam-Level: X-Spam-Status: No, score=-102.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvyJBinjyT19 for ; Thu, 12 Jan 2012 03:26:19 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id C5AE121F849D for ; Thu, 12 Jan 2012 03:26:18 -0800 (PST) Message-ID: <4F0EC33F.30503@deployingradius.com> Date: Thu, 12 Jan 2012 12:25:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext mailing list , =?ISO-8859-1?Q?Fernando_Pere=F1=EDguez?= Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:26:19 -0000 Peter Deacon wrote: > Lets assume order is universally respected. What prevents new > attributes from being inserted while respecting order of existing > attributes? From other text (below) my impression this is allowed and > expected. Allowed, yes. I'm less sure if it's expected, or widely used. > We already have EAP bless its heart... > > RFC 2865 5 (June 2000) > "A RADIUS server or client MUST NOT require attributes of the same type > to be contiguous." I had forgotten about that. I should update the extensions document to specifically reference this, and over-ride it. From what I've seen, most proxy implementations ensure that attributes of the same type can *remain* contiguous. This goes back to 1999, the Merit server (IIRC). Do you have a proposed change to the extensions document which fixes this issue? Alan DeKok. From alex@um.es Thu Jan 12 03:42:03 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB38621F85D8 for ; Thu, 12 Jan 2012 03:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.765 X-Spam-Level: X-Spam-Status: No, score=-6.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnPLhwaePwJC for ; Thu, 12 Jan 2012 03:42:03 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id CD86421F85D4 for ; Thu, 12 Jan 2012 03:42:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 9B95D5D45B for ; Thu, 12 Jan 2012 12:42:00 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nINqvGm3i6aT for ; Thu, 12 Jan 2012 12:42:00 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 428025D591 for ; Thu, 12 Jan 2012 12:41:59 +0100 (CET) Message-ID: <4F0EC706.5070907@um.es> Date: Thu, 12 Jan 2012 12:41:58 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 11:42:03 -0000 > Hi Fernando, > > Lets assume order is universally respected. What prevents new > attributes from being inserted while respecting order of existing > attributes? From other text (below) my impression this is allowed and > expected. > > The Gear + Cog example can only fail to detect an error with VSAs when > you assume order is respected however this is not end of story. > > A new example with order preserved not using VSAs.. two gears - Gear-A > and Gear-B. Gear-A and Gear-B are instances of the same extended type. > > OK: > [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] > > NOT OK: > [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] > ^^^^^^^^^^^^^^^^^^^^^^^ > > - Gear-A is truncated > - Gear-B is lost never appearing as a separate attribute > - Gear-B in its entirety is appended to Gear-A further corrupting > Gear-A. > - The last fragment of Gear-A becomes a standalone corrupt > attribute of its own. I did not get this one. If order is preserved, Gear-B would never be moved between Gear-A attributes. As Gear-A and Gear-B are instances of the same extended type, order would be preserver within the 5 of them. Best regards, Alejandro From radext-bounces@ietf.org Thu Jan 12 03:42:04 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5820D21F85D8; Thu, 12 Jan 2012 03:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326368524; bh=Wle3/Nl0CC6ICEn3LIajS/8kqLJEZ0io4aMXem3c1nY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=m5hzzjs84AYXSLqY5Y9HKCbOpPfDyJ8hPAuFAL9Sf83CyIO9mQD80nBcB3UEIwXpZ v5jtW6yVdqJJ0eWPJsseSbr6WVONJt2al1kN6JZryGFTJZXirZa7+tx5O9BXZsDRzk yVnFIGFep5Ddz36yCCZdO5DhEky3zHA0BZFOg7J4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB38621F85D8 for ; Thu, 12 Jan 2012 03:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.765 X-Spam-Level: X-Spam-Status: No, score=-6.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnPLhwaePwJC for ; Thu, 12 Jan 2012 03:42:03 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id CD86421F85D4 for ; Thu, 12 Jan 2012 03:42:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 9B95D5D45B for ; Thu, 12 Jan 2012 12:42:00 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nINqvGm3i6aT for ; Thu, 12 Jan 2012 12:42:00 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 428025D591 for ; Thu, 12 Jan 2012 12:41:59 +0100 (CET) Message-ID: <4F0EC706.5070907@um.es> Date: Thu, 12 Jan 2012 12:41:58 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4EF1DC0A.1070004@deployingradius.com> In-Reply-To: Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org > Hi Fernando, > > Lets assume order is universally respected. What prevents new > attributes from being inserted while respecting order of existing > attributes? From other text (below) my impression this is allowed and > expected. > > The Gear + Cog example can only fail to detect an error with VSAs when > you assume order is respected however this is not end of story. > > A new example with order preserved not using VSAs.. two gears - Gear-A > and Gear-B. Gear-A and Gear-B are instances of the same extended type. > > OK: > [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] > > NOT OK: > [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] > ^^^^^^^^^^^^^^^^^^^^^^^ > > - Gear-A is truncated > - Gear-B is lost never appearing as a separate attribute > - Gear-B in its entirety is appended to Gear-A further corrupting > Gear-A. > - The last fragment of Gear-A becomes a standalone corrupt > attribute of its own. I did not get this one. If order is preserved, Gear-B would never be moved between Gear-A attributes. As Gear-A and Gear-B are instances of the same extended type, order would be preserver within the 5 of them. Best regards, Alejandro _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Jan 12 04:55:14 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4E221F8480; Thu, 12 Jan 2012 04:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326372914; bh=XURi9Cdgk8gDdgRLCrtzpcQzeCzxkZ7zH6bloOJJooA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=nRnBZN/5qhM+0efE/0r/42A4T24MgKzaystL4LR/Sk/C4qGKCbkSwp7eOuAdIFkpr 8d3TC8nt5f9zGi8+tu5EMDZzpbOz11g+bWZZkWAU0DfAF2Twi5hVmKMcB54ukFGxrR xSOUxXlVjpA4gM1p0DNoC7GKjiXp+bEpGjMnLgcM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF521F8480 for ; Thu, 12 Jan 2012 04:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0oD5C9wsAg3 for ; Thu, 12 Jan 2012 04:55:13 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A753321F8471 for ; Thu, 12 Jan 2012 04:55:12 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1812D109F6 for ; Thu, 12 Jan 2012 13:55:11 +0100 (CET) Received: from [IPv6:2001:a18:1:8:f1f3:ab82:e484:b0f5] (unknown [IPv6:2001:a18:1:8:f1f3:ab82:e484:b0f5]) by smtprelay.restena.lu (Postfix) with ESMTPS id 05E57106CB for ; Thu, 12 Jan 2012 13:55:11 +0100 (CET) Message-ID: <4F0ED82A.7010809@restena.lu> Date: Thu, 12 Jan 2012 13:55:06 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> <4F0B049D.5010602@restena.lu> In-Reply-To: <4F0B049D.5010602@restena.lu> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3343145956586739532==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3343145956586739532== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8AF50E970082A2C134FB39C6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8AF50E970082A2C134FB39C6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, as must-fix note before publication: Appendix C states: "The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria ..." This should obviously become an informative reference to RFC6421. Stefan On 09.01.2012 16:15, Stefan Winter wrote: > Hello, >=20 > this is a mini update as per the document shepherd's request: >=20 > - updated reference to dynamic-discovery draft > - make a more explicit mention of the the fixed "shared secret" in the > Security Considerations section >=20 > Greetings, >=20 > Stefan Winter >=20 > On 09.01.2012 16:07, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the RADIUS EXTensions Working Grou= p of the IETF. >> >> Title : TLS encryption for RADIUS >> Author(s) : Stefan Winter >> Mike McCauley >> Stig Venaas >> Klaas Wierenga >> Filename : draft-ietf-radext-radsec-10.txt >> Pages : 21 >> Date : 2012-01-09 >> >> This document specifies security on the transport layer (TLS) for t= he >> RADIUS protocol when transmitted over TCP. This enables dynamic >> trust relationships between RADIUS servers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > =09 >=20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8AF50E970082A2C134FB39C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8O2C4ACgkQ+jm90f8eFWbsQQCePXBGHIBCMT6hY/hNRhyfFqJj jWYAni6vKFZwIcdfyA9qJNsB4V4TNkHw =snie -----END PGP SIGNATURE----- --------------enig8AF50E970082A2C134FB39C6-- --===============3343145956586739532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3343145956586739532==-- From stefan.winter@restena.lu Thu Jan 12 04:55:13 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF521F8480 for ; Thu, 12 Jan 2012 04:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0oD5C9wsAg3 for ; Thu, 12 Jan 2012 04:55:13 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A753321F8471 for ; Thu, 12 Jan 2012 04:55:12 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1812D109F6 for ; Thu, 12 Jan 2012 13:55:11 +0100 (CET) Received: from [IPv6:2001:a18:1:8:f1f3:ab82:e484:b0f5] (unknown [IPv6:2001:a18:1:8:f1f3:ab82:e484:b0f5]) by smtprelay.restena.lu (Postfix) with ESMTPS id 05E57106CB for ; Thu, 12 Jan 2012 13:55:11 +0100 (CET) Message-ID: <4F0ED82A.7010809@restena.lu> Date: Thu, 12 Jan 2012 13:55:06 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120109150711.5898.91566.idtracker@ietfa.amsl.com> <4F0B049D.5010602@restena.lu> In-Reply-To: <4F0B049D.5010602@restena.lu> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8AF50E970082A2C134FB39C6" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:55:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8AF50E970082A2C134FB39C6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, as must-fix note before publication: Appendix C states: "The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria ..." This should obviously become an informative reference to RFC6421. Stefan On 09.01.2012 16:15, Stefan Winter wrote: > Hello, >=20 > this is a mini update as per the document shepherd's request: >=20 > - updated reference to dynamic-discovery draft > - make a more explicit mention of the the fixed "shared secret" in the > Security Considerations section >=20 > Greetings, >=20 > Stefan Winter >=20 > On 09.01.2012 16:07, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. This draft is a work item of the RADIUS EXTensions Working Grou= p of the IETF. >> >> Title : TLS encryption for RADIUS >> Author(s) : Stefan Winter >> Mike McCauley >> Stig Venaas >> Klaas Wierenga >> Filename : draft-ietf-radext-radsec-10.txt >> Pages : 21 >> Date : 2012-01-09 >> >> This document specifies security on the transport layer (TLS) for t= he >> RADIUS protocol when transmitted over TCP. This enables dynamic >> trust relationships between RADIUS servers. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > =09 >=20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8AF50E970082A2C134FB39C6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8O2C4ACgkQ+jm90f8eFWbsQQCePXBGHIBCMT6hY/hNRhyfFqJj jWYAni6vKFZwIcdfyA9qJNsB4V4TNkHw =snie -----END PGP SIGNATURE----- --------------enig8AF50E970082A2C134FB39C6-- From dromasca@avaya.com Thu Jan 12 05:06:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4216021F854D for ; Thu, 12 Jan 2012 05:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.26 X-Spam-Level: X-Spam-Status: No, score=-103.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDJ8khuSCPJs for ; Thu, 12 Jan 2012 05:06:18 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91521F8527 for ; Thu, 12 Jan 2012 05:06:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH/ZDk+HCzI1/2dsb2JhbABDrQmBBYFyAQEBAQMBAQEJBh4+BBMEAgEIDQQEAQEBCgYMCwEGASYfCQgBAQQBEggBDQyHYJwimxyLOmMEiAiSeIxL X-IronPort-AV: E=Sophos;i="4.71,497,1320642000"; d="scan'208";a="285883430" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jan 2012 08:06:16 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2012 07:53:01 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 14:06:00 +0100 Message-ID: In-Reply-To: <4F0ED82A.7010809@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] I-D Action: draft-ietf-radext-radsec-10.txt Thread-Index: AczRKXA9QxiySV1LSCOwXZ8cRCjIQAAARN7g References: <20120109150711.5898.91566.idtracker@ietfa.amsl.com><4F0B049D.5010602@restena.lu> <4F0ED82A.7010809@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 13:06:19 -0000 Hi Stefan, I am reviewing this document as we speak. I do not see special reasons = for updating this document right now, so I will sent it to IETF Last = Call after I complete my review. The next update should address my = review and the Last Call comments, so please keep this must-fix edit for = that revision.=20 Thanks and Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Stefan Winter > Sent: Thursday, January 12, 2012 2:55 PM > To: radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt >=20 > Hi, >=20 > as must-fix note before publication: >=20 > Appendix C states: >=20 > "The RADIUS Crypto-Agility Requirements (link to RFC once issued here) > defines numerous classification criteria ..." >=20 > This should obviously become an informative reference to RFC6421. >=20 > Stefan >=20 > On 09.01.2012 16:15, Stefan Winter wrote: > > Hello, > > > > this is a mini update as per the document shepherd's request: > > > > - updated reference to dynamic-discovery draft > > - make a more explicit mention of the the fixed "shared secret" in > the > > Security Considerations section > > > > Greetings, > > > > Stefan Winter > > > > On 09.01.2012 16:07, internet-drafts@ietf.org wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the RADIUS EXTensions = Working > Group of the IETF. > >> > >> Title : TLS encryption for RADIUS > >> Author(s) : Stefan Winter > >> Mike McCauley > >> Stig Venaas > >> Klaas Wierenga > >> Filename : draft-ietf-radext-radsec-10.txt > >> Pages : 21 > >> Date : 2012-01-09 > >> > >> This document specifies security on the transport layer (TLS) = for > the > >> RADIUS protocol when transmitted over TCP. This enables dynamic > >> trust relationships between RADIUS servers. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt > >> > >> _______________________________________________ > >> radext mailing list > >> radext@ietf.org > >> https://www.ietf.org/mailman/listinfo/radext > > > > > > > > > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From radext-bounces@ietf.org Thu Jan 12 05:06:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE721F855E; Thu, 12 Jan 2012 05:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326373579; bh=mQpuPZYb0HJ2L8sKfTPontv62yCUWzv+MAfr/FKrYTA=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=wstMXTHM6NZxngocbkwkf2RzkHfdDMrPrVXRNUvuNt8BN9/Xo1RBBOAn36A/hQBr/ w6kTFIEOD0rPYzL0h2EOuI0o1QfOLUQkXpTj1h81XSXNymlH3NuFhB9bBXtAyUMrAr ijnKMGOLtgCPmR0DfQG9awY4cCXnXf8VAr0uznQM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4216021F854D for ; Thu, 12 Jan 2012 05:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.26 X-Spam-Level: X-Spam-Status: No, score=-103.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDJ8khuSCPJs for ; Thu, 12 Jan 2012 05:06:18 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91521F8527 for ; Thu, 12 Jan 2012 05:06:18 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAH/ZDk+HCzI1/2dsb2JhbABDrQmBBYFyAQEBAQMBAQEJBh4+BBMEAgEIDQQEAQEBCgYMCwEGASYfCQgBAQQBEggBDQyHYJwimxyLOmMEiAiSeIxL X-IronPort-AV: E=Sophos;i="4.71,497,1320642000"; d="scan'208";a="285883430" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 12 Jan 2012 08:06:16 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2012 07:53:01 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jan 2012 14:06:00 +0100 Message-ID: In-Reply-To: <4F0ED82A.7010809@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] I-D Action: draft-ietf-radext-radsec-10.txt Thread-Index: AczRKXA9QxiySV1LSCOwXZ8cRCjIQAAARN7g References: <20120109150711.5898.91566.idtracker@ietfa.amsl.com><4F0B049D.5010602@restena.lu> <4F0ED82A.7010809@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi Stefan, I am reviewing this document as we speak. I do not see special reasons for = updating this document right now, so I will sent it to IETF Last Call after= I complete my review. The next update should address my review and the Las= t Call comments, so please keep this must-fix edit for that revision. = Thanks and Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Stefan Winter > Sent: Thursday, January 12, 2012 2:55 PM > To: radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-10.txt > = > Hi, > = > as must-fix note before publication: > = > Appendix C states: > = > "The RADIUS Crypto-Agility Requirements (link to RFC once issued here) > defines numerous classification criteria ..." > = > This should obviously become an informative reference to RFC6421. > = > Stefan > = > On 09.01.2012 16:15, Stefan Winter wrote: > > Hello, > > > > this is a mini update as per the document shepherd's request: > > > > - updated reference to dynamic-discovery draft > > - make a more explicit mention of the the fixed "shared secret" in > the > > Security Considerations section > > > > Greetings, > > > > Stefan Winter > > > > On 09.01.2012 16:07, internet-drafts@ietf.org wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the RADIUS EXTensions Working > Group of the IETF. > >> > >> Title : TLS encryption for RADIUS > >> Author(s) : Stefan Winter > >> Mike McCauley > >> Stig Venaas > >> Klaas Wierenga > >> Filename : draft-ietf-radext-radsec-10.txt > >> Pages : 21 > >> Date : 2012-01-09 > >> > >> This document specifies security on the transport layer (TLS) for > the > >> RADIUS protocol when transmitted over TCP. This enables dynamic > >> trust relationships between RADIUS servers. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-10.txt > >> > >> _______________________________________________ > >> radext mailing list > >> radext@ietf.org > >> https://www.ietf.org/mailman/listinfo/radext > > > > > > > > > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > = > = > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > = > Tel: +352 424409 1 > Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Jan 12 05:37:47 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3989F21F85EE; Thu, 12 Jan 2012 05:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326375467; bh=EDmC7j6ygGt+aPT4hmUIwAaMDJ45V+gNuOUb7K4VI0I=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=zChzOtrvbooDAqDTtwNlf6a42OHMq6I9tvS0NJq8gBOUfQobUEZjl67HUB1Iz8Bb7 PEiZl/y8Tsf56kXhBp0hkdtu++FmS6UBZUQdekX6smyzX9gu9Qn5HkrtHV3R18aDN7 u24YehdzZ5UlAN8twQ5E0clwjBrHSvU3LGuepeOc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9721F85EC for ; Thu, 12 Jan 2012 05:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYf8+Lgi5PaW for ; Thu, 12 Jan 2012 05:37:43 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADE7921F85D2 for ; Thu, 12 Jan 2012 05:37:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ/hDk+HCzI1/2dsb2JhbABDrQmBBYFyAQEBAQIBEh4KRA0BFRUGDAwHVwEEGxqHWJgXhBibGYkBgjljBJsAjEs X-IronPort-AV: E=Sophos;i="4.71,498,1320642000"; d="scan'208";a="226405916" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Jan 2012 08:37:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2012 08:24:13 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jan 2012 14:37:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-radext-radsec-10 Thread-Index: AczRLy8ngtuDT3M9QZC1D7kog/6R9Q== From: "Romascanu, Dan (Dan)" To: Subject: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi, This is the AD review of draft-ietf-radext-radsec-10. The document is in good shape and I am sending it to IETF Last Call. Please address the comments below together with the other IETF Last Call comments. Technical comments are marked T and Editorial comments are marked E. T1. The Intended status of the document is Experimental. I would suggest to add some text to clarify: - what is the scope of the experiment - any specific features, behaviors, performance, scalability data that would validate the experiment and allow for possible migration of the document to Standards Track in the future - any restrictions in deployment or other operational considerations that should be known by operators or implementers? T2. In Section 4: > As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. This (non-)recommendation is not clear to me. Actually if no other transport works for a given RADIUS entity or between a client and a server a fallback to RADIUS/UDP will always happen because this is the current standard and mandatory-to-implement transport. What is meant here - I think - is to RECOMMEND that manual administrative interfaces be made available for configuration of transport and that these interfaces be used to select the preferred transport between clients and servers. E1. Section 2.3 > after completing the TCP handshake, immediately negotiate TLS sessions. The following restrictions apply: according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply: 'The following restrictions apply' appears twice - drop one of them E2. Add reference to RFC 6421 and link to it from Appendix C. Thanks and Regards, Dan _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dromasca@avaya.com Thu Jan 12 05:37:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9721F85EC for ; Thu, 12 Jan 2012 05:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYf8+Lgi5PaW for ; Thu, 12 Jan 2012 05:37:43 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id ADE7921F85D2 for ; Thu, 12 Jan 2012 05:37:43 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ/hDk+HCzI1/2dsb2JhbABDrQmBBYFyAQEBAQIBEh4KRA0BFRUGDAwHVwEEGxqHWJgXhBibGYkBgjljBJsAjEs X-IronPort-AV: E=Sophos;i="4.71,498,1320642000"; d="scan'208";a="226405916" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Jan 2012 08:37:27 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jan 2012 08:24:13 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jan 2012 14:37:25 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD Review of draft-ietf-radext-radsec-10 Thread-Index: AczRLy8ngtuDT3M9QZC1D7kog/6R9Q== From: "Romascanu, Dan (Dan)" To: Subject: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 13:37:46 -0000 Hi, This is the AD review of draft-ietf-radext-radsec-10. The document is in good shape and I am sending it to IETF Last Call. Please address the comments below together with the other IETF Last Call comments.=20 Technical comments are marked T and Editorial comments are marked E.=20 T1. The Intended status of the document is Experimental. I would suggest to add some text to clarify:=20 - what is the scope of the experiment - any specific features, behaviors, performance, scalability data that would validate the experiment and allow for possible migration of the document to Standards Track in the future - any restrictions in deployment or other operational considerations that should be known by operators or implementers?=20 T2. In Section 4:=20 > As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. This (non-)recommendation is not clear to me. Actually if no other transport works for a given RADIUS entity or between a client and a server a fallback to RADIUS/UDP will always happen because this is the current standard and mandatory-to-implement transport. What is meant here - I think - is to RECOMMEND that manual administrative interfaces be made available for configuration of transport and that these interfaces be used to select the preferred transport between clients and servers.=20 E1. Section 2.3 > after completing the TCP handshake, immediately negotiate TLS sessions. The following restrictions apply: according to [RFC5246] or its predecessor TLS 1.1. The following restrictions apply: 'The following restrictions apply' appears twice - drop one of them E2. Add reference to RFC 6421 and link to it from Appendix C. Thanks and Regards, Dan From iesg-secretary@ietf.org Thu Jan 12 07:16:38 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BE821F861E; Thu, 12 Jan 2012 07:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq-qmX0j8Fre; Thu, 12 Jan 2012 07:16:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2621F8615; Thu, 12 Jan 2012 07:16:38 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112151638.8772.89829.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 07:16:38 -0800 Cc: radext@ietf.org Subject: [radext] Last Call: (TLS encryption for RADIUS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 15:16:38 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'TLS encryption for RADIUS' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ No IPR declarations have been submitted directly on this I-D. From radext-bounces@ietf.org Thu Jan 12 07:16:42 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0132321F8629; Thu, 12 Jan 2012 07:16:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326381402; bh=yTB258/YOGnD3+qKwmsUQf+mFCuv9TNMY6dGoCz1x0A=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=GW8c9sWJVPTlMaJGsPOJxaYOls5AUsxxykSwPfhbom5o/xWEmk3LaOt2s2rfIz5O5 14RaCWscJmgLmBcxHvSJeTi7fE2F+3TqgB0vmgVwvrxjfkxo0niBg25+yI0Av11oqM wxJMT55KP25nWzf5uQNCJ5a39zrbVh1clOU6HzFY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BE821F861E; Thu, 12 Jan 2012 07:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq-qmX0j8Fre; Thu, 12 Jan 2012 07:16:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2621F8615; Thu, 12 Jan 2012 07:16:38 -0800 (PST) MIME-Version: 1.0 From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112151638.8772.89829.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 07:16:38 -0800 Cc: radext@ietf.org Subject: [radext] Last Call: (TLS encryption for RADIUS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'TLS encryption for RADIUS' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Thu Jan 12 11:25:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10FD21F8501 for ; Thu, 12 Jan 2012 11:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD5YtUDbxurz for ; Thu, 12 Jan 2012 11:25:23 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id A865021F84F1 for ; Thu, 12 Jan 2012 11:25:23 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jan 2012 11:25:23 -0800 Date: Thu, 12 Jan 2012 11:25:20 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0E9E33.7040701@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> <4F0E9E33.7040701@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:25:24 -0000 On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote: > well, but data corruption is always possible. Any proxy in the path could > change a header byte, for example, and mess all up. Hi Alejandro, We have a reasonable chance to mitigate this specific possibility for error at low low Internet draft discount rate. Solution could be as simple as a counter field. No heavy machinery required. > I think RADIUS EAP has been accepted and deployed enough to agree that is > a viable solution. > What if a RADIUS server decides to omit this recommendation anyway? It > should be managed the same way as RADIUS EAP does: let the upper layer > application (e.g. EAP stack) to detect the error, not RADIUS. This assumes attributes have their own upper layer error detection scheme to facilitate error detection. I can't think of any Authorization or Accounting attributes that do. I can't think of any EAP methods by their nature which do not. In the absence of upper layer error detection lower layers are best positioned to ensure ensure valid data. As mentioned earlier have to be careful about using EAP for comparison. There is only one EAP conversation allowed per RADIUS message. Extended attributes allows multiple long attributes. > If you re-order the attributes, most probably the result would not make > sense at all (TLV length will not match with the actual one, RADIUS > packet length will be invalid, checksum will fail...), and thus it will > be detected. > Am I assuming something wrong? If you reorder/mix long attributes carrying ACLs the most probable result will be an angry user or more seriously an angry operator. We can disagree on the likelihood of the problem occurring and therefore what should be done about it. Beyond this if it is agreed there is a reasonable chance of the problem occurring then something must be done. Dice rolling and upper layer punting is not something I expect operators are willing to accept. regards, Peter From radext-bounces@ietf.org Thu Jan 12 11:25:26 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B321F8526; Thu, 12 Jan 2012 11:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326396326; bh=d9FuzCNNcz+MjaYYVMoIgSTp9h+Qt/aaUTdSP9H/l94=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=IX2v9W4y9+HbPK/XMpO/fYDAOY2YGh0hX5mZxsIQM9EFYNUT6y9qIUYcHFnz9OxM1 zGka9r0M/c2jObA+fmc/5OM7RdxsUd9p0GGdhoBagvUp34wkaOR1PUTIr2P0LKuq4J OMH416TojFTt+fPTzKJZD80+jPPrKLhn5D8MvPXE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10FD21F8501 for ; Thu, 12 Jan 2012 11:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD5YtUDbxurz for ; Thu, 12 Jan 2012 11:25:23 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id A865021F84F1 for ; Thu, 12 Jan 2012 11:25:23 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jan 2012 11:25:23 -0800 Date: Thu, 12 Jan 2012 11:25:20 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0E9E33.7040701@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> <4F0E9E33.7040701@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote: > well, but data corruption is always possible. Any proxy in the path could > change a header byte, for example, and mess all up. Hi Alejandro, We have a reasonable chance to mitigate this specific possibility for error at low low Internet draft discount rate. Solution could be as simple as a counter field. No heavy machinery required. > I think RADIUS EAP has been accepted and deployed enough to agree that is > a viable solution. > What if a RADIUS server decides to omit this recommendation anyway? It > should be managed the same way as RADIUS EAP does: let the upper layer > application (e.g. EAP stack) to detect the error, not RADIUS. This assumes attributes have their own upper layer error detection scheme to facilitate error detection. I can't think of any Authorization or Accounting attributes that do. I can't think of any EAP methods by their nature which do not. In the absence of upper layer error detection lower layers are best positioned to ensure ensure valid data. As mentioned earlier have to be careful about using EAP for comparison. There is only one EAP conversation allowed per RADIUS message. Extended attributes allows multiple long attributes. > If you re-order the attributes, most probably the result would not make > sense at all (TLV length will not match with the actual one, RADIUS > packet length will be invalid, checksum will fail...), and thus it will > be detected. > Am I assuming something wrong? If you reorder/mix long attributes carrying ACLs the most probable result will be an angry user or more seriously an angry operator. We can disagree on the likelihood of the problem occurring and therefore what should be done about it. Beyond this if it is agreed there is a reasonable chance of the problem occurring then something must be done. Dice rolling and upper layer punting is not something I expect operators are willing to accept. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Thu Jan 12 11:34:14 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB6021F8617 for ; Thu, 12 Jan 2012 11:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pfgZFWjoU3h for ; Thu, 12 Jan 2012 11:34:14 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5C21F8616 for ; Thu, 12 Jan 2012 11:34:13 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jan 2012 11:34:13 -0800 Date: Thu, 12 Jan 2012 11:34:11 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0EC706.5070907@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0EC706.5070907@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 19:34:14 -0000 On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote: >> Lets assume order is universally respected. What prevents new >> attributes from being inserted while respecting order of existing >> attributes? From other text (below) my impression this is allowed and >> expected. >> The Gear + Cog example can only fail to detect an error with VSAs when >> you assume order is respected however this is not end of story. >> A new example with order preserved not using VSAs.. two gears - Gear-A >> and Gear-B. Gear-A and Gear-B are instances of the same extended type. >> OK: >> [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] >> >> NOT OK: >> [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] >> ^^^^^^^^^^^^^^^^^^^^^^^ >> >> - Gear-A is truncated >> - Gear-B is lost never appearing as a separate attribute >> - Gear-B in its entirety is appended to Gear-A further corrupting >> Gear-A. >> - The last fragment of Gear-A becomes a standalone corrupt attribute >> of its own. > I did not get this one. If order is preserved, Gear-B would never be moved > between Gear-A attributes. As Gear-A and Gear-B are instances of the same > extended type, order would be preserver within the 5 of them. Hi Alejandro, Gear-B is being added to an existing RADIUS message containing only Gear-A attributes. OK example is when Gear-B is appended to the end. NOT OK is when Gear-B is inserted in the middle of Gear-A. Note elements of Gear-A retain their ordering in the NOT OK example which is all that is required by existing RFCs. regards, Peter From radext-bounces@ietf.org Thu Jan 12 11:34:16 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0221F8617; Thu, 12 Jan 2012 11:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326396856; bh=+dPX2NPGYDF00NhvLRNnAXSCYdOZr5t4h3SVCZZQ4+E=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=PcjYdET6gW0CaMHjCAi+gPbN+o6q6V7ILRhZuQgxyIdeM5DwFXlj7xuQw+FggB/Rh dOeoRZWq6gy1T7nSUHsO2PGRt4TVsgSpOBVpVSS6qFBKMQWC1ez62tyH14pqX925Vg 5yjQAQpfTsFWjFswyaepG/qPCNLWhnFnCmQZIL80= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB6021F8617 for ; Thu, 12 Jan 2012 11:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pfgZFWjoU3h for ; Thu, 12 Jan 2012 11:34:14 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5C21F8616 for ; Thu, 12 Jan 2012 11:34:13 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 12 Jan 2012 11:34:13 -0800 Date: Thu, 12 Jan 2012 11:34:11 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <4F0EC706.5070907@um.es> Message-ID: References: <4EF1DC0A.1070004@deployingradius.com> <4F0EC706.5070907@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote: >> Lets assume order is universally respected. What prevents new >> attributes from being inserted while respecting order of existing >> attributes? From other text (below) my impression this is allowed and >> expected. >> The Gear + Cog example can only fail to detect an error with VSAs when >> you assume order is respected however this is not end of story. >> A new example with order preserved not using VSAs.. two gears - Gear-A >> and Gear-B. Gear-A and Gear-B are instances of the same extended type. >> OK: >> [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] >> >> NOT OK: >> [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] >> ^^^^^^^^^^^^^^^^^^^^^^^ >> >> - Gear-A is truncated >> - Gear-B is lost never appearing as a separate attribute >> - Gear-B in its entirety is appended to Gear-A further corrupting >> Gear-A. >> - The last fragment of Gear-A becomes a standalone corrupt attribute >> of its own. > I did not get this one. If order is preserved, Gear-B would never be moved > between Gear-A attributes. As Gear-A and Gear-B are instances of the same > extended type, order would be preserver within the 5 of them. Hi Alejandro, Gear-B is being added to an existing RADIUS message containing only Gear-A attributes. OK example is when Gear-B is appended to the end. NOT OK is when Gear-B is inserted in the middle of Gear-A. Note elements of Gear-A retain their ordering in the NOT OK example which is all that is required by existing RFCs. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Thu Jan 12 23:51:54 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010AF21F85C6 for ; Thu, 12 Jan 2012 23:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJDvIXe+fpW8 for ; Thu, 12 Jan 2012 23:51:53 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3990821F859E for ; Thu, 12 Jan 2012 23:51:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id DBA765D4FC; Fri, 13 Jan 2012 08:51:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7zYgV-g4zRa3; Fri, 13 Jan 2012 08:51:51 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 1BF245D4EB; Fri, 13 Jan 2012 08:51:48 +0100 (CET) Message-ID: <4F0FE294.7070902@um.es> Date: Fri, 13 Jan 2012 08:51:48 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> <4F0E9E33.7040701@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:51:54 -0000 El 12/01/12 20:25, Peter Deacon escribió: > On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote: > >> well, but data corruption is always possible. Any proxy in the path >> could >> change a header byte, for example, and mess all up. > > Hi Alejandro, > Hi Peter > We have a reasonable chance to mitigate this specific possibility for > error at low low Internet draft discount rate. Solution could be as > simple as a counter field. No heavy machinery required. Yes, you are right. > >> I think RADIUS EAP has been accepted and deployed enough to agree >> that is >> a viable solution. > >> What if a RADIUS server decides to omit this recommendation anyway? It >> should be managed the same way as RADIUS EAP does: let the upper layer >> application (e.g. EAP stack) to detect the error, not RADIUS. > > This assumes attributes have their own upper layer error detection > scheme to facilitate error detection. I can't think of any > Authorization or Accounting attributes that do. I can't think of any > EAP methods by their nature which do not. I was thinking on an attribute representing a SAML message (http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-02). If fragments are reordered, most likely resulting XML will not be valid. Moreover, if signature is being used, the chance of error detection is 100%. But I can see this is not the most usual case. > > In the absence of upper layer error detection lower layers are best > positioned to ensure ensure valid data. Agree. > > As mentioned earlier have to be careful about using EAP for > comparison. There is only one EAP conversation allowed per RADIUS > message. Extended attributes allows multiple long attributes. Right. > >> If you re-order the attributes, most probably the result would not make >> sense at all (TLV length will not match with the actual one, RADIUS >> packet length will be invalid, checksum will fail...), and thus it will >> be detected. >> Am I assuming something wrong? > > If you reorder/mix long attributes carrying ACLs the most probable > result will be an angry user or more seriously an angry operator. > > We can disagree on the likelihood of the problem occurring and > therefore what should be done about it. > > Beyond this if it is agreed there is a reasonable chance of the > problem occurring then something must be done. Dice rolling and upper > layer punting is not something I expect operators are willing to accept. You're right. Thanks for the clarifications and best regards, Alejandro > > regards, > Peter From radext-bounces@ietf.org Thu Jan 12 23:51:56 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF7221F85C6; Thu, 12 Jan 2012 23:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326441115; bh=2rCZBfd1kwOEzAv9+25fegcJrEGQFSGo1lEyVXgfIfs=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=Fpp2AIY199hnpG3RfuEiPufPTWQsc13Esi7Rla25SqSKStovN3VocBk03vg9k8k9F IwAMaUDtlt3Baxn82RqR9uMnT6ZLWDNuXCwAoIH6l58taFPlqgVMdArVaAi7TLxlxF Y5HvseyrBoPVTO8NBP7lBXqbbW2cAdwOtOkWa6zE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010AF21F85C6 for ; Thu, 12 Jan 2012 23:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJDvIXe+fpW8 for ; Thu, 12 Jan 2012 23:51:53 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3990821F859E for ; Thu, 12 Jan 2012 23:51:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id DBA765D4FC; Fri, 13 Jan 2012 08:51:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7zYgV-g4zRa3; Fri, 13 Jan 2012 08:51:51 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPA id 1BF245D4EB; Fri, 13 Jan 2012 08:51:48 +0100 (CET) Message-ID: <4F0FE294.7070902@um.es> Date: Fri, 13 Jan 2012 08:51:48 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> <4F0C271C.2060503@um.es> <4F0D4207.1000004@um.es> <4F0E9E33.7040701@um.es> In-Reply-To: Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org CgpFbCAxMi8wMS8xMiAyMDoyNSwgUGV0ZXIgRGVhY29uIGVzY3JpYmnDszoKPiBPbiBUaHUsIDEy IEphbiAyMDEyLCBBbGVqYW5kcm8gUGVyZXogTWVuZGV6IHdyb3RlOgo+Cj4+IHdlbGwsIGJ1dCBk YXRhIGNvcnJ1cHRpb24gaXMgYWx3YXlzIHBvc3NpYmxlLiBBbnkgcHJveHkgaW4gdGhlIHBhdGgg Cj4+IGNvdWxkCj4+IGNoYW5nZSBhIGhlYWRlciBieXRlLCBmb3IgZXhhbXBsZSwgYW5kIG1lc3Mg YWxsIHVwLgo+Cj4gSGkgQWxlamFuZHJvLAo+CgpIaSBQZXRlcgoKPiBXZSBoYXZlIGEgcmVhc29u YWJsZSBjaGFuY2UgdG8gbWl0aWdhdGUgdGhpcyBzcGVjaWZpYyBwb3NzaWJpbGl0eSBmb3IgCj4g ZXJyb3IgYXQgbG93IGxvdyBJbnRlcm5ldCBkcmFmdCBkaXNjb3VudCByYXRlLiAgU29sdXRpb24g Y291bGQgYmUgYXMgCj4gc2ltcGxlIGFzIGEgY291bnRlciBmaWVsZC4gIE5vIGhlYXZ5IG1hY2hp bmVyeSByZXF1aXJlZC4KClllcywgeW91IGFyZSByaWdodC4KCj4KPj4gSSB0aGluayBSQURJVVMg RUFQIGhhcyBiZWVuIGFjY2VwdGVkIGFuZCBkZXBsb3llZCBlbm91Z2ggdG8gYWdyZWUgCj4+IHRo YXQgaXMKPj4gYSB2aWFibGUgc29sdXRpb24uCj4KPj4gV2hhdCBpZiBhIFJBRElVUyBzZXJ2ZXIg ZGVjaWRlcyB0byBvbWl0IHRoaXMgcmVjb21tZW5kYXRpb24gYW55d2F5PyBJdAo+PiBzaG91bGQg YmUgbWFuYWdlZCB0aGUgc2FtZSB3YXkgYXMgUkFESVVTIEVBUCBkb2VzOiBsZXQgdGhlIHVwcGVy IGxheWVyCj4+IGFwcGxpY2F0aW9uIChlLmcuIEVBUCBzdGFjaykgdG8gZGV0ZWN0IHRoZSBlcnJv ciwgbm90IFJBRElVUy4KPgo+IFRoaXMgYXNzdW1lcyBhdHRyaWJ1dGVzIGhhdmUgdGhlaXIgb3du IHVwcGVyIGxheWVyIGVycm9yIGRldGVjdGlvbiAKPiBzY2hlbWUgdG8gZmFjaWxpdGF0ZSBlcnJv ciBkZXRlY3Rpb24uICBJIGNhbid0IHRoaW5rIG9mIGFueSAKPiBBdXRob3JpemF0aW9uIG9yIEFj Y291bnRpbmcgYXR0cmlidXRlcyB0aGF0IGRvLiAgSSBjYW4ndCB0aGluayBvZiBhbnkgCj4gRUFQ IG1ldGhvZHMgYnkgdGhlaXIgbmF0dXJlIHdoaWNoIGRvIG5vdC4KCkkgd2FzIHRoaW5raW5nIG9u IGFuIGF0dHJpYnV0ZSByZXByZXNlbnRpbmcgYSBTQU1MIG1lc3NhZ2UgCihodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFiZmFiLWFhYS1zYW1sLTAyKS4gSWYgZnJhZ21lbnRz IAphcmUgcmVvcmRlcmVkLCBtb3N0IGxpa2VseSByZXN1bHRpbmcgWE1MIHdpbGwgbm90IGJlIHZh bGlkLiBNb3Jlb3ZlciwgaWYgCnNpZ25hdHVyZSBpcyBiZWluZyB1c2VkLCB0aGUgY2hhbmNlIG9m IGVycm9yIGRldGVjdGlvbiBpcyAxMDAlLiBCdXQgSSAKY2FuIHNlZSB0aGlzIGlzIG5vdCB0aGUg bW9zdCB1c3VhbCBjYXNlLgoKPgo+IEluIHRoZSBhYnNlbmNlIG9mIHVwcGVyIGxheWVyIGVycm9y IGRldGVjdGlvbiBsb3dlciBsYXllcnMgYXJlIGJlc3QgCj4gcG9zaXRpb25lZCB0byBlbnN1cmUg ZW5zdXJlIHZhbGlkIGRhdGEuCgpBZ3JlZS4KCj4KPiBBcyBtZW50aW9uZWQgZWFybGllciBoYXZl IHRvIGJlIGNhcmVmdWwgYWJvdXQgdXNpbmcgRUFQIGZvciAKPiBjb21wYXJpc29uLiBUaGVyZSBp cyBvbmx5IG9uZSBFQVAgY29udmVyc2F0aW9uIGFsbG93ZWQgcGVyIFJBRElVUyAKPiBtZXNzYWdl LiAgRXh0ZW5kZWQgYXR0cmlidXRlcyBhbGxvd3MgbXVsdGlwbGUgbG9uZyBhdHRyaWJ1dGVzLgoK UmlnaHQuCgo+Cj4+IElmIHlvdSByZS1vcmRlciB0aGUgYXR0cmlidXRlcywgbW9zdCBwcm9iYWJs eSB0aGUgcmVzdWx0IHdvdWxkIG5vdCBtYWtlCj4+IHNlbnNlIGF0IGFsbCAoVExWIGxlbmd0aCB3 aWxsIG5vdCBtYXRjaCB3aXRoIHRoZSBhY3R1YWwgb25lLCBSQURJVVMKPj4gcGFja2V0IGxlbmd0 aCB3aWxsIGJlIGludmFsaWQsIGNoZWNrc3VtIHdpbGwgZmFpbC4uLiksIGFuZCB0aHVzIGl0IHdp bGwKPj4gYmUgZGV0ZWN0ZWQuCj4+IEFtIEkgYXNzdW1pbmcgc29tZXRoaW5nIHdyb25nPwo+Cj4g SWYgeW91IHJlb3JkZXIvbWl4IGxvbmcgYXR0cmlidXRlcyBjYXJyeWluZyBBQ0xzIHRoZSBtb3N0 IHByb2JhYmxlIAo+IHJlc3VsdCB3aWxsIGJlIGFuIGFuZ3J5IHVzZXIgb3IgbW9yZSBzZXJpb3Vz bHkgYW4gYW5ncnkgb3BlcmF0b3IuCj4KPiBXZSBjYW4gZGlzYWdyZWUgb24gdGhlIGxpa2VsaWhv b2Qgb2YgdGhlIHByb2JsZW0gb2NjdXJyaW5nIGFuZCAKPiB0aGVyZWZvcmUgd2hhdCBzaG91bGQg YmUgZG9uZSBhYm91dCBpdC4KPgo+IEJleW9uZCB0aGlzIGlmIGl0IGlzIGFncmVlZCB0aGVyZSBp cyBhIHJlYXNvbmFibGUgY2hhbmNlIG9mIHRoZSAKPiBwcm9ibGVtIG9jY3VycmluZyB0aGVuIHNv bWV0aGluZyBtdXN0IGJlIGRvbmUuICBEaWNlIHJvbGxpbmcgYW5kIHVwcGVyIAo+IGxheWVyIHB1 bnRpbmcgaXMgbm90IHNvbWV0aGluZyBJIGV4cGVjdCBvcGVyYXRvcnMgYXJlIHdpbGxpbmcgdG8g YWNjZXB0LgoKWW91J3JlIHJpZ2h0LgoKVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbnMgYW5k IGJlc3QgcmVnYXJkcywKQWxlamFuZHJvCgo+Cj4gcmVnYXJkcywKPiBQZXRlcgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBsaXN0 CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jh ZGV4dAo= From alex@um.es Thu Jan 12 23:56:13 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F321F85D4 for ; Thu, 12 Jan 2012 23:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IabqRnjhpv5 for ; Thu, 12 Jan 2012 23:56:12 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id AABE821F853A for ; Thu, 12 Jan 2012 23:56:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 8CC735D597; Fri, 13 Jan 2012 08:56:11 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cz06YtUsi5TM; Fri, 13 Jan 2012 08:56:11 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 26F395D548; Fri, 13 Jan 2012 08:56:09 +0100 (CET) Message-ID: <4F0FE398.9080207@um.es> Date: Fri, 13 Jan 2012 08:56:08 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> <4F0EC706.5070907@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:56:13 -0000 El 12/01/12 20:34, Peter Deacon escribió: > On Thu, 12 Jan 2012, Alejandro Perez Mendez wrote: > >>> Lets assume order is universally respected. What prevents new >>> attributes from being inserted while respecting order of existing >>> attributes? From other text (below) my impression this is allowed >>> and expected. > >>> The Gear + Cog example can only fail to detect an error with VSAs >>> when you assume order is respected however this is not end of story. > >>> A new example with order preserved not using VSAs.. two gears - >>> Gear-A and Gear-B. Gear-A and Gear-B are instances of the same >>> extended type. > >>> OK: >>> [Gear-A M.1][Gear-A M.2][Gear-A .3][Gear-B M.1][Gear-B .2] >>> >>> NOT OK: >>> [Gear-A M.1][Gear-A M.2][Gear-B M.1][Gear-B .2][Gear-A .3] >>> ^^^^^^^^^^^^^^^^^^^^^^^ >>> >>> - Gear-A is truncated >>> - Gear-B is lost never appearing as a separate attribute >>> - Gear-B in its entirety is appended to Gear-A further >>> corrupting Gear-A. >>> - The last fragment of Gear-A becomes a standalone corrupt >>> attribute of its own. > >> I did not get this one. If order is preserved, Gear-B would never be >> moved between Gear-A attributes. As Gear-A and Gear-B are instances >> of the same extended type, order would be preserver within the 5 of >> them. > > Hi Alejandro, > > Gear-B is being added to an existing RADIUS message containing only > Gear-A attributes. > > OK example is when Gear-B is appended to the end. > > NOT OK is when Gear-B is inserted in the middle of Gear-A. > > Note elements of Gear-A retain their ordering in the NOT OK example > which is all that is required by existing RFCs. hi Peter, I was thinking that the RADIUS server was re-ordering already included attributes. Now I see the Gear-B attributes are included afterwards, and I understand the problem perfectly. Best regards, Alejandro > > regards, > Peter From radext-bounces@ietf.org Thu Jan 12 23:56:14 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5814221F85D4; Thu, 12 Jan 2012 23:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326441374; bh=xRiXIh4SwZeiIy2AUPlAiC1L0cTzSV/RT6Ds/bQYars=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=kLMsAmBxO/syitQZBsvDb9hdWCtmQl0GL9vn58I50+QZ6gWVKH3rZR/oFkAqjiUf+ C5gsMTPm/Sv8jNVodb8UYP6tFaBQV7OeuQOpxYA9JIxTWxu28pKFNcfAx4o3DmDjuj PE1ce84DeeHDMatEXIH5gUkcFnT6KGYHFjBGlFkk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F321F85D4 for ; Thu, 12 Jan 2012 23:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IabqRnjhpv5 for ; Thu, 12 Jan 2012 23:56:12 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id AABE821F853A for ; Thu, 12 Jan 2012 23:56:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 8CC735D597; Fri, 13 Jan 2012 08:56:11 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cz06YtUsi5TM; Fri, 13 Jan 2012 08:56:11 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPA id 26F395D548; Fri, 13 Jan 2012 08:56:09 +0100 (CET) Message-ID: <4F0FE398.9080207@um.es> Date: Fri, 13 Jan 2012 08:56:08 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Peter Deacon References: <4EF1DC0A.1070004@deployingradius.com> <4F0EC706.5070907@um.es> In-Reply-To: Cc: radext@ietf.org Subject: Re: [radext] Status of extensions document? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org CgpFbCAxMi8wMS8xMiAyMDozNCwgUGV0ZXIgRGVhY29uIGVzY3JpYmnDszoKPiBPbiBUaHUsIDEy IEphbiAyMDEyLCBBbGVqYW5kcm8gUGVyZXogTWVuZGV6IHdyb3RlOgo+Cj4+PiBMZXRzIGFzc3Vt ZSBvcmRlciBpcyB1bml2ZXJzYWxseSByZXNwZWN0ZWQuICBXaGF0IHByZXZlbnRzIG5ldyAKPj4+ IGF0dHJpYnV0ZXMgZnJvbSBiZWluZyBpbnNlcnRlZCB3aGlsZSByZXNwZWN0aW5nIG9yZGVyIG9m IGV4aXN0aW5nIAo+Pj4gYXR0cmlidXRlcz8gIEZyb20gb3RoZXIgdGV4dCAoYmVsb3cpIG15IGlt cHJlc3Npb24gdGhpcyBpcyBhbGxvd2VkIAo+Pj4gYW5kIGV4cGVjdGVkLgo+Cj4+PiBUaGUgR2Vh ciArIENvZyBleGFtcGxlIGNhbiBvbmx5IGZhaWwgdG8gZGV0ZWN0IGFuIGVycm9yIHdpdGggVlNB cyAKPj4+IHdoZW4geW91IGFzc3VtZSBvcmRlciBpcyByZXNwZWN0ZWQgaG93ZXZlciB0aGlzIGlz IG5vdCBlbmQgb2Ygc3RvcnkuCj4KPj4+IEEgbmV3IGV4YW1wbGUgd2l0aCBvcmRlciBwcmVzZXJ2 ZWQgbm90IHVzaW5nIFZTQXMuLiB0d28gZ2VhcnMgLSAKPj4+IEdlYXItQSBhbmQgR2Vhci1CLiAg R2Vhci1BIGFuZCBHZWFyLUIgYXJlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSAKPj4+IGV4dGVuZGVk IHR5cGUuCj4KPj4+IE9LOgo+Pj4gW0dlYXItQSBNLjFdW0dlYXItQSBNLjJdW0dlYXItQSAuM11b R2Vhci1CIE0uMV1bR2Vhci1CIC4yXQo+Pj4KPj4+IE5PVCBPSzoKPj4+IFtHZWFyLUEgTS4xXVtH ZWFyLUEgTS4yXVtHZWFyLUIgTS4xXVtHZWFyLUIgLjJdW0dlYXItQSAuM10KPj4+ICAgICAgICAg ICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eCj4+Pgo+Pj4gICAgIC0gR2Vh ci1BIGlzIHRydW5jYXRlZAo+Pj4gICAgIC0gR2Vhci1CIGlzIGxvc3QgbmV2ZXIgYXBwZWFyaW5n IGFzIGEgc2VwYXJhdGUgYXR0cmlidXRlCj4+PiAgICAgLSBHZWFyLUIgaW4gaXRzIGVudGlyZXR5 IGlzIGFwcGVuZGVkIHRvIEdlYXItQSBmdXJ0aGVyIAo+Pj4gY29ycnVwdGluZyBHZWFyLUEuCj4+ PiAgICAgLSBUaGUgbGFzdCBmcmFnbWVudCBvZiBHZWFyLUEgYmVjb21lcyBhIHN0YW5kYWxvbmUg Y29ycnVwdCAKPj4+IGF0dHJpYnV0ZSBvZiBpdHMgb3duLgo+Cj4+IEkgZGlkIG5vdCBnZXQgdGhp cyBvbmUuIElmIG9yZGVyIGlzIHByZXNlcnZlZCwgR2Vhci1CIHdvdWxkIG5ldmVyIGJlIAo+PiBt b3ZlZCBiZXR3ZWVuIEdlYXItQSBhdHRyaWJ1dGVzLiBBcyBHZWFyLUEgYW5kIEdlYXItQiBhcmUg aW5zdGFuY2VzIAo+PiBvZiB0aGUgc2FtZSBleHRlbmRlZCB0eXBlLCBvcmRlciB3b3VsZCBiZSBw cmVzZXJ2ZXIgd2l0aGluIHRoZSA1IG9mIAo+PiB0aGVtLgo+Cj4gSGkgQWxlamFuZHJvLAo+Cj4g R2Vhci1CIGlzIGJlaW5nIGFkZGVkIHRvIGFuIGV4aXN0aW5nIFJBRElVUyBtZXNzYWdlIGNvbnRh aW5pbmcgb25seSAKPiBHZWFyLUEgYXR0cmlidXRlcy4KPgo+IE9LIGV4YW1wbGUgaXMgd2hlbiBH ZWFyLUIgaXMgYXBwZW5kZWQgdG8gdGhlIGVuZC4KPgo+IE5PVCBPSyBpcyB3aGVuIEdlYXItQiBp cyBpbnNlcnRlZCBpbiB0aGUgbWlkZGxlIG9mIEdlYXItQS4KPgo+IE5vdGUgZWxlbWVudHMgb2Yg R2Vhci1BIHJldGFpbiB0aGVpciBvcmRlcmluZyBpbiB0aGUgTk9UIE9LIGV4YW1wbGUgCj4gd2hp Y2ggaXMgYWxsIHRoYXQgaXMgcmVxdWlyZWQgYnkgZXhpc3RpbmcgUkZDcy4KCmhpIFBldGVyLAoK SSB3YXMgdGhpbmtpbmcgdGhhdCB0aGUgUkFESVVTIHNlcnZlciB3YXMgcmUtb3JkZXJpbmcgYWxy ZWFkeSBpbmNsdWRlZCAKYXR0cmlidXRlcy4gTm93IEkgc2VlIHRoZSBHZWFyLUIgYXR0cmlidXRl cyBhcmUgaW5jbHVkZWQgYWZ0ZXJ3YXJkcywgYW5kIApJIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0g cGVyZmVjdGx5LgoKQmVzdCByZWdhcmRzLApBbGVqYW5kcm8KCj4KPiByZWdhcmRzLAo+IFBldGVy Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJhZGV4dCBt YWlsaW5nIGxpc3QKcmFkZXh0QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcmFkZXh0Cg== From alex@um.es Mon Jan 16 05:43:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007AD21F85DF; Mon, 16 Jan 2012 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoqikBLDV8ZL; Mon, 16 Jan 2012 05:43:44 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1A20D21F8516; Mon, 16 Jan 2012 05:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 2C0304BB19; Mon, 16 Jan 2012 14:43:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h6gzv1b-c9DN; Mon, 16 Jan 2012 14:43:34 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id ECFCE4BCE7; Mon, 16 Jan 2012 14:43:28 +0100 (CET) Message-ID: <4F142980.6040404@um.es> Date: Mon, 16 Jan 2012 14:43:28 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> In-Reply-To: <4F0ACD9A.4000809@um.es> Content-Type: multipart/alternative; boundary="------------060904040002090608040905" Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 13:43:46 -0000 This is a multi-part message in MIME format. --------------060904040002090608040905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alan, all, we have been thinking on this topic and we realized that a different approach could be more convenient to handle inter-packet fragmentation than our first proposal. Taking draft-ietf-radext-radius-extensions as a base, we can assume that intra-packet fragmentation is already handled via the M flag. We can also assume that order between fragments is preserved when following draft-ietf-radext-radius-extensions. This may not be true now with the current spec (as Peter pointed out), but we can assume this will be solved somehow in the future (e.g. including offset field). We propose the following: 1) Extended flag attributes are used to fragment big RADIUS attributes, as specified in draft-ietf-radext-radius-extensions. 2) If a fragmented attribute cannot be completely included into the remaining space of a 4KB RADIUS packet, it is truncated, that is, only the fragments that fit into the free space of the packet to be sent are included. It is also included a new RADIUS attribute, called "More-Data-Pending". The presence of this attribute indicates to the receiver that the RADIUS packet is not complete, and more data MUST be received from the sender before processing any of the received attributes. Note that it is possible (and very likely), that the last fragment of a truncated attribute in a RADIUS packet has the M flag set. This case would be against what it is stated in draft-ietf-radext-radius-extensions. Nevertheless, we think this restriction can be easily relaxed when using the more-data-pending attribute. If it is present, it is allowed that the last fragment have the bit M set, which means the attribute is truncated. A good side effect of this is that if a server does not understand more-data-pending and its semantics, a truncated attribute will be shown as an invalid attribute, and not taking the truncated portion as the whole. The rest of the attribute fragments will be sent in successive packets, following the same procedure, using as many RADIUS packets as needed to transmit the required information. Let me illustrate this with an example, where a RADIUS client sends a packet with a size > 4 KB (to make it simpler, we assume each RADIUS packet can include 8 RADIUS attributes/fragments, instead of using bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate successive fragments of the attribute Data. The RADIUS client wants to send the following RADIUS packet: Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3 As only 8 attributes can be included in the packet, the RADIUS client truncates "Data" to fit into the packet, and includes the More-Data-Pending attribute: Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], More-Data-Pending When the server receives the RADIUS packet containing the More-Data-Pending attribute, the processing of the packet is left until all the pending data is received. The pending data is requested by means of an Access-Challenge packet, using the State attribute to tie together this response with the subsequent request from the client. Access-Challenge1 = State1 The client continues sending the data until another RADIUS packet is completed, including again the attribute More-Data-Pending Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], More-Data-Pending The server stores the attributes into the state associated to State1 and replies: Access-Challenge1 = State2 Finally, the client sends the last fragments of the original packet: Access-Request3 = State2, Other2[M], Other3 The server now can process the totality of the received attributes as if they all had been received into a single RADIUS packet of more than 4 KB The case where the server sends a fragmented packet to the client is very similar and makes no sense to expli Best regards, Alejandro El 09/01/12 12:20, Alejandro Perez Mendez escribió: > Hi Alan, > > thanks for the clarifications and hints. We will think about them and > their implications, and try to modify the proposal to make it address > all the requirements. > > Regards, > Alejandro > > El 09/01/12 10:58, Alan DeKok escribió: >> DIEGO LOPEZ GARCIA wrote: >>> Ordering constraints here are applied to related attributes. >> RADIUS doesn't work that way. >> >> There are hundreds of thousands of deployments which assume that >> ordering constraints do NOT apply to related attributes. Changing such >> a fundamental part of the protocol is impossible. >> >>> I don't see why this would go beyond the requirements imposed by the >>> current document on extended attributes, as the recent discussion on >>> it shows. >> I pointed you to RFC 2865, and explained why that restriction is >> impossible. Please go read those messages again. >> >>> It relies in the usage of an specific attribute that defines the >>> interpretation of the values of another attribute. Ordering rules >>> probably could be relaxed, but at the price of more complicated >>> processing rules. >> It relies on behavior which is mandated as NOT being part of RADIUS. >> >>>> I gave comments on your approach. Do you have any comments on my >>>> proposed alternative? It would seem to (a) solve the same problem, >>>> and >>>> (b) have none of the limitations. >>> One of the main goals of the proposal was to be compatible with >>> current mechanisms for attribute encoding inside the packet >>> (EAP-style, extended attributes…) and deal only with values spanning >>> more than one packet. Using your alternative would break this >>> compatibility. >> Nonsense. >> >> It is incompatible with existing methods like EAP-Message. Those >> *already* have semantics defined. Changing them by adding a "Chunked >> Attribute" is impossible. The extended format hasn't been deployed, so >> compatibility with it is impossible. >> >> My proposal was to allow *new* attributes to span multiple packets. >> >> Changing the rules on attribute ordering is impossible. Don't >> even try. >> >> Changing the meaning of existing attributes to allow more than 253 >> octets of data is impossible. Don't even try. >> >> Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------060904040002090608040905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Alan, all,

we have been thinking on this topic and we realized that a different approach could be more convenient to handle inter-packet fragmentation than our first proposal.

Taking draft-ietf-radext-radius-extensions as a base, we can assume that intra-packet fragmentation is already handled via the M flag. We can also assume that order between fragments is preserved when following draft-ietf-radext-radius-extensions. This may not be true now with the current spec (as Peter pointed out), but we can assume this will be solved somehow in the future (e.g. including offset field).

We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes, as specified in draft-ietf-radext-radius-extensions.
2) If a fragmented attribute cannot be completely included into the remaining space of a 4KB RADIUS packet, it is truncated, that is, only the fragments that fit into the free space of the packet to be sent are included. It is also included a new RADIUS attribute, called "More-Data-Pending". The presence of this attribute indicates to the receiver that the RADIUS packet is not complete, and more data MUST be received from the sender before processing any of the received attributes.

Note that it is possible (and very likely), that the last fragment of a truncated attribute in a RADIUS packet has the M flag set. This case would be against what it is stated in draft-ietf-radext-radius-extensions. Nevertheless, we think this restriction can be easily relaxed when using the more-data-pending attribute. If it is present, it is allowed that the last fragment have the bit M set, which means the attribute is truncated. A good side effect of this is that if a  server does not understand more-data-pending and its semantics, a truncated attribute will be shown as an invalid attribute, and not taking the truncated portion as the whole.

The rest of the attribute fragments will be sent in successive packets, following the same procedure, using as many RADIUS packets as needed to transmit the required information.

Let me illustrate this with an example, where a RADIUS client sends a packet with a size > 4 KB (to make it simpler, we assume each RADIUS packet can include 8 RADIUS attributes/fragments, instead of using bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate successive fragments of the attribute Data.

The RADIUS client wants to send the following RADIUS packet:

Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3


As only 8 attributes can be included in the packet, the RADIUS client truncates "Data" to fit into the packet, and includes the More-Data-Pending attribute:

Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], More-Data-Pending

When the server receives the RADIUS packet containing the More-Data-Pending attribute, the processing of the packet is left until all the pending data is received. The pending data is requested by means of an Access-Challenge packet, using the State attribute to tie together this response with the subsequent request from the client.

Access-Challenge1 = State1

The client continues sending the data until another RADIUS packet is completed, including again the attribute More-Data-Pending

Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], More-Data-Pending


The server stores the attributes into the state associated to State1 and replies:

Access-Challenge1 = State2

Finally, the client sends the last fragments of the original packet:

Access-Request3 = State2, Other2[M], Other3

The server now can process the totality of the received attributes as if they all had been received into a single RADIUS packet of more than 4 KB

The case where the server sends a fragmented packet to the client is very similar and makes no sense to expli

Best regards,
Alejandro

El 09/01/12 12:20, Alejandro Perez Mendez escribió:
Hi Alan,

thanks for the clarifications and hints. We will think about them and their implications, and try to modify the proposal to make it address all the requirements.

Regards,
Alejandro

El 09/01/12 10:58, Alan DeKok escribió:
DIEGO LOPEZ GARCIA wrote:
Ordering constraints here are applied to related attributes.
   RADIUS doesn't work that way.

   There are hundreds of thousands of deployments which assume that
ordering constraints do NOT apply to related attributes.  Changing such
a fundamental part of the protocol is impossible.

I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.
   I pointed you to RFC 2865, and explained why that restriction is
impossible.  Please go read those messages again.

It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules.
   It relies on behavior which is mandated as NOT being part of RADIUS.

I gave comments on your approach.  Do you have any comments on my
proposed alternative?  It would seem to (a) solve the same problem, and
(b) have none of the limitations.
One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility.
   Nonsense.

   It is incompatible with existing methods like EAP-Message.  Those
*already* have semantics defined.  Changing them by adding a "Chunked
Attribute" is impossible.  The extended format hasn't been deployed, so
compatibility with it is impossible.

   My proposal was to allow *new* attributes to span multiple packets.

   Changing the rules on attribute ordering is impossible.  Don't even try.

   Changing the meaning of existing attributes to allow more than 253
octets of data is impossible.  Don't even try.

   Alan DeKok.
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------060904040002090608040905-- From radext-bounces@ietf.org Mon Jan 16 05:43:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA0021F85E0; Mon, 16 Jan 2012 05:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326721428; bh=SjodB5OpeI13590s20ETHTZlTr8fxB3PmxVHMuFliSU=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=gzb9GiFIyTlsm6ApbasXCBfSj2l/Z/G9ZeEt/WTDRO6QdofgnU7Se33NYFR8XUkN0 46gnkOue60RqMnQVK5g2HA1tkGB45qjW2xhMWAQkJvB61LFdhtjdovQbmrF3eOABi3 NpMAUlufXiG3PWGQoZ0R2BQET/8SpI4DsyEbnIvQ= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007AD21F85DF; Mon, 16 Jan 2012 05:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoqikBLDV8ZL; Mon, 16 Jan 2012 05:43:44 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 1A20D21F8516; Mon, 16 Jan 2012 05:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 2C0304BB19; Mon, 16 Jan 2012 14:43:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id h6gzv1b-c9DN; Mon, 16 Jan 2012 14:43:34 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id ECFCE4BCE7; Mon, 16 Jan 2012 14:43:28 +0100 (CET) Message-ID: <4F142980.6040404@um.es> Date: Mon, 16 Jan 2012 14:43:28 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> In-Reply-To: <4F0ACD9A.4000809@um.es> Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0164943807893577917==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. --===============0164943807893577917== Content-Type: multipart/alternative; boundary="------------060904040002090608040905" This is a multi-part message in MIME format. --------------060904040002090608040905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alan, all, we have been thinking on this topic and we realized that a different approach could be more convenient to handle inter-packet fragmentation than our first proposal. Taking draft-ietf-radext-radius-extensions as a base, we can assume that intra-packet fragmentation is already handled via the M flag. We can also assume that order between fragments is preserved when following draft-ietf-radext-radius-extensions. This may not be true now with the current spec (as Peter pointed out), but we can assume this will be solved somehow in the future (e.g. including offset field). We propose the following: 1) Extended flag attributes are used to fragment big RADIUS attributes, as specified in draft-ietf-radext-radius-extensions. 2) If a fragmented attribute cannot be completely included into the remaining space of a 4KB RADIUS packet, it is truncated, that is, only the fragments that fit into the free space of the packet to be sent are included. It is also included a new RADIUS attribute, called "More-Data-Pending". The presence of this attribute indicates to the receiver that the RADIUS packet is not complete, and more data MUST be received from the sender before processing any of the received attributes. Note that it is possible (and very likely), that the last fragment of a truncated attribute in a RADIUS packet has the M flag set. This case would be against what it is stated in draft-ietf-radext-radius-extensions. Nevertheless, we think this restriction can be easily relaxed when using the more-data-pending attribute. If it is present, it is allowed that the last fragment have the bit M set, which means the attribute is truncated. A good side effect of this is that if a server does not understand more-data-pending and its semantics, a truncated attribute will be shown as an invalid attribute, and not taking the truncated portion as the whole. The rest of the attribute fragments will be sent in successive packets, following the same procedure, using as many RADIUS packets as needed to transmit the required information. Let me illustrate this with an example, where a RADIUS client sends a packet with a size > 4 KB (to make it simpler, we assume each RADIUS packet can include 8 RADIUS attributes/fragments, instead of using bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate successive fragments of the attribute Data. The RADIUS client wants to send the following RADIUS packet: Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3 As only 8 attributes can be included in the packet, the RADIUS client truncates "Data" to fit into the packet, and includes the More-Data-Pending attribute: Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], More-Data-Pending When the server receives the RADIUS packet containing the More-Data-Pending attribute, the processing of the packet is left until all the pending data is received. The pending data is requested by means of an Access-Challenge packet, using the State attribute to tie together this response with the subsequent request from the client. Access-Challenge1 = State1 The client continues sending the data until another RADIUS packet is completed, including again the attribute More-Data-Pending Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], More-Data-Pending The server stores the attributes into the state associated to State1 and replies: Access-Challenge1 = State2 Finally, the client sends the last fragments of the original packet: Access-Request3 = State2, Other2[M], Other3 The server now can process the totality of the received attributes as if they all had been received into a single RADIUS packet of more than 4 KB The case where the server sends a fragmented packet to the client is very similar and makes no sense to expli Best regards, Alejandro El 09/01/12 12:20, Alejandro Perez Mendez escribió: > Hi Alan, > > thanks for the clarifications and hints. We will think about them and > their implications, and try to modify the proposal to make it address > all the requirements. > > Regards, > Alejandro > > El 09/01/12 10:58, Alan DeKok escribió: >> DIEGO LOPEZ GARCIA wrote: >>> Ordering constraints here are applied to related attributes. >> RADIUS doesn't work that way. >> >> There are hundreds of thousands of deployments which assume that >> ordering constraints do NOT apply to related attributes. Changing such >> a fundamental part of the protocol is impossible. >> >>> I don't see why this would go beyond the requirements imposed by the >>> current document on extended attributes, as the recent discussion on >>> it shows. >> I pointed you to RFC 2865, and explained why that restriction is >> impossible. Please go read those messages again. >> >>> It relies in the usage of an specific attribute that defines the >>> interpretation of the values of another attribute. Ordering rules >>> probably could be relaxed, but at the price of more complicated >>> processing rules. >> It relies on behavior which is mandated as NOT being part of RADIUS. >> >>>> I gave comments on your approach. Do you have any comments on my >>>> proposed alternative? It would seem to (a) solve the same problem, >>>> and >>>> (b) have none of the limitations. >>> One of the main goals of the proposal was to be compatible with >>> current mechanisms for attribute encoding inside the packet >>> (EAP-style, extended attributes…) and deal only with values spanning >>> more than one packet. Using your alternative would break this >>> compatibility. >> Nonsense. >> >> It is incompatible with existing methods like EAP-Message. Those >> *already* have semantics defined. Changing them by adding a "Chunked >> Attribute" is impossible. The extended format hasn't been deployed, so >> compatibility with it is impossible. >> >> My proposal was to allow *new* attributes to span multiple packets. >> >> Changing the rules on attribute ordering is impossible. Don't >> even try. >> >> Changing the meaning of existing attributes to allow more than 253 >> octets of data is impossible. Don't even try. >> >> Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------060904040002090608040905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Alan, all,

we have been thinking on this topic and we realized that a different approach could be more convenient to handle inter-packet fragmentation than our first proposal.

Taking draft-ietf-radext-radius-extensions as a base, we can assume that intra-packet fragmentation is already handled via the M flag. We can also assume that order between fragments is preserved when following draft-ietf-radext-radius-extensions. This may not be true now with the current spec (as Peter pointed out), but we can assume this will be solved somehow in the future (e.g. including offset field).

We propose the following:
1) Extended flag attributes are used to fragment big RADIUS attributes, as specified in draft-ietf-radext-radius-extensions.
2) If a fragmented attribute cannot be completely included into the remaining space of a 4KB RADIUS packet, it is truncated, that is, only the fragments that fit into the free space of the packet to be sent are included. It is also included a new RADIUS attribute, called "More-Data-Pending". The presence of this attribute indicates to the receiver that the RADIUS packet is not complete, and more data MUST be received from the sender before processing any of the received attributes.

Note that it is possible (and very likely), that the last fragment of a truncated attribute in a RADIUS packet has the M flag set. This case would be against what it is stated in draft-ietf-radext-radius-extensions. Nevertheless, we think this restriction can be easily relaxed when using the more-data-pending attribute. If it is present, it is allowed that the last fragment have the bit M set, which means the attribute is truncated. A good side effect of this is that if a  server does not understand more-data-pending and its semantics, a truncated attribute will be shown as an invalid attribute, and not taking the truncated portion as the whole.

The rest of the attribute fragments will be sent in successive packets, following the same procedure, using as many RADIUS packets as needed to transmit the required information.

Let me illustrate this with an example, where a RADIUS client sends a packet with a size > 4 KB (to make it simpler, we assume each RADIUS packet can include 8 RADIUS attributes/fragments, instead of using bytes). Flag M is indicated as [M]. Data1, Data2, Data3... indicate successive fragments of the attribute Data.

The RADIUS client wants to send the following RADIUS packet:

Access-Request = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], Other2[M], Other3


As only 8 attributes can be included in the packet, the RADIUS client truncates "Data" to fit into the packet, and includes the More-Data-Pending attribute:

Acess-Request1 = User-Name, Calling-Station-Id, Data1[M], Data2[M], Data3[M], Data4[M], Data5[M], More-Data-Pending

When the server receives the RADIUS packet containing the More-Data-Pending attribute, the processing of the packet is left until all the pending data is received. The pending data is requested by means of an Access-Challenge packet, using the State attribute to tie together this response with the subsequent request from the client.

Access-Challenge1 = State1

The client continues sending the data until another RADIUS packet is completed, including again the attribute More-Data-Pending

Acess-Request2 = State1, Data6[M], Data7[M], Data8[M], Data9[M], Data10, Other1[M], More-Data-Pending


The server stores the attributes into the state associated to State1 and replies:

Access-Challenge1 = State2

Finally, the client sends the last fragments of the original packet:

Access-Request3 = State2, Other2[M], Other3

The server now can process the totality of the received attributes as if they all had been received into a single RADIUS packet of more than 4 KB

The case where the server sends a fragmented packet to the client is very similar and makes no sense to expli

Best regards,
Alejandro

El 09/01/12 12:20, Alejandro Perez Mendez escribió:
Hi Alan,

thanks for the clarifications and hints. We will think about them and their implications, and try to modify the proposal to make it address all the requirements.

Regards,
Alejandro

El 09/01/12 10:58, Alan DeKok escribió:
DIEGO LOPEZ GARCIA wrote:
Ordering constraints here are applied to related attributes.
   RADIUS doesn't work that way.

   There are hundreds of thousands of deployments which assume that
ordering constraints do NOT apply to related attributes.  Changing such
a fundamental part of the protocol is impossible.

I don't see why this would go beyond the requirements imposed by the current document on extended attributes, as the recent discussion on it shows.
   I pointed you to RFC 2865, and explained why that restriction is
impossible.  Please go read those messages again.

It relies in the usage of an specific attribute that defines the interpretation of the values of another attribute. Ordering rules probably could be relaxed, but at the price of more complicated processing rules.
   It relies on behavior which is mandated as NOT being part of RADIUS.

I gave comments on your approach.  Do you have any comments on my
proposed alternative?  It would seem to (a) solve the same problem, and
(b) have none of the limitations.
One of the main goals of the proposal was to be compatible with current mechanisms for attribute encoding inside the packet (EAP-style, extended attributes…) and deal only with values spanning more than one packet. Using your alternative would break this compatibility.
   Nonsense.

   It is incompatible with existing methods like EAP-Message.  Those
*already* have semantics defined.  Changing them by adding a "Chunked
Attribute" is impossible.  The extended format hasn't been deployed, so
compatibility with it is impossible.

   My proposal was to allow *new* attributes to span multiple packets.

   Changing the rules on attribute ordering is impossible.  Don't even try.

   Changing the meaning of existing attributes to allow more than 253
octets of data is impossible.  Don't even try.

   Alan DeKok.
_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab
--------------060904040002090608040905-- --===============0164943807893577917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0164943807893577917==-- From aland@deployingradius.com Mon Jan 16 06:24:55 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182021F8582; Mon, 16 Jan 2012 06:24:55 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh5fvUvCIwn1; Mon, 16 Jan 2012 06:24:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1B321F844F; Mon, 16 Jan 2012 06:24:54 -0800 (PST) Message-ID: <4F143317.3010300@deployingradius.com> Date: Mon, 16 Jan 2012 15:24:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> In-Reply-To: <4F142980.6040404@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:24:55 -0000 Alejandro Perez Mendez wrote: > We propose the following: > 1) Extended flag attributes are used to fragment big RADIUS attributes, > as specified in draft-ietf-radext-radius-extensions. That should be possible. > 2) If a fragmented attribute cannot be completely included into the > remaining space of a 4KB RADIUS packet, it is truncated, that is, only > the fragments that fit into the free space of the packet to be sent are > included. It is also included a new RADIUS attribute, called > "More-Data-Pending". The presence of this attribute indicates to the > receiver that the RADIUS packet is not complete, and more data MUST be > received from the sender before processing any of the received attributes. I've had similar discussions with people off-list. > Note that it is possible (and very likely), that the last fragment of a > truncated attribute in a RADIUS packet has the M flag set. This case > would be against what it is stated in > draft-ietf-radext-radius-extensions. Nevertheless, we think this > restriction can be easily relaxed when using the more-data-pending > attribute. If it is present, it is allowed that the last fragment have > the bit M set, which means the attribute is truncated. A good side > effect of this is that if a server does not understand > more-data-pending and its semantics, a truncated attribute will be shown > as an invalid attribute, and not taking the truncated portion as the whole. I'm wary of that, but it's a good start. There may be additional minor fixes which could make the fragmentation explicit rather than implicit. I think this proposal would require a new document at minimum. The document would discuss how to implement the above proposal. That means that others could use this specification, even if they don't need attributes longer than 4K. A separate document could document the >4K attributes. I'll see if I can write a short proposal to the radext list. If it's acceptable to the WG, I can put a draft together. Alan DeKok. From radext-bounces@ietf.org Mon Jan 16 06:24:57 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9516A21F85CD; Mon, 16 Jan 2012 06:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326723897; bh=CfNK5xj23qxaM8LGSCXhSjaT3j9Chho27aU9GMyklMA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=qQuuPCiSaTVfAxYhr6TUVUCRVEjFlHq/6mdXtpvPd9G5uHPzTLAMp/wDWo07PEZdx XrLDnuHJTULM4GQ+wHYw6FhmL+4CwRIzn1/xxRKP3zedkRLvlM7I8jXTNt6eTME3+q /TGyasxXLj8xjE+D5ezNe3pabPGxf+MwT4/38PUg= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5182021F8582; Mon, 16 Jan 2012 06:24:55 -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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hh5fvUvCIwn1; Mon, 16 Jan 2012 06:24:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1B321F844F; Mon, 16 Jan 2012 06:24:54 -0800 (PST) Message-ID: <4F143317.3010300@deployingradius.com> Date: Mon, 16 Jan 2012 15:24:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> In-Reply-To: <4F142980.6040404@um.es> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alejandro Perez Mendez wrote: > We propose the following: > 1) Extended flag attributes are used to fragment big RADIUS attributes, > as specified in draft-ietf-radext-radius-extensions. That should be possible. > 2) If a fragmented attribute cannot be completely included into the > remaining space of a 4KB RADIUS packet, it is truncated, that is, only > the fragments that fit into the free space of the packet to be sent are > included. It is also included a new RADIUS attribute, called > "More-Data-Pending". The presence of this attribute indicates to the > receiver that the RADIUS packet is not complete, and more data MUST be > received from the sender before processing any of the received attributes. I've had similar discussions with people off-list. > Note that it is possible (and very likely), that the last fragment of a > truncated attribute in a RADIUS packet has the M flag set. This case > would be against what it is stated in > draft-ietf-radext-radius-extensions. Nevertheless, we think this > restriction can be easily relaxed when using the more-data-pending > attribute. If it is present, it is allowed that the last fragment have > the bit M set, which means the attribute is truncated. A good side > effect of this is that if a server does not understand > more-data-pending and its semantics, a truncated attribute will be shown > as an invalid attribute, and not taking the truncated portion as the whole. I'm wary of that, but it's a good start. There may be additional minor fixes which could make the fragmentation explicit rather than implicit. I think this proposal would require a new document at minimum. The document would discuss how to implement the above proposal. That means that others could use this specification, even if they don't need attributes longer than 4K. A separate document could document the >4K attributes. I'll see if I can write a short proposal to the radext list. If it's acceptable to the WG, I can put a draft together. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From alex@um.es Mon Jan 16 07:30:31 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6421F861E; Mon, 16 Jan 2012 07:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cZIPKHzUBPZ; Mon, 16 Jan 2012 07:30:31 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8C21F8625; Mon, 16 Jan 2012 07:30:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 34D87535F5; Mon, 16 Jan 2012 16:30:29 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hA61AYNRJv2D; Mon, 16 Jan 2012 16:30:28 +0100 (CET) Received: from [192.168.1.131] (49.247.221.87.dynamic.jazztel.es [87.221.247.49]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id 0E595535F7; Mon, 16 Jan 2012 16:30:22 +0100 (CET) Message-ID: <4F144287.40505@um.es> Date: Mon, 16 Jan 2012 16:30:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> In-Reply-To: <4F143317.3010300@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:30:31 -0000 Hi Alan, > Alejandro Perez Mendez wrote: >> We propose the following: >> 1) Extended flag attributes are used to fragment big RADIUS attributes, >> as specified in draft-ietf-radext-radius-extensions. > That should be possible. > >> 2) If a fragmented attribute cannot be completely included into the >> remaining space of a 4KB RADIUS packet, it is truncated, that is, only >> the fragments that fit into the free space of the packet to be sent are >> included. It is also included a new RADIUS attribute, called >> "More-Data-Pending". The presence of this attribute indicates to the >> receiver that the RADIUS packet is not complete, and more data MUST be >> received from the sender before processing any of the received attributes. > I've had similar discussions with people off-list. that's good >> Note that it is possible (and very likely), that the last fragment of a >> truncated attribute in a RADIUS packet has the M flag set. This case >> would be against what it is stated in >> draft-ietf-radext-radius-extensions. Nevertheless, we think this >> restriction can be easily relaxed when using the more-data-pending >> attribute. If it is present, it is allowed that the last fragment have >> the bit M set, which means the attribute is truncated. A good side >> effect of this is that if a server does not understand >> more-data-pending and its semantics, a truncated attribute will be shown >> as an invalid attribute, and not taking the truncated portion as the whole. > I'm wary of that, but it's a good start. There may be additional > minor fixes which could make the fragmentation explicit rather than > implicit. We also thought that a new flag "T" could indicate the attribute is truncated across several packets. > I think this proposal would require a new document at minimum. The > document would discuss how to implement the above proposal. That means > that others could use this specification, even if they don't need > attributes longer than 4K. Indeed, this proposal is not only for attributes longer than 4K, but to support that an attribute is fragmented across different packets, because the total length of the packet is longer than 4K. That could happen even when the attribute is not very long, but it is placed at the end of the package. > A separate document could document the>4K attributes. IMO support for attributes > 4K is a logic consequence of the fragmentation support given by our proposal. > I'll see if I can write a short proposal to the radext list. If it's > acceptable to the WG, I can put a draft together. Precisely we were about to modify our document to reflect this, if the idea was reasonable. That was the intention of sending it first to the list, to see if there were objections before starting writing a new draft. Regards, Alejandro > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Jan 16 07:30:33 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4ED21F8628; Mon, 16 Jan 2012 07:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326727833; bh=Td7y85i4xGdZzDMNps5xuUAuwqGyb8K1JmuQDFFwPzw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=Rx+AKr2w0EO0uQjMPsymzQyMfAHgQzE7E54EjaZDLcvTzL6jhsa6+e4DBkxcposnL OjOmSA2mJItGmgwwV9tA0LEvOOmC6zjlt8S4rpXat944cSqXhu6Rxh76GBZeoN98fz HSjW2plmCI7iUbJGRppdsd6H8ZRIJPjk4h902UnM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6421F861E; Mon, 16 Jan 2012 07:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cZIPKHzUBPZ; Mon, 16 Jan 2012 07:30:31 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id BCE8C21F8625; Mon, 16 Jan 2012 07:30:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 34D87535F5; Mon, 16 Jan 2012 16:30:29 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hA61AYNRJv2D; Mon, 16 Jan 2012 16:30:28 +0100 (CET) Received: from [192.168.1.131] (49.247.221.87.dynamic.jazztel.es [87.221.247.49]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id 0E595535F7; Mon, 16 Jan 2012 16:30:22 +0100 (CET) Message-ID: <4F144287.40505@um.es> Date: Mon, 16 Jan 2012 16:30:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Alan DeKok References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> In-Reply-To: <4F143317.3010300@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi Alan, > Alejandro Perez Mendez wrote: >> We propose the following: >> 1) Extended flag attributes are used to fragment big RADIUS attributes, >> as specified in draft-ietf-radext-radius-extensions. > That should be possible. > >> 2) If a fragmented attribute cannot be completely included into the >> remaining space of a 4KB RADIUS packet, it is truncated, that is, only >> the fragments that fit into the free space of the packet to be sent are >> included. It is also included a new RADIUS attribute, called >> "More-Data-Pending". The presence of this attribute indicates to the >> receiver that the RADIUS packet is not complete, and more data MUST be >> received from the sender before processing any of the received attributes. > I've had similar discussions with people off-list. that's good >> Note that it is possible (and very likely), that the last fragment of a >> truncated attribute in a RADIUS packet has the M flag set. This case >> would be against what it is stated in >> draft-ietf-radext-radius-extensions. Nevertheless, we think this >> restriction can be easily relaxed when using the more-data-pending >> attribute. If it is present, it is allowed that the last fragment have >> the bit M set, which means the attribute is truncated. A good side >> effect of this is that if a server does not understand >> more-data-pending and its semantics, a truncated attribute will be shown >> as an invalid attribute, and not taking the truncated portion as the whole. > I'm wary of that, but it's a good start. There may be additional > minor fixes which could make the fragmentation explicit rather than > implicit. We also thought that a new flag "T" could indicate the attribute is truncated across several packets. > I think this proposal would require a new document at minimum. The > document would discuss how to implement the above proposal. That means > that others could use this specification, even if they don't need > attributes longer than 4K. Indeed, this proposal is not only for attributes longer than 4K, but to support that an attribute is fragmented across different packets, because the total length of the packet is longer than 4K. That could happen even when the attribute is not very long, but it is placed at the end of the package. > A separate document could document the>4K attributes. IMO support for attributes > 4K is a logic consequence of the fragmentation support given by our proposal. > I'll see if I can write a short proposal to the radext list. If it's > acceptable to the WG, I can put a draft together. Precisely we were about to modify our document to reflect this, if the idea was reasonable. That was the intention of sending it first to the list, to see if there were objections before starting writing a new draft. Regards, Alejandro > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Jan 16 07:39:00 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC23021F867B; Mon, 16 Jan 2012 07:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326728340; bh=wNlIAjIwO1zTC+vsk2Troe3XrT1IyytzJmSTHYE5VzE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=hTf9y5jpYsHJK/IFLptICnfo67f1DtbjWTKLi1I8sUYlSOdZxEHzCc3lTteCeFOn/ ii/Ss72x6InZqnmSkA5N7L+MzfRSyZkrlFTXuHzvIvfUAEzXA/xRzvvk+v7pwZEIQz irNWVJsuJkcak+hBgLeExpYeevmLvNt/MV3AzcL4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7121F867A; Mon, 16 Jan 2012 07:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrsca0vIjMEM; Mon, 16 Jan 2012 07:38:58 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 3D21521F862B; Mon, 16 Jan 2012 07:38:53 -0800 (PST) Received: from mail-vw0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTxREgNIimYhwQFdPeKLOO1C6KWZq/XzA@postini.com; Mon, 16 Jan 2012 07:38:53 PST Received: by mail-vw0-f47.google.com with SMTP id l22so612996vbn.20 for ; Mon, 16 Jan 2012 07:38:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.45 with SMTP id j13mr6155079vdu.115.1326728320554; Mon, 16 Jan 2012 07:38:40 -0800 (PST) Received: by 10.52.26.68 with HTTP; Mon, 16 Jan 2012 07:38:40 -0800 (PST) In-Reply-To: <4F144287.40505@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> Date: Mon, 16 Jan 2012 10:38:40 -0500 Message-ID: From: Dave Nelson To: Alejandro Perez Mendez Cc: "radext@ietf.org" , "abfab@ietf.org" , Alan DeKok Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5895250127997376668==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============5895250127997376668== Content-Type: multipart/alternative; boundary=20cf307f39ac42986204b6a702a3 --20cf307f39ac42986204b6a702a3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez wrote: > > We also thought that a new flag "T" could indicate the attribute is > truncated across several packets. Yeah. I would favor the definition of another flag bit, rather than mixing flags and "signal" attributes to accomplished related purposes. It's just more symmetrical. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf307f39ac42986204b6a702a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = <alex@um.es> wrote:

We also thought that a new flag "T" could indicate the attribute = is truncated across several packets.

Yeah. = =A0I would favor the definition of another flag bit, rather than mixing fla= gs and "signal" attributes to accomplished related purposes. =A0I= t's just more symmetrical.=A0

Regards,

Dave

David B. Nelson
Sr. Software Archi= tect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf307f39ac42986204b6a702a3-- --===============5895250127997376668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============5895250127997376668==-- From dnelson@elbrys.com Mon Jan 16 07:38:59 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C7121F867A; Mon, 16 Jan 2012 07:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrsca0vIjMEM; Mon, 16 Jan 2012 07:38:58 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id 3D21521F862B; Mon, 16 Jan 2012 07:38:53 -0800 (PST) Received: from mail-vw0-f47.google.com ([209.85.212.47]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTxREgNIimYhwQFdPeKLOO1C6KWZq/XzA@postini.com; Mon, 16 Jan 2012 07:38:53 PST Received: by mail-vw0-f47.google.com with SMTP id l22so612996vbn.20 for ; Mon, 16 Jan 2012 07:38:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.45 with SMTP id j13mr6155079vdu.115.1326728320554; Mon, 16 Jan 2012 07:38:40 -0800 (PST) Received: by 10.52.26.68 with HTTP; Mon, 16 Jan 2012 07:38:40 -0800 (PST) In-Reply-To: <4F144287.40505@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> Date: Mon, 16 Jan 2012 10:38:40 -0500 Message-ID: From: Dave Nelson To: Alejandro Perez Mendez Content-Type: multipart/alternative; boundary=20cf307f39ac42986204b6a702a3 Cc: "radext@ietf.org" , "abfab@ietf.org" , Alan DeKok Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:38:59 -0000 --20cf307f39ac42986204b6a702a3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez wrote: > > We also thought that a new flag "T" could indicate the attribute is > truncated across several packets. Yeah. I would favor the definition of another flag bit, rather than mixing flags and "signal" attributes to accomplished related purposes. It's just more symmetrical. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf307f39ac42986204b6a702a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = <alex@um.es> wrote:

We also thought that a new flag "T" could indicate the attribute = is truncated across several packets.

Yeah. = =A0I would favor the definition of another flag bit, rather than mixing fla= gs and "signal" attributes to accomplished related purposes. =A0I= t's just more symmetrical.=A0

Regards,

Dave

David B. Nelson
Sr. Software Archi= tect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf307f39ac42986204b6a702a3-- From aland@deployingradius.com Mon Jan 16 07:40:38 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7721F8680; Mon, 16 Jan 2012 07:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwELwXoBh-T5; Mon, 16 Jan 2012 07:40:38 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 107C621F8606; Mon, 16 Jan 2012 07:40:19 -0800 (PST) Message-ID: <4F1444C7.7010909@deployingradius.com> Date: Mon, 16 Jan 2012 16:39:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> In-Reply-To: <4F144287.40505@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:40:38 -0000 Alejandro Perez Mendez wrote: > We also thought that a new flag "T" could indicate the attribute is > truncated across several packets. That sounds good. > Precisely we were about to modify our document to reflect this, if the > idea was reasonable. That was the intention of sending it first to the > list, to see if there were objections before starting writing a new draft. My notes about this are: - the first Access-Accept must contain Service-Type = Authorize-Only *or* a new Servicer-Type = Additional-Authorization This means that the user is not given network access when the implementation does not support the new method. - the first Access-Accept must contain a State attribute for is already required for use of Authorize-Only - additional authorization attributes are received via a series of Access-Request / Access-Challenge - each Access-Request MUST contain Service-Type = Authorize-Only and a State - the State MUST change for each Access-Challenge response I can get into that later - the final Access-Accept contains the real Service-Type for the user Alan DeKok. From radext-bounces@ietf.org Mon Jan 16 07:40:40 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A671C21F8680; Mon, 16 Jan 2012 07:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326728440; bh=vdd2sgfk3DYgCv7l/Zr/SSfmLi/Gcfaw7DVzbONxdOE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=u5EPNJmoPHqMnv8Dz/to5vUN4ZVtHa5A5qI3aflIznIA/++Xaa10JioRgY0xuYpvC XH+6e25P00EC+BCOQKp/LQXXQQw6t1JKVj5fLQO+jb048Eq5wurQ8bMSGoz2UMvbxV Q5ijsxflyg2HiqIgiloqSZi9j5VZAzgGGIcR6sDA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7721F8680; Mon, 16 Jan 2012 07:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwELwXoBh-T5; Mon, 16 Jan 2012 07:40:38 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 107C621F8606; Mon, 16 Jan 2012 07:40:19 -0800 (PST) Message-ID: <4F1444C7.7010909@deployingradius.com> Date: Mon, 16 Jan 2012 16:39:51 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> In-Reply-To: <4F144287.40505@um.es> X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alejandro Perez Mendez wrote: > We also thought that a new flag "T" could indicate the attribute is > truncated across several packets. That sounds good. > Precisely we were about to modify our document to reflect this, if the > idea was reasonable. That was the intention of sending it first to the > list, to see if there were objections before starting writing a new draft. My notes about this are: - the first Access-Accept must contain Service-Type = Authorize-Only *or* a new Servicer-Type = Additional-Authorization This means that the user is not given network access when the implementation does not support the new method. - the first Access-Accept must contain a State attribute for is already required for use of Authorize-Only - additional authorization attributes are received via a series of Access-Request / Access-Challenge - each Access-Request MUST contain Service-Type = Authorize-Only and a State - the State MUST change for each Access-Challenge response I can get into that later - the final Access-Accept contains the real Service-Type for the user Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From diego@tid.es Mon Jan 16 08:02:17 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6B621F8677; Mon, 16 Jan 2012 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXjOScSiP8Jz; Mon, 16 Jan 2012 08:02:16 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 50F7D21F8602; Mon, 16 Jan 2012 08:02:16 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00G4ZF7REB@tid.hi.inet>; Mon, 16 Jan 2012 17:02:15 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id BC.E6.02643.70A441F4; Mon, 16 Jan 2012 17:02:15 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXW00G4UF7QEB@tid.hi.inet>; Mon, 16 Jan 2012 17:02:15 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 16 Jan 2012 17:02:14 +0100 Date: Mon, 16 Jan 2012 17:02:13 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F1444C7.7010909@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczUaDZFBoHYHcRZT/+RlhFKCOuGJQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-5f-4f144a074421 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsXCFe9nqMvuJeJvsLCDx+Lj9TeMFi2vZrI5 MHksWfKTKYAxissmJTUnsyy1SN8ugSvj7MGX7AVXRCp+3JdsYJwg0sXIySEhYCJxo6eFBcIW k7hwbz1bFyMXh5DANkaJab9uMEE4Txklbl1tZodwGhkl3l3oYgdpYRFQldiw7DQziM0moC7R cvQb2ChhgWyJM3PfsYLYnALGEhf6OsFqRAS0JBasXwRUw8HBLFAoMfWCDkiYV8BSorv7GTOE LSjxY/I9qBJ1iSlTckHCzALiEs2tN1kgbEWJaYsaGEFsRqCjv59awwQxPUfi1IzDbBC2nsTt mZ+YIWpEJe60r2eEeFJAYsme88wQtqjEy8f/wK4UEjjPLDGpQWUCo/gsJFfMQrhiFpIrZiG5 YgEjyypGseKkosz0jJLcxMycdAMjvYxMvcy81JJNjJBYytzBuHynyiFGAQ5GJR7eh4XC/kKs iWXFlbmHGCU5mJREedncRPyF+JLyUyozEosz4otKc1KLDzFKcDArifC26QOV86YkVlalFuXD pGQ4OJQkeFU8gdoEi1LTUyvSMnOACQMmzcTBCdLOA9QeDVLDW1yQmFucmQ6RP8UoKSXO6wWS EABJZJTmwfW+YhQHOlKYNwokywNMbXBdr4AGMgENzGkVAhlYkoiQkmpgrOA3+rfRvr1K6MCE xK+672oKLp7/f8gn5cPrOKN+0dMnI6oVHxSLLnp11znqZa+bi26QnnTq5q2H30q5qf/OvHni k3HNhYiF2nVXQubxfHx8efn6rYrVXda5cW9bHrKmmVuld7x2Z9olvOxMxWPD9LiMT4JZk7m+ NDUY1LjPP7D3VpPrhodRSizFGYmGWsxFxYkAskgsgyoDAAA= References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:02:17 -0000 DQpPbiAxNiBKYW4gMjAxMiwgYXQgMTY6MzkgLCBBbGFuIERlS29rIHdyb3RlOg0KPiBBbGVqYW5k cm8gUGVyZXogTWVuZGV6IHdyb3RlOg0KPj4gV2UgYWxzbyB0aG91Z2h0IHRoYXQgYSBuZXcgZmxh ZyAiVCIgY291bGQgaW5kaWNhdGUgdGhlIGF0dHJpYnV0ZSBpcw0KPj4gdHJ1bmNhdGVkIGFjcm9z cyBzZXZlcmFsIHBhY2tldHMuDQo+DQo+ICBUaGF0IHNvdW5kcyBnb29kLg0KDQpBcGFydCB0aGF0 IEkgdGhpbmsgaXQgd291bGQgbWFrZSB0aGUgbWVjaGFuaXNtcyBzaW1wbGVyIHRvIGRlYWwgd2l0 aCwgSSBtdXN0IHNheSBJIGxpa2UgRGF2ZSdzIHN5bW1ldHJ5IGFyZ3VtZW50IGZvciB0aGUgIlQi IGZsYWcuDQoNCj4gLSB0aGUgZmlyc3QgQWNjZXNzLUFjY2VwdCBtdXN0IGNvbnRhaW4gU2Vydmlj ZS1UeXBlID0gQXV0aG9yaXplLU9ubHkNCj4gICpvciogYSBuZXcgU2VydmljZXItVHlwZSA9IEFk ZGl0aW9uYWwtQXV0aG9yaXphdGlvbg0KPg0KPiAgVGhpcyBtZWFucyB0aGF0IHRoZSB1c2VyIGlz IG5vdCBnaXZlbiBuZXR3b3JrIGFjY2VzcyB3aGVuIHRoZQ0KPiAgaW1wbGVtZW50YXRpb24gZG9l cyBub3Qgc3VwcG9ydCB0aGUgbmV3IG1ldGhvZC4NCg0KSW4gdGhlIHNhbWUgc3Bpcml0IG9mIGtl ZXBpbmcgY2xhcml0eSwgSSdkIHNheSB0aGF0IEFkZGl0aW9uYWwtQXV0aG9yaXphdGlvbiB3b3Vs ZCBiZSBtb3JlIGNvcnJlY3QgY2hvaWNlLCB1bmxlc3MgYWRkaW5nIGEgbmV3IFNlcnZpY2UtVHlw ZSB3b3VsZCBzb21laG93IGNvbXBsaWNhdGUgYWRvcHRpb24uLi4NCg0KPiAtIHRoZSBmaXJzdCBB Y2Nlc3MtQWNjZXB0IG11c3QgY29udGFpbiBhIFN0YXRlIGF0dHJpYnV0ZQ0KPiAgZm9yIGlzIGFs cmVhZHkgcmVxdWlyZWQgZm9yIHVzZSBvZiBBdXRob3JpemUtT25seQ0KPg0KPiAtIGFkZGl0aW9u YWwgYXV0aG9yaXphdGlvbiBhdHRyaWJ1dGVzIGFyZSByZWNlaXZlZCB2aWEgYSBzZXJpZXMNCj4g IG9mIEFjY2Vzcy1SZXF1ZXN0IC8gQWNjZXNzLUNoYWxsZW5nZQ0KPg0KPiAgLSBlYWNoIEFjY2Vz cy1SZXF1ZXN0IE1VU1QgY29udGFpbiBTZXJ2aWNlLVR5cGUgPSBBdXRob3JpemUtT25seQ0KPiAg ICBhbmQgYSBTdGF0ZQ0KDQpPciwgcmVzcGVjdGl2ZWx5LCBBZGRpdGlvbmFsLUF1dGhvcml6YXRp b24sIGlzbid0IGl0Pw0KDQo+ICAtIHRoZSBTdGF0ZSBNVVNUIGNoYW5nZSBmb3IgZWFjaCBBY2Nl c3MtQ2hhbGxlbmdlIHJlc3BvbnNlDQo+ICAgIEkgY2FuIGdldCBpbnRvIHRoYXQgbGF0ZXINCg0K SSBjYW4gaW1hZ2luZSB0aGlzIGlzIHdpdGggdGhlIGludGVudGlvbiBvZiBndWFyYW50ZWVpbmcg b3JkZXIgYW5kIGF2b2lkaW5nIChvciBhbGxldmlhdGluZykgTUlUTSBhdHRhY2tzLCByaWdodD8N Cg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmll cm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCg0KZS1tYWlsOiBkaWVn b0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5 MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1l bnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBj b25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3Jy ZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From radext-bounces@ietf.org Mon Jan 16 08:02:20 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDEC21F8691; Mon, 16 Jan 2012 08:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326729740; bh=C/xHCeuAHweuLn+lWpCYX6mxwnRFICHCcoWTJo+9Obg=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=N2E4e0kynstaISWlwgRoBOPvyw4w2Uf4ekjfhGBtec+YljQYmBLWIwrYNiwJGHo6P wck0G1/UfvW8BiZt1DMqlgxGM9T8rWXfTmyJsfNWD7t/LvaYQNO3cM6HYI1ydziRW/ gTRgNbplQaKKObncLNmmorCdsQNq+BHxLbx+WkTM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6B621F8677; Mon, 16 Jan 2012 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.368 X-Spam-Level: X-Spam-Status: No, score=-5.368 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXjOScSiP8Jz; Mon, 16 Jan 2012 08:02:16 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 50F7D21F8602; Mon, 16 Jan 2012 08:02:16 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00G4ZF7REB@tid.hi.inet>; Mon, 16 Jan 2012 17:02:15 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id BC.E6.02643.70A441F4; Mon, 16 Jan 2012 17:02:15 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LXW00G4UF7QEB@tid.hi.inet>; Mon, 16 Jan 2012 17:02:15 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 16 Jan 2012 17:02:14 +0100 Date: Mon, 16 Jan 2012 17:02:13 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <4F1444C7.7010909@deployingradius.com> To: Alan DeKok Message-id: MIME-version: 1.0 Content-language: en-US Accept-Language: en-US Thread-topic: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt Thread-index: AczUaDZFBoHYHcRZT/+RlhFKCOuGJQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-5f-4f144a074421 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsXCFe9nqMvuJeJvsLCDx+Lj9TeMFi2vZrI5 MHksWfKTKYAxissmJTUnsyy1SN8ugSvj7MGX7AVXRCp+3JdsYJwg0sXIySEhYCJxo6eFBcIW k7hwbz1bFyMXh5DANkaJab9uMEE4Txklbl1tZodwGhkl3l3oYgdpYRFQldiw7DQziM0moC7R cvQb2ChhgWyJM3PfsYLYnALGEhf6OsFqRAS0JBasXwRUw8HBLFAoMfWCDkiYV8BSorv7GTOE LSjxY/I9qBJ1iSlTckHCzALiEs2tN1kgbEWJaYsaGEFsRqCjv59awwQxPUfi1IzDbBC2nsTt mZ+YIWpEJe60r2eEeFJAYsme88wQtqjEy8f/wK4UEjjPLDGpQWUCo/gsJFfMQrhiFpIrZiG5 YgEjyypGseKkosz0jJLcxMycdAMjvYxMvcy81JJNjJBYytzBuHynyiFGAQ5GJR7eh4XC/kKs iWXFlbmHGCU5mJREedncRPyF+JLyUyozEosz4otKc1KLDzFKcDArifC26QOV86YkVlalFuXD pGQ4OJQkeFU8gdoEi1LTUyvSMnOACQMmzcTBCdLOA9QeDVLDW1yQmFucmQ6RP8UoKSXO6wWS EABJZJTmwfW+YhQHOlKYNwokywNMbXBdr4AGMgENzGkVAhlYkoiQkmpgrOA3+rfRvr1K6MCE xK+672oKLp7/f8gn5cPrOKN+0dMnI6oVHxSLLnp11znqZa+bi26QnnTq5q2H30q5qf/OvHni k3HNhYiF2nVXQubxfHx8efn6rYrVXda5cW9bHrKmmVuld7x2Z9olvOxMxWPD9LiMT4JZk7m+ NDUY1LjPP7D3VpPrhodRSizFGYmGWsxFxYkAskgsgyoDAAA= References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org DQpPbiAxNiBKYW4gMjAxMiwgYXQgMTY6MzkgLCBBbGFuIERlS29rIHdyb3RlOg0KPiBBbGVqYW5k cm8gUGVyZXogTWVuZGV6IHdyb3RlOg0KPj4gV2UgYWxzbyB0aG91Z2h0IHRoYXQgYSBuZXcgZmxh ZyAiVCIgY291bGQgaW5kaWNhdGUgdGhlIGF0dHJpYnV0ZSBpcw0KPj4gdHJ1bmNhdGVkIGFjcm9z cyBzZXZlcmFsIHBhY2tldHMuDQo+DQo+ICBUaGF0IHNvdW5kcyBnb29kLg0KDQpBcGFydCB0aGF0 IEkgdGhpbmsgaXQgd291bGQgbWFrZSB0aGUgbWVjaGFuaXNtcyBzaW1wbGVyIHRvIGRlYWwgd2l0 aCwgSSBtdXN0IHNheSBJIGxpa2UgRGF2ZSdzIHN5bW1ldHJ5IGFyZ3VtZW50IGZvciB0aGUgIlQi IGZsYWcuDQoNCj4gLSB0aGUgZmlyc3QgQWNjZXNzLUFjY2VwdCBtdXN0IGNvbnRhaW4gU2Vydmlj ZS1UeXBlID0gQXV0aG9yaXplLU9ubHkNCj4gICpvciogYSBuZXcgU2VydmljZXItVHlwZSA9IEFk ZGl0aW9uYWwtQXV0aG9yaXphdGlvbg0KPg0KPiAgVGhpcyBtZWFucyB0aGF0IHRoZSB1c2VyIGlz IG5vdCBnaXZlbiBuZXR3b3JrIGFjY2VzcyB3aGVuIHRoZQ0KPiAgaW1wbGVtZW50YXRpb24gZG9l cyBub3Qgc3VwcG9ydCB0aGUgbmV3IG1ldGhvZC4NCg0KSW4gdGhlIHNhbWUgc3Bpcml0IG9mIGtl ZXBpbmcgY2xhcml0eSwgSSdkIHNheSB0aGF0IEFkZGl0aW9uYWwtQXV0aG9yaXphdGlvbiB3b3Vs ZCBiZSBtb3JlIGNvcnJlY3QgY2hvaWNlLCB1bmxlc3MgYWRkaW5nIGEgbmV3IFNlcnZpY2UtVHlw ZSB3b3VsZCBzb21laG93IGNvbXBsaWNhdGUgYWRvcHRpb24uLi4NCg0KPiAtIHRoZSBmaXJzdCBB Y2Nlc3MtQWNjZXB0IG11c3QgY29udGFpbiBhIFN0YXRlIGF0dHJpYnV0ZQ0KPiAgZm9yIGlzIGFs cmVhZHkgcmVxdWlyZWQgZm9yIHVzZSBvZiBBdXRob3JpemUtT25seQ0KPg0KPiAtIGFkZGl0aW9u YWwgYXV0aG9yaXphdGlvbiBhdHRyaWJ1dGVzIGFyZSByZWNlaXZlZCB2aWEgYSBzZXJpZXMNCj4g IG9mIEFjY2Vzcy1SZXF1ZXN0IC8gQWNjZXNzLUNoYWxsZW5nZQ0KPg0KPiAgLSBlYWNoIEFjY2Vz cy1SZXF1ZXN0IE1VU1QgY29udGFpbiBTZXJ2aWNlLVR5cGUgPSBBdXRob3JpemUtT25seQ0KPiAg ICBhbmQgYSBTdGF0ZQ0KDQpPciwgcmVzcGVjdGl2ZWx5LCBBZGRpdGlvbmFsLUF1dGhvcml6YXRp b24sIGlzbid0IGl0Pw0KDQo+ICAtIHRoZSBTdGF0ZSBNVVNUIGNoYW5nZSBmb3IgZWFjaCBBY2Nl c3MtQ2hhbGxlbmdlIHJlc3BvbnNlDQo+ICAgIEkgY2FuIGdldCBpbnRvIHRoYXQgbGF0ZXINCg0K SSBjYW4gaW1hZ2luZSB0aGlzIGlzIHdpdGggdGhlIGludGVudGlvbiBvZiBndWFyYW50ZWVpbmcg b3JkZXIgYW5kIGF2b2lkaW5nIChvciBhbGxldmlhdGluZykgTUlUTSBhdHRhY2tzLCByaWdodD8N Cg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmll cm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCg0KZS1tYWlsOiBkaWVn b0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5 MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1l bnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBj b25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3Jy ZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpyYWRleHQgbWFpbGluZyBs aXN0CnJhZGV4dEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JhZGV4dAo= From aland@deployingradius.com Mon Jan 16 08:11:43 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF32D21F8508; Mon, 16 Jan 2012 08:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2FYGeuKAWOC; Mon, 16 Jan 2012 08:11:43 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0902321F84FA; Mon, 16 Jan 2012 08:11:43 -0800 (PST) Message-ID: <4F144C22.40103@deployingradius.com> Date: Mon, 16 Jan 2012 17:11:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:11:43 -0000 DIEGO LOPEZ GARCIA wrote:> > In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption... I agree. >> - each Access-Request MUST contain Service-Type = Authorize-Only >> and a State > > Or, respectively, Additional-Authorization, isn't it? The Access-Challenge should contain Additional-Authorization. The request should probably contain Authorize-Only. >> - the State MUST change for each Access-Challenge response >> I can get into that later > > I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right? It's a way to guarantee ordering. I'm not sure if MITM attacks are anything we care about. Every entity in the AAA system is trusted, and the packets are signed to prevent non-AAA systems from modifying them.. Alan DeKok. From radext-bounces@ietf.org Mon Jan 16 08:11:46 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0F21F85BB; Mon, 16 Jan 2012 08:11:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326730306; bh=TboL42N3eZKI663Gyc7Tn3mFemXQCBIJCBihx6LDvBE=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Bf/ljCzcYGzyI4Yf6IBQYXGtXXac3Dg9k7nFnKFNs9EoS/H6J8wuwUbm9qPwDCUda 7n8m35q97HE/WVjKHS0tkI85kMHGiBgYE0I8FMAqEw6175v3tFdD1INIv61p3UQWfu nk82gkGA0WFMysVADtY8/gmIUUTs/zanpRchRBY0= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF32D21F8508; Mon, 16 Jan 2012 08:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2FYGeuKAWOC; Mon, 16 Jan 2012 08:11:43 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0902321F84FA; Mon, 16 Jan 2012 08:11:43 -0800 (PST) Message-ID: <4F144C22.40103@deployingradius.com> Date: Mon, 16 Jan 2012 17:11:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org DIEGO LOPEZ GARCIA wrote:> > In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption... I agree. >> - each Access-Request MUST contain Service-Type = Authorize-Only >> and a State > > Or, respectively, Additional-Authorization, isn't it? The Access-Challenge should contain Additional-Authorization. The request should probably contain Authorize-Only. >> - the State MUST change for each Access-Challenge response >> I can get into that later > > I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right? It's a way to guarantee ordering. I'm not sure if MITM attacks are anything we care about. Every entity in the AAA system is trusted, and the packets are signed to prevent non-AAA systems from modifying them.. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From arran.cudbard-bell@mancalanetworks.com Mon Jan 16 08:23:17 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0321F8690; Mon, 16 Jan 2012 08:23:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIrMRVEZRZOP; Mon, 16 Jan 2012 08:23:17 -0800 (PST) Received: from mail.mancalanetworks.com (mail.mancalanetworks.com [46.105.178.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4091E21F868C; Mon, 16 Jan 2012 08:23:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mancalanetworks.com (Postfix) with ESMTP id 318F31E2FA54; Mon, 16 Jan 2012 17:23:15 +0100 (CET) X-Virus-Scanned: amavisd-new at mancalanetworks.com Received: from mail.mancalanetworks.com ([127.0.0.1]) by localhost (mail.mancalanetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-9G9fsInQdF; Mon, 16 Jan 2012 17:23:14 +0100 (CET) Received: from [10.10.0.108] (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by mail.mancalanetworks.com (Postfix) with ESMTPSA id 05A6D1E2E4F5; Mon, 16 Jan 2012 17:23:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Arran Cudbard-Bell In-Reply-To: Date: Mon, 16 Jan 2012 17:23:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> To: DIEGO LOPEZ GARCIA X-Mailer: Apple Mail (2.1251.1) Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez , Alan DeKok Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 16:23:18 -0000 > In the same spirit of keeping clarity, I'd say that = Additional-Authorization would be more correct choice, unless adding a = new Service-Type would somehow complicate adoption... Agreed. >=20 >> - the first Access-Accept must contain a State attribute >> for is already required for use of Authorize-Only >>=20 >> - additional authorization attributes are received via a series >> of Access-Request / Access-Challenge >>=20 >> - each Access-Request MUST contain Service-Type =3D Authorize-Only >> and a State >=20 > Or, respectively, Additional-Authorization, isn't it? No it's an extension/reworking of the concept described in RFC 3576 3.1, = but the trigger is an Access-Accept packet with the = Service-Type/Additional-Authorization attribute. >=20 >> - the State MUST change for each Access-Challenge response >> I can get into that later >=20 > I can imagine this is with the intention of guaranteeing order and = avoiding (or alleviating) MITM attacks, right? Yes, correct. The packets don't contain any explicit ordering = information, so the attributes are just concatenated together in the = order they're received. -Arran= From radext-bounces@ietf.org Mon Jan 16 08:23:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138D21F8690; Mon, 16 Jan 2012 08:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326730999; bh=TU0CSAkHyejL9wPqg+/2/ZNtUT1Ds5xaZy+VOhUHK9Q=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Yjzs/0CK80N/wyMHZXMwsAhvyozQ8IHOWQYxDd9GP6UazzcL+/I1Nm+wBAXEbjnbv yE5E7PkhvHWTsQ0ISAAPeqzvimUBvx0S/ovNQHfGS4Lbro6aDR1DkYFzB/PO4KL4Z3 /cefaonITsG45MBwwIq5/UjBeshYrkneDOcR3p60= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0321F8690; Mon, 16 Jan 2012 08:23:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIrMRVEZRZOP; Mon, 16 Jan 2012 08:23:17 -0800 (PST) Received: from mail.mancalanetworks.com (mail.mancalanetworks.com [46.105.178.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4091E21F868C; Mon, 16 Jan 2012 08:23:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.mancalanetworks.com (Postfix) with ESMTP id 318F31E2FA54; Mon, 16 Jan 2012 17:23:15 +0100 (CET) X-Virus-Scanned: amavisd-new at mancalanetworks.com Received: from mail.mancalanetworks.com ([127.0.0.1]) by localhost (mail.mancalanetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-9G9fsInQdF; Mon, 16 Jan 2012 17:23:14 +0100 (CET) Received: from [10.10.0.108] (mey38-2-82-228-181-7.fbx.proxad.net [82.228.181.7]) by mail.mancalanetworks.com (Postfix) with ESMTPSA id 05A6D1E2E4F5; Mon, 16 Jan 2012 17:23:13 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) From: Arran Cudbard-Bell In-Reply-To: Date: Mon, 16 Jan 2012 17:23:13 +0100 Message-Id: References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> <4F1444C7.7010909@deployingradius.com> To: DIEGO LOPEZ GARCIA X-Mailer: Apple Mail (2.1251.1) Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez , Alan DeKok Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org > In the same spirit of keeping clarity, I'd say that Additional-Authorization would be more correct choice, unless adding a new Service-Type would somehow complicate adoption... Agreed. > >> - the first Access-Accept must contain a State attribute >> for is already required for use of Authorize-Only >> >> - additional authorization attributes are received via a series >> of Access-Request / Access-Challenge >> >> - each Access-Request MUST contain Service-Type = Authorize-Only >> and a State > > Or, respectively, Additional-Authorization, isn't it? No it's an extension/reworking of the concept described in RFC 3576 3.1, but the trigger is an Access-Accept packet with the Service-Type/Additional-Authorization attribute. > >> - the State MUST change for each Access-Challenge response >> I can get into that later > > I can imagine this is with the intention of guaranteeing order and avoiding (or alleviating) MITM attacks, right? Yes, correct. The packets don't contain any explicit ordering information, so the attributes are just concatenated together in the order they're received. -Arran _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From rafa@um.es Mon Jan 16 11:04:29 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55E921F86B8; Mon, 16 Jan 2012 11:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N09NgAnpHTDd; Mon, 16 Jan 2012 11:04:29 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 994B421F86AF; Mon, 16 Jan 2012 11:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 3FCF95D48E; Mon, 16 Jan 2012 20:04:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vYe4fcnyybrd; Mon, 16 Jan 2012 20:04:25 +0100 (CET) Received: from inf-205-13.inf.um.es (inf-205-13.inf.um.es [155.54.205.13]) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPA id 4CF5F5D51C; Mon, 16 Jan 2012 20:04:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F" From: Rafa Marin Lopez In-Reply-To: Date: Mon, 16 Jan 2012 20:04:19 +0100 Message-Id: <67333C97-D1A5-4C81-817C-94BC0766A81B@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> To: Dave Nelson X-Mailer: Apple Mail (2.1251.1) Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez , Rafa Marin Lopez Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 19:04:30 -0000 --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Dave: El 16/01/2012, a las 16:38, Dave Nelson escribi=F3: > On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = wrote: >=20 > We also thought that a new flag "T" could indicate the attribute is = truncated across several packets. >=20 > Yeah. I would favor the definition of another flag bit, rather than = mixing flags and "signal" attributes to accomplished related purposes. = It's just more symmetrical.=20 Just a clarification here. Our goal (authors of = draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism = for fragmentation between RADIUS packets when they exceed 4K = (inter-packet fragmentation). If we remove the signal attribute (e.g. = "More-Data-Pending"), the flag T should mean that the RADIUS packet is = truncated (and not necessarily the attribute where the flag T is = activated). For example:=20 A,B,C,... ,Y are attributes of different types in one RADIUS packet. = Adding attribute Z exceeds 4K, so we should signal that. We could decide = to activate the bit T in the last attribute Y[T], but, actually, it does = not mean anything in the context of extended attribute Y[T], since we = want to signal that more attributes (perhaps, of any other type as, for = example, Z) are coming after this list in a different RADIUS packet. In this sense, we believe that the presence of some kind of attribute = "More-Data-Pending" (or any other type of signaling at packet level) can = inform about this situation within the context of the RADIUS packet.=20 Best regards. >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Dave:

El 16/01/2012, a las 16:38, Dave Nelson = escribi=F3:

On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = <alex@um.es> wrote:

We also thought that a new flag "T" could indicate the attribute is = truncated across several packets.

Yeah. =  I would favor the definition of another flag bit, rather than = mixing flags and "signal" attributes to accomplished related purposes. =  It's just more = symmetrical. 

Just a = clarification here. Our goal (authors of = draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism = for fragmentation between RADIUS packets when they exceed 4K = (inter-packet fragmentation). If we remove the signal attribute = (e.g. "More-Data-Pending"), the flag T should mean that the RADIUS = packet is truncated (and not necessarily the attribute where the flag T = is activated). For = example: 

A,B,C,... ,Y are attributes of = different types in one RADIUS packet. Adding attribute Z exceeds 4K, so = we should signal that. We could decide to activate the bit T in the last = attribute Y[T], but, actually, it does not mean anything in the context = of extended attribute Y[T], since we want to signal that more attributes = (perhaps, of any other type as, for example, Z) are coming after this = list in a different RADIUS packet.

In this = sense, we believe that the presence of some kind of attribute = "More-Data-Pending" (or any other type of signaling at packet level) can = inform about this situation within the context of the RADIUS = packet. 

Best = regards.


Regards,

Dave

David B. Nelson
Sr. Software = Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

-------------------------------------------------------
<= div>Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------= ---------------------------------




= --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F-- From radext-bounces@ietf.org Mon Jan 16 11:04:31 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7EE21F86C4; Mon, 16 Jan 2012 11:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326740671; bh=4SF5xpYkyOtiKRyJ0B1dKv0396o4RZZe3NirbiwCkng=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=MsZuQqSKo9cIRu1MEg4Z2AAFRf5Gs+tyLGQJ3ew0X9bm5kNgeTE7udKr6VvCZZ5pY NtVUs/WFqTQSsYCids9FPTbmd1D24fyWGOP3UM0c9p9DJhpkvGRcaRhEDG7ior+SK1 YvQHhH+/lJsHn3QZDMtQ8gEtn7Cr9sQwVnuFOTTM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55E921F86B8; Mon, 16 Jan 2012 11:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N09NgAnpHTDd; Mon, 16 Jan 2012 11:04:29 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 994B421F86AF; Mon, 16 Jan 2012 11:04:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 3FCF95D48E; Mon, 16 Jan 2012 20:04:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vYe4fcnyybrd; Mon, 16 Jan 2012 20:04:25 +0100 (CET) Received: from inf-205-13.inf.um.es (inf-205-13.inf.um.es [155.54.205.13]) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPA id 4CF5F5D51C; Mon, 16 Jan 2012 20:04:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) From: Rafa Marin Lopez In-Reply-To: Date: Mon, 16 Jan 2012 20:04:19 +0100 Message-Id: <67333C97-D1A5-4C81-817C-94BC0766A81B@um.es> References: <20120104092153.18453.7518.idtracker@ietfa.amsl.com> <4F041D09.2060905@um.es> <4F045FE2.8070804@deployingradius.com> <4F05CA5A.2030602@deployingradius.com> <4F0ABA62.3040008@deployingradius.com> <4F0ACD9A.4000809@um.es> <4F142980.6040404@um.es> <4F143317.3010300@deployingradius.com> <4F144287.40505@um.es> To: Dave Nelson X-Mailer: Apple Mail (2.1251.1) Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez , Rafa Marin Lopez Subject: Re: [radext] [abfab] New Version Notification for draft-perez-radext-radius-fragmentation-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0446435673677310029==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============0446435673677310029== Content-Type: multipart/alternative; boundary="Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F" --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Dave: El 16/01/2012, a las 16:38, Dave Nelson escribi=F3: > On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = wrote: >=20 > We also thought that a new flag "T" could indicate the attribute is = truncated across several packets. >=20 > Yeah. I would favor the definition of another flag bit, rather than = mixing flags and "signal" attributes to accomplished related purposes. = It's just more symmetrical.=20 Just a clarification here. Our goal (authors of = draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism = for fragmentation between RADIUS packets when they exceed 4K = (inter-packet fragmentation). If we remove the signal attribute (e.g. = "More-Data-Pending"), the flag T should mean that the RADIUS packet is = truncated (and not necessarily the attribute where the flag T is = activated). For example:=20 A,B,C,... ,Y are attributes of different types in one RADIUS packet. = Adding attribute Z exceeds 4K, so we should signal that. We could decide = to activate the bit T in the last attribute Y[T], but, actually, it does = not mean anything in the context of extended attribute Y[T], since we = want to signal that more attributes (perhaps, of any other type as, for = example, Z) are coming after this list in a different RADIUS packet. In this sense, we believe that the presence of some kind of attribute = "More-Data-Pending" (or any other type of signaling at packet level) can = inform about this situation within the context of the RADIUS packet.=20 Best regards. >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Sr. Software Architect > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Dave:

El 16/01/2012, a las 16:38, Dave Nelson = escribi=F3:

On Mon, Jan 16, 2012 at 10:30 AM, Alejandro Perez Mendez = <alex@um.es> wrote:

We also thought that a new flag "T" could indicate the attribute is = truncated across several packets.

Yeah. =  I would favor the definition of another flag bit, rather than = mixing flags and "signal" attributes to accomplished related purposes. =  It's just more = symmetrical. 

Just a = clarification here. Our goal (authors of = draft-perez-radext-radius-fragmentation-00.txt) is to enable a mechanism = for fragmentation between RADIUS packets when they exceed 4K = (inter-packet fragmentation). If we remove the signal attribute = (e.g. "More-Data-Pending"), the flag T should mean that the RADIUS = packet is truncated (and not necessarily the attribute where the flag T = is activated). For = example: 

A,B,C,... ,Y are attributes of = different types in one RADIUS packet. Adding attribute Z exceeds 4K, so = we should signal that. We could decide to activate the bit T in the last = attribute Y[T], but, actually, it does not mean anything in the context = of extended attribute Y[T], since we want to signal that more attributes = (perhaps, of any other type as, for example, Z) are coming after this = list in a different RADIUS packet.

In this = sense, we believe that the presence of some kind of attribute = "More-Data-Pending" (or any other type of signaling at packet level) can = inform about this situation within the context of the RADIUS = packet. 

Best = regards.


Regards,

Dave

David B. Nelson
Sr. Software = Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

-------------------------------------------------------
<= div>Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------= ---------------------------------




= --Apple-Mail=_B6C6A542-EEF0-44F1-B5A9-CC0B54A79C4F-- --===============0446435673677310029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0446435673677310029==-- From dromasca@avaya.com Wed Jan 18 04:56:41 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF88A21F8510 for ; Wed, 18 Jan 2012 04:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.315 X-Spam-Level: X-Spam-Status: No, score=-103.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCuy+6xLLSSc for ; Wed, 18 Jan 2012 04:56:41 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBE221F85EF for ; Wed, 18 Jan 2012 04:56:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGbAFk+HCzI1/2dsb2JhbABErEWBAYEFgXIBAQEBAxIeCksGAQgNBAQBAQsGDAsBB0UHAQEFBAEEEwgah2CYVIQYm3wEiTc2AQVWCAIHAQECAQEFAwEBAQECKA4cCTcFAYFtKAQCAgsBCRIWAQEBAg6COWMEmwqMUA X-IronPort-AV: E=Sophos;i="4.71,529,1320642000"; d="scan'208";a="325117749" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Jan 2012 07:56:40 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Jan 2012 07:43:15 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jan 2012 13:56:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-radext-radsec-10.txt updated by Amanda Baber Thread-Index: AczVjSltJsV9nj15RzOm5uYHMsDr+AAUaQ5A From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: draft-ietf-radext-radsec-10.txt updated by Amanda Baber X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 12:56:42 -0000 Document editors, What is your opinion? At least the text near the port assignment should point to the future RFC.=20 Dan -----Original Message----- From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org]=20 Sent: Wednesday, January 18, 2012 4:59 AM To: Romascanu, Dan (Dan) Subject: draft-ietf-radext-radsec-10.txt updated by Amanda Baber Please DO NOT reply on this email. I-D: draft-ietf-radext-radsec-10.txt ID Tracker URL: https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=3Dview_id&dTag= =3D 17332&rfc_flag=3D0 A new comment added by Amanda Baber IANA has a question about this document. IANA recognizes that previously, TCP port 2083 was already assigned by IANA for RadSec, an early implementation of RADIUS/TLS. We note that one of the authors is the assignee and contact for that port number. Our question is: do the authors want to make any changes to the registration of port 2083 upon approval of this document (description, assignee, contact, reference)? From radext-bounces@ietf.org Wed Jan 18 04:56:44 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1966C21F86D9; Wed, 18 Jan 2012 04:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326891404; bh=NwRP3IuwXBEk+4bqohqMam5ZSCrf7Rs9Yg6RTW3zOWU=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=YTXhSqrsLCgrrHBPBRfW5tjSPSP1RAYIizAV0OD5rl3N3IgDS4MUBDmm9uyywR29b 7N689934RioRSOys5bH83NAMGA925ztc/RBBL8jKUkLd05pUuECCratR+dwXj3UArW fNEJZ9/7wOOOMgjcxOGcNd3Ti1ETXQBzcBLumgQ0= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF88A21F8510 for ; Wed, 18 Jan 2012 04:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.315 X-Spam-Level: X-Spam-Status: No, score=-103.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCuy+6xLLSSc for ; Wed, 18 Jan 2012 04:56:41 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBE221F85EF for ; Wed, 18 Jan 2012 04:56:41 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGbAFk+HCzI1/2dsb2JhbABErEWBAYEFgXIBAQEBAxIeCksGAQgNBAQBAQsGDAsBB0UHAQEFBAEEEwgah2CYVIQYm3wEiTc2AQVWCAIHAQECAQEFAwEBAQECKA4cCTcFAYFtKAQCAgsBCRIWAQEBAg6COWMEmwqMUA X-IronPort-AV: E=Sophos;i="4.71,529,1320642000"; d="scan'208";a="325117749" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Jan 2012 07:56:40 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Jan 2012 07:43:15 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jan 2012 13:56:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-radext-radsec-10.txt updated by Amanda Baber Thread-Index: AczVjSltJsV9nj15RzOm5uYHMsDr+AAUaQ5A From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: draft-ietf-radext-radsec-10.txt updated by Amanda Baber X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Document editors, What is your opinion? At least the text near the port assignment should point to the future RFC. Dan -----Original Message----- From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] Sent: Wednesday, January 18, 2012 4:59 AM To: Romascanu, Dan (Dan) Subject: draft-ietf-radext-radsec-10.txt updated by Amanda Baber Please DO NOT reply on this email. I-D: draft-ietf-radext-radsec-10.txt ID Tracker URL: https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag= 17332&rfc_flag=0 A new comment added by Amanda Baber IANA has a question about this document. IANA recognizes that previously, TCP port 2083 was already assigned by IANA for RadSec, an early implementation of RADIUS/TLS. We note that one of the authors is the assignee and contact for that port number. Our question is: do the authors want to make any changes to the registration of port 2083 upon approval of this document (description, assignee, contact, reference)? _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Wed Jan 18 19:17:29 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1694311E80F8; Wed, 18 Jan 2012 19:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv4PkC9oD4Oy; Wed, 18 Jan 2012 19:17:27 -0800 (PST) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4C511E8093; Wed, 18 Jan 2012 19:17:27 -0800 (PST) Received: from BLU152-W47 ([65.55.111.71]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 19:17:27 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_8a84e9de-00de-453d-bae0-dbb3494ff61c_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 18 Jan 2012 19:17:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 03:17:27.0526 (UTC) FILETIME=[DF180060:01CCD658] Subject: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 03:17:29 -0000 --_8a84e9de-00de-453d-bae0-dbb3494ff61c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec.=20 Overall=2C this draft was a pleasant to read=2C and it is clear that a lot = of thought as well as implementation experience has gone into it.=20 Kudos to the authors.=20 General Issues There is a considerable amount of text relating to dynamic discovery in thi= s document=2C yet there is only an informational reference to it.=20 Since inserting a normative reference to dynamic discovery could delay the = publication of this document unnecessarily=2C my recommendation is to consolidate some of = the dynamic discovery material into a single section in which you can discuss the impli= cations=2C while clearly indicating the status of the dynamic discovery work (e.g. still und= er development=2C optional to implement along with RADSEC=2C etc.).=20 For example=2C you might consider consolidating the following text from Sec= tions 3.1 and 6=20 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS=20 is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechani= sm is still under development and therefore is not a normative dependency o= f RADIUS/TLS=2C the use of dynamic discovery has potential future implicat= ions that are important to understand.=20 If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. =20 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery.=20 Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication=2C accounting and dynauth traffic. [BA] Recommend changing to: "See Section 3.3 for considerations regarding separation of authentication=2C accounting and dynamic authorisation traffic." Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. As noted above=2C I'd suggest removing this material from Section 3.1 and=20 consolidating it with other dynamic-discovery material. =20 Section 3.3 Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet=2C an unconditional NAK is sent back to indicate that the action is not supported. [BA] What Error-Cause attribute value should be included within the NAK to = make it clear that the action is not supported? Error 406 "Unsupported Extension"? That is what RFC 5176 Section 3.5 seems to indicate.=20 There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured=3B no negative ICMP response will reveal this. [BA] This seems like a bad idea. How about requiring implementations not supporting Accounting to respond with an Accounting-Response containing Error-Cause attribute value 406? Implementations receiving an Accounting-R= esponse with this Error-Cause can be required to treat this like an ICMP response.= =20 Section 4 As a consequence=2C the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS= /UDP=2C that seems more like a MUST NOT!! Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related mate= rial into a separate section prior to 3.1.=20 Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that. = = --_8a84e9de-00de-453d-bae0-dbb3494ff61c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec. <= br>
Overall=2C this draft was a pleasant to read=2C and it is clear that= a lot of thought as well as implementation experience has gone into it.
Kudos to the authors.

General Issue= s

There is a considerable amount of text relating to dynamic discove= ry in this document=2C yet
there is only an informational reference to i= t.

Since inserting a normative reference to dynamic discovery could= delay the publication of
this document unnecessarily=2C my recommendati= on is to consolidate some of the dynamic
discovery material into a singl= e section in which you can discuss the implications=2C while
clearly ind= icating the status of the dynamic discovery work (e.g. still under developm= ent=2C optional to
implement along with RADSEC=2C etc.).

For exa= mple=2C you might consider consolidating the following text from Sections 3= .1 and 6
and placing it prior to the current Section 3.1:

Sectio= n 3.X: =3B Implications of Dynamic Peer Discovery

 =3B =3B One mechanism to discover RADIUS over TLS peers dynamicall= y via DNS
 =3B =3B is specified in [I-D.ietf-radext-dynamic-discovery]. = =3B While this mechanism
 =3B =3B is still under development and therefore is not a normativ= e dependency of
 =3B =3B RADIUS/TLS=2C the use of dynamic discovery has potential f= uture implications that are
 =3B =3B important to understand.

 =3B =3B If dynam= ic peer discovery as per
 =3B =3B [I-D.ietf-radext-dynamic-disco= very] is used=2C peer authentication
 =3B =3B alone is not suffi= cient=3B the peer must also be authorised to perform
 =3B =3B us= er authentications. =3B In these cases=2C the trust fabric cannot depen= d
 =3B =3B on peer authentication methods like DNSSEC to identif= y RADIUS/TLS
 =3B =3B nodes. =3B The nodes also need to be p= roperly authorised. =3B Typically=2C
 =3B =3B this can be ac= hieved by adding appropriate authorisation fields into
 =3B =3B = a X.509 certificate. =3B Such fields include SRV authority [RFC4985]=2C=
 =3B =3B subjectAltNames=2C or a defined list of certificate fi= ngerprints.
 =3B =3B Operators of a RADIUS/TLS infrastructure sh= ould define their own
 =3B =3B authorisation trust model and app= ly this model to the certificates.
 =3B =3B The checks enumerate= d in Section 2.3 provide sufficient flexibility
 =3B =3B for the= implementation of authorisation trust models.

[BA] I think you need= to be more prescriptive here. =3B Are there specific
fields that a = RADSEC TLS certificate should contain? =3B Having individual
impleme= ntations/deployments defining their own authorization schemes seems
like= a bad idea. =3B

 =3B =3B In the case of dynamic peer d= iscovery as per
 =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C = a RADIUS/TLS node needs to be
 =3B =3B able to accept connection= s from a large=2C not previously known=2C group
 =3B =3B of host= s=2C possibly the whole internet. =3B In this case=2C the server's
&= nbsp=3B =3B RADIUS/TLS port can not be protected from unauthorised conn= ection
 =3B =3B attempts with measures on the network layer=2C i= .e. access lists and
 =3B =3B firewalls. =3B This opens more= attack vectors for Distributed Denial of
 =3B =3B Service attac= ks=2C just like any other service that is supposed to
 =3B =3B s= erve arbitrary clients (like for example web servers).

 =3B = =3B In the case of dynamic peer discovery as per
 =3B =3B [I-D.i= etf-radext-dynamic-discovery]=2C X.509 certificates are the only
 = =3B =3B proof of authorisation for a connecting RADIUS/TLS nodes. = =3B Special
 =3B =3B care needs to be taken that certificates ge= t verified properly
 =3B =3B according to the chosen trust model= (particularly: consulting CRLs=2C
 =3B =3B checking critical ex= tensions=2C checking subjectAltNames etc.) to
 =3B =3B prevent u= nauthorised connections.

Other comments

Section 1

&nbs= p=3B =3B One mechanism to discover RADIUS over TLS peers with DNS is sp= ecified in
 =3B =3B [I-D.ietf-radext-dynamic-discovery].

= [BA] Recommend moving this to a section devoted to dynamic discovery.
<= br>Section 2.1

 =3B =3B See
 =3B =3B section Sect= ion 3.3 (4) and (5) for considerations regarding
 =3B =3B separa= tion of authentication=2C accounting and dynauth traffic.

[BA] Recom= mend changing to:

 =3B =3B "See Section 3.3 for consideratio= ns regarding separation of
 =3B =3B =3B authentication=2C ac= counting and dynamic authorisation traffic."

Section 2.3

&nbs= p=3B =3B 4. =3B start exchanging RADIUS datagrams. =3B Note Sec= tion 3.3 (1) ). =3B The
 =3B =3B =3B =3B =3B&nbs= p=3B shared secret to compute the (obsolete) MD5 integrity checks and
&n= bsp=3B =3B =3B =3B =3B =3B attribute encryption MUST be= "radsec" (see Section 3.3 (2) ).

Section 3.1

 =3B = =3B (3) If dynamic peer discovery as per
 =3B =3B [I-D.ietf-rade= xt-dynamic-discovery] is used=2C peer authentication
 =3B =3B al= one is not sufficient=3B the peer must also be authorised to perform
&nb= sp=3B =3B user authentications. =3B In these cases=2C the trust fab= ric cannot depend
 =3B =3B on peer authentication methods like D= NSSEC to identify RADIUS/TLS
 =3B =3B nodes. =3B The nodes a= lso need to be properly authorised. =3B Typically=2C
 =3B = =3B this can be achieved by adding appropriate authorisation fields into =3B =3B a X.509 certificate. =3B Such fields include SRV auth= ority [RFC4985]=2C
 =3B =3B subjectAltNames=2C or a defined list= of certificate fingerprints.
 =3B =3B Operators of a RADIUS/TLS= infrastructure should define their own
 =3B =3B authorisation t= rust model and apply this model to the certificates.
 =3B =3B Th= e checks enumerated in Section 2.3 provide sufficient flexibility
 = =3B =3B for the implementation of authorisation trust models.

As= noted above=2C I'd suggest removing this material from Section 3.1 and consolidating it with other dynamic-discovery material.  =3B

Se= ction 3.3

 =3B =3B Note well: it is not required for an impl= ementation
 =3B =3B to actually process these packet types. = =3B It is sufficient that upon
 =3B =3B receiving such a packet= =2C an unconditional NAK is sent back to
 =3B =3B indicate that = the action is not supported.

[BA] What Error-Cause attribute value s= hould be included within the NAK to make it
clear that the action is not= supported? =3B Error 406 "Unsupported Extension"?
That is what RFC = 5176 Section 3.5 seems to indicate.

 =3B =3B There
 = =3B =3B is no RADIUS datagram to signal an Accounting NAK. =3B Clie= nts may be
 =3B =3B misconfigured to send Accounting packets to = a RADIUS/TLS server which
 =3B =3B does not wish to process thei= r Accounting packet. =3B The server will
 =3B =3B need to si= lently drop the packet. =3B The client will need to deduce
 =3B&= nbsp=3B from the absence of replies that it is misconfigured=3B no negative=
 =3B =3B ICMP response will reveal this.

[BA] This seems= like a bad idea. =3B How about requiring implementations not
suppor= ting Accounting to respond with an Accounting-Response containing
Error-= Cause attribute value 406? =3B Implementations receiving an Accounting-= Response
with this Error-Cause can be required to treat this like an ICM= P response.

Section 4

 =3B =3B As a consequence=2C t= he selection of transports to communicate from a
 =3B =3B client= to a server is a manual administrative action. =3B An automatic
&nb= sp=3B =3B fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead t= o down-
 =3B =3B bidding attacks on the peer communication.
<= br>[BA] If a fixed shared secret "radsec" is used alongside fallback to RAD= IUS/UDP=2C
that seems more like a MUST NOT!!

Section 6

&nb= sp=3B =3B In the case of dynamic peer discovery as per
 =3B = =3B [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be =3B =3B able to accept connections from a large=2C not previously= known=2C group
 =3B =3B of hosts=2C possibly the whole internet= . =3B In this case=2C the server's
 =3B =3B RADIUS/TLS port = can not be protected from unauthorised connection
 =3B =3B attem= pts with measures on the network layer=2C i.e. access lists and
 =3B=  =3B firewalls. =3B This opens more attack vectors for Distributed = Denial of
 =3B =3B Service attacks=2C just like any other servic= e that is supposed to
 =3B =3B serve arbitrary clients (like for= example web servers).

 =3B =3B In the case of dynamic peer = discovery as per
 =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C= X.509 certificates are the only
 =3B =3B proof of authorisation= for a connecting RADIUS/TLS nodes. =3B Special
 =3B =3B car= e needs to be taken that certificates get verified properly
 =3B&nbs= p=3B according to the chosen trust model (particularly: consulting CRLs=2C<= br> =3B =3B checking critical extensions=2C checking subjectAltName= s etc.) to
 =3B =3B prevent unauthorised connections.

[BA] I'd recommend collecting this and other dynamic-discovery related mat= erial
into a separate section prior to 3.1.

Appendix C. Assessme= nt of Crypto-Agility Requirements


 =3B =3B The RADIUS Cr= ypto-Agility Requirements (link to RFC once issued here)
 =3B = =3B defines numerous classification criteria for protocols that strive to =3B =3B enhance the security of RADIUS. =3B It contains mand= atory (M) and
 =3B =3B recommended (R) criteria which crypto-agi= le protocols have to
 =3B =3B fulfill. =3B The authors belie= ve that the following assessment about the
 =3B =3B crypto-agili= ty properties of RADIUS/TLS are true.

[BA] The Crypto-Agility RFC is= now published so you should reference that.
= --_8a84e9de-00de-453d-bae0-dbb3494ff61c_-- From radext-bounces@ietf.org Wed Jan 18 19:17:32 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6452E11E8107; Wed, 18 Jan 2012 19:17:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326943052; bh=+sSfYoN9fTta1J3czf7JGMAc9FdLW/JEPNyR7cV3kFE=; h=Message-ID:From:To:Date:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=Qk9FNRyC6CYS05Hx8PSSSeCEraYL3g+eFljcGa6nkRPtsjiaaFMM2YJ07mzlKk0p1 I1WU6cCvgxC8IR1iY6M8tD/DkiAGiLhll+5kk5+tVHG5/RWrGLNGu2BtgJtCxgXDWz W6VRsAaH9wsDHuRYd6tsS/Gl5KZjfDqwtUt+/NnY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1694311E80F8; Wed, 18 Jan 2012 19:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv4PkC9oD4Oy; Wed, 18 Jan 2012 19:17:27 -0800 (PST) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4C511E8093; Wed, 18 Jan 2012 19:17:27 -0800 (PST) Received: from BLU152-W47 ([65.55.111.71]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 19:17:27 -0800 Message-ID: X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Date: Wed, 18 Jan 2012 19:17:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 03:17:27.0526 (UTC) FILETIME=[DF180060:01CCD658] Subject: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1509162269159569208==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============1509162269159569208== Content-Type: multipart/alternative; boundary="_8a84e9de-00de-453d-bae0-dbb3494ff61c_" --_8a84e9de-00de-453d-bae0-dbb3494ff61c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec.=20 Overall=2C this draft was a pleasant to read=2C and it is clear that a lot = of thought as well as implementation experience has gone into it.=20 Kudos to the authors.=20 General Issues There is a considerable amount of text relating to dynamic discovery in thi= s document=2C yet there is only an informational reference to it.=20 Since inserting a normative reference to dynamic discovery could delay the = publication of this document unnecessarily=2C my recommendation is to consolidate some of = the dynamic discovery material into a single section in which you can discuss the impli= cations=2C while clearly indicating the status of the dynamic discovery work (e.g. still und= er development=2C optional to implement along with RADSEC=2C etc.).=20 For example=2C you might consider consolidating the following text from Sec= tions 3.1 and 6=20 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS=20 is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechani= sm is still under development and therefore is not a normative dependency o= f RADIUS/TLS=2C the use of dynamic discovery has potential future implicat= ions that are important to understand.=20 If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. =20 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery.=20 Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication=2C accounting and dynauth traffic. [BA] Recommend changing to: "See Section 3.3 for considerations regarding separation of authentication=2C accounting and dynamic authorisation traffic." Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. As noted above=2C I'd suggest removing this material from Section 3.1 and=20 consolidating it with other dynamic-discovery material. =20 Section 3.3 Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet=2C an unconditional NAK is sent back to indicate that the action is not supported. [BA] What Error-Cause attribute value should be included within the NAK to = make it clear that the action is not supported? Error 406 "Unsupported Extension"? That is what RFC 5176 Section 3.5 seems to indicate.=20 There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured=3B no negative ICMP response will reveal this. [BA] This seems like a bad idea. How about requiring implementations not supporting Accounting to respond with an Accounting-Response containing Error-Cause attribute value 406? Implementations receiving an Accounting-R= esponse with this Error-Cause can be required to treat this like an ICMP response.= =20 Section 4 As a consequence=2C the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS= /UDP=2C that seems more like a MUST NOT!! Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related mate= rial into a separate section prior to 3.1.=20 Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that. = = --_8a84e9de-00de-453d-bae0-dbb3494ff61c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec. <= br>
Overall=2C this draft was a pleasant to read=2C and it is clear that= a lot of thought as well as implementation experience has gone into it.
Kudos to the authors.

General Issue= s

There is a considerable amount of text relating to dynamic discove= ry in this document=2C yet
there is only an informational reference to i= t.

Since inserting a normative reference to dynamic discovery could= delay the publication of
this document unnecessarily=2C my recommendati= on is to consolidate some of the dynamic
discovery material into a singl= e section in which you can discuss the implications=2C while
clearly ind= icating the status of the dynamic discovery work (e.g. still under developm= ent=2C optional to
implement along with RADSEC=2C etc.).

For exa= mple=2C you might consider consolidating the following text from Sections 3= .1 and 6
and placing it prior to the current Section 3.1:

Sectio= n 3.X: =3B Implications of Dynamic Peer Discovery

 =3B =3B One mechanism to discover RADIUS over TLS peers dynamicall= y via DNS
 =3B =3B is specified in [I-D.ietf-radext-dynamic-discovery]. = =3B While this mechanism
 =3B =3B is still under development and therefore is not a normativ= e dependency of
 =3B =3B RADIUS/TLS=2C the use of dynamic discovery has potential f= uture implications that are
 =3B =3B important to understand.

 =3B =3B If dynam= ic peer discovery as per
 =3B =3B [I-D.ietf-radext-dynamic-disco= very] is used=2C peer authentication
 =3B =3B alone is not suffi= cient=3B the peer must also be authorised to perform
 =3B =3B us= er authentications. =3B In these cases=2C the trust fabric cannot depen= d
 =3B =3B on peer authentication methods like DNSSEC to identif= y RADIUS/TLS
 =3B =3B nodes. =3B The nodes also need to be p= roperly authorised. =3B Typically=2C
 =3B =3B this can be ac= hieved by adding appropriate authorisation fields into
 =3B =3B = a X.509 certificate. =3B Such fields include SRV authority [RFC4985]=2C=
 =3B =3B subjectAltNames=2C or a defined list of certificate fi= ngerprints.
 =3B =3B Operators of a RADIUS/TLS infrastructure sh= ould define their own
 =3B =3B authorisation trust model and app= ly this model to the certificates.
 =3B =3B The checks enumerate= d in Section 2.3 provide sufficient flexibility
 =3B =3B for the= implementation of authorisation trust models.

[BA] I think you need= to be more prescriptive here. =3B Are there specific
fields that a = RADSEC TLS certificate should contain? =3B Having individual
impleme= ntations/deployments defining their own authorization schemes seems
like= a bad idea. =3B

 =3B =3B In the case of dynamic peer d= iscovery as per
 =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C = a RADIUS/TLS node needs to be
 =3B =3B able to accept connection= s from a large=2C not previously known=2C group
 =3B =3B of host= s=2C possibly the whole internet. =3B In this case=2C the server's
&= nbsp=3B =3B RADIUS/TLS port can not be protected from unauthorised conn= ection
 =3B =3B attempts with measures on the network layer=2C i= .e. access lists and
 =3B =3B firewalls. =3B This opens more= attack vectors for Distributed Denial of
 =3B =3B Service attac= ks=2C just like any other service that is supposed to
 =3B =3B s= erve arbitrary clients (like for example web servers).

 =3B = =3B In the case of dynamic peer discovery as per
 =3B =3B [I-D.i= etf-radext-dynamic-discovery]=2C X.509 certificates are the only
 = =3B =3B proof of authorisation for a connecting RADIUS/TLS nodes. = =3B Special
 =3B =3B care needs to be taken that certificates ge= t verified properly
 =3B =3B according to the chosen trust model= (particularly: consulting CRLs=2C
 =3B =3B checking critical ex= tensions=2C checking subjectAltNames etc.) to
 =3B =3B prevent u= nauthorised connections.

Other comments

Section 1

&nbs= p=3B =3B One mechanism to discover RADIUS over TLS peers with DNS is sp= ecified in
 =3B =3B [I-D.ietf-radext-dynamic-discovery].

= [BA] Recommend moving this to a section devoted to dynamic discovery.
<= br>Section 2.1

 =3B =3B See
 =3B =3B section Sect= ion 3.3 (4) and (5) for considerations regarding
 =3B =3B separa= tion of authentication=2C accounting and dynauth traffic.

[BA] Recom= mend changing to:

 =3B =3B "See Section 3.3 for consideratio= ns regarding separation of
 =3B =3B =3B authentication=2C ac= counting and dynamic authorisation traffic."

Section 2.3

&nbs= p=3B =3B 4. =3B start exchanging RADIUS datagrams. =3B Note Sec= tion 3.3 (1) ). =3B The
 =3B =3B =3B =3B =3B&nbs= p=3B shared secret to compute the (obsolete) MD5 integrity checks and
&n= bsp=3B =3B =3B =3B =3B =3B attribute encryption MUST be= "radsec" (see Section 3.3 (2) ).

Section 3.1

 =3B = =3B (3) If dynamic peer discovery as per
 =3B =3B [I-D.ietf-rade= xt-dynamic-discovery] is used=2C peer authentication
 =3B =3B al= one is not sufficient=3B the peer must also be authorised to perform
&nb= sp=3B =3B user authentications. =3B In these cases=2C the trust fab= ric cannot depend
 =3B =3B on peer authentication methods like D= NSSEC to identify RADIUS/TLS
 =3B =3B nodes. =3B The nodes a= lso need to be properly authorised. =3B Typically=2C
 =3B = =3B this can be achieved by adding appropriate authorisation fields into =3B =3B a X.509 certificate. =3B Such fields include SRV auth= ority [RFC4985]=2C
 =3B =3B subjectAltNames=2C or a defined list= of certificate fingerprints.
 =3B =3B Operators of a RADIUS/TLS= infrastructure should define their own
 =3B =3B authorisation t= rust model and apply this model to the certificates.
 =3B =3B Th= e checks enumerated in Section 2.3 provide sufficient flexibility
 = =3B =3B for the implementation of authorisation trust models.

As= noted above=2C I'd suggest removing this material from Section 3.1 and consolidating it with other dynamic-discovery material.  =3B

Se= ction 3.3

 =3B =3B Note well: it is not required for an impl= ementation
 =3B =3B to actually process these packet types. = =3B It is sufficient that upon
 =3B =3B receiving such a packet= =2C an unconditional NAK is sent back to
 =3B =3B indicate that = the action is not supported.

[BA] What Error-Cause attribute value s= hould be included within the NAK to make it
clear that the action is not= supported? =3B Error 406 "Unsupported Extension"?
That is what RFC = 5176 Section 3.5 seems to indicate.

 =3B =3B There
 = =3B =3B is no RADIUS datagram to signal an Accounting NAK. =3B Clie= nts may be
 =3B =3B misconfigured to send Accounting packets to = a RADIUS/TLS server which
 =3B =3B does not wish to process thei= r Accounting packet. =3B The server will
 =3B =3B need to si= lently drop the packet. =3B The client will need to deduce
 =3B&= nbsp=3B from the absence of replies that it is misconfigured=3B no negative=
 =3B =3B ICMP response will reveal this.

[BA] This seems= like a bad idea. =3B How about requiring implementations not
suppor= ting Accounting to respond with an Accounting-Response containing
Error-= Cause attribute value 406? =3B Implementations receiving an Accounting-= Response
with this Error-Cause can be required to treat this like an ICM= P response.

Section 4

 =3B =3B As a consequence=2C t= he selection of transports to communicate from a
 =3B =3B client= to a server is a manual administrative action. =3B An automatic
&nb= sp=3B =3B fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead t= o down-
 =3B =3B bidding attacks on the peer communication.
<= br>[BA] If a fixed shared secret "radsec" is used alongside fallback to RAD= IUS/UDP=2C
that seems more like a MUST NOT!!

Section 6

&nb= sp=3B =3B In the case of dynamic peer discovery as per
 =3B = =3B [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be =3B =3B able to accept connections from a large=2C not previously= known=2C group
 =3B =3B of hosts=2C possibly the whole internet= . =3B In this case=2C the server's
 =3B =3B RADIUS/TLS port = can not be protected from unauthorised connection
 =3B =3B attem= pts with measures on the network layer=2C i.e. access lists and
 =3B=  =3B firewalls. =3B This opens more attack vectors for Distributed = Denial of
 =3B =3B Service attacks=2C just like any other servic= e that is supposed to
 =3B =3B serve arbitrary clients (like for= example web servers).

 =3B =3B In the case of dynamic peer = discovery as per
 =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C= X.509 certificates are the only
 =3B =3B proof of authorisation= for a connecting RADIUS/TLS nodes. =3B Special
 =3B =3B car= e needs to be taken that certificates get verified properly
 =3B&nbs= p=3B according to the chosen trust model (particularly: consulting CRLs=2C<= br> =3B =3B checking critical extensions=2C checking subjectAltName= s etc.) to
 =3B =3B prevent unauthorised connections.

[BA] I'd recommend collecting this and other dynamic-discovery related mat= erial
into a separate section prior to 3.1.

Appendix C. Assessme= nt of Crypto-Agility Requirements


 =3B =3B The RADIUS Cr= ypto-Agility Requirements (link to RFC once issued here)
 =3B = =3B defines numerous classification criteria for protocols that strive to =3B =3B enhance the security of RADIUS. =3B It contains mand= atory (M) and
 =3B =3B recommended (R) criteria which crypto-agi= le protocols have to
 =3B =3B fulfill. =3B The authors belie= ve that the following assessment about the
 =3B =3B crypto-agili= ty properties of RADIUS/TLS are true.

[BA] The Crypto-Agility RFC is= now published so you should reference that.
= --_8a84e9de-00de-453d-bae0-dbb3494ff61c_-- --===============1509162269159569208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1509162269159569208==-- From stefan.winter@restena.lu Thu Jan 19 00:48:55 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3521F8570 for ; Thu, 19 Jan 2012 00:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN21abfWWz9O for ; Thu, 19 Jan 2012 00:48:48 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 57FF721F8568 for ; Thu, 19 Jan 2012 00:48:48 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id B28E19DD19 for ; Thu, 19 Jan 2012 09:48:47 +0100 (CET) Received: from [158.64.15.219] (219-15.vpn.restena.lu [158.64.15.219]) by legolas.restena.lu (Postfix) with ESMTPSA id 9455E9DD07 for ; Thu, 19 Jan 2012 09:48:47 +0100 (CET) Message-ID: <4F17D8EE.9060901@restena.lu> Date: Thu, 19 Jan 2012 09:48:46 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: draft-ietf-radext-radsec-10.txt updated by Amanda Baber X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 08:48:55 -0000 Hi Dan, this is what I just replied to Amanda: ------------- having Mike as one of the co-authors as assignee and contact looks just fine to me. Looking at the service-names registry, it looks like the protocol does not have anything in the "reference" column yet. It would make sense to add a reference to the RFC number once issued. It also might make sense to add text to the "Assignment notes" section, detailing that there has been previous use of that port number, which is compatible to the use in the RFC-to-be. I will issue a new -11 revision taking all LC comments, including this one, into account, and will propose corresponding text in the "IANA Considerations" section. --------------- Greetings, Stefan Winter On 18.01.12 13:56, Romascanu, Dan (Dan) wrote: > Document editors, > > What is your opinion? At least the text near the port assignment should > point to the future RFC. > > Dan > > > > > -----Original Message----- > From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, January 18, 2012 4:59 AM > To: Romascanu, Dan (Dan) > Subject: draft-ietf-radext-radsec-10.txt updated by Amanda Baber > > > Please DO NOT reply on this email. > > > I-D: draft-ietf-radext-radsec-10.txt > ID Tracker URL: > https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag= > 17332&rfc_flag=0 > A new comment added by Amanda Baber > > IANA has a question about this document. > > > > IANA recognizes that previously, TCP port 2083 was already assigned by > IANA for RadSec, an early implementation of RADIUS/TLS. We note that one > of the authors is the assignee and contact for that port number. Our > question is: do the authors want to make any changes to the registration > of port 2083 upon approval of this document (description, assignee, > contact, reference)? > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Thu Jan 19 00:48:56 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C4321F856F; Thu, 19 Jan 2012 00:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326962936; bh=ViwfzY5ZMD/rIiYppjBPZ7q1vW/+4c8380SAIApafbM=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=nzN0R0aZ3ClFhlbQLMh+Hd5TrV0HJZWIhVZXnRc0OS4YYH5Sho3x8nRuisYlzcPnu 8gy1dgkVAoyzDAeveBcjOshdJEfb7POvCJpcQg6iFKlfQP1zqKUrIQhA9DKUVF5AQ0 W06N7mZV2zxqReYQMnmPALs2CmoQWraLtodMAMwo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA3521F8570 for ; Thu, 19 Jan 2012 00:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN21abfWWz9O for ; Thu, 19 Jan 2012 00:48:48 -0800 (PST) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 57FF721F8568 for ; Thu, 19 Jan 2012 00:48:48 -0800 (PST) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id B28E19DD19 for ; Thu, 19 Jan 2012 09:48:47 +0100 (CET) Received: from [158.64.15.219] (219-15.vpn.restena.lu [158.64.15.219]) by legolas.restena.lu (Postfix) with ESMTPSA id 9455E9DD07 for ; Thu, 19 Jan 2012 09:48:47 +0100 (CET) Message-ID: <4F17D8EE.9060901@restena.lu> Date: Thu, 19 Jan 2012 09:48:46 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: draft-ietf-radext-radsec-10.txt updated by Amanda Baber X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi Dan, this is what I just replied to Amanda: ------------- having Mike as one of the co-authors as assignee and contact looks just fine to me. Looking at the service-names registry, it looks like the protocol does not have anything in the "reference" column yet. It would make sense to add a reference to the RFC number once issued. It also might make sense to add text to the "Assignment notes" section, detailing that there has been previous use of that port number, which is compatible to the use in the RFC-to-be. I will issue a new -11 revision taking all LC comments, including this one, into account, and will propose corresponding text in the "IANA Considerations" section. --------------- Greetings, Stefan Winter On 18.01.12 13:56, Romascanu, Dan (Dan) wrote: > Document editors, > > What is your opinion? At least the text near the port assignment should > point to the future RFC. > > Dan > > > > > -----Original Message----- > From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org] > Sent: Wednesday, January 18, 2012 4:59 AM > To: Romascanu, Dan (Dan) > Subject: draft-ietf-radext-radsec-10.txt updated by Amanda Baber > > > Please DO NOT reply on this email. > > > I-D: draft-ietf-radext-radsec-10.txt > ID Tracker URL: > https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=view_id&dTag= > 17332&rfc_flag=0 > A new comment added by Amanda Baber > > IANA has a question about this document. > > > > IANA recognizes that previously, TCP port 2083 was already assigned by > IANA for RadSec, an early implementation of RADIUS/TLS. We note that one > of the authors is the assignee and contact for that port number. Our > question is: do the authors want to make any changes to the registration > of port 2083 upon approval of this document (description, assignee, > contact, reference)? > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Jan 23 03:35:40 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1821F8707; Mon, 23 Jan 2012 03:35:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327318540; bh=ME+CE7qc5yZWNJJPyD9xnXaUxZ99t86qPgmDDbtdgd8=; h=MIME-Version:Content-Type:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=uXkCrdVBJYhNJmXUsdI+48c6pSlfsDDJhgXImuy/Xh2GaiiEqUUVMdkx6RIZkESOQ lIeGX8wgEPWvU8WIuDw96Yzv9V2AdFmyLrFcbXT9rZn86qOSAlNocgD6NUEA5M+pWg ituaUpvigeeTmXzq1KWdxNvQUoRnPnhy3N5GfIg8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22B821F8701 for ; Mon, 23 Jan 2012 03:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7TGuq5uKYy8 for ; Mon, 23 Jan 2012 03:35:38 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B521F8707 for ; Mon, 23 Jan 2012 03:35:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsJAFdFHU+HCzI1/2dsb2JhbAA4CoJNpT+GGoEFgXIBAQEBAwEBAQ8KEQM+HQEIDQQEAQELBgwEBwEHASUfBwEBBQQBBBMIGodimQmEGZpzBIhpglpjBI9Oi0SMVg X-IronPort-AV: E=Sophos;i="4.71,555,1320642000"; d="txt'?scan'208,217";a="287566564" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jan 2012 06:35:35 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jan 2012 06:21:58 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CCD9C3.1E207B74" Date: Mon, 23 Jan 2012 12:35:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Review of draft-ietf-radext-radsec Thread-Index: AczWxbMONdxRk864TbSsTHEm0DZyvQC/WM9g From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: [AAA-DOCTORS] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD9C3.1E207B74 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CCD9C3.1E207B74" ------_=_NextPart_002_01CCD9C3.1E207B74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, January 19, 2012 6:16 PM To: aaa-doctors@ietf.org Subject: [AAA-DOCTORS] Review of draft-ietf-radext-radsec =20 =20 =20 Overall, this draft was a pleasant to read, and it is clear that a lot of thought as well as implementation experience has gone into it.=20 Kudos to the authors.=20 General Issues There is a considerable amount of text relating to dynamic discovery in this document, yet there is only an informational reference to it.=20 Since inserting a normative reference to dynamic discovery could delay the publication of this document unnecessarily, my recommendation is to consolidate some of the dynamic discovery material into a single section in which you can discuss the implications, while clearly indicating the status of the dynamic discovery work (e.g. still under development, optional to implement along with RADSEC, etc.).=20 For example, you might consider consolidating the following text from Sections 3.1 and 6=20 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS=20 is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechanism is still under development and therefore is not a normative dependency of RADIUS/TLS, the use of dynamic discovery has potential future implications that are important to understand.=20 If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used, peer authentication alone is not sufficient; the peer must also be authorised to perform user authentications. In these cases, the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically, this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985], subjectAltNames, or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. =20 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery.=20 Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication, accounting and dynauth traffic. [BA] Recommend changing to: "See Section 3.3 for considerations regarding separation of authentication, accounting and dynamic authorisation traffic." Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used, peer authentication alone is not sufficient; the peer must also be authorised to perform user authentications. In these cases, the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically, this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985], subjectAltNames, or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. As noted above, I'd suggest removing this material from Section 3.1 and=20 consolidating it with other dynamic-discovery material. =20 Section 3.3 Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. [BA] What Error-Cause attribute value should be included within the NAK to make it clear that the action is not supported? Error 406 "Unsupported Extension"? That is what RFC 5176 Section 3.5 seems to indicate.=20 There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured; no negative ICMP response will reveal this. [BA] This seems like a bad idea. How about requiring implementations not supporting Accounting to respond with an Accounting-Response containing Error-Cause attribute value 406? Implementations receiving an Accounting-Response with this Error-Cause can be required to treat this like an ICMP response.=20 Section 4 As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS/UDP, that seems more like a MUST NOT!! Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related material into a separate section prior to 3.1.=20 Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that.=20 ------_=_NextPart_002_01CCD9C3.1E207B74 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

From:= = aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On = Behalf Of Bernard Aboba
Sent: Thursday, January 19, 2012 = 6:16 PM
To: aaa-doctors@ietf.org
Subject: = [AAA-DOCTORS] Review of = draft-ietf-radext-radsec

 

 <= /o:p>

 <= /o:p>


Overall,= this draft was a pleasant to read, and it is clear that a lot of = thought as well as implementation experience has gone into it. =

Kudos to the authors.

General Issues

There is a = considerable amount of text relating to dynamic discovery in this = document, yet
there is only an informational reference to it. =

Since inserting a normative reference to dynamic discovery could = delay the publication of
this document unnecessarily, my = recommendation is to consolidate some of the dynamic
discovery = material into a single section in which you can discuss the = implications, while
clearly indicating the status of the dynamic = discovery work (e.g. still under development, optional to
implement = along with RADSEC, etc.).

For example, you might consider = consolidating the following text from Sections 3.1 and 6
and placing = it prior to the current Section 3.1:

Section 3.X:  = Implications of Dynamic Peer Discovery

   One mechanism = to discover RADIUS over TLS peers dynamically via DNS
   = is specified in [I-D.ietf-radext-dynamic-discovery].  While this = mechanism
   is still under development and therefore is = not a normative dependency of
   RADIUS/TLS, the use of = dynamic discovery has potential future implications that = are
   important to understand.

   If = dynamic peer discovery as per
   = [I-D.ietf-radext-dynamic-discovery] is used, peer = authentication
   alone is not sufficient; the peer must = also be authorised to perform
   user = authentications.  In these cases, the trust fabric cannot = depend
   on peer authentication methods like DNSSEC to = identify RADIUS/TLS
   nodes.  The nodes also need to = be properly authorised.  Typically,
   this can be = achieved by adding appropriate authorisation fields into
   = a X.509 certificate.  Such fields include SRV authority = [RFC4985],
   subjectAltNames, or a defined list of = certificate fingerprints.
   Operators of a RADIUS/TLS = infrastructure should define their own
   authorisation = trust model and apply this model to the certificates.
   = The checks enumerated in Section 2.3 provide sufficient = flexibility
   for the implementation of authorisation = trust models.

[BA] I think you need to be more prescriptive = here.  Are there specific
fields that a RADSEC TLS certificate = should contain?  Having individual
implementations/deployments = defining their own authorization schemes seems
like a bad idea.  =

   In the case of dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS = node needs to be
   able to accept connections from a = large, not previously known, group
   of hosts, possibly = the whole internet.  In this case, the server's
   = RADIUS/TLS port can not be protected from unauthorised = connection
   attempts with measures on the network layer, = i.e. access lists and
   firewalls.  This opens more = attack vectors for Distributed Denial of
   Service = attacks, just like any other service that is supposed to
   = serve arbitrary clients (like for example web = servers).

   In the case of dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery], X.509 = certificates are the only
   proof of authorisation for a = connecting RADIUS/TLS nodes.  Special
   care needs to = be taken that certificates get verified properly
   = according to the chosen trust model (particularly: consulting = CRLs,
   checking critical extensions, checking = subjectAltNames etc.) to
   prevent unauthorised = connections.

Other comments

Section 1

   = One mechanism to discover RADIUS over TLS peers with DNS is specified = in
   [I-D.ietf-radext-dynamic-discovery].

[BA] = Recommend moving this to a section devoted to dynamic discovery. =

Section 2.1

   See
   section = Section 3.3 (4) and (5) for considerations regarding
   = separation of authentication, accounting and dynauth = traffic.

[BA] Recommend changing to:

   = "See Section 3.3 for considerations regarding separation = of
    authentication, accounting and dynamic = authorisation traffic."

Section 2.3

   = 4.  start exchanging RADIUS datagrams.  Note Section 3.3 (1) = ).  The
       shared secret to = compute the (obsolete) MD5 integrity checks = and
       attribute encryption MUST be = "radsec" (see Section 3.3 (2) ).

Section = 3.1

   (3) If dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery] is used, peer = authentication
   alone is not sufficient; the peer must = also be authorised to perform
   user = authentications.  In these cases, the trust fabric cannot = depend
   on peer authentication methods like DNSSEC to = identify RADIUS/TLS
   nodes.  The nodes also need to = be properly authorised.  Typically,
   this can be = achieved by adding appropriate authorisation fields into
   = a X.509 certificate.  Such fields include SRV authority = [RFC4985],
   subjectAltNames, or a defined list of = certificate fingerprints.
   Operators of a RADIUS/TLS = infrastructure should define their own
   authorisation = trust model and apply this model to the certificates.
   = The checks enumerated in Section 2.3 provide sufficient = flexibility
   for the implementation of authorisation = trust models.

As noted above, I'd suggest removing this material = from Section 3.1 and
consolidating it with other dynamic-discovery = material.  

Section 3.3

   Note well: it is = not required for an implementation
   to actually process = these packet types.  It is sufficient that upon
   = receiving such a packet, an unconditional NAK is sent back = to
   indicate that the action is not = supported.

[BA] What Error-Cause attribute value should be = included within the NAK to make it
clear that the action is not = supported?  Error 406 "Unsupported Extension"?
That is = what RFC 5176 Section 3.5 seems to indicate.

   = There
   is no RADIUS datagram to signal an Accounting = NAK.  Clients may be
   misconfigured to send = Accounting packets to a RADIUS/TLS server which
   does not = wish to process their Accounting packet.  The server = will
   need to silently drop the packet.  The client = will need to deduce
   from the absence of replies that it = is misconfigured; no negative
   ICMP response will reveal = this.

[BA] This seems like a bad idea.  How about requiring = implementations not
supporting Accounting to respond with an = Accounting-Response containing
Error-Cause attribute value 406?  = Implementations receiving an Accounting-Response
with this = Error-Cause can be required to treat this like an ICMP response. =

Section 4

   As a consequence, the selection of = transports to communicate from a
   client to a server is a = manual administrative action.  An automatic
   = fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to = down-
   bidding attacks on the peer = communication.

[BA] If a fixed shared secret "radsec" = is used alongside fallback to RADIUS/UDP,
that seems more like a MUST = NOT!!

Section 6

   In the case of dynamic peer = discovery as per
   [I-D.ietf-radext-dynamic-discovery], a = RADIUS/TLS node needs to be
   able to accept connections = from a large, not previously known, group
   of hosts, = possibly the whole internet.  In this case, the = server's
   RADIUS/TLS port can not be protected from = unauthorised connection
   attempts with measures on the = network layer, i.e. access lists and
   firewalls.  = This opens more attack vectors for Distributed Denial of
   = Service attacks, just like any other service that is supposed = to
   serve arbitrary clients (like for example web = servers).

   In the case of dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery], X.509 = certificates are the only
   proof of authorisation for a = connecting RADIUS/TLS nodes.  Special
   care needs to = be taken that certificates get verified properly
   = according to the chosen trust model (particularly: consulting = CRLs,
   checking critical extensions, checking = subjectAltNames etc.) to
   prevent unauthorised = connections.


[BA] I'd recommend collecting this and other = dynamic-discovery related material
into a separate section prior to = 3.1.

Appendix C. Assessment of Crypto-Agility = Requirements


   The RADIUS Crypto-Agility = Requirements (link to RFC once issued here)
   defines = numerous classification criteria for protocols that strive = to
   enhance the security of RADIUS.  It contains = mandatory (M) and
   recommended (R) criteria which = crypto-agile protocols have to
   fulfill.  The = authors believe that the following assessment about the
   = crypto-agility properties of RADIUS/TLS are true.

[BA] The = Crypto-Agility RFC is now published so you should reference that. =

------_=_NextPart_002_01CCD9C3.1E207B74-- ------_=_NextPart_001_01CCD9C3.1E207B74 Content-Type: text/plain; name="ATT8034407.txt" Content-Transfer-Encoding: base64 Content-Description: ATT8034407.txt Content-Disposition: inline; filename="ATT8034407.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFBQS1ET0NU T1JTIG1haWxpbmcgbGlzdA0KQUFBLURPQ1RPUlNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWFhLWRvY3RvcnMNCg== ------_=_NextPart_001_01CCD9C3.1E207B74 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ------_=_NextPart_001_01CCD9C3.1E207B74-- From dromasca@avaya.com Mon Jan 23 03:35:39 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22B821F8701 for ; Mon, 23 Jan 2012 03:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7TGuq5uKYy8 for ; Mon, 23 Jan 2012 03:35:38 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B521F8707 for ; Mon, 23 Jan 2012 03:35:37 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsJAFdFHU+HCzI1/2dsb2JhbAA4CoJNpT+GGoEFgXIBAQEBAwEBAQ8KEQM+HQEIDQQEAQELBgwEBwEHASUfBwEBBQQBBBMIGodimQmEGZpzBIhpglpjBI9Oi0SMVg X-IronPort-AV: E=Sophos;i="4.71,555,1320642000"; d="txt'?scan'208,217";a="287566564" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jan 2012 06:35:35 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jan 2012 06:21:58 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CCD9C3.1E207B74" Date: Mon, 23 Jan 2012 12:35:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-DOCTORS] Review of draft-ietf-radext-radsec Thread-Index: AczWxbMONdxRk864TbSsTHEm0DZyvQC/WM9g From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: [AAA-DOCTORS] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 11:35:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD9C3.1E207B74 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CCD9C3.1E207B74" ------_=_NextPart_002_01CCD9C3.1E207B74 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 From: aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, January 19, 2012 6:16 PM To: aaa-doctors@ietf.org Subject: [AAA-DOCTORS] Review of draft-ietf-radext-radsec =20 =20 =20 Overall, this draft was a pleasant to read, and it is clear that a lot of thought as well as implementation experience has gone into it.=20 Kudos to the authors.=20 General Issues There is a considerable amount of text relating to dynamic discovery in this document, yet there is only an informational reference to it.=20 Since inserting a normative reference to dynamic discovery could delay the publication of this document unnecessarily, my recommendation is to consolidate some of the dynamic discovery material into a single section in which you can discuss the implications, while clearly indicating the status of the dynamic discovery work (e.g. still under development, optional to implement along with RADSEC, etc.).=20 For example, you might consider consolidating the following text from Sections 3.1 and 6=20 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS=20 is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechanism is still under development and therefore is not a normative dependency of RADIUS/TLS, the use of dynamic discovery has potential future implications that are important to understand.=20 If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used, peer authentication alone is not sufficient; the peer must also be authorised to perform user authentications. In these cases, the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically, this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985], subjectAltNames, or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. =20 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery.=20 Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication, accounting and dynauth traffic. [BA] Recommend changing to: "See Section 3.3 for considerations regarding separation of authentication, accounting and dynamic authorisation traffic." Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used, peer authentication alone is not sufficient; the peer must also be authorised to perform user authentications. In these cases, the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically, this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985], subjectAltNames, or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. As noted above, I'd suggest removing this material from Section 3.1 and=20 consolidating it with other dynamic-discovery material. =20 Section 3.3 Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. [BA] What Error-Cause attribute value should be included within the NAK to make it clear that the action is not supported? Error 406 "Unsupported Extension"? That is what RFC 5176 Section 3.5 seems to indicate.=20 There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured; no negative ICMP response will reveal this. [BA] This seems like a bad idea. How about requiring implementations not supporting Accounting to respond with an Accounting-Response containing Error-Cause attribute value 406? Implementations receiving an Accounting-Response with this Error-Cause can be required to treat this like an ICMP response.=20 Section 4 As a consequence, the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS/UDP, that seems more like a MUST NOT!! Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be able to accept connections from a large, not previously known, group of hosts, possibly the whole internet. In this case, the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer, i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks, just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs, checking critical extensions, checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related material into a separate section prior to 3.1.=20 Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that.=20 ------_=_NextPart_002_01CCD9C3.1E207B74 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

 

From:= = aaa-doctors-bounces@ietf.org [mailto:aaa-doctors-bounces@ietf.org] On = Behalf Of Bernard Aboba
Sent: Thursday, January 19, 2012 = 6:16 PM
To: aaa-doctors@ietf.org
Subject: = [AAA-DOCTORS] Review of = draft-ietf-radext-radsec

 

 <= /o:p>

 <= /o:p>


Overall,= this draft was a pleasant to read, and it is clear that a lot of = thought as well as implementation experience has gone into it. =

Kudos to the authors.

General Issues

There is a = considerable amount of text relating to dynamic discovery in this = document, yet
there is only an informational reference to it. =

Since inserting a normative reference to dynamic discovery could = delay the publication of
this document unnecessarily, my = recommendation is to consolidate some of the dynamic
discovery = material into a single section in which you can discuss the = implications, while
clearly indicating the status of the dynamic = discovery work (e.g. still under development, optional to
implement = along with RADSEC, etc.).

For example, you might consider = consolidating the following text from Sections 3.1 and 6
and placing = it prior to the current Section 3.1:

Section 3.X:  = Implications of Dynamic Peer Discovery

   One mechanism = to discover RADIUS over TLS peers dynamically via DNS
   = is specified in [I-D.ietf-radext-dynamic-discovery].  While this = mechanism
   is still under development and therefore is = not a normative dependency of
   RADIUS/TLS, the use of = dynamic discovery has potential future implications that = are
   important to understand.

   If = dynamic peer discovery as per
   = [I-D.ietf-radext-dynamic-discovery] is used, peer = authentication
   alone is not sufficient; the peer must = also be authorised to perform
   user = authentications.  In these cases, the trust fabric cannot = depend
   on peer authentication methods like DNSSEC to = identify RADIUS/TLS
   nodes.  The nodes also need to = be properly authorised.  Typically,
   this can be = achieved by adding appropriate authorisation fields into
   = a X.509 certificate.  Such fields include SRV authority = [RFC4985],
   subjectAltNames, or a defined list of = certificate fingerprints.
   Operators of a RADIUS/TLS = infrastructure should define their own
   authorisation = trust model and apply this model to the certificates.
   = The checks enumerated in Section 2.3 provide sufficient = flexibility
   for the implementation of authorisation = trust models.

[BA] I think you need to be more prescriptive = here.  Are there specific
fields that a RADSEC TLS certificate = should contain?  Having individual
implementations/deployments = defining their own authorization schemes seems
like a bad idea.  =

   In the case of dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS = node needs to be
   able to accept connections from a = large, not previously known, group
   of hosts, possibly = the whole internet.  In this case, the server's
   = RADIUS/TLS port can not be protected from unauthorised = connection
   attempts with measures on the network layer, = i.e. access lists and
   firewalls.  This opens more = attack vectors for Distributed Denial of
   Service = attacks, just like any other service that is supposed to
   = serve arbitrary clients (like for example web = servers).

   In the case of dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery], X.509 = certificates are the only
   proof of authorisation for a = connecting RADIUS/TLS nodes.  Special
   care needs to = be taken that certificates get verified properly
   = according to the chosen trust model (particularly: consulting = CRLs,
   checking critical extensions, checking = subjectAltNames etc.) to
   prevent unauthorised = connections.

Other comments

Section 1

   = One mechanism to discover RADIUS over TLS peers with DNS is specified = in
   [I-D.ietf-radext-dynamic-discovery].

[BA] = Recommend moving this to a section devoted to dynamic discovery. =

Section 2.1

   See
   section = Section 3.3 (4) and (5) for considerations regarding
   = separation of authentication, accounting and dynauth = traffic.

[BA] Recommend changing to:

   = "See Section 3.3 for considerations regarding separation = of
    authentication, accounting and dynamic = authorisation traffic."

Section 2.3

   = 4.  start exchanging RADIUS datagrams.  Note Section 3.3 (1) = ).  The
       shared secret to = compute the (obsolete) MD5 integrity checks = and
       attribute encryption MUST be = "radsec" (see Section 3.3 (2) ).

Section = 3.1

   (3) If dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery] is used, peer = authentication
   alone is not sufficient; the peer must = also be authorised to perform
   user = authentications.  In these cases, the trust fabric cannot = depend
   on peer authentication methods like DNSSEC to = identify RADIUS/TLS
   nodes.  The nodes also need to = be properly authorised.  Typically,
   this can be = achieved by adding appropriate authorisation fields into
   = a X.509 certificate.  Such fields include SRV authority = [RFC4985],
   subjectAltNames, or a defined list of = certificate fingerprints.
   Operators of a RADIUS/TLS = infrastructure should define their own
   authorisation = trust model and apply this model to the certificates.
   = The checks enumerated in Section 2.3 provide sufficient = flexibility
   for the implementation of authorisation = trust models.

As noted above, I'd suggest removing this material = from Section 3.1 and
consolidating it with other dynamic-discovery = material.  

Section 3.3

   Note well: it is = not required for an implementation
   to actually process = these packet types.  It is sufficient that upon
   = receiving such a packet, an unconditional NAK is sent back = to
   indicate that the action is not = supported.

[BA] What Error-Cause attribute value should be = included within the NAK to make it
clear that the action is not = supported?  Error 406 "Unsupported Extension"?
That is = what RFC 5176 Section 3.5 seems to indicate.

   = There
   is no RADIUS datagram to signal an Accounting = NAK.  Clients may be
   misconfigured to send = Accounting packets to a RADIUS/TLS server which
   does not = wish to process their Accounting packet.  The server = will
   need to silently drop the packet.  The client = will need to deduce
   from the absence of replies that it = is misconfigured; no negative
   ICMP response will reveal = this.

[BA] This seems like a bad idea.  How about requiring = implementations not
supporting Accounting to respond with an = Accounting-Response containing
Error-Cause attribute value 406?  = Implementations receiving an Accounting-Response
with this = Error-Cause can be required to treat this like an ICMP response. =

Section 4

   As a consequence, the selection of = transports to communicate from a
   client to a server is a = manual administrative action.  An automatic
   = fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to = down-
   bidding attacks on the peer = communication.

[BA] If a fixed shared secret "radsec" = is used alongside fallback to RADIUS/UDP,
that seems more like a MUST = NOT!!

Section 6

   In the case of dynamic peer = discovery as per
   [I-D.ietf-radext-dynamic-discovery], a = RADIUS/TLS node needs to be
   able to accept connections = from a large, not previously known, group
   of hosts, = possibly the whole internet.  In this case, the = server's
   RADIUS/TLS port can not be protected from = unauthorised connection
   attempts with measures on the = network layer, i.e. access lists and
   firewalls.  = This opens more attack vectors for Distributed Denial of
   = Service attacks, just like any other service that is supposed = to
   serve arbitrary clients (like for example web = servers).

   In the case of dynamic peer discovery as = per
   [I-D.ietf-radext-dynamic-discovery], X.509 = certificates are the only
   proof of authorisation for a = connecting RADIUS/TLS nodes.  Special
   care needs to = be taken that certificates get verified properly
   = according to the chosen trust model (particularly: consulting = CRLs,
   checking critical extensions, checking = subjectAltNames etc.) to
   prevent unauthorised = connections.


[BA] I'd recommend collecting this and other = dynamic-discovery related material
into a separate section prior to = 3.1.

Appendix C. Assessment of Crypto-Agility = Requirements


   The RADIUS Crypto-Agility = Requirements (link to RFC once issued here)
   defines = numerous classification criteria for protocols that strive = to
   enhance the security of RADIUS.  It contains = mandatory (M) and
   recommended (R) criteria which = crypto-agile protocols have to
   fulfill.  The = authors believe that the following assessment about the
   = crypto-agility properties of RADIUS/TLS are true.

[BA] The = Crypto-Agility RFC is now published so you should reference that. =

------_=_NextPart_002_01CCD9C3.1E207B74-- ------_=_NextPart_001_01CCD9C3.1E207B74 Content-Type: text/plain; name="ATT8034407.txt" Content-Transfer-Encoding: base64 Content-Description: ATT8034407.txt Content-Disposition: inline; filename="ATT8034407.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFBQS1ET0NU T1JTIG1haWxpbmcgbGlzdA0KQUFBLURPQ1RPUlNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWFhLWRvY3RvcnMNCg== ------_=_NextPart_001_01CCD9C3.1E207B74-- From mauricio.sanchez@hp.com Mon Jan 23 09:52:06 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6270D21F846A for ; Mon, 23 Jan 2012 09:52:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfTybJzpKw6M for ; Mon, 23 Jan 2012 09:52:05 -0800 (PST) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id D628221F843C for ; Mon, 23 Jan 2012 09:52:05 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 3747F3816E for ; Mon, 23 Jan 2012 17:52:05 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 23 Jan 2012 17:51:49 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Mon, 23 Jan 2012 17:51:49 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Mon, 23 Jan 2012 17:51:47 +0000 Thread-Topic: Call for Adoption as a RADEXT WG work item: Thread-Index: AczZ963Rc1goHytiQvmmumbOzQAHUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] Call for Adoption as a RADEXT WG work item: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:52:06 -0000 At IETF 82, the RADEXT WG was polled on whether draft-aboba-radext-wlan (ht= tp://tools.ietf.org/html/draft-aboba-radext-wlan-15) should be accepted as= a RADEXT WG work item. We would now like to verify the results of that po= ll (12-0 in favor of adoption per notes at http://www.ietf.org/proceedings/= 82/minutes/radext.txt) on the mailing list. If you did not indicate your preference during the IETF 82 poll, but wish t= o express your opinion on this matter, please respond to this note. If you are in favor of adoption, please say so. If you are not in favor, please state that, perhaps along with elucidating = the issues you have with the document. This "call for adoption" will last until February 6, 2012 From radext-bounces@ietf.org Mon Jan 23 09:52:07 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C986021F8467; Mon, 23 Jan 2012 09:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327341127; bh=E/8RfeQXWyl1xo9Nz1i6WnxHYUIlQ16fAivOaf1Zzfw=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=bBxNSJ42WoqvhyrVT+MbtrcPH5eOAbXSSaSYK3dHlahdGB/Rr+Gh/dnuUh+T+sAyc 6wt71UlD9ADTUL/5pdlu4USanTpBMVTRvZeO1WmUqCmAphxXpLBbPr5WL4zJMO3KAj OSe1CajFbotw7t/yiGslUq/CxYZo3bBhHbrXmVo0= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6270D21F846A for ; Mon, 23 Jan 2012 09:52:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfTybJzpKw6M for ; Mon, 23 Jan 2012 09:52:05 -0800 (PST) Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id D628221F843C for ; Mon, 23 Jan 2012 09:52:05 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 3747F3816E for ; Mon, 23 Jan 2012 17:52:05 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 23 Jan 2012 17:51:49 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Mon, 23 Jan 2012 17:51:49 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Mon, 23 Jan 2012 17:51:47 +0000 Thread-Topic: Call for Adoption as a RADEXT WG work item: Thread-Index: AczZ963Rc1goHytiQvmmumbOzQAHUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: [radext] Call for Adoption as a RADEXT WG work item: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org At IETF 82, the RADEXT WG was polled on whether draft-aboba-radext-wlan (http://tools.ietf.org/html/draft-aboba-radext-wlan-15) should be accepted as a RADEXT WG work item. We would now like to verify the results of that poll (12-0 in favor of adoption per notes at http://www.ietf.org/proceedings/82/minutes/radext.txt) on the mailing list. If you did not indicate your preference during the IETF 82 poll, but wish to express your opinion on this matter, please respond to this note. If you are in favor of adoption, please say so. If you are not in favor, please state that, perhaps along with elucidating the issues you have with the document. This "call for adoption" will last until February 6, 2012 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From trac+radext@trac.tools.ietf.org Mon Jan 23 10:57:09 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B488721F847E for ; Mon, 23 Jan 2012 10:57:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zbUEBuEkQcd for ; Mon, 23 Jan 2012 10:57:09 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2339D21F8478 for ; Mon, 23 Jan 2012 10:57:08 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpP4b-0004tI-Sb; Mon, 23 Jan 2012 13:56:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Mon, 23 Jan 2012 18:56:57 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/104#comment:1 Message-ID: <081.81d434b9c5db76f7bffb771fad191912@trac.tools.ietf.org> References: <066.5ac4fc24a7c755a6b5b25c2c3c2dd2f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <066.5ac4fc24a7c755a6b5b25c2c3c2dd2f9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123185709.2339D21F8478@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 10:57:08 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #104: IANA Considerations Issues X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:57:09 -0000 #104: IANA Considerations Issues Changes (by aland@…): * status: new => closed * resolution: => fixed Comment: All of these comments are addressed in the -04 draft. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext-radius- bernard_aboba@… | extensions@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: radius- | Version: 1.0 extensions | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From radext-bounces@ietf.org Mon Jan 23 10:57:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC90121F847E; Mon, 23 Jan 2012 10:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327345030; bh=1Lf51aJS1LjzHU6QAPuCxl9sylBC1bqPkOQfBn9+mwY=; h=MIME-Version:From:To:Date:Message-ID:References:In-Reply-To: Resent-To:Resent-Message-Id:Resent-Date:Resent-From:Cc:Subject: Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=r6Jm5uuJIj0FJUDqwtEAg+Kjmv+21WVZUm9Xp63fTaMLdZ0HbD2yExIayPYvOE+Zq gVw/Qw4oXRzYTjZI+nRjNECM5XRVaiS7i7uWMJqcbQQTdx+AziNjcpec8YHtJHHRom zJhss3SA2Grb2Dovc9S4vmIkrnnGk0srq0qQ+FVw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B488721F847E for ; Mon, 23 Jan 2012 10:57:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zbUEBuEkQcd for ; Mon, 23 Jan 2012 10:57:09 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2339D21F8478 for ; Mon, 23 Jan 2012 10:57:08 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpP4b-0004tI-Sb; Mon, 23 Jan 2012 13:56:59 -0500 MIME-Version: 1.0 From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Mon, 23 Jan 2012 18:56:57 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/104#comment:1 Message-ID: <081.81d434b9c5db76f7bffb771fad191912@trac.tools.ietf.org> References: <066.5ac4fc24a7c755a6b5b25c2c3c2dd2f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 104 In-Reply-To: <066.5ac4fc24a7c755a6b5b25c2c3c2dd2f9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123185709.2339D21F8478@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 10:57:08 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #104: IANA Considerations Issues X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org IzEwNDogSUFOQSBDb25zaWRlcmF0aW9ucyBJc3N1ZXMKCkNoYW5nZXMgKGJ5IGFsYW5kQOKApik6 CgogKiBzdGF0dXM6ICBuZXcgPT4gY2xvc2VkCiAqIHJlc29sdXRpb246ICAgPT4gZml4ZWQKCgpD b21tZW50OgoKIEFsbCBvZiB0aGVzZSBjb21tZW50cyBhcmUgYWRkcmVzc2VkIGluIHRoZSAtMDQg ZHJhZnQuCgotLSAKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiBSZXBvcnRlcjogICAgICAgICAgICAgICB8 ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1yYWRleHQtcmFkaXVzLQogIGJlcm5hcmRfYWJvYmFA 4oCmICAgICAgICB8ICBleHRlbnNpb25zQOKApgogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgfCAg ICAgIFN0YXR1czogIGNsb3NlZAogUHJpb3JpdHk6ICBibG9ja2VyICAgICAgfCAgIE1pbGVzdG9u ZTogIG1pbGVzdG9uZTEKQ29tcG9uZW50OiAgcmFkaXVzLSAgICAgIHwgICAgIFZlcnNpb246ICAx LjAKICBleHRlbnNpb25zICAgICAgICAgICAgIHwgIFJlc29sdXRpb246ICBmaXhlZAogU2V2ZXJp dHk6ICBJbiBXRyBMYXN0ICAgfAogIENhbGwgICAgICAgICAgICAgICAgICAgfAogS2V5d29yZHM6 ICAgICAgICAgICAgICAgfAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRpY2tldCBVUkw6IDxodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9yYWRleHQvdHJhYy90aWNrZXQvMTA0I2NvbW1lbnQ6MT4K cmFkZXh0IDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmFkZXh0Lz4KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QKcmFkZXh0 QGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0Cg== From trac+radext@trac.tools.ietf.org Mon Jan 23 11:08:29 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BC221F86AA for ; Mon, 23 Jan 2012 11:08:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL6pgv1j9RPL for ; Mon, 23 Jan 2012 11:08:29 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFEB21F86A9 for ; Mon, 23 Jan 2012 11:08:28 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpPFa-0002Ki-RE; Mon, 23 Jan 2012 14:08:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-radius-extensions@tools.ietf.org, peterd@iea-software.com, aland@deployingradius.com X-Trac-Project: radext Date: Mon, 23 Jan 2012 19:08:18 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/103#comment:2 Message-ID: <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, peterd@iea-software.com, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123190829.0EFEB21F86A9@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 11:08:28 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 19:08:29 -0000 #103: Long attribute fragmentation constraints Changes (by aland@…): * status: new => closed * resolution: => invalid Comment: The document is clear: > This means if I started a fragment with vendor id 4444 and before finishing that fragment start a new fragment with vendor id 3333 the implementation would have no choice other than to think vendor id 3333 attribute is a continuation of the 4444 fragment rather than presenting an error. Yes. That's how it works. The same issue applies when nested TLVs are used. Or when multiple "long" attributes are used. Inserting a new attribute into the middle of a list of attributes is wrong. While this is technically allowed by RFC 2865, I am not aware of any RADIUS implementation which is *required* to do such insertions. In contrast, most make it difficult to perform such insertions. We have the same argument against EAP-Message. There are RADIUS proxies which do not do EAP authentication, and are unaware of EAP. They have not been demonstrated to have this issue in the real world. Similarly, WiMAX uses attributes longer than 253 octets, and has its own "continuation" bit. Problems with WiMAX continuations have not been observed in the real world. Any RADIUS implementation which erroneously uses the 244..245 space for other definitions is already in violation of the RFCS. If they're violating the RFCs, then all bets are off. Those systems don't implement RADIUS correctly, and need to be fixed. To summarize, this argument is entirely specious. There exist multiple "fragmented" attributes today, none of which have shown problems in the real world. Any system which does create problems is either violating the current RFCs, or will be violating this document (if the implementation understands it). > So the reader is left wondering at least one of two things: >1) Should I assume string is the value field? > 2) Should I assume Vendor-ID is the value field? The Vendor-Id is the VALUE field of the attributes with format Extended- Type with flags. The Vendor-Id in turn has a value field, which can be of type string, etc. The same explanation applies to nested TLVs. The fact that there are multiple fields that can be called "value" is no reason to confuse them. They have clearly defined contexts. -- -------------------------+------------------------------------------------- Reporter: peterd@… | Owner: draft-ietf-radext-radius- Type: defect | extensions@… Priority: major | Status: closed Component: radius- | Milestone: milestone1 extensions | Version: 1.0 Severity: Active WG | Resolution: invalid Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From radext-bounces@ietf.org Mon Jan 23 11:08:31 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680C321F86AB; Mon, 23 Jan 2012 11:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327345711; bh=knn3VN2XqIgcgqP7Ja6liHy4TXcQluW7cezjwvvRaIk=; h=MIME-Version:From:To:Date:Message-ID:References:In-Reply-To: Resent-To:Resent-Message-Id:Resent-Date:Resent-From:Cc:Subject: Reply-To:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=JeBuVEr9KhHVPoRV03w2J+W32g+GCBL8SpeKUyhEAC35laLqdvRUYa0J908CFDD93 5+UR9hExeCoHeUYEUHTJbZ14zKYyaqJhx+mzkRypoR8rUfrxur2rYWl0g+kRct6ZV4 jMhiaaJCC0KGRUEAp2e0N52X/a+nDeDxLtvHa1Hw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BC221F86AA for ; Mon, 23 Jan 2012 11:08:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL6pgv1j9RPL for ; Mon, 23 Jan 2012 11:08:29 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFEB21F86A9 for ; Mon, 23 Jan 2012 11:08:28 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RpPFa-0002Ki-RE; Mon, 23 Jan 2012 14:08:18 -0500 MIME-Version: 1.0 From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-radius-extensions@tools.ietf.org, peterd@iea-software.com, aland@deployingradius.com X-Trac-Project: radext Date: Mon, 23 Jan 2012 19:08:18 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/103#comment:2 Message-ID: <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-extensions@tools.ietf.org, peterd@iea-software.com, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120123190829.0EFEB21F86A9@ietfa.amsl.com> Resent-Date: Mon, 23 Jan 2012 11:08:28 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org IzEwMzogTG9uZyBhdHRyaWJ1dGUgZnJhZ21lbnRhdGlvbiBjb25zdHJhaW50cwoKQ2hhbmdlcyAo YnkgYWxhbmRA4oCmKToKCiAqIHN0YXR1czogIG5ldyA9PiBjbG9zZWQKICogcmVzb2x1dGlvbjog ICA9PiBpbnZhbGlkCgoKQ29tbWVudDoKCiBUaGUgZG9jdW1lbnQgaXMgY2xlYXI6CgogPiBUaGlz IG1lYW5zIGlmIEkgc3RhcnRlZCBhIGZyYWdtZW50IHdpdGggdmVuZG9yIGlkIDQ0NDQgYW5kIGJl Zm9yZQogZmluaXNoaW5nIHRoYXQgZnJhZ21lbnQgc3RhcnQgYSBuZXcgZnJhZ21lbnQgd2l0aCB2 ZW5kb3IgaWQgMzMzMyB0aGUKIGltcGxlbWVudGF0aW9uIHdvdWxkIGhhdmUgbm8gY2hvaWNlIG90 aGVyIHRoYW4gdG8gdGhpbmsgdmVuZG9yIGlkIDMzMzMKIGF0dHJpYnV0ZSBpcyBhIGNvbnRpbnVh dGlvbiBvZiB0aGUgNDQ0NCBmcmFnbWVudCByYXRoZXIgdGhhbiBwcmVzZW50aW5nIGFuCiBlcnJv ci4KCiAgIFllcy4gIFRoYXQncyBob3cgaXQgd29ya3MuICBUaGUgc2FtZSBpc3N1ZSBhcHBsaWVz IHdoZW4gbmVzdGVkIFRMVnMgYXJlCiB1c2VkLiAgT3Igd2hlbiBtdWx0aXBsZSAibG9uZyIgYXR0 cmlidXRlcyBhcmUgdXNlZC4KCiAgIEluc2VydGluZyBhIG5ldyBhdHRyaWJ1dGUgaW50byB0aGUg bWlkZGxlIG9mIGEgbGlzdCBvZiBhdHRyaWJ1dGVzIGlzCiB3cm9uZy4gIFdoaWxlIHRoaXMgaXMg dGVjaG5pY2FsbHkgYWxsb3dlZCBieSBSRkMgMjg2NSwKIEkgYW0gbm90IGF3YXJlIG9mIGFueSBS QURJVVMgaW1wbGVtZW50YXRpb24gd2hpY2ggaXMgKnJlcXVpcmVkKiB0byBkbyBzdWNoCiBpbnNl cnRpb25zLiAgSW4gY29udHJhc3QsIG1vc3QgbWFrZSBpdCBkaWZmaWN1bHQKIHRvIHBlcmZvcm0g c3VjaCBpbnNlcnRpb25zLgoKICAgV2UgaGF2ZSB0aGUgc2FtZSBhcmd1bWVudCBhZ2FpbnN0IEVB UC1NZXNzYWdlLiAgIFRoZXJlIGFyZSBSQURJVVMKIHByb3hpZXMgd2hpY2ggZG8gbm90IGRvIEVB UCBhdXRoZW50aWNhdGlvbiwKIGFuZCBhcmUgdW5hd2FyZSBvZiBFQVAuICBUaGV5IGhhdmUgbm90 IGJlZW4gZGVtb25zdHJhdGVkIHRvIGhhdmUgdGhpcwogaXNzdWUgaW4gdGhlIHJlYWwgd29ybGQu CgogICBTaW1pbGFybHksIFdpTUFYIHVzZXMgYXR0cmlidXRlcyBsb25nZXIgdGhhbiAyNTMgb2N0 ZXRzLCBhbmQgaGFzIGl0cyBvd24KICJjb250aW51YXRpb24iIGJpdC4gIFByb2JsZW1zIHdpdGgg V2lNQVggY29udGludWF0aW9ucyBoYXZlIG5vdCBiZWVuCiBvYnNlcnZlZCBpbiB0aGUgcmVhbCB3 b3JsZC4KCiAgIEFueSBSQURJVVMgaW1wbGVtZW50YXRpb24gd2hpY2ggZXJyb25lb3VzbHkgdXNl cyB0aGUgMjQ0Li4yNDUgc3BhY2UgZm9yCiBvdGhlciBkZWZpbml0aW9ucyBpcyBhbHJlYWR5IGlu IHZpb2xhdGlvbiBvZiB0aGUgUkZDUy4KIElmIHRoZXkncmUgdmlvbGF0aW5nIHRoZSBSRkNzLCB0 aGVuIGFsbCBiZXRzIGFyZSBvZmYuICBUaG9zZSBzeXN0ZW1zIGRvbid0CiBpbXBsZW1lbnQgUkFE SVVTIGNvcnJlY3RseSwgYW5kIG5lZWQgdG8gYmUgZml4ZWQuCgogICBUbyBzdW1tYXJpemUsIHRo aXMgYXJndW1lbnQgaXMgZW50aXJlbHkgc3BlY2lvdXMuICBUaGVyZSBleGlzdCBtdWx0aXBsZQog ImZyYWdtZW50ZWQiIGF0dHJpYnV0ZXMgdG9kYXksIG5vbmUgb2Ygd2hpY2ggaGF2ZSBzaG93biBw cm9ibGVtcyBpbiB0aGUKIHJlYWwgd29ybGQuICBBbnkgc3lzdGVtIHdoaWNoIGRvZXMgY3JlYXRl IHByb2JsZW1zIGlzIGVpdGhlciB2aW9sYXRpbmcgdGhlCiBjdXJyZW50IFJGQ3MsIG9yIHdpbGwg YmUgdmlvbGF0aW5nIHRoaXMgZG9jdW1lbnQgKGlmIHRoZSBpbXBsZW1lbnRhdGlvbgogdW5kZXJz dGFuZHMgaXQpLgoKID4gU28gdGhlIHJlYWRlciBpcyBsZWZ0IHdvbmRlcmluZyBhdCBsZWFzdCBv bmUgb2YgdHdvIHRoaW5nczoKID4xKSAgU2hvdWxkIEkgYXNzdW1lIHN0cmluZyBpcyB0aGUgdmFs dWUgZmllbGQ/CiA+IDIpIFNob3VsZCBJIGFzc3VtZSBWZW5kb3ItSUQgaXMgdGhlIHZhbHVlIGZp ZWxkPwoKICAgVGhlIFZlbmRvci1JZCBpcyB0aGUgVkFMVUUgZmllbGQgb2YgdGhlIGF0dHJpYnV0 ZXMgd2l0aCBmb3JtYXQgRXh0ZW5kZWQtCiBUeXBlIHdpdGggZmxhZ3MuICBUaGUgVmVuZG9yLUlk IGluIHR1cm4gaGFzIGEgdmFsdWUgZmllbGQsIHdoaWNoIGNhbiBiZSBvZgogdHlwZSBzdHJpbmcs IGV0Yy4KCiAgIFRoZSBzYW1lIGV4cGxhbmF0aW9uIGFwcGxpZXMgdG8gbmVzdGVkIFRMVnMuICBU aGUgZmFjdCB0aGF0IHRoZXJlIGFyZQogbXVsdGlwbGUgZmllbGRzIHRoYXQgY2FuIGJlIGNhbGxl ZCAidmFsdWUiIGlzIG5vIHJlYXNvbiB0byBjb25mdXNlIHRoZW0uCiBUaGV5IGhhdmUgY2xlYXJs eSBkZWZpbmVkIGNvbnRleHRzLgoKLS0gCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogUmVwb3J0ZXI6ICBw ZXRlcmRA4oCmICAgICB8ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1yYWRleHQtcmFkaXVzLQog ICAgIFR5cGU6ICBkZWZlY3QgICAgICAgfCAgZXh0ZW5zaW9uc0DigKYKIFByaW9yaXR5OiAgbWFq b3IgICAgICAgIHwgICAgICBTdGF0dXM6ICBjbG9zZWQKQ29tcG9uZW50OiAgcmFkaXVzLSAgICAg IHwgICBNaWxlc3RvbmU6ICBtaWxlc3RvbmUxCiAgZXh0ZW5zaW9ucyAgICAgICAgICAgICB8ICAg ICBWZXJzaW9uOiAgMS4wCiBTZXZlcml0eTogIEFjdGl2ZSBXRyAgICB8ICBSZXNvbHV0aW9uOiAg aW52YWxpZAogIERvY3VtZW50ICAgICAgICAgICAgICAgfAogS2V5d29yZHM6ICAgICAgICAgICAg ICAgfAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRpY2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5p ZXRmLm9yZy93Zy9yYWRleHQvdHJhYy90aWNrZXQvMTAzI2NvbW1lbnQ6Mj4KcmFkZXh0IDxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcmFkZXh0Lz4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCnJhZGV4dCBtYWlsaW5nIGxpc3QKcmFkZXh0QGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmFkZXh0Cg== From peterd@iea-software.com Mon Jan 23 12:52:07 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1333321F8525 for ; Mon, 23 Jan 2012 12:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+8+cV9MM8ch for ; Mon, 23 Jan 2012 12:52:06 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7128121F84C9 for ; Mon, 23 Jan 2012 12:52:06 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 23 Jan 2012 12:52:05 -0800 Date: Mon, 23 Jan 2012 12:52:05 -0800 (Pacific Standard Time) From: Peter Deacon To: radext@ietf.org In-Reply-To: <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: trac+radext@trac.tools.ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:52:07 -0000 On Mon, 23 Jan 2012, radext issue tracker wrote: > Inserting a new attribute into the middle of a list of attributes is > wrong. Says who? > While this is technically allowed by RFC 2865, I am not aware of > any RADIUS implementation which is *required* to do such insertions. What happens when an RFC compliant implementation behaves in a manner your not aware for reasons your not aware? > In contrast, most make it difficult to perform such insertions. > We have the same argument against EAP-Message. There are RADIUS > proxies which do not do EAP authentication, and are unaware of EAP. > They have not been demonstrated to have this issue in the real world. Although it is tempting to draw parallels with EAP experience there is only one instance of an *EAP packet* allowed per RADIUS message. RFC 3579 3.1 "Multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request packet." > Similarly, WiMAX uses attributes longer than 253 octets, and has its > own "continuation" bit. Problems with WiMAX continuations have not been > observed in the real world. Who has seen even a single WIMAX VSA with continuation bit set? > To summarize, this argument is entirely specious. There exist > multiple "fragmented" attributes today, none of which have shown > problems in the real world. Any system which does create problems is > either violating the current RFCs, or will be violating this document > (if the implementation understands it). I understand you may disagree with regards to the degree this may be a problem. I don't believe this warrants marking my issue 'invalid'. Fundamentally I think it is better to work from the position of what the RFCs actually say rather than what we all wish they would have said. I am not seeking major unreasonable disruptive change. Only to mitigate against possibilities that MAY exist in a fully RFC compliant system. regards, Peter From radext-bounces@ietf.org Mon Jan 23 12:52:08 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A10921F8525; Mon, 23 Jan 2012 12:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327351928; bh=ltNDtMGseiI8G25ZGVLqH5CF/hoMbhLQ5PfSE+6vsMs=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=wqLCHavMOCcFu6eOJkUeTw8plZ9dCPjAFYW3PfRx+kWn5EUnreX8R8dp4q+J5lQnp DlYiDJqEKPasPyoY0QBcjQptuoVe3fh/XRt3m/hvNafHwmMmXQ7hRCq3lWbZA10eA+ 65/9W+sWlzwpKmU2zVST9n8gUlzQ1HA7MeIMCxyY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1333321F8525 for ; Mon, 23 Jan 2012 12:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+8+cV9MM8ch for ; Mon, 23 Jan 2012 12:52:06 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7128121F84C9 for ; Mon, 23 Jan 2012 12:52:06 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 23 Jan 2012 12:52:05 -0800 Date: Mon, 23 Jan 2012 12:52:05 -0800 (Pacific Standard Time) From: Peter Deacon To: radext@ietf.org In-Reply-To: <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: trac+radext@trac.tools.ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, aland@deployingradius.com Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Mon, 23 Jan 2012, radext issue tracker wrote: > Inserting a new attribute into the middle of a list of attributes is > wrong. Says who? > While this is technically allowed by RFC 2865, I am not aware of > any RADIUS implementation which is *required* to do such insertions. What happens when an RFC compliant implementation behaves in a manner your not aware for reasons your not aware? > In contrast, most make it difficult to perform such insertions. > We have the same argument against EAP-Message. There are RADIUS > proxies which do not do EAP authentication, and are unaware of EAP. > They have not been demonstrated to have this issue in the real world. Although it is tempting to draw parallels with EAP experience there is only one instance of an *EAP packet* allowed per RADIUS message. RFC 3579 3.1 "Multiple EAP packets MUST NOT be encoded within EAP-Message attributes contained within a single Access-Challenge, Access-Accept, Access-Reject or Access-Request packet." > Similarly, WiMAX uses attributes longer than 253 octets, and has its > own "continuation" bit. Problems with WiMAX continuations have not been > observed in the real world. Who has seen even a single WIMAX VSA with continuation bit set? > To summarize, this argument is entirely specious. There exist > multiple "fragmented" attributes today, none of which have shown > problems in the real world. Any system which does create problems is > either violating the current RFCs, or will be violating this document > (if the implementation understands it). I understand you may disagree with regards to the degree this may be a problem. I don't believe this warrants marking my issue 'invalid'. Fundamentally I think it is better to work from the position of what the RFCs actually say rather than what we all wish they would have said. I am not seeking major unreasonable disruptive change. Only to mitigate against possibilities that MAY exist in a fully RFC compliant system. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Jan 23 13:47:41 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6D21F86A4 for ; Mon, 23 Jan 2012 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uajHnXwj37jE for ; Mon, 23 Jan 2012 13:47:40 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4321F868C for ; Mon, 23 Jan 2012 13:47:40 -0800 (PST) Message-ID: <4F1DD563.2060802@deployingradius.com> Date: Mon, 23 Jan 2012 22:47:15 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 21:47:41 -0000 Peter Deacon wrote: >> Inserting a new attribute into the middle of a list of attributes is >> wrong. > > Says who? Says the extensions draft. > Although it is tempting to draw parallels with EAP experience there is > only one instance of an *EAP packet* allowed per RADIUS message. RFC 2865 says nothing about EAP packets. It's perfectly legal under RFC 2865 to insert one instance of attribute 79 in the middle of a list of attribute 79's. Doing so will break EAP. So by your argument, adding EAP to RADIUS is impossible. > Who has seen even a single WIMAX VSA with continuation bit set? Is it really necessary to ask a rhetorical question? There's also RFC 5904, which defines two more attributes that can span multiple RADIUS attributes. I think it's time to stop discussing the theoretical issue of insertions into the middle of a list. That ship has sailed. There are multiple IETF and SSO specifications which violate your requirements. They are widely deployed, and no one has indicated there is *any* problem with them. > I understand you may disagree with regards to the degree this may be a > problem. I don't believe this warrants marking my issue 'invalid'. I don't see it as a valid objection. It's based on assumptions which have proven to be false for a decade. > Fundamentally I think it is better to work from the position of what the > RFCs actually say rather than what we all wish they would have said. Let's discard RFC 2869 because it's "Informational" and RFC 2865 is "Standards Track". 2869 CLEARLY VIOLATES 2865. Then, we'll deploy an RFC 2865 compliant RADIUS proxy. We'll have it mangle attribute 79 as per your argument. It's allowed under 2865. It's exactly your scenario. You MUST then agree that 2869 is wrong and impossible to implement. Except we've already proven that argument false. RFC 2869 has proven it false for over a decade. Therefore, your arguments against the extensions draft don't apply, either. > I am not seeking major unreasonable disruptive change. Only to mitigate > against possibilities that MAY exist in a fully RFC compliant system. It's impossible to be fully compliant to the RADIUS RFCs. They are contradictory, incomplete, and often plain wrong. See RFC 5080. The only question now is whether or not we can build something which works. I believe so, and have given proof. Alan DeKok. From radext-bounces@ietf.org Mon Jan 23 13:47:43 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E59821F86A4; Mon, 23 Jan 2012 13:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327355263; bh=E+3q/K548F1EHjaBrmPzvonNDEFS4NXAEGuGbjzZddA=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=a9nhekZURZawhDdDwq+lZKBPowCuVeRoeM3HnkpkIHJW56xKNuZfu6FdCDIEKm9dF QiiSvFGoFlu45xW9ioTC+SFMB+ghUR68oHUgGeJb4knqneddKnClLvMBui5ghFJE03 g0xUXYWDk7Nw8ghvm6z1bA8Hepr0IvBb+ZSyVE04= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6D21F86A4 for ; Mon, 23 Jan 2012 13:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uajHnXwj37jE for ; Mon, 23 Jan 2012 13:47:40 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4321F868C for ; Mon, 23 Jan 2012 13:47:40 -0800 (PST) Message-ID: <4F1DD563.2060802@deployingradius.com> Date: Mon, 23 Jan 2012 22:47:15 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: >> Inserting a new attribute into the middle of a list of attributes is >> wrong. > > Says who? Says the extensions draft. > Although it is tempting to draw parallels with EAP experience there is > only one instance of an *EAP packet* allowed per RADIUS message. RFC 2865 says nothing about EAP packets. It's perfectly legal under RFC 2865 to insert one instance of attribute 79 in the middle of a list of attribute 79's. Doing so will break EAP. So by your argument, adding EAP to RADIUS is impossible. > Who has seen even a single WIMAX VSA with continuation bit set? Is it really necessary to ask a rhetorical question? There's also RFC 5904, which defines two more attributes that can span multiple RADIUS attributes. I think it's time to stop discussing the theoretical issue of insertions into the middle of a list. That ship has sailed. There are multiple IETF and SSO specifications which violate your requirements. They are widely deployed, and no one has indicated there is *any* problem with them. > I understand you may disagree with regards to the degree this may be a > problem. I don't believe this warrants marking my issue 'invalid'. I don't see it as a valid objection. It's based on assumptions which have proven to be false for a decade. > Fundamentally I think it is better to work from the position of what the > RFCs actually say rather than what we all wish they would have said. Let's discard RFC 2869 because it's "Informational" and RFC 2865 is "Standards Track". 2869 CLEARLY VIOLATES 2865. Then, we'll deploy an RFC 2865 compliant RADIUS proxy. We'll have it mangle attribute 79 as per your argument. It's allowed under 2865. It's exactly your scenario. You MUST then agree that 2869 is wrong and impossible to implement. Except we've already proven that argument false. RFC 2869 has proven it false for over a decade. Therefore, your arguments against the extensions draft don't apply, either. > I am not seeking major unreasonable disruptive change. Only to mitigate > against possibilities that MAY exist in a fully RFC compliant system. It's impossible to be fully compliant to the RADIUS RFCs. They are contradictory, incomplete, and often plain wrong. See RFC 5080. The only question now is whether or not we can build something which works. I believe so, and have given proof. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Mon Jan 23 14:12:21 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3993221F8701; Mon, 23 Jan 2012 14:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327356741; bh=NSBdjK8WBRPQBygGjZUbxDP+sOedt2qnkvLENFBvOpw=; h=From:To:Date:Message-ID:Content-Type:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Sender; b=tyYfjlk/8PP/hhi+BEyykgbEcnchNyCovZYdRVgyNKrDLx2SAWD/rBgU3YWqUGRpE x6nN47dmjfI94slFlDXwJMFaEJBkCWLfYh8aCYTHERDKQBWS3FolgrCVfFwgAxd+De a1ILF4INnOdKClWxjJlLmCCH9/lZztQYoHz+w53o= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2E121F8559 for ; Mon, 23 Jan 2012 14:12:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B95IKYDGm+2 for ; Mon, 23 Jan 2012 14:12:18 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 433A721F84E7 for ; Mon, 23 Jan 2012 14:12:18 -0800 (PST) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 97D443825F for ; Mon, 23 Jan 2012 22:12:17 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 23 Jan 2012 22:11:43 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Mon, 23 Jan 2012 22:11:42 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Mon, 23 Jan 2012 22:11:22 +0000 Thread-Topic: RADEXT recharter Thread-Index: AczaG/xDKiJT9gNoRwm22tOW8sfaJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_CB431B0A1C095mauriciosanchezhpcom_" MIME-Version: 1.0 Subject: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 82, the RADEXT WG discussed (see notes section 7 http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the charter to position the WG to be able to embrace several work items that the WG believes relevant, as well as recalibrating dates on several committed goals. =20 Below is the new proposed WG charter that your chairs and AD agreed upon. Attached are a PDF version of updated milestones and a marked version detailing changes introduced from existing charter. At this time the chairs would like to open up the list for discussion. Propose your changes and justify why. =20 Our aim is to have this re-chartering discussion completed by next IETF meeting. =20 - Mauricio and Jouni =09 --------- Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: -RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. -RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. -IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify egregious issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC=20 --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: application/pdf; name="radext charter-milestones.pdf" Content-Description: radext charter-milestones.pdf Content-Disposition: attachment; filename="radext charter-milestones.pdf"; size=63691; creation-date="Mon, 23 Jan 2012 22:11:41 GMT"; modification-date="Mon, 23 Jan 2012 22:11:41 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFnFtv3Mhyx9/nU/BRAqTZ4W0u501Z7y4UwEmOpM0eIMiD LMmXxCvZK/lskk+fX/W/2OwekRzaVhAIINm36rpX9WX0ufhr8bnYLet1UdfLbbNa1UW7q5fVttg0 2+W2+OOu+K24L3748bEsbh6LVfh7vGHQalk1KtvHplpW9W7LsFW13K0XN78X/3BVbNrQw19Xvxc/ XF2Vy1VRFldvi38rjl4dF6fAKY7uuo/H7uOm+/jjeKE+H45tzuLok7+fuooHr7j3d+Hvrv5tV/Fb AFUXR13LH90k/9l9dDA7WO/2YP7i5YhVB+qLN4DdvxdX/1j8dBVYm3OprnYwa9VxqRjg0mKPS0cg f/Ufw+Ai09ebdllWDm61XK122+LqZtGUgf3+EuAqYf/V+2NEYcznyTzr4ugCRsDjM17UmXwonR8v aPpVhUs1qftPKvxXgPB0XLQdNPjHeKTJcHjKcBhFzf3xItYLxG+AiM0IpCmOkEYcJkCIgWEMYAJE cIoMkQBdBRXm0wzrY6c/6RRhfAwI6CkYbxOU0LRqcSQQQlh9OoR7oGJUJBasVZMTa7xKx0aY1ItF ahX5qomCmNCd7WZZ79ZlIWG7hU2KeEp36t1qWW6aNgeH7pTlDt0pJgFjuheoCNx+dX5cbNENtEK8 3y5MDkE+LnW+IZJOkM037Jbc+EYk1MMInoheDKX+c+j55XjBN9qz13o7ZWLtql1uNrud0+U2kVHj JhYtYYpN7Wq7bNttlYMzE2vqOSb2BNGnKC00jou2t+N1jR27aIMdV3NkcSeV/HR9f5vPs8jdT7na LLf1alOswzypvzg4zwKZC77Z+L0MFdlQQqLI/n0+9V58KFu0d2V83Ccx8PGguj1hIcZHDC6wE6M6 RY2ernHpVGOB9kIz7HWtFziaE/PKwmufnrwe5Gl9o76Y/2m7OHrag48qJwAtJjEpfcZlWW3LZbXZ fhOdRyfwcMzZV9s1wmvWzyHvDgrPYu317a2EdgfvIFxPE9piPFwRVrY7XM6+vmyJ4KM+Ag+v8H7D hFjwf8M2JjRe8sIXyP6tgF+3l/qZgPp+JvByYeZP9xvw5OU9cBsUfKwZWASh3poiACiOfpe0FoMB uSEgl3XT5BRm3qLYi5uY8mJMRk1dLndl9bUGFhl2/U4WBYGosb4VIODhuM41GFez7YhI3Mc82zop gvYHlXD9NqWHzokpUfNd05nzQU+yIPGL/hZlfCAAhynseX9n0RpFmfQgvZNsy9xJTiojqi5lfDTT RlFujNioMKFyYTOjUdKbTBnNsdD50ZU3UzZ1f8xUk/zG+pvP4aWmG+mrK6/AS1HhAtO6fahzqsGA thzHEX50AK73Ts7e7GHabHYv3AkxzahJnLZ0Rn07ld6+DEgyT9SGxX72j2dHAcklgmiGYu6AFcnT LWwBkoepXtJVS8KvJDmG3PFQsZCgzw1vUy4PvTC8Ewm1xjZeXlnE+Oz1PtbDigcH5IcwvUcBjyh5 xy5gODyf0sNGnCvohImPmW3ZwnjvuYfr2yKPc8/Ah2hnGtCT4iB8MoebW3RxwQiyqDNeG6X15Gnn v6qW3M1qf3ilovBzbPGep+UqEp/gE7Wh+LyXZtSb3XK1W6EOifwO+dRRbajxNNs1K8sU2ozcyLXh 9u6TvOkDZgbfjSDj3b38qqLgSeKNrtVdT7SezhfYDu7JuMeawthE6SeV/qbXFS+gq78taWDoL7ye ebU9XvW6XrLq7nV9RhZuGdmfiJsp0D5yZ5ZNeAtQQNIIkSc08kQz6GOEgz0Ex06vVUXybosySKCd 4aCeJunoF8MFCq3gW8BVr/6qt6kXR6/UrCqfVSgAA9j6BuVEg/Y8QFWTqLYtiYdx5XuXOqy4l+u6 Jj4m0EyD5gWOGzMp1xy47JEA8iw9gSTYCcU8zVvQTwX0JzaoU+bmYzTqAPhi1gDA2HHW1DXrtqol DcwVRuuR3DnuL3RQmJPOK7qDeAJP4ayJzTYgoC+4r8EvBdfj7sUCNpr1Lb4wsM24x0zuXzVhismT Mcv01CdSD1sEjHOm2VbLpm7JSRIxz3M7A1s1hLNlVdY4sQQaSjPDMMPOFhjDoEEjWESblN1iNuNU 9Q5ixcJi30Ec3OL5U3jAWybV06w0sB5Lli3Kbt1UhbKGTZu+BpNfAGiZ0PAsPSjbZtmWKwwwoWGe ZKbSg5ZdLzYq+/wg7HrlJtDnHTHJ/hnVR7/hPQqG+WHT6BU10BPrjRk0o+6xSs0nDAj5IsM0WH3g ITXqA9sYhafFn6aTqVU9UX36kGfwxNvSU7tepvAUkEKcGA7zzTAsRl01peOIQ4qQwEgGDC6aAUHy jeR56lt9FA0F1OeMzRAojqhZaGuPQX1EmshXjUjGWURML0TImfJOC5qQdR7ws7yDwmWiM8+SwBrh blbrTZFKeVrdjUVjK7N6oww1QluwPW0xoLad0jGdgRrllB+M15YHeWb3EZ6YA1P1wuRuRbhgLxhj ftydnJc+uOv0PrDQFAx1sq5grhHByXqbV7oL9Ck+fox9w1x93xk+pGUdX22TBeL/YwT0aGlkwYCn sNIxUmGK1/nLGCYW0WRaxeuMF17HtIoSWsXTtIoXyYxnXRRMBIx1EBhSD8nHor59PxOnrLjHybHA XTAh4hpnc7VpUKhNU4jN7pgyP7cfkadUttqsl5ttu83Bmc7O3HrMlxLFW1dAfAEs0TNULY5cxeCF Mwsl7gI/hBszjA3Uurrle2i+L8bKxrzZoJ53u285NM8f9ozLkfKpfGKTHfN36YtbUeGtOCeTfbc8 6W3MpDWy9cN+etPu1s/ZO+kSYhgZtmeMc1xBYiwntf0eO3R1fpTuBq2WC4L70lNX2kzh3eCyNBTf BNtMUSTicXaVtrTfkl0J9yHl7mOt/CbKPbpTVrY1x4SkVxm4g/lV5H53/PBTUFkWYeB/1S1gSG9+ k0LYEoyWv0xJpSp9azqTSma2A5SNRppeyKx+42b+NLjT8cBFGGzXux2Mmg8OJRyLg4TBmkQZp5KC M75zKjkjEJ7hN1jD6ck8fKNkBPOH4wVPPAFekpyHb7NqCqgiBVSWJ+rGAAybegbjaomn1KO02DZ2 z7eBC8dxfAucIGgajXot0Obxke4lguelJgEXWBu4cCDYClOz/cUTEwC4+mdYEi5oEK4plsLsbTgG 1TCBi1QpaDA2paRHoqsXfLhAhiUIgiw4QAY588VQo2brGuxz3KmE3ZY1biwV6LS6MdGofnTn+C3L nqi98xOlLjHy6GHxF8mGALEIG53mw0XhBS8s9YwXZL9S6VxtJlnaLtXmAxyYbbECBX2w14kGeJcP CNi450XP1kJAibELwVqs+GD+kCOfDuMcUGiMUc/BeWVKVEjbDdyfYAXG3oYaWIYLjuOCqzY1Aagl ww2sHvKoX5suVGxyZNBMcCHHm86c2RiY2OUIdmscC8HijRJ6PABVWJizO7BAjA0taC5VHlngX9/Z YrUUvFkcPaqfQGMG1mK6IxkyyLSEl2kJTsO0hBJawjMmfDR1W/je/Wf6wf8f1f0R2dJfWGRT+dY8 DstmNJWKR04TyOxBB+64lPtwwNo3M6gZx3ZHHPq148a6a2zXnVVvm8Ketv2JULNj061cr3AlKThT oZmo7uDzmGMpq8ruFxHHUuDTuMLYcXDtcl2yK5yBm4kr6l6X6wps5Y141iwMu/JCZaMmad+u0nKz Xm+nxF617IFvLHmfT+6EaKo1e1urdpeDm09us97UQp+vSKiRxwWH1dRBX81WbLPhDFiEJLstw4eL +yd9JwUKbI56pdcuK3XLAjM2+rhP15DFUanajV5rvZZTbG/Katk23DfLsM207Gt8ajTeZss5cbL7 NveCFXEAx0NQwLtAI0+iD46JwMQ3cYmn9QkbyUR6NF5Jkdd3fQhr1OO6eH4MTzxvhKZRgsw+bYSM W+Nb/WEt31GFIzQgS8njvMLKoOGeA7aal+gXoWn2FJpaVS98CPpQKmi/EzRghMgWO5TajIEGBGhZ LgQMdWIAVaJPzebsaf7Z3DxvTVsHNFE6kNU3Ksf3pN7UGw6Z7HKFBP29Jw693tiGyyxoE8YflwDN bGiwYsxzxhVACg1P8u0LABMDDD57pczgPKSxv06ZaVnVy7qtqyLgMCvzuRynqORIZFXV5VdAm+BP WROoVmWTQTP+hHtxB/Oo0RO511JSvyl3FZZLoEHOiOlonaRVEckwpoO1YDrU/K5xmA4FTIcnlkAn rMIHk8SGb6xPIKj3jX91JQ1TA8PUqbthZ/UC9HefwO7cpeBwW9QIjvDFZQBHqAhTQdAofVv/sMYB Fc2IK1EOFlEH8njeVK83XKWpNxLDLBOaEGq94QiQLGZf5+fddZw60dw/zMHNQLIY5ZsQ4r64gLPH 0UZBwQsJ1mQd3C08Eqd68ebywOkyigl4SjaC9idVkZ3PjmB6j2RbT0kUP5zahZt/yBPnq6cFrKA1 1Lz5ojq/VAYOVEIA/uD9wxc0gqJdSrSud+wHWfFOMQcCKd3febMGPaivgL6/5h1penZEUFWoyKre FY3R9L0qUuFF1tuqzqBZhjWc59hV9vRG08gFRb9IYkacXKPo0p6Ju4gwG7laUlRgYxY8HRQyD7W+ GO06EeutGi5aX6/t8ilYjUBSe3umIHZAwkVXJ3/IJY9ugg2c0dmljbpet2LmfHXzSxtvHlwBpA0W YPBBZ7wI869UOg/qQ5ixpks1qXu4pmqa5j2laNcmAyrvXGGlxRpheQZQ1NGnfjDNNuUb3j5u6y2X CtaEicSgskRzgF+j26G9edb8QiDh16Tyxd3Qbjsen2wkuoq4LmCECN+bBm8fLQvuTIVNlW57fU+b 4VVYkUdNHNA1nw3VFqTvxElav7Ag+Jwk6bNrt+u64zhOZ3Cv496kLnEiXBMpmkQEIwIV480Jj2VZ dclZUFOSUCbQzJsMnLjtr0hYnj67HuL5gEnBpMuLyS1W+A6LsYlKrszbC5HTZvyJHc1dUDBmxTrY SDeHN7gV4t0zSNkoYYGlAMhRyaboLk769cMbDSYA0F/fNyYxUBIM1Tk1jtlyKgi05W65qVckf8bo 7w0CvR3arY/upHRECzArToentKAHxy5ABGfJJNt+M3bbf4MRhHlU24IHFwSUWpRsUp1TJ67ZC57T Dw+Hf8QQx7U8bMOs1mh5wAhPYwfh30+gHdfnu1uzjhOu0BmhzxNdistSXzCaz0ZTII92tJAnGkIv lIZvdEbZVBzN3iHfsI2n+nwMu/YwRStE3KNa0UHGMic1wOG5hws1F0zPsDNpqK1vKP2kEmdOVroS BF+pCjTyAunpXzG9C+t09dQoIjhIa4ksVogA9RELVC90NcpqFk6qGKRnOkrERxZAthgXCY768jwt 4BpU+AmABDw/LxiOmtEg6v1fFMwLdKNn2NorwDxQD7hongP5+SmEHzPDgFPbcraXblXTBb5aT6+c PCgsm3a5avmxo5B/MV9jW2zzPNfpeMCJmwTzoaE6Y+ErbhKk0OIieNpfEL6601mcFCLJfhyGdpJp wXWeMF1hgE6IihrkxhPEYg1WEbXz2QqATVz7sc2OH6/2LLQoO3mEj4L4rR6QMeG7Dnz84GpjwarX CcKPh0x7XVHCgCzW0eWD6w0YW6PDwzKtMWRL4SjTSubKkiWAT4UhJsDNi5gOx0s+eAMbizGfshvn cFmph7lz7B0FV3lfDnzI+ziF8b5Sjj0e0XDxWZhznPHhUnbD72ZSxr9AFOEMs7MEE+Phxandtbz1 xSemD6/e3cMJ3vzExNYAKlxAGopljhyf/UoltJMOgysIeVg9zZOGrQw67y13UY04haBpiCbNVhVa ChOM4gCYD7c/3aEmvIV8ujJWfXYdnYNrugr6jTZ67wVGw2/vDNmux/sHMJiQITazW3GEUidcfwEZ 5vdlhxLe/ZURMhw+frQ8Nt5s8XNDqIdC02tYQYS0F1ynzgvqoCoYZu1mRrw8CfVf7JhBYsk+yntq 8MFkWdfVYDZKZfYCcMfIDI/SjfmUvlZgERJomuXToqowe3d4mcFzHByen5NqUI65wwuvyCyBOgkT Dg3KUMnY17WEhURXCBjjWia0iZ8nsuLn/wiY/IfyhP1ljnFgNP501xDI7CO06BEObsK+uZbxkILB abfDa9nGrQyGybFENyJjKKVPtt/EG6p5vtFLhqtvNadWmNh4OMNh3HuB9h/laqDmTKHfv1O3C6Ye 8EzmJoY8k3f/WTr0owYLOsJmkKA6/UYxYUPtKd2ZV9EQIfcevZ0Q8ppbtHZCHMTyYglQxela6vYH 1shDLsO8Q7TfR1syO+YDG1LlarVstxzwhLmSDZYDc/mGlLsMN3W8NBPDtn56uEdBT7iORBE8NakV d78WcdfwSLIZwVxKkgLgLskNO3d1An6rdX5q3/8qCA48H+t4M3ZctlXDJf2WiJtKYzocnI4bcNVw mWC7qzNolkDOu2Z2iccmUEMMT2xZ/GSJS1DnCW95qh4x8A3L6AnVPGEYT9VfvpKl/PMU6XXFT6u5 4Jgh+82kh1/oNNyUTBn5f0L6cpIoO0AhTxMaL+aQqw2ZdmI/Yd120CHH32SaauOlTKf7F+LETYet yZjkmgLT48TXbk/5L4EwfUboWaDWFlBN8xlh2TFmpbvIXmdemrx66GeQXCYyP0urmSCaVDhujin/ YQCwROjuJ0mekjtknKrN1m3oO9YOoqv1TuEVCUR7hadR0k3mUBk/bqhE2eW2anZFEMXLOeH1t+Te 45F2cbQXaY3Oh2+LtBYN00AKJwH2xfP+STOo2NbdcOmlqIw+FPdl9rv4Z0f9ht43u4q4aP8KcPi1 0aypu9ybgTPXM++cc2LZ/hptxamip7hitJynvrVuR2+pMeHSSQV1IqCZ4XU+mjNOElq6Uo+tsYrm m+jEEysmG0fK9P+fLrTGnqpXT0FehkgAZPpfBY8vaOqJhii2MgvWFGfB6qgXDgm6C6dJaAnd4Z/O RXiiklSAGs0pvFhkMJvwEvXCi/4TNm33T2w9Lcm9nLfmiDT/iZz9r5CD7vqLDIwDW0sps3/WcIGM oe9MorYtUUrnod9QvqoF7QPClTgA908ZhEsBspkWQYHocX1//e7OPUX3Q21HBe9urh5448ys1qwZ KgKTHRDHXfdpIwX8mFVVa/tZT0XqmIKzxcjkniV4+v8j+BdIREmWkzjzY5+q4ppdNsk34xz3WasX uX7Y+6kU3Is4FnkRGYqeqSMgfUa9Upchs0NcmL2MnIBMH44decq8Yx+4rm/2DmiVdatGxioI+85l YbJiLLPwvEqcSwpZYwUz9YtyN6rhn5Th1FQjaImPBXayNdo5VAHkCYE5K4zAyApaQWbcCOxGGzfM UaggshfzKBwG5DchwwLqoEfpzgFhS7o9Ak/wC/Cfp6+x+P8sYesB2qFXTyi1UcjMXvCG7lr9TWzb GNTg122MbYvy0nzIwwoO1RI6SoLndZrCC6F70An5MJ5XjCHS2S4wQzP8Hbgvubr/NmPeDE0IECNS mkU4WYoKYIESLnqq2ZEUOxz238UoDelpmtCJxm458luiTIiZk/mmTZqSNUF+O3ZWlOE/UoE7/h4+ 8NT3w73vTUA3lRgZDGa7LYSF224PR42+XaPhsEb8o2fcpk2BfPJNkbuTZBPW92/ea3I4zmgPex6A rtXk/y+kK3klmziG2XgWHIx/QiKt/bdMfjIqFr5YMl+S7GbHsQe2OTxUDe/CBpvtNi8gHDb7toYK 0lN9S6Uzq8w029rDr8t7a3Qr8+1dgTn4sxD3I9qH1aSyjQw/vKXNo3af53E6DvMfvKoVvwrNOJiZ yP5WlDmVsdwhxuFy9u2E0wlo3W8BU2gvEoV/hHm4J+SGz1VAhWnEGGXcSvLVR4FNfWLGHTX82QFy ya+c6u2mLgLOycbBYY20i4f+j9/OECSYSdPcl7sXTMUuQbtXdpeLdNA4B+BDD+gtGoKO28Dnvz8K 99jPQ5Plu/S4FG7q7nO7enpIS/XTWzymCBG169up8lDnvUW3nsgocvvZgWhtG7Qb/olvqiEvoL2W +bpzssS3bebcXvnDLA4GgTexEvK0NrQzeCNfLMY8jWQKRnKse01hp5M69LJNm1hS9IP+wAFTMn/E WIcEP6kzUUR4Fj8pOEbozDgP+VXRkptbuICE6mkeTthsufP9hxSa8XDe2WYXtHSS4XcXUTUWSzCU 0ONx6e4dNEGgKmEATWgKbLDOtqTya7bXfmH3fbewYqOMdhJn+mbnHw9+kHqtGCw4Hi/vkCmjeI7z sWZJs11zPTelfJqPzHHYk5bfsk+VEbGXN9i/XhLf9vIGMeXhXotYdbnt+Rb4KkZ0bDdWiu34EL7F tF9QPryXOvkK1pkrSb33lEM97m3ehaW+prGOuTe903ypaCWeL0JWz+xffOoc3O5iT8iK26zNzsKe cXdosdBHvcOXH/uot+rPAkd0fj/hxOdn4slO8lJNfHPXsURMthtjcPzhS2cRncK/63I2jRbHNca8 DGNeST7J7+LiWZ4L5nrWYaBA+xV2F8unT2x+mIbROMF/O4Gw/Z8y4diIrXwF//E91cr+p3vyP5Ke /7PYIRFIzUSQXyq4z7yDq7H46Cn7OyN1nMiyIRXYbcpiAK2BCzsDaH0AIUvozLUjN4vwdqUGVrun D6uxvIgZ2d0Z8/wM4Xcv9rLEkNeH0KiwQNGiEi9M17NTe11RIgT5lFz4CRkAdFujuUNlSTbQoeGr U3QcZ0egwzkA6P/zysdp80QrmoaLnnucyzRkn1+z8lL+VeO+htTbxYyrqd1dKRyOEfvROeosdGIJ zsYlr7ToDJd8hA/o+OEjLAmgj/PM0p+uRMBzAN7HReCV+OhEaBeUkMsZL3ZZzL4pnavLryBF6VJt DsWRcgniXm1eSxq66UNyMa7bFf/ijP/90xYdQ2ct5U7H411l/zCbS5f7AEfcaO+eiePad5z6Z8KW M0E5xEGxRZnPX+RNvWhSobGLdfJlJ5MerLFTqd1mH99MRfexTFX0r/8Lou2lFgplbmRzdHJlYW0K ZW5kb2JqCjUgMCBvYmoKNjc1MQplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMi4wIDkgMCBSCi9UVDEuMCA4IDAg UiA+PiA+PgplbmRvYmoKMTAgMCBvYmoKPDwgL0xlbmd0aCAxMSAwIFIgL04gMyAvQWx0ZXJuYXRl IC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe9 0BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl 3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFm ZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK 9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1U SZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeY aeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09 yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIM JwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/j wDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfI bz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMEC EpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6C NnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD5 0CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db 4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMG h6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2Bb sJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e 348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYk F1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlD pVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJR wUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRN tDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP 2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80 /+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ 7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+t n6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3J TVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLess H1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEH PYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKR LmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS 92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUE w8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeL jRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz 7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE 0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMw Q7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341 ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz 7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fg dgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a 5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9H hUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarp J/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF 8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnp te9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9 Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16 sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/ 9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTEgMCBv YmoKMjYxMgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxMCAwIFIgXQplbmRvYmoKMTMgMCBv YmoKPDwgL0xlbmd0aCAxNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB5Z3f c9w2ksff+VfwKTWqiifDH0NyHhXZvtJWzpWV5L2Hyz7I8tjxXWI5sb3eu7/+Po0vCIIckkONnDzc JlUkBQINNLr7240GOP4t/Wv6W7pbF1VaFOum3GyKdLsr1nmT1mWzbtLf9+l/pO/T7y4+Zundx3Tj /v94R6PNOi/1tz3U+Tovdg3NNrv1Lk/ufk2/v6HOZrPL05u7tMxcXX+7+TX97uYmX2/SLL15k/5n urr9eMbzKj1Lt+nqy1n6pEhX+1/4K1nZtX3Tq/Z6/w/XyNVLV/cffqUdVffvP0VN7t/4PxJe3b/f q4v738/SsqXq2/kyX+MZxPJ09U/XxYe96r9ztH49S+J+buMRXmnsz7nBz4X+ipn7IEr3Gvu7MxvW a9F9//Ys/Xt685f02Y2TS3+Ki7paN1tmUFOcaop7E5sMJtbm8+a/xskFiVW7Gol5ciaxBqHcJT3C 6YAwEvv4WSx+6N3u9Rc8IkDE4OY44YoUuPZeMziK3qvFXjdmwObN1xMBJod6t/Ym8TRV5Gt5CiLn y9SdilzL1PQIMiK5R4J0o2H69r5a3Ccysmp+bKJ2p0b/o1eO+3ZUvm/Pg+p5qn6WflYrDf9uZHhv NTBPSSRUW+PyBExjK2Qwqy9lsd5mZZFKwN4kZ8W6TF+abd/C6WKBhX8ynsyQbSq4w5sk7Wzpk80x pXfcTErpFQ9NujrnVqerp/rr8qXu1ypdz7Gfbet1XqHYVTzer8B+tVk0lU9mTG+73la73TatFtJC USbNuFkXZQNed7TMhpfJ5NJAjunt3+jt78kUCmWbYr3Lytr6izBjFuWTFuWbTQ5xxHyLNnPTFU1A 5Gg5Ja8+q2wvyETCFKrNC8ZaJKu99w4PI6TaP996j2F/JqtX+/17vWhB+cO9+t2/VrkGg+bOwHKx W2+A5EgAX0HJyiZyoQ6Qj7rQGUBOPNLBDjMNa1wv3dUkD1L3b6rQ8Arw2+iW65aeGZh/FCGPbR4/ X6uGL0So0PVlH0Vx4AMSKuiFiVQqwFUt96LmCajaaH/2KnEhwzgFwb4n99GP5AdRN3RhEKZZxhXa Bin1dUMZ7r8H2EfgtlmXzSZLq7KRYcy7UOtn0qjbaKoiMHN+PsGos2y3BGi/oK4wxTTiIf7bSZmu wFIsjOuns4Qr80EdcyMwqddf9J754r2uegHbzA7unhaAd7jen5kE1Q8KQSvqgyaIiXLVp5wSZpES 9Ym28Kxy9QjmM+1qFZeLD9X/1tHReAb06Vf0W74T+Bbl/3UjD5SpqfKYcjxm9YXOeXNPLDoeRGHZ dp1tS8y9Fc28YQYxj9DqQjAi6IdEzIlFzEwb5qnr/Wcf88IfgPn+LVxxXwKzgLON0Vrt969b4HtF fBNeXLrXz6Qs/ZtaelxPVm/RBnTl/vMH4ahe+0FpqGgWfX1eFvIW5boqa2wqLxc5Xfo7blNZvDx5 lKNstBAwiISnXLd1pvu36YR7NWCl+kErFwj5xilKa5XQSLt1KjmyMMg3JR4/r9Iq82H86ciTb6p1 3Zg3C7QeHU4Efh2Dg1mqxOA62NwYg9V2XWcZ8VIY1ONd7JawsDGzS1iozpNbEsqJ3KOVtI3meuSW Y/8LYewX7ACwuzp3RvwU+22S1cvr1qR5JZwVdgsfhX3CeqF8i6fmR6hPK71dOw9CFyC7etCzqGkE 8h8YPq1E/5XDfZWrjrVySyfqPGgk9CsGNU61lTcixOCt+h30RS96G/iaCeryzTrbVFnak8O8ljCk o9izrS3L0oV2C116LMg0FiSBT8yrONbcaL67mXYgErwwcXB4VivNn2ZUrQAd6nzrZGiyaiUpLVDJ l1jcXfetO4+rxqqlVub4W2EhGgQkZlQutSFcCQKN3XZMWW2XiDWrSFYVTdqTw1cQa5X1xbpplkRq 10wD4RfsMs/ESzyjy8A96QmFZbAeLJVypoRyLJUrE0Ar5MUzrHNVW+orMyDZVS6g1RRyVVv1iLgo Ub/IGgpMf6hDFoMSpAy1G4ccF8pN/PhdVPaDq3UtZfhp5UZ/BaQTO5w/1f362YUefjpzr0Xy1rGo 4ahz0Xipur6t78v/pWH4LteRx0gOojQ8RlXXZbp1kvHB1QJBJ6OptxCobQvLfSwi9+QsmYSDdv2/ mJwT4iS54DTi0U04jWGKkEjyqSxHVqew3S8MZKYICV1CrwKW65ncJSVqrDoSoUqEtSq5dvpDK7Sr NWuve1BGk2fyDU29bqp08Uylq5mJz3bZOtuxRuuRs5maNdiQv/AGK0MDQjEQmbBKxKwMSuYpg5Up Wc1khdoyCdTErM51k/oza5CLscCEwPSoByaY10zhzNKE1Pt215DBj/XgKyh9TsqnVXqLBpcle177 HA4sgQbMkLAeGHsFznBrVymfmStq3L61zHvkk1nzxlsM2XazrvKiTrcPGg+kb97YgilsBFjfTCTX n32uH/20dbAK/aLJRhUNZrAMdHEyMakfzKK4byaMzDOLN4huxVsUIMwqpuPNtk9mFNP2F6SYskip pPRMeC8/oGfZKIs/pkOtLDeDdOy124tBe9VAykuYQVV0dHquig2CQ2diuZ2+QumwOMuklhbAH1XL MFUHu0b719jktFVlOZhRb3ElbX+2s/V4qypBtZEtnOFOC3BGWDnhllo/spQWIpuk1TqRjtaEB+lG GHDxpcJGgAy8CgCPc0AvKKHb4DrkKFRT5eZ3nGaFOmAF6IjGUSKl1bPV7NNXed8FWbwYXBAU6IUS vzJCvymaTJGdOyRSP3cu1SkOwAJ61lWjvnRUxYfqiDMZ0HDspK3dTIizQGfGZrKavH5dpD1xbLZl smCr5afVFUbLFD7nxrgv9Fepv3LdLHfBO//XT2cYAWZ+o5eW9uQlbGDcs0BYNKQ9660b6CIUZPqm ApkC95zjvIzpCAIfnfa0MEWClxR8dCNBTi6gpAXSJMnt9zNLLYqG3kraIiS9H+g3mqeaYCajUB2j lnT6TTmAKzuZ1oiAeyVhbZwsXKIRe5+Y279FpDiEe+9zGTl/qezjmaUCETbXz953673fHfFl/e11 vxsjEkyHeVU2CbhdoUMwZToIRdNB/ipzskHTTLI4W+927GYFJi3xPR9wBGT3e0sait/Y0YjcIJPV vWfnZ3+MYGSTSTUuHR+eBAgU5gjJORywmRLpIck57oqaraKq6pjru5FhaG5L70lTaWzFWZaLaTHO aVpkWfO8jmhNQP9whEQeV8gXjLgonQbn7oqIEbWelYZAJmh5wD2eMTszS5mFrgwRcxnkLaZ1BXRc b8sGtKijjMqG1f0CiHzHWNyej27E7JZmxbSfsC8IqttfjMc0FznbDSDwhdND6my0snj5eGaRDqek UrPu2WTEGWWgZaawjL1f3hnGZRtsG0CycYM8dnPMOG8UcYiGG4d+EnwDPwm+XUvOzVBIS5OcsYa+ zi9+wtouAT6bYj9xLQVCheF4GOUrZdLf/fLOT/c735OXkydthozWtJXMTXWCMsDh5Tmk0KOn+gtT tiG+1F/Xs+ZJHn1bN9iBm/GDMG+o/aYgU9IrNvjvLTsXHa0JIBtSxaZuBTNs6tg29LS6FSX+si7a Tto4eNl28Z1NnhceN7rEZk2S/HGHYJGciSC8YiRdkemI1TPZcjdd4YaVU8W/86dgtGHs6fpXvvos byXHz7YVjiDIQpi0xNu9OHdODNGjDvTC1bt8eXP6h1cBELpvCuWu8tSMlbeoYShXKwZPecCwAFXm u11+ZlpQHS5sjx+aSAZH49qzCf90TDFSNH7cc00PIMvydZORzy637ekVU8eFm18mNjMzb4veMomP I/P2dUy0VtVbuTdQEz+l/fbftntcpgeT501yFo9uZczIo7BnduRhXfIGrTbF7GNJixr9l6RzfMjb NfgCi6ZCHsLepC+oRAH6ZRBzmSINanve2zNMnq4v9bx/Qt2o6in13+H+eCVabFnbMLpW9qrfKiUO jbj6jRZMrkdvUemz1kKvn4Z2uE4cRzS3tB1Y/jPFiaZ/PAM01Nxbh1+M7dW+PXkj9bWTltPKWu7y dbnD0XXKumC5PX7Ksdxtgch8oPgLt10mlwZ4K6CA6eQ6i2Kd4cNOHLQfxCgjbgD498dOASNm8ZbD HChDe2ZpPPK2c023jIn6wBnVUS6e996n6M3b+96Z1V5mzJTFOjNJJSt/rMD9haJLfG3iTh3c+xYf fOJMdXyOT72j+5AUF/HBgikWwuLBDI3o8ik3pvrSsfIS7eePa71az2lS0bAzbmezbM9nPNnS09lZ j95w/Ba1/Bq0OrUg5ODQtIZWb90Zad28PmTRGel/O7MkpEMDdzeMcA9MsrubQbsHpBzXQIy+AHju Vfh31wLZIDT3oiVlUOEKAk07v0lJRyuuMm3MuR3D3HFWplzMaiwFO4BTZ+ttnhZMWp37P8iUjp1M T+ZOphd1NNcKJg6scCS35XdHmEGZ/DSru2qdlVVWMNSopx50Da18yGpWlhwia3ktoMhfo8wmm3SE 2azcrsuSDY7eEJYzeySRhzLgm9AufKACJJRCGEiJWwomqwve4xxz94bjHbznUAvXIyv/nHNV2EIY +fHV05Pp+Du3iWianSfXZZOW5hIqfIaDmyssgcEHJHLg0yKRe+WRSNXNorAnVfieP5RAA4j1nink +fMrB5ouCRSQUfjYnsBS2qH3ncKHz69aPO3wPaCuQew9ajqtoCWTsuG0cDfHB2ucoQEMFdTbIkbN 2Rn9MaqeINmIegbcK8LB56O6yXTpE5FJQzzY/e0MMZxR7llhx6SIByY5o2eA01qhuJyzwnE2Oyvs sblwKwfVwXx+lBWZ9qEv2ktPTK14Z4tZCv2uO24AHSP844oKkaEkwOUZfOaKQoTyd641Xpv1ilqp vsox5VCfzqGDt6CEWA3NUn2UknK10gDJGmId6l17QabZFIkoVRmwGmhAIqoORBSToL6VtMPS2x/V s8YVH3RQgwE5urlWb0bVuSkGr97Uj8jF/fvZfe5s8mLWdGoUdcuqo9PcZSqFQkU+rBz6sORhX1cV +IcQL0yYztDHkFCYNJ2D462d6bieHprRj61HvAbrScYc9hhIdNZzGrNtRhIlmobCrGrWdc3nCGFG 2+zJ+NJm+L1azhaFD3GF6PSGlXTo7s46YgMT6N77kM3H6z/KW6CmONn7+FMEg/ZrvUXFzRrfv/YB vf9QwTQZI0KTDRlmVbloOIO2IzUl1k8RsfcC+dALPFSbi2hNObYm+0qq7Lo5Hk4gwjadF+uxuAx6 TOC5jM1Oj09gM1JiIqvCIeTWXWt3VVzFiHlrIQdQd8kfyYqQAwVADxWogYp6BqHRDyXXDaFpgHYq jhNCcwVSqQRCOjy2jVSQk+dAjvoqUTis/umYmirBQVBHUSGKjLNwnbXnAQXQ6liV1ExECW5oDFHI tRMwZ8SFnaasa/t2tc1qnQLKZJjCwoIDJ0vl2wUzG76UbRdxfywou55Osdg2pBGvXpk5VP9wUM5O 8kCTJ1jT1d+cxv7gFO3cPb+QCphSOD8e6aSpBjiJiku7YlWKS1A0VClsq9KKbQFaSQH1Nq4vw5CR 6K1sIWg+FGQX1qpVZ2m7aGrMS42NwbXG5j+DokRWELoMJSIdsy3bISZiavRsrdpTBq0B22Rdu8nS EEVfFqc6KtFEhFb0i/XZCVRbys340LDY3JBdjgyAQOlgZT0C5T+tfmcOLNtJ13Zj+u1GgGq+rP+O kSA+xK3QzuqpCMattm/EZNgrZsZunoQdPJ1mI88bPhTNCe0cG6dYl/xhri8KolXRMkcRgCSPJ/GP 84fq5lR/6Ll8hD88hc0Z/Lh0pu59mkxCjsQMLGl3fuyP1knF1qDnGEaCa8N6RFsWyUoHlRJEiJrK UcNgqbFtUQ4FIrLgatnBkV4zrNC2BywtBswAy7QiF8S0Rb5tUibYazHeaGHCQwkJZ2EjIasFoP2Q 1R+OYIJ49Z7xcvPJChOF1WdquTG19up9yDgbrSsZLZNzNFzdsnWFzjmuxnK4Q2AJi/neyotpGTj5 w9+1mM0e5hXp3wjjxsyzyyuEHagTVl69nnrxzDFWvZP3vAYnP5IqPZI9ZMfkFGZnjDQ2A1kn2oHZ yJBaT2wnQmRC7B5jKjKh88iFqVVb3yiMe+5HGBj9DsJkf34MS40HHfvLgeempkqEDZ3n5gySY2zo uduJCDShcB2xLWoxuvD9BAMd9dwGOD4Ja19kEIMLbGJsFOCJHbbo6U4DCxEQJRq8oEgdqY6HWl5P Y1FY/OTVBlXq4Gj+pL3ycWQs/kY8CBvnL4QQUoRv7JasfF4IFjRs6jE8QQ0lMAXLhH6U04BnZjXU YSZ5hilX087zHYkOOGNh31aKjzEAGlr9BABxsu1RKdO8fPiZyEn0mU6Z0s08kxJRYLKfMrXze3AZ BweHODub9DmFzXatiLQBhMJZ2NZda2clWizLqKX4wftSX89S/IHhGznUSUrF4lpoFYyUt1OGL1OV 2l46CiqR4sVfzntrEiEZpMYoY1MzvRVwisuOZzPehXbuDQbgCHYODyJoI3O/E4FJDO2cSjDBVXMV z9hhJPSNwy1AhfrPnbWJny76aemoY02nAEZ8MhTaai6cdU6eDtlmhDw1KrtcbcNXWV1aNuezwH4G YJnSdoF7boviCOSWHVk+xTxdT8stVB8OROksz+tccHBkUyMvBoi+jNmp4GD66E/GjvtmkyFc16Nn eiLBMkRhO5oam6t0UFqmclaMxPNTFme6mdiu31dKGpinGWg3dksvXGN7mkUghQnugKqiI8xEREVC 5FQi4+pCj9aq+6GHP+YHtRjVrlu2A33BkOqIvqaya5WElJ1GcTokAUOQWBJbYP1xTD52nm0YM6MX 7akwUM7WKQbAdlI2JRFlp7qIPKz4XH+94MYspN9w6sQExoTaHe5t5YJWcfWEemWfCEBckoIZMnL+ JXNnJ4zffDoSdVT4UVu55TGLvcXAUOGDR+6vezZ2TvwRO7X8uMSfgmub9qOGCSbnww5x+Ziw4wQ2 pxAN3Hgau0VBj1Y0siNZCOd5TIfkilVJ5qTG5u3br0TULCYqEkuRA43lm/LYyimRHQfkCLYu0t87 1Y67VCTEW4Z1oVELBHRVVY1UqCpCMQSpyz7yWpygElGwDpbl/8stJ24yEAAllXdY/llh5/3NzQTv Hw4zJMt/8pIR9GBoLDUwAkOT3n96U1Y9eXtcZigeDXxqwPMaDOXh+f8TmZ20lbB9JdWQ+ujZLKaN uX2UPKVj505ZQ1CLcnMGAnVXICv91HnvwU9CUVOWp5rBPNHAyzkfVPAx6KYh8HyASJ50+4sHv1fA rkppv6rXI3c01BEo2ga/jGYMDpLeVh98yTY1k537PoCDABAibVbcXx70AwmLpQ5pTgcSBkYSs6QT RkK/7dpmTgBbIL8uyv6EPcgkfJ6eW99BPjBpn8Wf4/2Bpu+6OTVpn4nLYPeLNzlDHucUNn0ArmWr zEwiV5Cr8hj0b3yipguWZZDS61jhpDSdR+rvCsqYbRnZOtBBXygZb7nGAOEdj7DE/WjS4Ld2jiAC XqDgoGs3U5PqmHCiTR92j59aL3IOQ1b81EFHawILxvzKNBb0t/0PsGByJ3IEC9rcoyYwFo0Jq4Xt YNX0NY0FhtQzWOB2IuexYMdhzyKarYmZV1p+PFLOCCYOw4AH/PI1p1f/pCSAenpEEsDzGsPBsoxH BwdDZhcebpTFImySsHrGafPM5trMgo9zHjVHltJljB+zroxPKwFqDlY7JqK8wggTIwY282MbloXG /LCXWazI2dPKOH7lR7AooJuJHnJ+k7Ksym2f3ARidOvGf+HooWSrv274KKRntBOoMVh69tbXfKD7 yPABLQgfBv2B4YPr5uTwQVzGeLEsSurw4gQ2Z9YMF/L/Ot8j5wOa4GRwR9MJRWcn2x0uOoxmXuQz PyVliRlhUqCFwc1vtodd4Vv/MwxEJQAGkRFXxs8VjkgJACE8X5EfwDPuf/usGvBsQbYthUghtT/D gLsNLfTsPy7oExb59uOCaC+fs0yn7+VHw+TE0NG9/JJN9GrHj+ceFcCsp84f66k58ROn6/UvHvR/ jGEEJv+C2zIWiUmnfRW5gKLigye+2ok6mVczxN0ePB0uDO0Hy8qMU4k9ckc1zUNWvuHLmynSGZ+o N3ZcpEd6fqT5DLmsWBcNv1jzAHIR49EWRSb5BrQ5IUnh5v7BuNoCjiLVZ86wbCMdXPHZ7LYG3h0f H35Rtds//4dLO2hNI4yi/bS25ASdm5yfEdOkMWKDaCfeRT9jcXOBShI+/SjN/M5td9/84EZ+LYO0 RDOwwTC0E44CC0jQZp5ZBlEudKAOsAOIQJGwjLcs1Ljav3cCCVAoVKUBz/DJa4J8rupAREVC5FSC zagOyMXEmhnpe3bAm2cR0rjUjaGcUgq8Vmv1KXogp37ZklFcaQ6eMxfTM13ygylZVgA9sW70tH0Y 6hlLrfFE6UIyP/2EwWHoPHuSKMsij78hDJ37uRKLZcnvPNcEIY5pDhsWQXVW5GnXwWL2DmCHM1fl riKi7A/28N/yOZi0I5jTrHdFuXyMeSeC4RgZGp+Jb1kVhDEu5jdGG8kzoM3DT0t1/ZvhLvtlgkuz WCAEvDA154SCbRKl5yolHW6l/obs7SVGZYX+ll7OrZjs5wmFK+NzM/BuyVwyIudnJQtO4UXzDJ9j oSpUe59Tzycm/58mI0yRqnoTm05PLbupn4txIFLz0xfFI3budhZ/QKLbvjsGNv5DyweBzaCXCVbB eEt5RYA6tGZ+80GIMyC4PNSZQQr+zRo+H6/TE2lnS1BoQHvxRERQFIQewOjhoU87jCj4cVmN+Z0x LPUZ/jgkZYAcnnG7XHHvXFViz253Hug6xx9z0xXXDUThuinBS9FAeR29VWOQi+WM4oRLebLx37XM C07k1524PC/zUzq3VmP5Wm344m1kcsYPr/zJMDbt1IsMr56zxGyH3lnzwpOUM1/RWr63k6sTDeKL vqLtqwCRF3KVpKUUyJIGVzgm9oaeu0huPggj9trlVcfNmGQPIooINbowzP3+3RGAHD/lHE5t2Y+D 8F/Rmco8QIbl+4MActBLT4nnWJ0EyAFBAeTRn8VaLYvLWuKLUpJLYPFBBAeS9pvWQdSPgMV2GJ2s FcAchcWnyjEBhWGTwpYmGAJgx8KQGI2gjIHbqQ8VgXMK3rhqe+RwVSiqsh+PheNbQXlRrbcNvwnT crBIMnPJYv69sl3GR5MDgtMx3fDb53+9zeaSb4ARxG44Zz1j7gK7w2jnr/8H9XeYBgplbmRzdHJl YW0KZW5kb2JqCjE0IDAgb2JqCjY5NTEKZW5kb2JqCjEyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMyAwIFIgL1Jlc291cmNlcyAxNSAwIFIgL0NvbnRlbnRzIDEzIDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMTUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQyLjAgOSAwIFIKL1RU MS4wIDggMCBSID4+ID4+CmVuZG9iagoxNyAwIG9iago8PCAvTGVuZ3RoIDE4IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWE1v3DYQvfNXTG7SYRnxQyR1TOwUSNE2ia2ghyKH ZJsADWK3sd2i6K/P44yi1dfK2vqQwABFieSQnHnvzaw/0yv6TNHo2lKsgnZ48IuxdPOefqVrenx2 a2h/SxX/3e4xv9LWy3vuRKuta1KCgaR9UvsretpiTmU8tXvyhqd2j/aKHret1RUZaj/Qb1T8/Lak moqbkt5Q+yM9a/lI4y1So30Ivh5vsWq5oJLaj8vmGpzY+xjH5nDiqrH3HrmwlbHHbRvjtW+qZmx7 81FzOIyHiexOjodrQn4zVm0NiPG19r4y3RHoEBDTzK6n5hG5+KEkS8UZPJio8CU5KnBjtGnQf8f9 P3jObUme4HGF+dL/m0dlzlVJO9iTqXclRSrQYup7nvQ7t7IZsIBtsgmVA4iZ8kVGX5ZATUZKoOJP nvkXt9KXjec2L0uFVbKjWLvmVbKvfBGb/Umw78AJA1yqMS5dCjrEGhxg6Hee3hZs9WrAvdAY/RDq hcZpF/4/9ZocPTIVBxpsrEqF1qxx0uDKjW0cyd7rd0cEwPaMomOc7Hlzgjkc+au5AW/Elz1tNutY T5uZMxdoQwu0ecLwPH/O2H59yW8ZuKoD6z8MOwGoAE5gfd4y337i4X4ZMAhLA+xNZBeaq10dTOf/ Lvbr2NsdHDZVceutDinYsbms4ttufy53ERKO2a9G7Afv72c/w7Fnv/AVG0RVPGO3/su+EvYPHSoa 0wmODMjiIf0/cYBErb7SfM3Tvoo6Br+G9KmKDrPPIcOGeH+GVWsZNsScYQeCXqWZoB+QKaRDin0C R0GAgbnjcEpRp5yxR1uM0LR2xymamkrXsYlw2eTEkmHVyPDhxFIU5Ax7HKgG0bAcDTa9CferumN1 snXqTrrJHJC4pDsS3V54Ts/XM2cBc9MKahoFhPc5OLEDWcYPQrLesZTzAy7IbwSRynPv7m5KtUNe BGPQIlHnUfA2P+7AnPwEmXc5r9+jQwnxiBCO7fFY1SHUnwfkDFLat9chxL0jEJL3FPLOoEg1Ps4g j0Q5i+IB8j1JX4Ke8DlqGVBVCCt9RAE1EUKC76hQ0GYlpOISmiYSiU9QOau6YZQ0+CLmhgsuEE7E GtUd2rP+Lgv1trfI7SaEU2I6IYX8jAhhUteo035ShJDrmoHg2XrmywVGvNhzQSqij4Mh5wD/8GLF LdQFfXw5LofGZFlAGS8neIgssAseogpTHywQYcEHF8fKkXGJLjlU2lxHq66+FnAJ0sSDHxhuUmsD XKjBZfQX2QgiATTKVOlflwpuliAAvujLMsnIQGk/ChFCiMT0cFQydR5VxX8c0n4V9pqvkgNh9+OB dT5ph+ieEtgVuXK10cFPzX0fZRO8cVyuvIVc1QkUn8Lre5WrrF2HKy2oVu2Nji49hLMoqQM5p5Ov Kkc1flVZ/BAHZNLmbN7/OyRgWV+s4X8X+R8o8ujY6rTpCp5Hg4LiC4Ndim8KZW5kc3RyZWFtCmVu ZG9iagoxOCAwIG9iagoxMTAzCmVuZG9iagoxNiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDMgMCBSIC9SZXNvdXJjZXMgMTkgMCBSIC9Db250ZW50cyAxNyAwIFIgL01lZGlhQm94ClswIDAg NjEyIDc5Ml0gPj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMi4wIDkgMCBSCi9UVDMuMSAy MSAwIFIgPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAw IDYxMiA3OTJdIC9Db3VudCAzIC9LaWRzIFsgMiAwIFIgMTIgMCBSIDE2IDAgUgpdID4+CmVuZG9i agoyMiAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2JqCjkgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvU0NGS0xPK0Fy aWFsTVQgL0ZvbnREZXNjcmlwdG9yCjIzIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rpbmcg L0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMTIyIC9XaWR0aHMgWyAyNzgKMCAwIDAgMCAwIDY2NyAw IDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2CjU1NiA1NTYgMjc4IDAgMCAwIDAgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCAw IDI3OCA1MDAgMCA1NTYgODMzIDcyMgo3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQg NjY3IDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2CjI3OCA1NTYgNTU2IDIyMiAw IDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAK NTAwIDUwMCBdID4+CmVuZG9iagoyMyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0Zv bnROYW1lIC9TQ0ZLTE8rQXJpYWxNVCAvRmxhZ3MgMzIgL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAw MCAxMDA2XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBIZWln aHQgNzE2IC9TdGVtViA5NSAvTGVhZGluZwozMyAvWEhlaWdodCA1MTkgL1N0ZW1IIDg0IC9BdmdX aWR0aCA0NDEgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxlMiAyNCAwIFIgPj4KZW5kb2JqCjI0IDAg b2JqCjw8IC9MZW5ndGggMjUgMCBSIC9MZW5ndGgxIDMzNjgwIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4AYy9CWAURfY/XlXdPffRc09mJnNkkglhAoEkEAKRNEdARO7DBIkEuUHkCKDi QVA5RBR0V7wFbzyQEAIGZJeorO6qLKy67nqzLp4ryu6yrAqZ/D9VPQHc/f5/32+GqnpdXdNdVe+o 9169GpYtXT6L2EgTkYg2Y+H0xUT8hY6j+P2MFcvi+rU9SIhh4uzFcxbq156rcH31nKuum61fR6oI mb1x7qzpM/VrchZl37mo0K9pOcr8uQuXXatf53xECDVdtWhG9n64FfVrF06/Nvt+gvskfvX0hbP0 9rfw+vjiRY3L9Oubf4ty++Kls7LtaS0h1l/r97pyB14BeDD5B6kiDxMjYUQlJWQyIfLzci5RcM3v K86pv9j/dL9pzqp/mcIm8eXH/lrYnQO/efDKy37a2TFHJSYbLs2iPb+B7xkHZkaTISr5aedPK1X9 TfxO19/gfWSi1G13Khg7ekAqIseQmFTUks6N7ZMKpdyWATGtTUrudvtKnYN6SHE8sUTkceSLkHYi HUSSyTQpirsq8lVITUg7kQ4iHUUyEIKc340jLULainQMySDlSpGWeEwdVCjl4Ls5GK9TCpDvkTqR JBJDXoI0Bmka0iakrUgG0Y7XLEJahXQQ6SSSgWhSoOXuMvQ90HK7KHbPv6pUXE7XL6fWi8vdl9Xp 5ahxejl0hN6sv96sd7le3XOwXhYW66W7oLQJD99tsZe2D/JLfgzSj44vRk7ZIeKklMTINslHmpGY hK6KGk1y785PlW49KMmESkyiZCaJdbZLtMXuKh1kYZ3se+ImMfYdO6HfYSd2O1ylWwddwj4jO5EO IknsM3z+wv5CVrFjfM6RVyNtRTqIdATpeyQDO4bPp/h8wj4hTvYxKUGqRpqGtBXpINL3SEb2MXKV fcQpRuQcrkZi7CPkKvsQw/oQuZN9AOgD9kFnO3unpaKydJ8A0iVZIFaQBQLhLOD2l7axt1t+LAJF pYBpUNRLUh4ZSMqkvJaC3rE2KdhSNS/Wxv66O56ObRvUi71LmpEYevIu3vwuiSONRWpAWoxkAPQe oPdIE9JmpG1IzUigMuQqUpy9gfQW0nukF5KGNBbJxI624DVt7EhLanBskJ/9nr1OApjxw+y3onyL vSbKN9lvRPk7lFHcf4O91hKNkUFW3Cf4jopSRVmC+wp7eXe+O9Y5yMUOYgZjyEuQqpHGIE1D2oRk YAdZXsvMmBsPeYm8AR6OsRbytSifIo+ZiDY/pqWGgADjPEv1vwgQsq3xrSmmpbbcj0uepe68GxDP UrduBMSz1MrVgHiWumoFIJ6lZs4HxLPUlGmAeJYaMxEQsjb2yIv5hbGKMQtofJCTXYNZugazdA1m 6Rois2v4h/wo8z4+2NK9O2bsAS1d1D3WtJ82HaBN42nTY7RpFm26iTatpk1VtOkK2pSmTRHaFKVN Gm16ifbDVDRRrfVnl5VakDa9QZt20KZG2pSiTQW0KZ82xWmF1sYSLSPAdShqRLF7EGc6lth90UBI HydLYEYToPkEZMJB5EeQOsWVhkbxPL1xTpSXebu7V+vXPfuXLhp0MXsVX3wVaHiVfIokA0Gvgoxe xUNexeOcyKuRpiG1I32P1IlkQOs8jGOTyJ3IS5CqkaYhrUL6HskguvM9usLIIuS8iztFx0qQVyON 4VfsVXzy8EmwhJarRtS0erG0KUKdUTom2hllFcTvh1x2u0yuNmrf+2/7D/+2E/MgM7uTbSK5QMTm bLmp5cfcWBu9ryX1UmyQj95LojKojlaSFC1A2Y80ius+JGLi9eUkwp5DWdoSmYyvOVtSxbH91MG/ tTf2Y+R47OtIGwP4VeSl2J/ibTJtif0RNc/tjb0buS32u5I2E2oOpNooiv1x0XRfpF9sxxui6Wrc eKAldhMv9sZujAyPLYiIG7P0G1c04kpzxsanpsQuxvOGRq6MaY145t5YdeSKWJXeqg//zt5YL3Qh rYPd0dmiiHhpMioeOKmijc7Vio1bjLXGMca+xlJjsTFhjBlzjWGj1+Q2qSaHyWaymEwmg0k2MRMx eds6j2lpvup5DWLxM4CgKZEFrELCUC5mkBNGTYxcQpo90kg2csJgOrK5fQYZeWW8+fSEZBu1jJvS rCQH02b3SDJy4uDmfumRbcbO8c0V6ZHNxrGX1+6i9M461Daz9W2UTKxto528ak242T2kdh+h1LXm jjAvu625o66OBP0rqoPV7oGuymFD/4esQVQ2DE2f/wueB9PBdG7zlpETapufza1rLuVAZ27dyOZf TIhPrd1H/0FP1gzdR//Oi7rafdJA+o+a8bxeGji0rm5kG50s2pE4/TvagWJQoJ0JCzNvR+KmqN7u Ab1dAb6Pdvm8QDuzmRSIdgVms2gnU95uV2N+zdBd+cjQJhAnjaJNYyB+YZs3CtCmABna+JvIG6LN G/4m3qZ5oHhMJIImUWRoQkMkIppEaEg0ET3fJZqUZJvcdq7JbeJNkt4b0YZneIz9WFcb+zG0uWAi /9/grMHpNN09oG7G1JpZyZqGZM0spIbm21fMDTY3XRmP75pRx2/Em6VUw5Uz5vJy+qzmuuSsoc0z kkPjuwaI7/3H7an89oDk0F1kas3E2l1TtVlDWwZoA2qS04fW7R4+trziZ++67dy7ysf+D+8ayx9W zt81XHzvP95VwW8P5++q4O+q4O8arg0X7yKCxsfW7jKRwXVDgD9e7mZWC+i1IZyoG+xXFw8UxDsg EbwpvB/aynZiTdc125KDm+1InK57DOoxiN8CT/FbDlQ7s7eCNw1IhPfT7dlbKqpdycEkvWx543IS rJk3VP/XiD9ULVvOUaHnaV73P/6hSU2zNn0o161HNnefMLK5etyU2l1GI2obhtahrn9XndVa09bZ rlf2RGV/3lCSzjXkdVW8zmzONvxvWhB9QjVmZx8UjZd2Uy1Kl5HGOqk5OnIigyiYOAXTMHVK7X7o UnyRaKzDABtpmjZ2PY2PQ8BEryEYdmNXWrY8C2XnYlm2FE0b0yTd2DUlXY9L88kSmZirZWmINmU/ yUEKKU+THDlFYP90fon0FS8z8zq/4vd5yb6BoGvLJtgkZAedR3aQg+QVehLf2kn2kVbCVaCh5CFy A/klWYdlbQpqbiPj8VFQ/0ua09kKy+RRLJiPksNoexm5iewnfhrs/JqsImukd/CtNcRO8sggMpYs InfQSzuXk6nkU/kWUkEuJVeTxbSps7bzzs67O58gT5J90m87O4iVhMgMfA53fqf8ufMj0gPfuIfc Tz6ld5v3EA1vaULLh8lS8oBUL9POOZ0/oQcJcg36IJNR5DBtZ2k8fRb5kgbpDdIQPOXxzubOQ2gV IfVkLnmA7Kd96HCWUKZ2juo8TPx4x7V46v2khezFp438inxAbcrJzic6T5IcUkxGYDyt5Pe0Xcp0 rM5UY94UzFIRqcSdReTX5HVylCbpy2yRYlNKFU1Z2fku8ZLeZBJ6+zS++QX9N7sJn1XSa/KwzsHE gXm5i882+Q35Cw3REjqGTmZFbBF7RFpKTHhjb3xmknmY7/vw9E9ARnuZjR2RHpefk88YcjPHOh3A SIo8SB4mL1M7RhqnjfRm+h79KxvCprEH2WfSL+Vn5LeN0zHqK8hCcgd5jvybumk/Oo5eTufSG+g6 ehe9nx6mR+lXbBCbyBaw76W50hLpV/JgfCbIjfItylrldsNXmdrMocwfMv/uLO1cS8aBHlaj9/eQ RzCyfeQIeR+fT8lnVKFW6sAnThN0Er0en5voHfQxup0+Q1vxlqP0M/o1lqR/0TMMKy0zsDCUH64C JdlSaJi/ZA+xI/gcZd+yH6WAlCelpT5SlVQnLUKv1kmb8dkj/UUOyUfkTsxzqbJF2apsV55TXlFO GmzGm7HGv3X28Y7uHZ9kSGZ9ZkumJdPa+RfiAw6xesAEq0Lvp+MzH/jeAorbSd6hNsxdiHanA+ml mJlpdD5dQq/FTN5KH6BPir6/QA9glv5Ev0ef7Swi+tyT9WGD2Rh8rmCz2BIoY3ezVvYe+0kySlbJ Kfmk7tJwqV6aJS2TrpO2SM3SW9LH0mfSaeksPp2yRY7JeXJKTsvD5WnycvkR+Uv5S2Wq8qbyucFi WGhYa2gz/B1azUDjWOM4Y71xk3Gv8V1TA6jzVbKHvAgKPPdHj0mrpRppD7mTlck5MGF+D3qeRmZK oxgolW2n69mNtJXlK9caBrABdDQ5Kacw16+xrew0GyCNoiPpBDKf9dYfaPDKzwKqkl8lJ+QDGNvv 8eRrDTZ6E/veYCMt0JEqoSP9Ruolp6U3yQfSp9QoP0o+lC00QE+wp6WxoIJfyQOVWpKQHiIvSEvo jWQPqyHEcsa0EXQ8mj4LuTCRltIfpE6owaNBRRXSX8ktZAH7MzkBPl5P7qUz5TnkTlJGbyBfkqfA FUXK1YbuBh/9HZsnb2Ae2kqY/AxGV0nzqaR4ya20XnrA8D17nywnR2QL+UR6Hr0/wl6QRsknlfF0 LjjgRrKWLOlcTa5TauW36Rwi0cmkQD4G6XaDVConUK6CVJkKmbYX3L0fcmCQNAo1QVDOpaCLSZAQ D+BzH+SEDAqaBx6/DFLs96TVMJG1kTmKg0LqwFPzZmY8mdL5FLm/cw65uvNu0gPyYF3nDXjidvI5 2US20zWZ68limJLvg7cvVYaxI8qwzh5sA3ufTWBbfo5fzHYBDZJv8HkBmBmovEQ2yH8iE0h158bO P4K6u0HC3k+uhMJ6HKP8Dm+4WGonZZnRbFfnMGkxxvspGdf5dGeMWsjczqvIGHKAPGlUyHRjGjhu pm9jvNeTWWx85zJpVmYe5mETZkHDbC2H/LlNGzJp4iCteuBFVQP6V/ar6FNeVtq7V0nPHsXp7kXd ClMF+cm8RDwWzY2EQznBgN/n9bhdqtNht1ktZpPRoMgSo6S4JjmsId6camiWU8mLL+7Br5PTUTH9 goqG5jiqhv28TXOcf286bv2spYaWs/+jpaa31M61pGq8ilT1KI7XJOPNh4cm4210yrhawHcMTdbF m08IeJSANwvYDjiRwBfiNcG5Q+PNtCFe0zxsxdwNNQ1DexTTXVbLkOSQWZYexWSXxQrQCqg5kFy8 iwYGUgGwQE3/XYyY7Bhicyg5tKY5J4mv4jFSQc30mc1jx9XWDA0nEnU9ipvpkBnJK5sJ15TSogkZ Il7TbBjSbBSvic+DjtNMbo/vKm7fsLFNJVc2pG0zkzOnT61tlqbjGTXNrjTeO7Q5sPJ48PwlHg6d bN2Fd8PShprgvDhvvGHDunjztnG1F3w3nOBPqKvDM/BdVjCsYcMwvHojMDWS6+LNbE1dbTNdg1dC sSwQo9LHp2u9BQ3z483m5ODk3A3zG4Ca0IZmMv66REsopO3rPEZCNfENE2uTiebqcLJu+tDILi/Z MP663TlaPOfnd3oU71Jd+sTucjizgM1+ITALk67fE5BozqGR48/NLOV9TI6AJtgcnxFHT2qTGFM/ ns3qRzbM6AcE4K+O4lvNM4GRec3mIQ0b1P68HkOkzUqBmoxv+BcBBSRPfPvzmunZGkOB+i/Cb3I6 OUdqzXR6F9ycTjd3785JxDgEOEUfB4rrPj2KV7SxZHKxCvuZGw1kLOZ2el3/Ekx/IsERfHubRq7E RXPTuFr9Ok6uDLcQrQS6NWvgd9q77vgm8TtNXXfOfb0hCUpu5fYs8TWbUuf+OVW/p2Zu/2bq/3/c nqXfHzkhORKqcbxmQ0OWakdO/NmVfp9PKOYN97JQs2dIrRRmqOMQC0virq4hdzWBulxra5YL8M8g iHpmm9EEqhQ1ND6sWW24WM/rLIlElmf+ty+1dZ7k3xLF+a9lh9HcP53tqN7t5gE/u/5Z92wbpJET IXIYNPsNGyw/uwdS03s5IluA4mHoJ+JDmskkcGYB/sHk6MdTXbhZw5ThzkRwkaiuC2cvf9YwnP1S Hf44dfYoHgaZuWHDsGR82IaGDdPbOpuuTMbV5IZ97BX2yobFNZB2OuG0de6/Pdw8bGMdZmwu7Q/2 YGTwriRdP26XRtdPmFK7Dy6O+PqJtS2MsiENg+t25eNe7b44IZqoZbyWV/ImcX5BRlIMsoWZRPvw Po2QJnFXFhXiega8G6JOb4Q6Sma0Mb1O7WrHUCfrdZqo4+PjMmbIxNosWgRBcNYDDWGHBo/hOoYy mdSyZ8kNIlWSZ1EOQv1+fk9uJJOQPkWqQpqMFELidaOQpiNBfyWT0HafMrmzA8/aorxOZiM9Avgx +a9ku6GSLMT9g7BKK9B2i+FZch/uP4T6GWjzCOBHUU5F215Z2Gy8A/bVZGJG+0uQ1uK7Y1EOQxqJ Z3lQDkZaR18n63FvPcpb8Nx1vA5paLa8GGNZg/vV+E4+6m4BHMI7uEPKiZRA6kYIJoIzL8FOl4G0 o4yTy7M1vBbqD5LELW78KWhjhO1gJhbYUDbYXQ7ixN6Ri7iJR7ToyrzQGfyw14JCLyYkDN2YwKUI xzbekACcR5IknxTAvigU/ej6pl4Wke4kDRulB+kJXakXLBVCSkkZKSd9SF9Ydv1gF/UnA6BtXwTH fjU0iUHZB/iIj1roJfRh+j49y0JsvNRLekTerWwzjDX2MAVNV5vbLG9bifWPtkftA+2fOYY6tjrn ON9XR6l3uwvdZz1bvDm+Mf4n/GcCdwSH58wOfRuZlDs0Go3+AE/l6sR1eSPzfpPvyt9U8HRqQ+GC bqOKgkUPphcV0+KjPT7t5e2dKh1fNgw9gTrCp0vhc2fEZLsSrgJk8ASSs3Gp/aymkDMkLrfz+7Wd nyiFyjuYmWLSl16k/Xalb6l/aWBlz5Ula/1PlXxMTFtyH/ez20pu6ctuidyaYK1+2hCYnmB+n+af T6Rnox/4WWOkMZctDy0Ns+Xkej/bELglzJ7xveBnt0Q3xNkGyy0R9mb8tUJ22P9KmO0PveZl8/ru 97N5gVllbFYJnVw2tS8bVjYlxkb5B4dZr1BljKXC+XFGevSI9uhpsZCw35/ri/v98fh+Sw+vxdIj VaTS8qJof8kaXpubvKLBs9izzSOVeDQP83yUuylIg21sihbJGRhdGs+luf36FV2xzU7t23pfETdS 4/yKJfcF0+rp+hOn6k+op+qPnzpRjwLwcVJ9/ET1iXWOnmnHjeoho6NqnYMXapUAevei9f/9R7JV BQZDMq8w1ae8b0WK52WlUBYV2rciYDD6A8YU7du3T3kqmWfwef0BSg28LCvtKx2ue3vlX25dsPOF GYOPPLzlYOZv1Ngj56Ve42c1XbcwE11eM234iOnJJB2V2Xv37DtvHrdjx4wZ991w//oPJyy9c/Ct r7at/sMvM7tql3Vrv2Ht5ZuGSWtq5laPnHbF0LyR3Tv60Psvu2dEXfsscNUNmXGsAZhWyUWapdCJ jTS30aSqbbRsN9nqMKHUXMatjiuIpEpxSZKedz28UUxSx+kT6ukTpLqquoqPn6aYq7yib0WZwYiP T6X003t+P2rKgdXXFV6UTNN0ZtwB+gN1fPdBx5mjdRu2vPSrTCwT/9n7Z2m2bqybyswWlRK3mffA slWiKFux03mFA2tbq6qySQB+aHU6BXC81W4XwLea02Jhk5yOmIM5nndn+8h9Rv/RT0+SuMoLU/iU +aG1q6xjNU2n8y4qXLn6wJRRRzLj6DH6lwP7tmyY8vaZjg++y/wjY0Ivn818Qm+Bp8VCRu+xgH2e M7TRsVqKSlWMgbWriAXbmFIVMfQz9h8DK3QRbKptYLVt1kc5SZ2qP3VcPVGlVpFqnqsn1I4T1OWu 7N2rrE+Zz2swFvbtW7H38NjLSiuB98NLbk+NypnOZd4g2sbms4XgyGItZzFbLLFRdBRemSQspCxG gxx58R3B9Gj1eL36BSkZdaJ3L7KE1nv6JHyDWBFt27OHS9P9yNah9xIp0IKMd7ZK7+JOIm/D/W2y 6OVpkDo6qHdq/+HDh/l34UFjlaAPiUzYR6TOT1q8layt8xMt7q28V6JM2irtxBbuCkK9aA0RIxGL 9BVhXwFvz+Dl8u6VGH+VeuqEqtPKOqVnuh48xGkmnfbRMkqf2ZypzVG+/QlPYGRS55eyS2kHPebS SbuwQk+s1SyhqKx4o3Z7wNzW+ZXAPQe0HI58s4vYODUQv82G3MbrSAkQfxjZYYyHjyi8y/DfTzqF Jxkm4UlfgIoE8J2WY7UCchGV1xDVZuM5rzv3yPPPbDXEc9QIyBLKg/XXUPf9SG4kJzZcrpQN69h6 63rn7xyK2WgNshrPpb5LcoaEJ3qm+qbmjA8vMC6wzvBc5VuQ0xC+jl1jWGFd6VxnuM+4Rf1d8AP2 nuE964fO0LmBN5q1RLK8l5kSs2pm5s0xVyOBmqU5UBvHUsPI5ujrtwvGTIMv65ekOSr50Gn9Erj/ +vE/ilRX51HdXAb53SB+IZk8Kpc3LhUyyGiYtOCdbStalg2e/86j7153175nbrjhmWduuuGSevYO lelFz0/bnen8IJPJvLrjvhfpw5l7vz8Jn9r87+at5bTyKRB4BrizkJ1aXNLsrvIF8iq2id1vQhAH NRODwiSzQm2MvmERvbfwMREax3exSSW4G8A3mksgNCIQ6hAIxSxrORxdXTgR+AnZFM3uLFe6ZqKX QuPwQzIlx7qfVtE1RGeNJWlI9az/GDNTNaoDjFgdqKQucCCtJ/XpRNJlMBj7gAvL2JnWQe9MvPez kmXy9QNviL0w/I1pfGxVoGUjxhalr2dpyexS7UGPxzDJ3tZ5qtXlEsB3mllVAUW9SpSTaIA3iEb5 3WjEgTtRECjyNvaSZmOWQAAxHy7G4jFIg5J3D/P8MCk5wTtbzfNDcDqEs2zAX2hzu5l4oWZ2ugDp 7zmmWd0eNinq5XX82S14NGcVq5VNAvCtJmbxf3ob5xH+Pv428TKt7wBlgOEl5aDhJePrpt9FjCNs dbaJjgW2mY6V7pWe29wH3J+HPg+fDNkOWl/0sDC2cHPVqGr4NZzGRhC/CaUZ2ApFLarJYHgjEvJG IiFTJARpYQpFJHtUbWNP7B7jotjgDe7hIyBiOpyU2SyNgXcw25zW6UtsNYkTlfbTbK491XDuLmKr mMz2s3xs427apRM75MrpNBcvWIg6qqpPdNQfd7k5ZpF1Lde6pBUswDmgH6mn9Uvr6gp8iVQFMN61 /HIhLNZmUAL+ycazFSxQ8PgD32+///qbH6L7PD/84Z3TFz/9ymNTozt2DKqa0X7Toc9nL/jFQxs8 R97/ZkftsweeWD+9NyhlcucXsh+UkqZ1WcRZc4Iap+JghFBOqmkbLmhR0mJ32pxRi6XIF43I0aKI UmRP2m3BHCx/cYgeNiluTHEs8uapEi7QDpfwD3FXVldjETkBajnxmvqau1I9lC7lCcSidVPsfnuN fa1drnFd5loRlsb7r1Lne2f6l9uv8661b/DeFn7SblHiEt8XtlptdodspHgvlpondmsYwEtwuxUR O+3TarP55OB+9gTJYXO1QvRSQTft7sZp8UVxFg9ySo43GRtTQjalKEmpKYYen3qR30lt7hFso/1a ct6h+2k/LCTtmvW8tCpuo3dncZg+IbDIZdaptFiCgEegEYNTBT51dIJVIcLArXRJnafCz2WW0JuM FedAsZBy2cbXVJ6TZF5qcmvsngWrdj52Y9mlXre1sW3t/Hkbva2Jb1649o0Fs2fevDnz1Xsvd9Jb gveva775hke9j7Brb5xx8623xve8Pqdl5rSHekZ/dWd75l9fQMSGIANUZT/km52mtL7uWttc2wO2 Z2y/symXSpfafylLbtA4sRkko2KxSkZiA7O/IcleSZIlO2E2u2yUXkLYiwnK+DbNQmQZTcgbFrmN zX5RUSxabqzc0iUJAfCFiU0C8J1YoSxttEKzG7W8ZLmxKdHHuNmJpRizaveWE6bCgpVwfUx8B8Dx vRwLbI+jjW4UM/1tOl0vBOEpLl6q1C9UIQfVU1Wnq1yVfJIrK9f1TMtYnZ1OJ6Zb7PrZsea7KyHj 3tWsZZVSXo9KSc7NreKPqAMy0Ebz2jRrpa1pbKVNS1Xa8iIoe1TyBuk6GBh9aJmrzJd0SS7KtnTc yh7+xWuvtWb60GlPSnvPXvJk5lEw9T0dC0B4fO1PKE9Bxk7WOQfRAhifnU8CjTgsUZ8v4uaS0+qU 5WjE7qDEGMR6ITQCAQgu4+s+5xK+/oGIOg6BMzhjFLmF7HWKfGToutwNuVs8T3tetb1n+zBsMnuC ju4hydxL6WXdDzkmgTtUj8Xn9njecDi9Do/X4bSDRTQP74jm2AZF0+HUfDTbqRedMn2Hsw+kmhbn 3XNNUxepq9RNqqyCSYKCSYKUBNUgQ2d1JglujrsP0D6IjLsHRNWvxbHnf2IWBKxcyCzn2aWea5Tg ETHQeldlST3EwvF1pp5pBVgkwKjgGvDNEmhbP2Mb8Ion4UtIkHnE5zVCE0hN+pXv/qtubt2x8bKN 3Z65k73f8eKYW+9qp6Zld5z6bQdtUjfcfuixB1rGVPvZ35/PrJiaOf2H1+9qOca1tlHAnA8yL5d0 p2OyUi/mpDFsLEk03C2qwcqyY0kMK3lRr90SpaRAxRToGpwaDah8wQ8ImRcAegBnNbjD7x5Wf9OF SVhih+o5JnssyKFDjZpvaM7Q+BT3xPgCaaZxpmm+e2Z8mWl5ZI1pbeQ907t+lzHOOaBQ5wnDpKQQ eLwqIW4Y+Y3CeDKe4DdcvJdj7Qz9DNN3pnFEQuiZu/oMfbaf5iZ7ChpVgUjYKCqsEYzi5ItcS1Q3 F1u4mIvSSs1fHZgWWBRYFZADUEoNkwJ+/tJAG8vfndaVNHDiCb5yCZmna2q6pCup5yobX6U4+3Bp V0eNsFa4amYw8gXKDdkGZBGXWoErP/Wel4QG6czuYPGIBZMHTbqSDTowp7XjmqO3/iVz/OHbvtrx cUfFmDtHL33isetXPitPcMzvNarXwO8+mtGQ+ffbG07chM2wG+gzL29/5ezH9c/WtT1y386dmIDp kHd+7KnbyWLNcchOZfxjJtkMWca5sBejstlmb5QkxqdkjFiiJRZymhrNfyNjgPtpTKpGsYiugvKY A0EkqHg07KElVaNOnRitnubaGLcM+Opd6RIyCONfIiwYA5EMxmRft7tiurRnY+bEyL7OfdLN/7xN /mnHxnsy7syZtg930G/o6w9xj8UEUGAOKDAAH04vRnQabLWRcLQnl5HQw9iknj3diahB6RZ126Nm G19gofyfgpgEkHZy+5KTIQBdceKAuOkMYq3UjU8B8FYAsuQr5ftsXM/yiSf6BPn6suSrWyEXmCKQ R+kTleDKrEXyouiIMD54RwDwjhwXlgkHRF32/Vz9xWvPanm8IX8tJy7+Qp7zkZ4fXxfL4F1UyEO9 J8Im4hxU0cdPi/wj/CNSX9i+7qWYe2G78kZ6g7zMtMS61LbcvjJwO9lAN8prTautt9rW2u8IvOV6 zePOA6e0ROIhXsTjJbzoEceKf0yLFsVtJBokNnRjW096vifRxoNmam5jczQ13ejU4tD44WVwqk7m bKN37S0NNjbDdMb9lvxGX5ciH/dpPubb3PucSaN7ZLiGkFUQ3JX1JXxwfNHKcgznGmh2S8iSujp6 3tVyThMgcL54hG9F97dIF7IOnb/4qi8Otn+zYOG6OzKn338/c/quK9cumLvmttlz1vcfsXnC6u07 bl71tBQuum/+tg8+3Tb73qLiQ+sPdBJK2ze9TCfOvfWWaTPW3Xq2c9TmMU813fzs9i5bltNkFFLx Bd1qeNEawxJQ4MICcFogma8EYnEHcFLrxjEadAmUuoT16Qq6itPWblHu2RjjkBwOLxlLqVAj7Sqs CspXGghVRWD8ULq+FCRWf6JUTAwwzwlR5VL0499wohMG9QWdOL92at3F4ukSVPz/89afv+s/XoU3 nX+RVt4/dKlfS17uvyw5W7rKvzA0J7kydGN0Y+j26AP+Z0IHQt/4v4ifjnsu8j/i3+GX+hfNNLBC vu4mQUzBRNwQ7xYd45jGF9kIHx59Z6wuklt5JxC6WUmskMiuny+rm4u5nG7lYtp1jpZcmou5Nmcl b72ubXLBy+XuubWzS+ySevhPYCQLBXMg61NeyKUtSgJhix1ebjKnaJe/Djro4h3+G6ZPuHFsX9r3 pYV7z1Lja5tOXL/y7489/wF788ll17Y8c8ONj9IJ6sqrL13158W24OQF1PTnT6n6QOav8C19mdn9 wkGp/MG9hx7aCJGLlXQfzJ+1iGHiPtp+0CPg3zaamaFKlqqoQYbnBnoNYXHMxaOmrG9pCZefsAYE ygU7eOBVkpD2wYkj1R0+fPZpOHMYooyIUgf91UgcdM5e6nDCmwZF8R+tWeAHQYioOaXVcULkMtIw SRF5idpLnWOaa25Q10ub1d8prxna1ZOq1aTUIYRnrDrX2qz+0/ZP+z8dZtkm22WHhG1wRZZhXZgM RqMNsAmxKvAnwXunOYVlHzfavLjFJAi1HzRIM0jVuGzz4lvmqKKYogbJ0MYWa2ac6Phawx4O20+t YDir5rbFySyjNH4sQmI+laXNMpURI6tZx9rajZ/apM02auPXqtN4xMhWGZuMzPgL53t/Ep64JTlY ffAviBkL5aiggmB1VehE9XG45fCP+6fS0J3W9US4KUoxqdCO16mHDjkOHVqn6CVEzshmKyLootgm bJWdksm4H4Yv6fyBS6E6upTrW/wvCQ9XUkpInoSUKjQYJVb2B1b78XMdDz76Pv37/cPyImXK/p+G 0QOZoWwK3bLvmjtu56vZFqy8XwNTLqFRefYRGTgZzv1QsjwsOTk5O9lovtVsmBdariw2N1pvUW6x Ggr9ZilY2D3qzzWbPe5o9+5FRSSSG8W8xeCAIKZgymDj/lMD7AqtjK9hBjdneYOBz7zBxJ8OEBg3 ePmSYphYkLJF+DdsFt7OxunCx1vZQsW50bhw28T5feCUC7MswNui5idYj+cA+G24eMNzANWnB0zl nip9guqx8kMRwMUomH/6HwiaW/NIEGZVMFMqS1yVkPQUVj1mnntsylyJC+w8B0vSRKluyqeSMDpK KzjvpgBvYantbzbOnrNm02VNL2/M/IJetLrfJSOH3fxI5kO68IrUkCn9J96zMbND2V+3b9YVT5UV Hmias6uhtzTe5Z89asSiojPbjLZ+C4aNvw7bPZTM7vxSWQFvaC55Z88MNj+XQRBzZUGM7yttGofi pNQ+A1Euy3KbyK25m8kDynPSk/Z9Uqv9dftRcjz3n7kuhzvXlZsrdTd0c3WPxGPD7ZO9l/km58xV FuRe777d/YB0v+OByHb6BNvu+qPDg3ibkOpVQzI485OWbpVC+PfoVqk6CZXDnqhNCkdls5pyXkJS cawNoVggFTdRE7QSwyRTTnQGZhs6V7p+FNe4kHNvCWwjl5hMqKLcQwhlcykNGORkXj4mzp1fVipj bwJ6p4H5vG5uYcutr1yUefXzE5k/PbiTDnnlI1o84GDZK7945q9TF36x9vHPGOv9/ZmX6dVvfw6/ 7bE3e2y7+7HM93e9lPl6wwEu1x6B7JkCinZi7j7XSuIxOsSkU6dLjTqJCV0205hwk5gFUZktnKLM cDLoahoXEBBJoViu+n8mvX+DBgVqfugiveh/kl6WDLlWkSW53r2GXKf1lcJGRNAriKGXDTnBUJAZ rBbwgUUy+Pxev8cvGcJSIEHdDmRBUyRB/RZXAhGu2Ezojr/VtJ5TaAB7DFDYGeizIFGa9TUVgiof oT8+N+WmumWNo1fedXhNZhetvOvJ3jWj7r1q9I7MW8p+X+6lV2aOHHo6k3lmeumOvr1rvn7qi393 52fLHoNk4PGsVnKP5jMoUZPJaCSSzNncYo5aiQlWTTsOVrjLjROlS+KWuJ1ZQnbZ/H+eM863P2dX 24DLdQISzFnP3aeCjk4dT5+btCyfYu/ABaMymx6T888+IqXP/lG6Vdm/I1P9fMa+g3MRlCN5DcZg JndoaTGGTdh+6xoGhvBQHB51xkLW/0O/NauQM4LYIWQy/9V9C0c5p3/973z/sauXFTH1XMZc2Pft 0sdnP2fNHWN5v/vv6JiNXi8E7+8D7xdQjxYKe8M+1lBIrzB5qFvKzycJd4AVEKCBT3+cTyG28gJR hwSLw0xpqrAgH9tnGFdhg3DTcBU/u/pyCgdrfyAEplh9w/z7bGlTIS3MTcUt1CJUQUtOakYWE2Di UWq9kKAYDzoP4XjO4ZEGIeOay0sk7gIAQQ+Vk+FIKJITkQy2lFrgS8VSpgIEpRUE7bkJ4nd6Emjs 9cSNuMpTChI0YgVle13IouZEguRLyEQENygcGzrCASRmlNM6nHJ9Clw/kx7Y2uzJID74bqDXLUOA VLikS9nCTZmj2/6c2dq6m479cCuld6d2Jq7cu2jNK9ck+q2j7K6bTg5k1c/TjmNLG/fRK/78Hm1s ndP2y16Lm0aNu3XM+q2HMj80Ta+gLuDjIEhpNahIIm/toQg9Y3wbYHe/i8R2wO6ycr3s0UsvuxXp ZbJAL3OjehkMiRLar1oeVzYrOxVgCWrKJuzfNRO5BHsrY7GxcZIo7jgqNxNJ7DZYxSoXzK5+33at ftxPpy+DmnBmkLhYGx6T36u7YMWDz6ylCYpMfd2SpVUdWUUBHjnQIyfCMtfBV7hSgDFWdH4pTccY XeQZTZ3F5hiWseWG9fb1LoNZUFqrlRNaGw1pVjnqNJtTFospZeUuMd4zAfAOAeB8IQB9ueI1mnBO WOvjHhrHFvlYT4NH9tAUmAguZ33t/qaLmz7KCtCR7r1dIzmh1i/R13CuN2FFOZFG90l91jfbtw8G IlwVqQE7jYtnjJjf7ZW6l29++TDdFtx+w5DGm6R/nM1pe2P+J1wicH2nO8apkIWajTJZiirEFOdq HXtacxoZUBJHs/+DtnG6q8fnRL7hv0T+F/W63NInO+Hb8gp7GxP+zx14xX2IxHGiJyo73uWDNHWe 1oWMyWHH/go4FGgGAEL4TuvGIZubz5fitEk4dsxMZquDmMzMYjUILGAvUcz8T3sFClRM8Bdde136 TjZqzuqUw801bqTzXcbq9nb16NF2vpWRhgMTfJcmXRuZMaOgLIPIJZHLIldEboJWryU57TEhGMH0 XKI4eK5r9Rah6WGx0JV+fOEHLcbVsxQ26OIWd7lTZIpNItSBZcWE9YUPnD9TAPxRlpfYZMTZqGyy Zie6BBYvwnj0xxLufEifKoHwxZRXV0Eu8cHAicdHI/70UyFhbRVhTpOXhU3yCtta228xlbYRthFO qUgusBc7aqXL5RX2ax3r7CYrU0yV9r6OMWykBCegaZR9sMNyH7tf2mLcYtouPW00uJnT4eilMK+i MBNs6V6KCaDJNt45nmowI0wms8UKDnY4cFjczBrcTW7m3s+2wwPbu0WJI+iht2axmS1xzbbKSq37 MUgHteIOa4PxYYb7Iu5crFLsY01+Ma40KE0KhALbvts1ALyRw3f766uCHWAKbl8ADp27OF4PawPT wAVo1ycEG4RbHetuFEYHCnDReePiV8TWeQa7au/BgHtP2BYjm20wPLrB8NhH7J0/7HJYuMWRdda/ uzdR6ShOCIf93opKR2mFAPf0QG3WKZ+ug3VClmAXrK4OyzX1B/pW0IQr6cJhDtd9iCy/vJc/B/55 qryUmbwzU6vsP/OPuy4e+6B09qdh8ptn+sjHznBmhNtNiYFTzPTGXW7Ik3bN4vGVm4I2v/COfaUl OGSCeRc3mmDomZhRkkxmmTGz0SRLcYMBDKRLTgD/wDYG2ETROamt899aiJOaUh+30rh1rLXButja ZFWsJmgyIC/sCuBl/4tMyKoGspDBeOR/iQYLR1iXIYLNESycEGrZ7RG+OQKShUGNfeLKdbLAkO7F 4ZEQx160ucpNcWSg4LrevbjqBxy0mrRhlTBo2/cOqzRppTpYWmnMyxFxE3tzAJbqIK9N6tEU1mSl 0eFF8vDrU3s9AHN1MBegj4M/7PLpmypCyeS8I1gHKCyjELXA3UOvS2z/62czQNhqeRWQ1XSmieve M6C5fKy8i8i4MHlDGxtyUq/q9YYD4bAsq7LXGrCG5WcCex2vOaRAIBhm8VzNNcYzJqCFapVa82Xq JNc0z5TAtODk0GXh2wP3MzUnKknuqNXsS/G4Kb5ecEEHQF//AJwUKwiAb4TEAKB7uQD8BMKA7DCG mhCC5UxxHBoEhnTRkRPpsld0g0XXciAzRulWC7f/YK/AaPGoJFEqc/VaWC0VKlw0CO5hMFrIDLqe 9n2TDnuuNbP34JHM/u2/pbl/+pCGr/v6rt9n/sTeoAvpw69knvzo08y2Pb+lU36d+XfmCC2n4d3U +ovM57q9IneAuu0kSFq04lmuBV42Uh3pvVy93CtbbfDHOUggyNVuYnKnTLBsQesiUgSi9JQmNDhT KB6i+BcK2v/X9es/1Nj/1sJzLlzG0rrVvERMDp+YLluZq7FcHRPGRxSmG0skXDBE+FapsDtY0d2j rrq77rvM7zLr6fUHHqm/tPetmduU/Q73rL0LX8p0dDwv0Y2rpt7is3PKeRQ8DtMYc5BHz2oJt9VB 3X0jU2KzTQtjMDn5emESuVHk+aB7gXgREsFXO+40EDUQEDrgbuv8bLc7VI7y5O68wnL46T7bnVtY jp0UUcLrLUrc//Pu3JR+H+3FfZT8vjYCQIHjksgl8QnWqZGFkaXmax3XOddY1jvvtT/jbHN+5fjS qWK1i7ucXpfL6XLazG6cugr5LQb48Ow2JWg2+wOhnCiCI9r1oJ9AgCTyBD6DQafTYYqmHA/BVaKH GwE4LRZoAMe0PD4yg0E4Serj+Yvzm/Kl/Lzg/xXHOrX/T/IoOWD7f5kqWTU/53gQaBaLRhbXaQgr OEawoFJY8jzYge/5cfTrC2s250JC7NJaTJqz0qn2d7n7o6qOLhErhgOxXKGcShfkkxvJoUUq1Twv UgzpnMDh60SXuwU2rScp9WQgp6QgLbENn3iUbTj01so33hnVbdKlnademXT1ZT0SI/9CH12zZfS9 j2d6KfvH/Pa6h97LLcgfvTyzhPa+dWM/q7FjuVRWcd3wuSJ6aCp2cP4G+6oX82mFM6QZcqO0TJYL CvtIlZEh0gjjpbk1saH5wwonSHXGqbmXdbvN40hy5yUXPSA8HSjoAlJdQGEXgMbAod5YB9BYB9BY B9D4tDaMN+pmT+WzfKmwoK8Tp4sLakqmxCcnJxVcZZ1vX+CY7Z0VvM660r7SeaO6PL+xYK20wXqb fYPzDnVN/i0Fd9u3OLf4otkwoR6JlDucCplTRVCtSVHILZf2TuGYJiP2HteFbwuzcIHf3iNaWEAL FD8WwlOa7nWN9jBHo35JeGrSsOPqdZOOF/Uw1QKIjtA/2A4tyHfYrUoC/pQwjh7h5JGBFuTnoQ7G dbhHCE9kkzZBDp3AmU9hoIpVVqVxOpY20MV0MzXAiGjWPD34KxW8Gj2+xJwiRbSIi3CHg00CcEqz 8ycVhUoxJpoCh34rbgHA9EEAAsg6d7EpC7me0ztrsNaPOg6ag8dVePrOu6AQ35E+zrNTfEQgY4xO ePmwoMITnyVhFJD5nooogxWpS7L8QrHBw3dAeQwt91P5vAE/Nlx57Ad89PmpqS/ap/32xkXPThg7 dUDmqnHz5tz0j18+/uNaZb9zxzPNj1b2o+/XNq1ce+bh1zP/vJ/+Sb36jssGNw6tmZMMTE9XPD5r 0csz57212nH7nasvH1NWtqDbgD0rlh9pXPY1wbB6wVrZD6loxCkxu8KimHA4LXDkC9tcjbuF2ULp i4Y4ZSV8a4vSPVSYL5AmmpWTKzFlvaX/ELIR+sxnXYbjWdQI90sGNRzAE0177z+vpsBXAZVS7The /wXXIHXR37sXD7TgnhfmyeTKGzJhxb5jx0//5L19FKt/HnrrJe9rlpSzVq41/c4k+7ng80OHKpcH mIbJl5hWOJ9SvnIabYS5sLnbajB7U1A6dP0MQFY/Y8KsxfUxLcIXbVYf99O4f6yfNfgX+5vwI0B2 4bDgT+fqoEWYbDAYdAexADilAPhJX/IsQj3Dta6eAchabpZ6H1fPzntusGcOp0fW6NS1AbHapeF9 gKmpawHC6hRb4i654ZWZmTPv/j7z0+JXhu+48b29yv6zuz7OnH38Tmr/WhpztuXgnitfEXGr8EQR ZRjmyEIHZqMX3AqFS4Gv7haimE0KZUrJx9hFO+wqK8OcV4NQ+T5qfolCu5NuUoGlxNbL1mC7zXSb ebOt3XbSZo3bxtoQ2mI1sezWn5naYEjhkdXVYlcB37aYzXGT4jWZFLgD4kzxMqaY8aqv4xZYJrNM dBaDOoEQn26VY020ybQZv+jBdzbsTOtWOY3RTTjNymCVUM0VV8YqrBeskc1Ku3JSUWCRrN9tbcCC wi2SJcfBTTwFedwYFpJQzgnse3C7I7vZwfc6dKvDC8uihTiBib+3mN2QF39vgWEG5Q7WB/7q0Kwb DJC+wgBBWBdiSoVSxoMVEtjuEPZEGWWDOn77Nr2xZyyvB934WgdcGmf+1LT42mvlIrg2uHDA73Kt 4LoF/VBLFZGUq8idClaSvq5Kd9/gCDLcNcI9PFhLLnPVui8LqveZ7nNmJ1IrU2koJ+0rV8ptQ5Wh tpG+icpE2+W+mcpM2wLfMmWZ7XqfU/Fxy9WNs9FOnOYRky6wFhDSs7IyrEUlGfahwYjJt8CHaLY7 nE4bTnG6ff5AMIit6KrdOO4e56XN7eKlNsUH8wO/dMTi+DEVilAexWSK+oJeny/otpnNUZ8boNuF eOS46vKqqstttpmCPsWJvVzC0CVFCiLUxWw2mRDEzYJutwsbM6FAIKQOMtNxJE5syH1IGlHouL1x 7s7PyWmjt+/SFYP6UM6oDpiTHaGcjuDomllDvzinE3SZk1wfgBDlglQkmC6jLjQu+cbWeVMTopUf ZTiErIpnArowA7KdQLaL04TbwretdQooQGX38xSQNVgdqNlt0xQNjThRLK0HQXh0gvC4YWd6sBsG Z6jBSOkjmetf/zQ/1A8nqL95e0wy0uOLVzNXv5R5s9AY8GZ+B16tvveev+VLn3SEMt/+8/ZW6QUY NPUb47OGn3kc1MM5dgSox8P2aEVYjXKo38qK3EWefrRC6mfqZ+5n7+/o467wWNyeuDtR7uYZjg4c 240S6qkoEf4hSvDYMe0q3JB5K4ln19BrrCwlFxm7Wbs7Uu6+cn9Tfyt/4sWmiXK9aap1imOiew6d Jc83LbDOc8xyL5dXmrhOcI37Gs9aeYNxg+Ueuc30ovs1+XemP8l/Nr3veM/9pfyV6SvHF+5iqJGI crbBdaT6eW418Rys9sNuDmRVB6sNkVlq0IJtfnzhK83BIdWA4/iQSgxyBOYpxzGWR16EtXpQs9lM +eFjCQuNB8eR7VRV7S4EsVkxZ8xulWwei5UaVOYxWzyeODEj6t4sIeopbpO8NpsEiYR4HuaxY6kn phKEt4E64zYEK2NLddqLcctmS7tFQiRi255pWeHTplkMrZo6Vj2iSjg4Mk2zxEmO1/dKgguf9OhT nGbrg5/nnKg/UQ9AkC33wHGK1fN1ys9IlMet4c/p5FRZZRLE2VXoRHqoTli/uq1zzpUkFForFFpr TiXlymwwXAmV5JOWcKVHL2RM495wpSkvXAnct7dEuHOkXYtFKj1QfCUku8MfqPK4/YGLTLAQqiQZ EGyXT7SecKfnuSutttzERZTkJqqsFg4xDtk8AdR5AqjjEAN0XnXh0LkuAobmDW0G5x7OScouljCz ioztS2qZkOw9hBa+09HB0iczm2KJ3r7MZnaW/Tqzfnn12Mvomo5RZ39k1h59xkYzlFtpl3R+JUfk gTizVsF6aMVmu7l7jj3UvcjevTscZb6KcP/uI7rX2+u7z7fP697Qa4N9bdED/gdDz9h93biBw9dx KL44T8Ghp3Ke7bY356Vuh3KOdHvb93E301A/RSj7KZArFBM3NMeukIA+nGsm8etYIBZMF3cvr5Qr i0fIFxdPNtWlZ5vmpVfY1iE49kf7j2lXRbmDympJfnmgNOENTitaVMSKIiWOascmx1ZHp0PZ6tjp +B7xLeIsB/hU92ADwJ4zj6h3iJgYh4EHQSEkREI03bN7g/cgttwI9emUFhJqU02hpTQiWYumq9MJ 7DNoWgUJ2AbfdhkJ3+pepnyZ67G4cRyDF8ApMQuo+YhraIZJ+eJFuNb1sfw2drnmKNR4hHM81Su1 M6VUgnCE9gvj4b29XENO9eZ1mj2KEKfK9kq2rZJWwr48pQ3iTwwUBPNK8g8ajhhYzFBtYAYsN7Ai MSzkQWFRwoPKazgWDOBc5GLfx9C733kf1RLs3qbhpErD9Y6Dal1kVtWR/vxzbiscRyS/HjwtbtUv ObEE3MQZShgNXK3mN0Q8KFkizqbxQ2nYmuQfhLtwVdpYOBCqNjRrv48fSkumEIjngDOBbwOjkVQ1 c9/8nQeGN17cZ8EHc2hZzfpV1+U2B68+etv6Z8eq5kDegUjgykOLppYunDf3sVTuLZOGPbdm9OrR Xoc9lF9gubrHRXVLgktuH6lNv6TntSfPrLmoH/24W0TtNqrk4obLx1x0DSh6LSia+xb5KaAm7UGq 2Jz5Sh+lRlGqY80xFoshbiIyOLI4tjlm6O+p8lch2OjSUL2p3l7rrPdfEZpvuso+13m1/+pQe+x9 2weBD3I+83wb+Dbnr7nHYp2xnLhS4izx9lKqnZpyqXOsMlv5IPdf8k+qTfU5ZAMj4QgWKIsv4rAG 849aqWrV4H9sssr6/rRV0KhV7ExDNPAdB+HfPyloSDg6OJUCOCaUeV6jlXB8WpfBU0cE8RFZqPdl UgFj7RQW2DbaTE9SOUar8as4OPaGHRtuKgA4q+Vy8qKCVKhQwKmbkwr0SZAKXzXQVABnNT9/NQU9 IffyV9Cc6PCKn6nRIBzsO2HXENQD46uLhEAqnIDwT8RacEqBnFpKluBwTJkLlhbcSSoC6gslGFog BD2IjvZ4unXprit3LtEy//jVgQWsfNJdK55/cvmK55X9Hf/aNGbTG42Z7zPvPUy3HJx0++E3j752 GGv32M6vpBOQVyE6JattlztWOanTSvlm22Ls6MnuiNUYjMj4ZR2f0cRHbxSjN8I2Bgw/G3K+tZA+ /O5rwkRGZDBOQNSLExDDzTYaiwzxDAlM8EwINHgaAg+yB6UH7E+oT4RsJnuOZT6bJ81XltsW25vs T9n2mPda9thsfmw7/JVJjrxpzkXOVU7JiQMRz2rX9RI7gA3o1mZsCR7DTqCZOJ1WmIBdfYyg6/kO E59sR14Y48u3pmPQDqG7aQJBmsDOxQInIYGTERFf/hEjjRmrEZrk4I2MFt7IKMSrsXe4/FDW4gNW dOavX5o9Ni6C4vvVnVh6Kn1iqRg79n4R+q3WH8c/YTcDb3UI5oAZDH+oOO11zkbmmJOqduV+/8IH mX8v/fq2HR/FduasmrL+2SdunX8nXRN48QjNpZbnKVu989Hwgqtefee9V27ma8ww4OxTcCQikugk 7QkLk+0F9nL7ULvSx9snchmbaBnvnRCZw2Yqs8wzvA2R9ti7yh89H+d87vnc+33gbzmfC87zx2Lp EGfXkSHOu9ghzrf39PdnfewjWY19mHdE5DLLZPsc++eGL/0/0VMOlfokhxWBLmHQg4uAJSVrsIwH UDoLVPWoi6oI7mtwNbnAmpwmdAZ1uTnnwLGIRYsLWZeBU5BLMCxqYcryGXc5+Izj+jvBpQB+0AZz 7LiWufMPInLsU2OnUeYoGmOUjFFBckJOG3ESkROkQJtYloxi9THmRMvHXsBp9UtGnTjHXZzpsCOE rXqEHZyA5oZ0ns/4fkyiD/DFvRo6wsBziO0+x2dSv1mHVv1x+fx3b2nYUrK7I/788hVPbr/+2kfX PrLxzONbqbRh3CDm+GkYc7/1xsuvffDWIY6zkZCiUfCZDziboAViJOLD1ky9Um+eZJ0lLVAWmWdZ TTB0+ClaMRPHtfEcyo3wvND9vvKT93RI7u3un9M7Msg9KjQoMs6Ns4uR6e6FoemRaw3X+k6z00EV P37mtAcCY/3cByD5I87N6jaExqtyOGIx4pcLnuXHOLqkWTu4AfOOA8L0Hg84PKBBBftIuD8A6Add AOg7z0I7Mxd2L2/GAYJQDMvr7oJUOS+1QXyZjdGYv0zNN2r53cu7MIUNUGBHxxQGAlhnMBwnBIP5 +dA4pi6UifXpUR3HR6vwNyEgHX/CucA35rMHK6o6llQJFVucp+DhZ3wF5fFSgsX0jQevMSH8DjQh 4vUN0hX7i7/b93Xme+r96I/4fbCzX1la1szY2PEBG2frN/m2G56hkwOPt+KMhIQf4+qW+STzoxrf uX8uvWftkLlPQYp4gMIm+EMD1K5FvWbqzCnJ6ZWDY8A5D9oesj9jN4Xs3ezNOe05cg6fj26hWHmu yS7ZnBEL9bG01yPjF5ctW73U2+nR5ECBjF+duhtiiU9i737lvNTSkVj5ZkJzNM4mOZodbEK8wkPV TXio8jjjkGKhSQnG4eKXeDnl4/tcRxPAFyKUGTU/ibMQ5PFgzgG6nyTIafz2EmwAPUyAzyzYgB89 OgXVH36IEzADsBvKA69OIPpfBKp4EdVsNhpM0JBUOO2Jy+AM4/ez0t1X46A2+GQptrr6lPXBWXMs SRBr3PPn4+eLWrZu9YRuWXHp1HC/0vFDjxyRHti4ZEH5sMvcD1uGNVy58exscMTgzDjpG3AEj8he pDVYrYq32FrgvdRa4zWYc3Nyi60pb3Gy0trXe4l1mHeysdY61/qT5V8+R89kceHA5MDCSws3F28r NvZN9C2qLh5mHZaoKZqYmFg0zzgjMaOoobip+IPCrxLfJb8vdAX8Bl8b29XaLeIxipVEjcNxyNeR JtJOjsJ52MZu1EqVSMRpqcmL2Cx+X1lBmaUgGDwaoGpACzQEmgJyMZxkbFKxiIsLCLEmNEoh1gJC rPHDJeKQ5ze6WOOt+GGTrFgDcFa7hBN9YJmTFpC8WP5B5xHnp85OpxxzVjvHYKETHOOEDMPhB5wt QC58e/pBKV5vmOTMSRcvS3DxBoMui0iIN5xE+g8J13H8ND+TBMYRodXH9V8HwIbdkgAPhhMKZCG4 hgcZcgT26QoSuTAyf/ZOa+mQZTeuDzroiuYPT179hzsOrHxq1ofbfv3N/U/deMP2HSuv3V4bGldQ OnNKRfPttOrj+yjdeF/T2fk/HLn2Oan7H9oPvvXqa69yH9M6BNPyaDkvnb4Px7Pbd/sC5dicPcbP wxomFch98Aty++2yqOofyCkPmGCUeyX4/pwRxehFyF+BWSvrW95ppu1m6scMs0l+CDCEJHYTuZcz CEzJbzUXnzgEP2MSzdi6FrWIG+GsYgZLIecLDDa5ASG0UVyfRkQIgNHCGRso71ve7D/pZ4v92/zN /k6/7GfeAn2zW0UfTmI88BAdhQ4ic1YTApUDWkBwqa5WIowXHNq15f2Trg/i6CHeA78BXk5G+4YD jecsCn4GSd/3Tp+zJgSfiiPkfJ3CMsVdSoI7HQaHscBhsIWp3QS+xCHXdHo1AVNTROQKLREOeIQS iAB5g8+1rvWm9hUvjGxdvmDsHVVQCf9xd/0TD3VMY4+uu37CnTd2vASeXA9E4Ra0PiM5rF1h7stH MMa82bzN3GxuN39qPmk2EnPMvNjcZN6arTpm7jRbYjgNj1/hw5lyg3QTNpEVxMcbjAUKkbfK2+Rm uV0+Jhva5ZMyI3JcPoorWdZ1ZTYJQHbeEG0OlMkICEEuJBvu6ZINgO6FB3AWESGYQ3m06T9nDyFc wgtfrQfgc1OL+yWWLkmLMHzMyvrW1lb5b0eOnPHJqTMfcLrEmKUfMGYrm66FuQ2INckw2TDFLDnt /1ROGxD8wskLXh990xS+WB0AEekASPYrTWy6TpKusTC3Ie5JlMOPdXK3u7AcrU62onRjPwkVCVGh 3YoagywrsqHCPFxWCgw9LLWWa6Tllg+kvxqMTxlo0pAyFpgqDf3M1fYx9jq5zlBrrDPfKF+n3G9+ zfC2/J7huOFr478NP5p8bosFgXIyQ3gfvJm4gEuzwGhAmIdBwqadYkHAjcUCxMjc4S0r3M1qtRKc dKVOHKrDnMOLkAdftlNLxIUWLExdY2gzFnprAWEFsIkIrcav9jHQeEbrLWgcAwZ1CxOICIwRGEKg aaE249fnOH3n2Ox/SQyffYGk4qrXKO73xhKPM3c8zvz8XirUMOyewg/Oz72iDOo/8aKaqkxVksiz 3jj7SAQom2+VGGKSedAHdGzgGT4nzWIuzq00m3AqFgj7pCW3EsW7LXFR7EroQRs4K4uImyXYjRVe KgOcTwkRHNLi58UnLSpvzgtxZRPFLms24qOOO5D4q9wfy9Tk9eNtXm+VyPCt0y1B/uVvd4X15gjs 0a18vm0m+BK+JjiZjKBE+uzXmfn04CeZR1fBxXqANmdWdMxksZWZyzld3oKsQvDiX/cqghFBQe27 K/rpwZLlffSyV2+9zNODKbUCiFUngoG2Kp8q8hhkJxUppixGYFSngl9h57+Oogsy/iSgs13zYQXf Smg7zCl2oVTjliwwzLlTGL1ZY1nHta534NdpgOUu1gTQKfR3AFkeJaPln/MoULUUWodgU86a/Ir/ cYl1S6sItcTYsVYYUtANkvR1Hlelx6uAo3QALPVnbZTVXl4gH5ePm/8S+Dyu/FE5HWcBUzxpDobj cJsmoxGDjy+dRmpIIvbLcrSAbi7YVsAK4EN1FGzGTx7IfHguBBgI+wTuKE7WLi8XQTBA8HsRXAy5 GCdqF0QAcuGIwj09IoRbKVltndZrtmDB5jANi8eF+SIkHhcWj8P1d5qLPy4sVoOwMDBRm9EXoTC8 GIZJuNY9XOE2PA//e0dZsoAeJeC9bYTFcNRoDOQy/46OjQv5T3iriF/wH39KFi2nNC9/MBHikoh1 luTkF7TRa3cnOFrO6Q9AgPBDdBw/F5uNmvMuLVx0CF8xfBBcSYSmKJgY7Mp18a4FCVs2Ka/NFaZu u69rQeIRMDp+fVxLxP4DMn1ZEvrihQvUo6VPzV9xb+ymNx55dndy6sDFv2ytnXnp6v5y6p7R066s 3b9zb0che/iqaf3veaLjXtZy7bVjH7ir433OK1y3+AL04qc3ah5FMnjYdrVN/av0peekdNpjwJpx UqsCwVyn0vvUo8Fjwc6gHDd5HV6/G7oFNfjtFrvD5sgPCn0iKHQLq9AqrEKrgNsoq1VYxRJlzePI FM4koVVYhVaB6x91hFqFVoHr0zgfBfFqFYqLlXYihHE0Nm7atRDXMIIng2xxcFuwOdgelIM4j+Tz C948jZ8w0TnvPAteqFjoLHhesYAKCizrioXuy+KvcP+nojI6IH6NhrOb+AMXQvnn/kukC//4DyPx HQ2cSzmnbfgNLrPFZDHi1IWaghUfpk6LO4tkHnYOcQpPOn5dgOOXeysFYnUUr3ts+ccNj45VLa3d F1zc+LScundnzeJRpTd2NLK1Vy8cdPdbHeJcylDYyIXAop3k0AV7feI3LbBZ8JVgMsQafaU18lUl R9xwGy05tuGGi02TDXWmOYZ5JlO52t/d398nWKOOdI/01wSnKlPN49V6d71/fHChstA8U13oXuif GbyG+swGxX65hK1Ky+W2q6RZyizLVTZLICIbXRAZ3vyw0PHDggyM0EB014VROC2yDi++qnN2w+2T on8C4HgQAEc6gHbNk19Q3gtn7YyqMQ7XRe9PISN4/QhuMgN25BObAxKIiPNf+AkKSB+CTiAXpnKW a4X84T+rBDxreCQXB4z0DnHTGUg9h7wTMJzr8eNR5yrO//YQ92vwZcs8QZlgvlK50izztYk39Ijj 69jfEib0hcr/0Cdu+82H1H/9327/NHNiX8u6tS2716xrwY8fF965IvOXjsN/u5lGqf2tN9/6w2/e fAMdWpeZJyeAQTfO3l+p3Wn7/xq7EuimrjP97pP09BZJb5Gs1Yssy5awHEy9QGxI/AKEzQlmC8Vg UjIkZGxICOAQCC6BM6TZKEnImQKn7QkNNITTzLAZzFImTNrQkIwbZgJJQ4eGOYGU0GaG6XGZptTy fP+V7ECaOWcEerrvabF0l//e//u//7vGLcZtRrPhbIrvjYsl8WGesqKagpqisUWPxF+Iy42hxtiU 0JRYqzzP0xZqi3XIiz3txkOhxbET8fcD58Pno+8XXwxcLL4QH4gHy5wZI1NQ72w0wJAw5hqXtN8V ZQ3N9AHkIIhYCgIiFnyR5GmVGaqtLlDXqc44b8I4b06s2z6FWgXqWuUNiXOy43lND2pLvrKjJkTh sl1Gla12Mn+tWGuVC8LXI8ODgDC3xnlAmEOiQ4DwNW6NOXacA4Q5pwgmEl2ZRUoACLMbiRU5QwxA +KtwMFb/NB7J1g6iwX4abny8gVwIR64iZSKReginempn4+a/ffp0x6Mfr5n7/HDz1ZWrfrKrc8W+ bLvr+LPTp28c2Loje/25uxr7rzt29v783bPvvvMhIVWTsu2OC2hDQyhkI+1NmpgRK8OjxWZxtUdq KmiKNEdeKN5e7Krz18Waisf7x8cA7MYW+hfGFhSvKz4jnbU+lT7zXAkbw8SEJwO2bL1nsjjBM1ds Fz/y/Dr8SfCzyKexv4g6FAwCUSCJPikA5EnwhXy1EKIwTuvM0G19gb5OdxZzhxtSEOQGc4cbRiCP I+rc4da5w42rmEipKfUgzXxkKvg6hL+8iSpa7zT/GkdM0jAjvBBH7mu7+QBzc1zYHSkqvtnL/hoM sb+P3I2vNAxU36BgxfFejovArb4JPayq3HLP8ex/LX1/7VvLXukvfX3Vilf3rHx0R7ZdlEdPZcOZ e3v2717d9Odxjn/o7f3ZL8588Aua4Z5E05xEq5jCKXt0tZ8ZTlbmrHOOg0j+ImenU1JMWZEVr99U vIJDZhofEoKqpF9A9mEi7md+MWH+3x7s0FrvT7Z5gwcLeiSfh25YUfA+LOT4wblF/lRr4iBCzs0O JpMxWEjM71tOWV3UZ+G08nVCg2CcesrHSfXzl1NWXq775pAj5CaZT75ye3vTvHtvHzt29L2BYmfF j5ZNatyVmti0YHn/GaqFJiDf+1ALIxwhe40zEUg0KlOU8cnZiQcSXcomZUPyVf9Pqt50eJVQNBwa 0Vz1QcgVQ5aIaNQwNdwmtyltapvW5mnzdsgdSofaoXV4OrzdFd0pPVWRTCWHjUzOVVu1+yvuT3eW dYJK+pL6A8/m9Jaqvx+xU93t2ZHaiZ3p3qoIIlSbW4kmBgtlg4XkYIG/hkwIfw0V+GuowF9DhSIK ZlvFDXPlVLlHdUbjFQVObXhRlIIdiUgVVX5JpCnSEvlWZE/kvYikR0oiSyMfR5wlkecjYuQ42qYA /YJjujZW5KAwMCRVGNjnQBSYAQ1ATDUHAsE6erQNn1nH2PC2oiVFYlFhgRurIgq1cgeckmDgUZOJ 9JMFdBYO10rAUkxGbH+4robeXs1xSb6+pRkYGCVGC45xemckTu+KcMcxwnHdCMK0+93JSrz1YGHD 6UqG0qfc3qKQY/LyAtUDClcO0TCtjPI/VQqUeUHNiRqxqWZdjVhD+HRS4H8zLwYYz9WyeA8v0Beg Qk6VLp7UuQHW+dfT49x6kBODrwgLwfNu8nBa4uNBtzbyjTwIjUGeh15I8s0AUXL51HyIN5NZdkNe ND0DcA0vavp8GaI+fAXNCZRwaUgxC//zYV6k/NmpW4rLAHBWmIZl+A2HlPDGY4KSdseY6xYcigM4 LfWVxYQE5L/kYWqMpVOKKmWcMaHEKKJ1Vi7Tj4gaOQpDZWb9esA9gzfSSkAuyZAaV6oihR0iIHSa myCGgk6E/IWIjU4mqqJpv/7Mmq5V9eUvndzWcsetlS/O/PbxueZez4r2ro5gsDq24Y0ts9tPfvu9 j9hthYuXPzD+trJwec3k9VMnrk6XZCateTA8o23GqLLCIr+arL2jq23uy998ncZpcuAPYqVrGxRg fnVEUNEHyyoI90CkAIV1EFVDAFVlDiFoQGNFxdTt0HQjAWK71yr3sAG3fKdy5wL3I1ALeMHtFLBy 2u7e6z7hPg09UwJTyXFDgUQjeeEPPPiPK+SP8St/4j0NVwiay63JaO5HiVsuPJFbVbqPih1gvY3c B4ziSxgOczAXCQWr+yJZeMSHkMaJqReEQ+MUua2ZTHmI6q+inhBwcxRX1eIaJqIRvWvM3yyp2rDh wMGD/ky6+EcvG7c/8Iq4cCNzL8l+d2P/S3dXQbwM/j1s2QXaIYe1HBGiqBsFnrsY9weJVn/VrrUC dRk/S8r+oIf5gxriByaqSagNlodD5E5Eua8S4l5KyCKjDXwZbifVQIh7KRye5v5JKEC1gPM86hni DifOrxGNWLpnIMROhFhoKsRkgAeQaxK9GhUfiW6P7o0ORJ1RQK/0DIc+SfcyrpxWLijg2PJwN8dX 8xNHHnWFh5JDVXOgp8J9E3CeMMaVqZGbIAFMF5S++BUnBDMI1XvTmNzMwQHPqNPweXUv8QQpHRyO iNMTE7yyGUM2LKISleuxMMJ4yEfvoPMLUAEBcloR8RRIR1PX2Xt3tBhat2Y+PH36ptHdP+ie9FBL /Qpxc/+B735j4vSZzz8tNgAWZAKayHEZraOyK/m4eMglC6osMWmIhJqk7ueqztzIRaXlWayn3sWE hNmgkn33mg0K3Mw6mQ6gbl45gEcYZP6IV/zKVopL64Q0Dji7bCtAcoQgDjg7Z69ND68T4jjonmFC GkmlDUK9OkmYqM6G1kerPEdZxBaJ7XK7skoATU5cLa9SHlOfYk+J33E8435aflb5obBVeVF9XXhF PS70uPepp4S31HPCWfX3wifqdaFPrcLPUcNCUE0LFeootUUAhOayrWCdC12pLo+3QSlUoJ8u4Dv1 2To1o0ryrvBGgDbSNb6cJWouvyq6XB4NBrD6fAY8Xdx7M70ZoXqIqjtKBQZZrqgBRVERCgPCyDmc gCmxZOGETMmtKiCNuqqhH5KQbdsG4ixCiDh20AaUhfxiFrOVuGizhHbl32jsIsGvH5S2aPjzi8TL x2BtGOK1mRxU/JJpCbAQhpPzbgbNJzhsnDHLCZJgRrJ/zC75p4vl4FL9/kj2YWdF/4YHl85aKT6d w4wlMB570DssZ9FgZqpFK1NufXJkJ35EdZ3hkpGYWcE3J/FIM05HPAHGEswYnsDUSiXT5ueq6WCQ LXSjtnXUhtcDg4XcHQj2YcceE0gOR6dyhs7ErNPba3zQa5zhSap5Vi3/dfTDaDDEMAIDrNI5TBWn mPPMTdD+w5TIfRySJ+STfq4APOuqrZSU1hmFyAHC2L5q95Qk65ySR/FLMSViubC1mqQho1a2DMHv CLgL5ZhWBA+23F0pZ3wQX3c3yqN94x0TJdt9t9ysjdMnmlOsefoMazE04R60VkuPuzvlI9JR/ZD1 R+m6ktbMtJD2pnxpPWVVB24VRlmPyd+Rtzq2eHax18TXNBBChEPSUd/bwLs/Ui47L+u/tfqkPyuF Gs/48fCjwY8+ftT50cp325jq052WYMpuAOJ6uY/cOJ/b4WWeckSzP7BHkZXyovdVUgF7WAX8kqqZ FWrGnOWcobaZS8wu81lTNVUn+iI1R65haFlLfXmQwFyNtNpc2oRxkf7lZn8cYzYCWERsdrsUpIPD R1EN5EAdHmgGn9nCmmWyvUjVffGfmW457jYtK4NIl8vl9qGdy72+APJiZYA7GVWGpLpMbOf8SIFo pdtyyrrp8Xn517Ngx0l/AlxmyULOlE9QA9cML1vgJWKNw3uY7QIXtEVlS9UnVKQPi/fYCnRfl5pP QJCJzjTDxRZwnBgJtGzXQXbNfw2TIij/kbshvB7un78M/2mQzQ9/PdM5P+qw1sfY+38Qnd1glNKd qM50b95bMnNON8ivcfGnEJ9iuPsGTncLI/Q4mKMXuBIfJ703762biXxbeeD0PjcJ9GG3xlJQoGs5 BVoeuLDPHc9dtXCVRIGO0AcdwlIQnw1rdXq/ewR94n7hVpFkrvCXhj6cfxq9L8TfZ4KUrMadcVKs 5SxqHjHwDZw5ZDUIVbhjgO/zE9TfSgOOnHccaVXGc3pLwbjmTGt/iNOtHSkHa84eO7q7yVm7+8jL 9bcd2pPtPrZ72IcwMN+/aL4jPty/9d1ecdH1c2LXwb+8h3lIxzz037A0Bvv3/DxUoDNNcooKgvJe 9Eidr8j1aiR1U58kHZlYj24xHaRbimLY0yINc/XvOb8nQ8hGP+E6IZ1wv6sruh1siDr8SoE3atSz Rm0926TJ1dY3na3uVm2Obwvbqm7VesTDnre1d3z/YpxznFX+1ftr45JqDQ4uMKItUw97sbDA3wEj mko6Z0RD/l0i/PBmRvQiCWKsnBMtIeoEVrSOvECQonXdawwxog1VghqdapwUTiqiUT7EiT6JWFT5 jbRoCYgLaNFqi8Wsyd61noSq3ycpa23QoWM9tjRNWsclq8bZvrhjrZhoQV1ONru4ozq/LzdZYK4w LkGvmGsQ3MiAhix6frIgeXROgQYBmpOff5474oG6LuJSmEso8NTtCxc1APAF4bkIuqshqLOG+DlC S0iXRAZOATjLpQ0KeM3UUejWykFTmOn5rURBxrp85KhRFB1ypJjONmS3/ceO4YVV5Qc+zL7Injt/ rjH7mZhm2S8mjhhbez3r6f8lm9KanY/fVQomxX+ij0TZ/+T7SJEa0LEJXGFEtyRN8tsWeAW2J57v K5HqTPR8NNyLsAg9cCcdtgwd54CO3X/pRzxU2JAOzNb3qJAOt9Eg8fSIOoMOkA+zgt6wldJSnpR3 pGekt963zdTSVto/KdhqtfpbC9qtdn97wWpppXe1+Xjg8YInvc+aG62N/mcCW9XXtJ8ax8yjgSvq bwN/9PYbXwQGCosHe1TQrxXGnPp4fQOIEJGhr58DEXKpdsSsH4XcEKRzWFg5RAJ+f7mlBnAC+WbT U66pcINVJI54PJpEv18oNArF6sI3CkXsINx0UEdd2IHD4ixba7JsS/yW9Qb0Bg6zsYd0lhDujMEw zsrVFoRjRnhaPI5pngHOtx97oBrcQnxGdyzeBcOIyusn7TJ0IpIWCBt9FyOQ/l/2eRRpPbwEeQE4 DtSvKKQp3xjSpC4Fk0eE+ua9PlibMKzNMagLXBa0gctkvPLd6ogQGPgNtAPUBPQDMMoOFiA9NJcK it4DSwNtM3Qff4rWuJw3nM/xwBIGawi4KE8ERleNmRQyK1xa9qE3z2cSJZlPurNL7kiO6Jpdl31w t5FOxhbrRc50/7ZH13etFBdff3vP2NaZ5KGkYXvOoF/52B7bC7HfU7JosRorRLHtX9oKCux2rFpx 9qY9BYVhYlqpNsC0ViezCeIEebLSYrSxWeIsea4yzVjCFooLAbusYZ3yGuU59iTSs75gfWIsIlew YXJGaZB/LH/I3DRaeoyCOhHmFYuQM3YZHGmxUVFFxLbLmYhkH5GRlJ14nyuDn6je5xUwm/fZCp/N Mz4VSVh6NyZDl3RMRCgVUuh9No+NAeXbDqFin+1b4Fvnu+pzcU47YECwRTsFdS1jkFptwY4R2BVQ CNNlIaIbnaVkNihWlo9d91PhIraSoMbtJxBgjHEJLuIlTiKkxob1MHykdEwrMADvNNphJA4i7xQJ UIO1J1Nd4uzNHqpFqkr+QmhqM8oSphnuN/t1qoT8w+Ue5ErIwdhttDjbH6JnkKAXbBARhRajwS8N S209op6UhMjcI2tLC9LizhVzsi2O+/v/eenqDva7zQ5Z2vxY/71rlO8T4stvAylSfvma21hcc4Bo Szv6fLmbz807+ND+PUU37NdD+/PQ7jy5vXloZ56b9+UZL9wpTBAmCpOwe+kUoRl7pU5FdHMa9sac gV0FZ2HX0tnY13CO0IodX+dhJ8D5/HtBix29km4S9BOEmeMmNN/Vkrljeft9S+6e9b+GiE81CmVu ZHN0cmVhbQplbmRvYmoKMjUgMCBvYmoKMjM4NjkKZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0Zv bnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTVJDU1lDK0FyaWFsLUJvbGRNVCAvRm9u dERlc2NyaXB0b3IKMjYgMCBSIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFy IDMyIC9MYXN0Q2hhciAxMTcgL1dpZHRocyBbIDI3OAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzIyCjAgMCA3Nzgg MCAwIDAgMCAwIDgzMyAwIDAgMCAwIDAgMCAwIDAgMCA5NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTU2 IDAgNTU2IDYxMQo1NTYgMzMzIDYxMSAwIDI3OCAwIDU1NiAyNzggMCA2MTEgNjExIDYxMSAwIDM4 OSA1NTYgMzMzIDYxMSBdID4+CmVuZG9iagoyNiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0 b3IgL0ZvbnROYW1lIC9NUkNTWUMrQXJpYWwtQm9sZE1UIC9GbGFncyAzMiAvRm9udEJCb3gKWy02 MjggLTM3NiAyMDAwIDEwMThdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTA1IC9EZXNjZW50IC0y MTIgL0NhcEhlaWdodAo3MTYgL1N0ZW1WIDE0NSAvTGVhZGluZyAzMyAvWEhlaWdodCA1MTkgL1N0 ZW1IIDEyMSAvQXZnV2lkdGggNDc5IC9NYXhXaWR0aAoyMDAwIC9Gb250RmlsZTIgMjcgMCBSID4+ CmVuZG9iagoyNyAwIG9iago8PCAvTGVuZ3RoIDI4IDAgUiAvTGVuZ3RoMSAxNTgwNCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGlewl8VNXZ9znnbnNnn8lktiwzk0kmIZOQkEwIgUhu IIlgRMJqBk0JSxDcSATEHVyR4BL3jZZoXSjYMpkAJiw1al26WKm2Vn1r5W2xqJVP2iJaJTPf/9wJ qG1/7/f7vm/Cuc/Z/md5znOe85znXtZesa6LmMlGIhBt2WVLuon+Cw6B/GzZlWuDmXRWGSHKohXd F12WSftvJ0T6/UWXXr0ikw49S0jOgyu7lizPpMkp0IkrkZFJ0xho4crL1l6VSQc7QdsvXb1srDx0 HdLjL1ty1Vj/5A9IBy9fclkXKH5n3Y9HSffqNWv1JDmrCbSt+4qusfq0nRDHm5my008rIRRxN/k7 qSd3E5kwYicVZAFmUs9eJBLSvFyyXfiTWZteXmyr/9zgM+jgJ/5cn8cjLz+2dMFXX50atRNDIeqq en1eAJwyNXUemW4nX3311TX2TE+85PTPPTB/Y6NFeJbsQkDHeAYR+hHAaOHZQcVSpQ2BOl06Tbqj VcPpEeHZ5ORqPb/8/qqNB4SdZDGpRvbO5AKevXNQa+LVdw5WT8nQigk6TRoyxYqrKtDoB6wCgRHb WGw26N0I2xCeR5AxoJ3kA4Q0giBsF55ItgTQ8FNoyNboEp7CFDU830BIIwgY/VOYy1Pks7EcEaP6 4aBq5t3/UEflCD8EyoanHWEjwi6ENxAkshrPbQhpBAGxJ1D2BGHCE8LjSXvA3mgUfkA2IDDhUWKj lATQ+sODdp03jwzasqq0RrvwAGlDYCQhzCIjCAzN3gPYPYShemuyfILOwtZBo7XKjvpbMOgtGMgW dNmPJ9XTGmK8/pbBLDcf/M1Jm0PHXZusjGUig3ZvVRu4cBWhQpdwOQmTgHADaD7oMtA80KXCcmLR x6kN2uxVG9FfA6o3CNlkHIobBTepAm0S/CRHr7Yuac30sy5ZUlqFGU8XvHoVm2AhMVQ1CEqyKhDc L2g6828fVE18fLcn7dlVB4VbBYW4UGsjankCtoOCEWts1Gcyf1C1VPU1moX5mOZ8sCWAMVJwmT81 4fIkGmp0CM1CLjZDQLhEyCPZoC1Cvk6fER4nLUh/fzCSGxjZL9yno+7ljaL7qRnRmjposVaNNKrC VJQmhLuwAHfpnfcNRiZVkcaIUEIqERh4vAGxDYjZhV7EerFqvVipXqxULwbVC+kjwmaUbEadCuEa 0i2sJ30I2xDnYpWdBEP5ZshOFpZUDQs+wQvG2PeDlRS5/kHVykfmTTqz9GreQbO1quGgsIbMRmCY 8tpBj7dq9X6hVJ9K2aA3hwO6kxDXg4InszRoyc2X5KCQC0ZwxuQJ+cnsQKIxgDQX5ACh7BfsEGcS e4v9ji83ewNpTn85Rl8fo7/O0PQIO5TZFOxNTg835rIP0dhi9j7Zhhhj+9lLpBINvMeG+Oqzd9kw aQB9B+nloMOg1aD7kqHXAkNsaBAEY38saXHzybKXktGKsUigaCziyRmLON1VjUXsRfYCyUUTvwct BH2BjZAC0OdBvaAjbC15DXQPqyFTQHeP0Z+xA1zE2XNsL5kEOpi08iEkkgonu5IyJz9JkkyqrSJw gP2E7SR+VP1xMuJH4fbBSGHAth/tUfYUW5vMCzgbjexx2k5PoFI/eYdT4mRPJGt5I33JA8HAMOtj fZq3VivSyrWnhcqiyvLKp4VgUbA8WBt8OthoZ3dBgWxj2L9sC561JMggPQgaQh/bnBRrE42jmBOf FyMb8ezXY514dusxgqddj/HS43qsgd1KZiMwtHEDwgaEjQg3EhHPaxCuRbgO4Xo9Zy1i6xDWQ5t0 A9ENRDcQ3TqiG4huILqB6NYRvOduILp1RCcQnUB0AtGpIzqB6ASiE4hOHcHH2wlEp45oA6INiDYg 2nREGxBtQLQB0aYj2oBoA6JNR2hAaEBoQGg6QgNCA0IDQtMRGhAaEJqOqASiEohKICp1RCUQlUBU AlGpIyqBqASiUkcEgQgCEQQiqCOCQASBCAIR1BFBIIJABHWEHQg7EHYg7DrCDoQdCDsQdh1hB8IO hF1HHAbiMBCHgTisIw4DcRiIw0Ac1hGHgTgMxGG2fkA41PgyIIcAOQTIIR1yCJBDgBwC5JAOOQTI IUAOjU2dM4ILzAiwI8COADuiY0eAHQF2BNgRHTuCmiPAjujYBBAJIBJAJHREAogEEAkgEjoiAUQC iISO6AeiH4h+IPp1RD8Q/UD0A9GvI/qB6AeiX0f0AdEHRB8QfTqiD4g+IPqA6NMRfUD0AdGnI/6v l4bdSNsNOGvZRjpOpxvIpzq9gbyj0+vJgE6vI0/r9Fpyk06vIbU6XU8iOsVS63QtCRhoMlBra3RD BcxGWIywGmEbwi6E5xEUPfYGYh8gpFmNViDalNnKNmWX8rwi7VIOK8wmz5a3ybvk52Vpl3xYZsHG HGbR9ShUC7kbOEo24PkZAg4RPBv0WAOLod8Y9GwN/mIspjmOBT8rpW+U0udL6a5SencpbVTZ2VTU NV2Q1DIwgLZr5sjUwDsItZHiqdBMd+391BNIRiYGhuiBDBmnRZH8FGEA4WmEmxBqEaoQyhGKEAII tZFSwNq1grEmD4AWI4QQggi1xO2Gmeh0GLRhZqFPD75sISrvp7gEuP3J4kqQoWTxbJDnksVLA40q 3UuKuVVE92BT7QTdlQwcQfGPM+TZZGA/UtuTgRhIR7J4PMgFyeLXA40WuoAERA6dP0bnYcF5em4y sBDV5iQD40CiyeIIr12KjopQOg4W9RFQxHV0YaancDIwBbULkoE6XttAivnCU5mU68OTEOdpYRAD +myYtotUMwWOBe4LfIrx/hWMhXi8GxwSQd4oGqILNWPgQPkPULkxkGw08vo4HwbGaILTPYGnizYH HkNbtGhv4JHA+MBd5UMGZN+JcW/Wu0gGbgoOsZ1aVmBjoDKwtvxIYE3gnMCSwNxARxHyk4ELAwf4 MEmctrOdewNtaHAmZlGUDJxdhLFgiC2BqwNaoDhQFzzA+Usm8a4hyeUHOAdIVab3MvC3tAi9JwML aoeoQytVjit9ygXKNGWKElYKlHwlT3EZnAa7wWowG4wGg0E2iAZmIAbXUPqwFuX3BJesXxdkkSdE PW5nPI4HnoRRAyPnkESW0Mpa502jrYmRZaR1aTBxcl54iBrnLEpI4Wk04WwlrfOnJSZFW4eU9NxE bbQ1obRd0D5A6V1x5CbY7UOUzG8fommedWtOwjkdheTWO3OGCaW+W++Mx4nXfWWDt8E51VHX0vQf Hp16ZmdT9Juf99vRvMSDrfPaEzvy4okqHknnxVsTN84LXtg+zGzM0tw0zKycxNuHxW5ma57L88Xu pjiqHdGrQZqtqEaKOUE1wzQS5NWgT6bxalijTL0I4KgX4gT1jBYS0etFjBa9nkh5vYF3gs1NA0E8 UKeIkHf0Ou8UkW/VgcQA2zQQwQO1wkHazmvR9nBQH9g4vaFAAFXK8UAVCntPbyhA9c4SFd9UKRqr UnOmSo3el5AZj94Mf6AZV8npOq4S1PmGkf9vsa5pUTo4Yd0NLzV3hZs7w81dCJ2JLVeu9CY2Lg0G B25YxwuCCSHSuXTZSk6XdCXWhbuaEjeEm4IDE3TcvxS/xIsnhJsGyEvN89sHXtK6mpITtAnN4SVN 8cGG+vbG7/S1+Uxf7fX/oa963lg776tBx/1LX428uIH31cj7auR9NWgNel/Nq7jct7UPGMi0+HSs K6eDzGSEDHfmhOLT3PbuqVygh6eEvDfk7BMJ3U5M0XjCHJ6WsCDwovLG8kZehH3Gi6zIto0VeW+Y EsrZR7ePFdmR7QhPI6cXgnB8a6JmTmsiNG9ROxeVhAYW/Kc1W8N/erGXNK9qwj+k1+ph7Zq1p1vk lPCa//5b+59+69atW7MWj3XRNYS0JkrntSYmzsFIFAVddTbFkTf+dJ4g6HkDqto8lB5BYRSDoGt5 dzwWpVFwUDMSmSisX+5XGL9FrB3051WtPgi7YQMCrsNsfRKuBF60frCgCLclVKmoyVBcV3k66Q9V oYfBWkA5LcpQzVGOSF9RX3lfbX9Rf3l/rYzSvU8jM/A0P0qTFU8LZG10zWlmILo2DmZjWLy/x5O5 eXrH/TwSjcaja6jOr9P1v6F6PpLfMBZz1H9r9OY5v3UO48mjYDovxXpkel/HU/yXiehY8FkHIRe1 Mik9iz+++SEFV9E+kquHZ0iuGMEdi6SPnA6pVekjvIxT9gk0OTxIPIz9kuRZ8ntaQoNkkH5FPORL 6qMTyExI5xe4T+wio+QBXO/nkwepkxTiNrqAzKQi6kTJHfSx9JXpj8lZ5F7yRPo5elN6B8rvJq+Q LzGCP+LErCXnof4C0kU+Fj4k8fSjxEA2EROZQuZSN1lC3sbf5xjHfeR+8lN6XfpL9OoiN6G9etJI GtMvpE+RUnKH2Ce9o+4h95D9VE4vS6+ChVRAelk0/Xb6AxIhcfJD8izGFKUj4gwSIpeQW8nD1Ce8 gtgD5EmSombWIUyXnkdPM8lCcjlZT3rJDvIL6qRt0jvS8fS16aOQwixSgjGtIh/TGjqLPSWa01PT 75ELyDB5DfPlfyPiBeIz0gWphvT30y/i9v0cNdID9AWpSrpr9Mb04+mfwF8ZIRPAkfPQz1JyM3mB /Jz8jfydbUhvIDPIPPT8Ms2jQRoBx99mPnYDu0F4i4zHbDsw2nVkG0mQJNlH9pOD4M1/kcPkQ+qi OfQcupTeQ//OzGw5e0N4TNgt/Fak4o/A7zApAo/WkqfIXvIr8jp5g0pov5K20YvpavoQ/T49zBLs U/aFaBBvFr8WR6VI6nDq6/R56c9x5/aTc8k1ZAN4+0MySHaTX5PfwSv5D3KS2ukkupI+ThP0MP2U qayAzWbd7EHcnn8snCfcI7wg1ojTxEvE18X3pNukLcoSJXXq6dR9qR+nfpN+Lv0byI4V7UfgwFlF boRUPEWeJ2+h9XfJ++RPXH7Q/hS6iH4Pvayht9P76Y/py/Q39BPMEhYH/grYFNaEXlezK8Cnm9h9 7H70/gb3dMBJ8T77K/tckIQCYaLQIzwuJIQh4ZDwF9EuRsTx4gRxtrhITGNlqqSzpXnSdmmn9KJ0 XK6Xl8vd8kfKTcothl+Nlo7+MUVSK1OJ1CBk1wBJugac+AGBExC82E9+AY7+GiM+TE5gFfw0RIsx 7jraQlvpLHo+vZB20ZvoJnovfZg+Rp+gP8EMMAemYOxR1sjmsSWsi93CNrE74cvYzfaxn7O34VA5 hpF7hLAQFSYIM4VFwgXC5ZjDWrjybgFn7xF2CG8IbwlHhY+EY1g1j5gvrhOvER8RnxF3i7+RzpUu w98T0vPSiPQb6ZR0SmayX86VK+SL5e3ynxRZmai0KZuV3yr/MHTTXFqKkQch+2d+zIc9mM92MJe4 gR5Ddh5uHTbMPIp1mIdd8Q/SIKSwLlZejrFlM5+YxeGyJiZgCK6l+0kNfZlskJkAw1A8TJL0D+yw +BI7i/yOdlKf+IxwufQLFiI7oY362AG2n04ju1k9W8i2CoR+iFPxQ8j7VeR+egldQ3bSY3QyvZ7W 0g3kt8wtzKO3kPr0E0ykKp1JjxOMgNwoLiffOzOF/xihdfDOf5z6gWgRr4N+GiIPYkWfJR/QH5Gv qJT+FNpNgDZaAi1zB+T9VsK1Xgf22QbsRx80yKXyG2Q3leFDr5WniteQ4+Sf5GNpHyRqGrTp0dQq 8Qfin9O16XLsMOwysh37biU5GzvmQ0jJQaR56kLsdCN0CZyPpI0sgvPsemi9e9KJ9Nb0zemr06vJ L4H9ipbRr2g/dsQQEPXwe72GXfIu3YJ9ePZ/nN7/MTO1nIyQT6iXFtEq7Idj0pVSn7RD2i39VHpd ngBu30Ieg0T/CdJsxAyWkd+QT8gX1IC18ZEyEsN4J2Hs7eRSFhcOkunUT7qxZ0ugx6eNzWQNWrkJ 3NuK/XwQe+M49MSF5KfwnzHqwYyWoX8D2mkFnxeTNeRprODNdBA5y6G1S8lfMW8rnQT3QBnR0NKD 0FojGNMfyF/A7bQ+rjLohSa6EG19Qc4ny9HDRNJGB7ACe0kdNGuT8Cvwu5DayTRaQJ8ErhM71Arn d530Z8pIWeq89CS2SjiIMyaN/H6cXjnkLNqDUdgwj1GSTWeTmtRcjOEtKogJ+qY+ikdYV3qTsD51 Kfkl+RHWRBOvVJoI0Rrnaw1Tz6qfMrluUm1NrLpqQmXF+PKyaOm4kuJIUWG4IBQM5Ofl5vh9Xo87 25XldNhtVovZZFQNiiyJAqOkrDnc0hlMRDoTYiQ8Y0Y5T4eXIGPJtzI6E0FktXy3TiLIcUtQ9J2a Gmqu+JeaWqamdqYmtQfrSX15WbA5HEy83hQODtFFc3CbSNzZFI4HE8f0+Cw93qfHLYiHQgAEm70r m4IJ2hlsTrRcubK3ubOpvIwOmIzTw9O7jOVlZMBoQtSEWMIT7h6gnqlUjzBP8+QBRgwWTDHhDzc1 J3xhQNGMUNS8ZHmibU57c1NOKBQvL0vQ6cvCSxOEW79RvQqZrneTkKcnFL2b4CpYtwmyJThQNtJ7 x5CdLO2MmpeHly+5sD0hLEEbzQlHFP02JTzXHPF+k0TjsJM3fbs0R+ht9q4K8sq9vZuCiZE57d/C 5oR4C/E42gCWFbV09rag6zuwUq38SpVgt8bbE/RWdInLQpE+q8z8MjeZos6Lgwk1PC28svfiTiyN vzdB5l4dSvr92nD6MPE3B3vnt4dDiYaccHxJU+6Ai/TOvXrQpwV93y0pLxuwOzKMHbDaxiJmy7cj XWB6pkyP6dV5rHXuGc5SPsbwTNjjieCyIEbSHsacJvFH1yTSu2wSFgC/OAUqsRwrsiqhTu/stU/m +ZgiTUhF9nCw93MCCQgf+/S7OUvGcuQi++eEF3I5OSNqCbrkdDwRjSZKS7mIKNOxphjjVD1dU152 5RCbGO62wzcyERdB0gbeLolPrgD7QyG+wFuGNLIUicTGOe2ZdJAszUkSrQL3JdbJS7CAmZLsBbxk 4+mSM/DOMCR5N/dbkOyEIXLmn83uzmpeOTlB3f9DcVemvHVeuBW3m2Bzb+eY1LbO/04qU84ZCr6h bCyWyJreLuQw5PEYyxH0UgjlhYvOVEGi3ZwQi/BP5oPG7hAglHoGDbYk7J0zMs+4MRQa2zL/jhlS DN8CDaWPc5ROvoGNzSIxOTo2zsyoE1O+k/7O6My9Qut8aBzWOn9Rb6/xO2Ut0GW9vS3hYEtvZ++S ofTGpeGgPdw7zJ5hz/R2N0MLZRZ0KL1vS06i5Y44prKSTobYMjJtIExvnzOg0dtxfR2Giyl4+/z2 JKNseue0+EAhytqHg1C5ei47k8vrBHmKtFIIepIZ9KKcYY2QjXpdUc/Q08vgXtLzMpWQR8myIZbJ s+v14vF4OQx+eLbqcHd6ldwv15Gl8g5yj3InUcQ1ZCbCAvHPZD5oI9tBvDyOuvchvVmnfyb3IG8u wha8tNyE/ErUCyB9JyFomIsdwW1AxslCSBC3gUyOnv3/9eDOOLym/FYbcBb820/6txwYb8hTYOWq sE5MiJsRLDgfCU5FO3GAOnEHcuFew38T8beTnseuEh4R+6Wp0l75gFJvKDVcqzrUs9UDxpgxaSo0 v2o53/JL1MYhB07iDyNTyLTdjKZkZYg1aFlEElMCMSpiihKfQZZSTDhAI0TFxcJLvFH7yfrR+vPs J+pnjdaTBsTtp/CYUBlyhBxFeMATSU4FhZFTmkS+JkFxBH3htkikJbjT2uEB3aBVl0glxrM9XWKX WSr11HlmuOPulW6pzjMxZ1POI9KDJingKMJaZzmLbHaDr3iXQhXuJlBNMQzxDi1rY4gGQ5UhFnI4 gyRor7Qz+xDbMhicMM8bxdA6+Nhm2Tt6TkZ7Zh3TB8kHOqGSdPTQjqxQlcftdma7YHfjLxyijuqq 2qmsJhaJFEfC97O85zpvHOosr10x6+alT46+RUvev652xuL6+kvnTd0j7cuNvJg6+us9N/cvay0N iC+eqrE6F768Y8feFU79K5Gl6aPSQektSNA7Wsuk/Nb8hcqVhivNtxpuMd/quSVHlT1yjtPjzClx lHhL/CX5hhmmC8T56iLTxeK14jXetf691r32Vy2v2H9vP2q3CrlykGDqWsBfh3fIpIhR6s4tl1Wn ZnXGnK2zs2iWlu2NZQ3REq3UXW6DrU6DvsXILnYuZIFgUGD+YEFlASvwFfcbqc0YMFYaBSO4OBi6 YVuGW+DRefaOk5xp9hPHehzOugqs7OiJaMeRaMMxB1KjPdF6ZHMG0o4OWhNyyGK4oBAsc9ZOrA6K HikSCRfI2XZnddXE2hqhgd3Qkdq25y+pHc+ODN/5JnXQ6rLUe4GdG1/88KMDHfuns5wvRocWbX6B XvTWh3T54pkf/qL20utP/j31derrmbF9mOc9EH4f5MXMvJrJJEQMEZMgClSA8tLU3MkxY3DylJgK R/jgGNWezB2PXDxk1WD8s/qpURRVozGL5Yp2NWAMszIxqFYYL2IrxS71YuN6dpX4pLrDuEfdZzyp fmV0bxP71G3GV9SfG3/P3hHfVt81HmUfiR+qnxgt69WrjDezO8Sb1TuMfUxpN3Wxi8WL1JXGK9nV otLEWsUmtdV4vuF8td2oeI0V1hibLMbUKcYGqyIwsyirqjGb+UWPqgzIbPr8di3ARMGoSmZFqZKt 5ipsQbvADG0GS8zEH/osrSZLzKBZi2Mm/kDWVs3OIyaDgB1GmWKEYmior2/AwnjqMt6lDlpxzP7b YzwjZyg9RStHL0HRoKpVgugSBBFuT2OVwBBlaEYwi4yZjUZVVQwBK7UOUcsgt3/3sUlEwm67oCMm cdHzzJsfk6oUTdlgoIaDG7AKB01Bk5kNsUmaE1pEQ0WioRKpCpipmTdjmbAOiuJEz7Fo1F7/v+z1 fp99tGe0p97vtY9Go8iwH+nB4EExfox2kzQ+uun6n20a7+UkGp9QiXcVWfPgvTekDw+YgpMmxSF3 /NdzBZ8qifZ0VEPVUK50cMl33EP34yai0AOpY6n3U39O/VHad8orfPRVi3jT1zfwAJlSoEy3cJmi ac0ZFaJy0FRtEolMTZp/cgyexo2DoJz5p2nSVwMZO6qp/ryY0YeH+XSK8BS4c1iLu/NiYhAPBcss m/0kWx1HilTlY+NR8xfqP41fmKVXpZ8bXzW/R34LqXrb/An5UFV3ij+UdhqfMu8XB6X9xj3m10R1 vFggVRiD5sfE+6THjA+YDRlh2W2gVgt3gw5aQ3xwI5qKCIQixIe8dTAjL1u1bC49y3nKJEMJKBAR VZcQyMg3EkKxi+tydr9oEqXgULpyUIaADKWrtAsFYg4SgbEg3irhvZtRlqQqk9FlwqVIVpSgQXUZ DKpoMpvHRAmdCGYcIqJZkIwmRcXbKUWRJBEiRTNCRQxWj8dfAZkZopWaMSgfNB3UKvgeRtIc5B4v Rn2W7y3LKCG/b9Zoh987Our3jXZ4z2vuavrLGQnhcsL/9NFjAo66OjyJgwvOrG9LzpgAnZYjeIAh SbrYZDaI7sPt6QjRUBakJguUUtqVeoJWvE/NMIrpf9PS1NbUK6k/pN6HBDmEz07hNIMUzfh6CKfY zPRH8FRNhQevivZoKxW/IVfKc/vPyZmRO7Pov+wfONSJvhbf+ZEVvosit0Xu9d3nf9o/nPOq/7Uc syxbst2yz10sj8uO+9az29jT8h75Fdn8fOxdO8srrJrgKLMUatHxsUKtoAQPX15sdeGpQlbYkscX vdJqi52VR0mePS+R9888MS+vjFYTDbk2HKmMLAhpuY6GkJZjx8Prj4XgZd8jKmaLsYzLDsp0imKd okYZamiay5Q/IWIYp5ZY4gHzNjPDDk5jE2tWd8zsnx2jsU7snLsqwabqcaHFHvqBh872LPas9gge X/WqxrED5IpZx7DZO/gpEsUWReoINw6w/aMN9Q3Y8tETHdEjOFc6eqIZsU5W5NGe+LFMYpgUpkee y8mLzS9cXsg6ovEOICCpgtVeX49jm/Z08JO7eOLE6iq3O1twuT0hHNXFshwuiNTEJk6sxaET4ycQ lXGiZ7vcONCRWUO70tE33zgw1CrkFKU+MdkVYcaTHU8eXPjYvS+f27a6dT793sRPCmvbm85trrab 2J/GP3p/fPNzqaE7bj03t9ZnaGlJ3r7oztbcomDunOYpqTedVd7i+ikLqyK1hV3gygJIQwOkwUf+ W5vTbos7YcTYVjlXua/3Xu17iD1kfsX+ivf39re9H8sfGz7O+jj7SzlrUtak7HOc57hbvHHzKrMy 2VnrrvUK66X1tk3SbbbNvu3OZ9zDzr1u1cpXzZsT43SP0xWzVlt4ji8/plObI2bZBx+gEWvodJiI hqpEQz1S3Ye12octLKIo6FEoz6UhUmHhEUtoNjS9P0cJuXz+9szy8dP/ZMesY9ETx6L82MepH+Wn fxQ0YzL1dNCxA55zdmKtxBlPHHaC5RAnpP5qXTZ71fUbLmlbkU1d0ROvf5z6K3Ufe/FD9mnVvPn3 7Di49YLVFT99ER47ERq66BluD84H77g9aMN7hz6t3BmX48a4c6F7oTee+7DyiPqlqnbnb8xnk4WY eXJ2zHeO0GQ+J7vJ94iquvj7I8nk5+JrNSlWG5bC6BlntUToEB2n2WzEf3c+zbeHDL689npdQPkM e2DfHBut50oFf8cajunGTE/H9HbNskpeZVzlXOFe4V2VK3fAo1IzNkGYMx4cMy4Pn3ZGwsQlqa8b BxY9B1vlxeRN1DfqrGi6Zsntt1y0fNPWC+JwN0NfU9/9zH6qe8e5lz/15HOPb8N8GzHfYsiKi+TS Hw4Te/pLrcVU94j6qOVB+3bpGeN+db9lyG8wuOgMdrbcYpydv92yV97rf9X4mvlt4zvmL5UvLJZc W262hl2SrVkdMVv289lvZAvZXCps+Q06tXpA2Z2a2WZ1tlk7rczqdVJU2OvLidFqJzckB/OCMZ0W jMvQaHmGenN1qtmgUvrBUpjqjCx2OsHmQdHk9HJ2F5oUEqIV2RkhqshfnL86f1u+mG8LGTSLLQaG j2mEaMaihFCdgPl9jL81dHm1EleDV8u34QE15OX6imvleMMof31HnBgcajj5IFFJp6jHafJ01RPQ H/ynAwgKnHV8MkkPJ4lB1ThVTzaGGvTXdfEjXIt06N1bNXDJyju18u6tGpilHwdxmLfRKMwKHC/V /LjoIR1RykU8WByp4TJOhJCbC0AWN3IV2cO+ot6JH+9K/fXWVdT11jHqlEc14aYl0xYVC1ctvLC+ ntK5FY8+vuee9yEL0dSrqYPXb5lBL71mw/TpeAVL8Y6FsL/ghuAmQ1rVRJGWikF70BEXN3olg/i8 l2W7HczldDusWbjlWbMoPmVzqQabiS42pU3MxBfCKFOHzU3TburmyXz+6cdxNC1nuYxqdYNhNoxJ wVBir3AsdjDHEBU1izUrwlyLSb97xM3c4Nle1Rxz+zxXDbNVuNTh0hTtqZ/Fb3KnOupPdPiOEC+2 SUdP/ShCAx51VTb8xnRxVjXXutgcCle62dnV2WEYYmHv1rpH1l21JjJ96lk1b76ZOrpVjLTddsu8 wp/Z6+a0vn/qOWGmvvdTc8RO/RStoOdpS9fnbcpjTrOle8Jtlo0TxCANs7BQSatZtaDR6Wy6cIEt 7ooXLRy3MBqvuMT2pePLLOcUS7V7Skl1Waulyd1a0lR23DzqMd6Fc8tktphKzZZiq9uTXW4xe9yi t5DvgD36DtAF3+rQhWTQZM7QktLMBggXZeiEWGYjqNk5+uG3WAKLkwFbMSdWYzlnuClb8frk0nGm iN/LlY7q8/n9d0+gE6CChvCCvLow5PRVntE+J8b0j/2YffQIV0BQP9CwuikbHTsQh+Eth43n0DvH 18Ux7IwjUVg8kG1utPGgGOz8Egt13NGj6y3bKteqoovGrYiuqoDeIh0eyc1VlX721UBHjwmwBxc2 l5WFgzgss3QVntFlV9NGQ17Jwstri7IsN4y8ff1SSp9/eSNVpnbvvzv19z+durnzortuX9l1c0vx pOz8kHtC+HuPPbvn7t9RE/X/+IFTZx/Yd3H98F1WdvOPvv/4D57q/z4Uxn0QxGeh17lPYf0wUWG5 NDiMDZraprKNakIdUQ+pn6lSQO1UN6j9yJAEWYHDQYAW18ghvBUQSAdcE7IkK6KRKTgzsHqaGiqM iT5DQ0adR8dcD1yTc/EUJJgJ+KcL5xXRLH4nQLiP+lJH8WZrLxVTp74+R4x8/R62yGa8/VqMEZrI P4aJkH5/0OJo0M3q633lMQUXsSy5WF0h7zI+b3xN/aXxPaNxntApMIviVVvk8w1XytJe9QPxmHhK /FyWzlPOM6yQrxfvEB8Tt0qPyo8qjxqMAdEpR8WoVCqXKqWGCkur2CoZYZeoeL9glIyqIIsmSZS5 A8ZkMii4jRtN4hC7TPNLFYa6AHwdXRZmitCNhPIrv8/ccO2YmcXn7bOf7PFCrXJ7GKKEJ2cDv0MZ rrf/zFB/2qIS0q8l1VCMnDaBe8gVsKpwaeL3JfxTHJvxBm0mXZR6gN6a+k3q85th8J6kV6auG/0e fX9z6ll0/c1qzhvmV0JtHF9LqU1iG6UE3mUekj6TpIDUKW2Q+pEhYUpwHDEhQvlO01eN+MR/W7Wx deJjwRpJ+75qQV+48YtxaAU32aZ5lSxP1iLDSoOIT+pihpi9ydBk+9guyXzv5TkUXIjMJhOOfUYj bqIFC2O78Dk/GsFuRL/ugsJYn7ffy7q9x73sMy/1Gk0RM+6345IWC65wI5oNkH4zPQ6N4fOMjQ83 S/iMsEPh3OLXzJN6hu7jyjD5tMUQCjngKYLek7Mxg1A29GA+yxbjqaOFc+pmro1C6KQtb3U8OjvA 8p/tmtR2SzIVECNbd09fecu1XP/NhS3wKGZqgeX4kDbjI3rU8EXWF9niq+wjiTl9kk9lcfvCrIXu uPch9rD8sOEh85D6O/Zf0h/U35mPSkfljyz2Zwy/ZL+SXzK8YpbWGTbLtxgEB1dPRpOHs8glKq46 xd+Z053DcqwhXFa/Zer1nOQusYwBdFqTqKvsK2D/rPKKtANqBD6ymBPTItkuAjdPpOhbOmNu7+jW v9FY6uef3pv6opcGH7z88gceuPzyB1nBHVTuTb362d9SL92S3v6D7dv7t27fzue7JXWp+BDma4et 96g2flLWjCzmjAl1lrqsWE6TMNMyM6sp55856kJ54Rkb8KTyzxx8ZylzKy8pKdzm09wmE97TeUIG fzfsO8c4q9UWsdt1o8/UTTaiJ19eQ8akhUerHgtpP8LtPt0DqKtcriFwk6Bcd66QV3zb5iNwC2bz I42btbhVFHOzD6p0zOrbQuXqn1w8TFnq1HD73bOxxO67Viy96bZlF92OpW1bnvpjajR1MvVuy4LR j4XhwZ3fH3zmiW0QyE2ECLX63LdrJQ9JVLXSedIKaZ0kVDjbrSut3U7RqNrMATO725w2swbzbDMz D7H12jhFgXwLTDaWENWuVqrdqqj6Nzi3Odli5wbnLuchp+i0kwi/To/TTAwfXvfz+7SjYZjmZg50 nOdnxPlkh29W5kjH4QPprsM7Uc6KHnz+5cHnXzX8kzBj1SQsPsQ7w4nM4S47aD+X6OmXNHXGzz/7 rClzK8TIQ5c01Xw+vnFH6m+YYyXk2Y45lrIXtRHZIYcNxR6HJ/yw82HXQ8UPlKqKq8XFnPstw9ZX Qx+Gv7ScLJDHWRZYuiwPmB5yPlMwbFYaw1phU+SiguWRTc5NrtsKbi5UayPNcovpHMtsW0toWoFS UFgcqTXXhGoKasI1hYpslBxqyGspNhcUFISVwgKtbI35KtfV2VeOW1d6e/YtpY9mP1C6u2B32LKR 3u25w/tI6Y9KE2WyJ+TWQuGYW8vF17du+gHMp2pDqK3o7iJWpHnzYkV+fjnWPNBybWW0soxWlNGy /FClndqraUi3Hmxqg05RJaPjVEuM+KJXDXEVfQqmqX4THtMg3Pt8gnusjpGMWtZqZEpl6qaRgomh ltB8Gvcsp6s8J+G78jDRHypgJVkWMyvxL8a3Qi0lpjY/9bdkKbC/8I+bAqdDR0/OMClI/3IQ1kto KEMLuDs0v5CnDw8GCmN62sddAXBT5SByiYVOLGgpeNhyf8HPCn5bIIcKzBZR9PN5cPuIVHNLadBT 3gCqG9N6uqAoxqmW58cNAU4bDR8qiZ10Iz1O4WeyI9WJix1HZrlRk1JtFvyTi8XjIuNTcGto2l3t 0dCuR4OF7tFqamMe7unwaEXj8EC7Nk9AdyqIngV+Ddrb5qdt/rSfjU2+h7sP9B8c0jjx4ZnmXOU3 VM6QsUuBftLBU9CDXwc3+rlb4eeaanI22ErwCA2lP91rqTO7zHU8mjTXgUOfDJjq9GsAPgiMw7LK KuKmPlwHMfgXIHSwc3HJzfi3uWcBFiX/ZgC2VaSS+p2XL7ustsiVPTP17AU3vPfhe78tSX3hWNy+ ujKYG6EvxNtPfPbuKK2Izl1QklsRzHY5WqcufKT3wF1bJkydFnCH87NzV5zTetu9byawiwLpj9g9 0vdxJryujQsSmMHGcbbJ1nOscZviyyZewZ1NPM4sF/U4mYt6BVUxKmYYn1SzEU+/J+EROkFG4JeB uZ/ERRwqc5Bk83c6uCebTXB+VxBSQRdDS/ALQYlXiHicC7IbXNtcu1xCp2ujq891yHXcJRGX3RV0 VbpEuAiu6h8zPa5oTdRCT0yBnhgmrvTIpHjmtoB3LfYT+m3hmP4uCDe0IzBVHdVjt4UOiquBS+ep hzMNbpsaR7imuqbIwa4ZMRXnFp/jXXrdudfUmdQbb6R+MXI4Nf+maG7Oe6XVc5onPEDfOPzWk6nN 4M+d0DLz8G2Sm2zVPOc7LnI8KAmq7JPrWb0DX7c7jjLFxqfqEE1uYsx24SKE21AkO5twBWl161ZC 5sr0P1gJqoGLum4eGOhx+C6/ax582zbIHDFnTLCMddCRcR1EMEmY3PqtcSKPCudNPrjqkh3nUl9g bsOMK0qpb9uCpd/b8SDrT3kPd02Zve4IHYF5yt/L8QfuAsXk95nYvzz5//cQSDG+zKkkk0kTvtY7 G18AzcRn/ufiS5vZZA6Zi68WF+D95fn4Loj/KHEi8B//YpLMmjt9Xnx6tPGKVUsuLZ+2+tLls+aj 6H8DOrO2dQplbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjExMzI2CmVuZG9iagoyMSAwIG9iago8 PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9XRlhKRVorQ2FsaWJy aSAvRm9udERlc2NyaXB0b3IKMjkgMCBSIC9Ub1VuaWNvZGUgMzAgMCBSIC9GaXJzdENoYXIgMzMg L0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAyMjYgXSA+PgplbmRvYmoKMzAgMCBvYmoKPDwgL0xlbmd0 aCAzMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDPasQgEMbvPsUct4dF k1shCGXLQg79Q9M+gNFJVmhUJuaQt+9owxZ68AO/md/4OfLSP/fBZ5DvFO2AGSYfHOEaN7III84+ iKYF520+btWzi0lCMjzsa8alD1OErhMA8oORNdMOpycXR3wo3hs5JB9mOH1dhuoMW0rfuGDIoITW 4HDicS8mvZoFQVb03Duu+7yfmfrr+NwTAidiovmNZKPDNRmLZMKMolNKd9erFhjcv9IBjJO9GRJd 22huVo/A4lhaxWJUJY+eMqP89Z7NbkQcqy6kJi5JfMD7zlJM5eV6fgDV7nFlCmVuZHN0cmVhbQpl bmRvYmoKMzEgMCBvYmoKMjMzCmVuZG9iagoyOSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0 b3IgL0ZvbnROYW1lIC9XRlhKRVorQ2FsaWJyaSAvRmxhZ3MgNCAvRm9udEJCb3ggWy01MDMgLTMw NyAxMjQwIDk2NF0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5NTIgL0Rlc2NlbnQgLTI2OSAvQ2Fw SGVpZ2h0IDYzMiAvU3RlbVYgMCAvWEhlaWdodAo0NjQgL0F2Z1dpZHRoIDUyMSAvTWF4V2lkdGgg MTMyOCAvRm9udEZpbGUyIDMyIDAgUiA+PgplbmRvYmoKMzIgMCBvYmoKPDwgL0xlbmd0aCAzMyAw IFIgL0xlbmd0aDEgMTM2MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Zt3QFNn 28afk7BDIEFANGKCEaoFRIsDRyUCiSAOEKIJKBKWoKLIcKO4qsXa2trarXZpWzoOx1bRLtvaPWzt rq3V7mX3erXId51zc1v1e/t+f3z/9A38cv2e+xk55zlJwJQ21jdVCoNoEXoxuLzWVye0W+rdiN7l ixpt1I6vFsK/T1Xd7FpqX7xOiODes+ctraJ26stCSBnVlb4Kaos/kcOrUaC2NBTZv7q2cQm1U3ci g+YtKO/uTz2EdkCtb0n344sP0LbN99VWInEbZsKdra6+srtf8mA50/lt8xFt6Nm7MBwSGjrJJkzi aREodMgUgRXNW6Q1wg+9ar//9o7Nv79knhU+5lfRK0ib/cg3K3A+Qjy34e5Np091bgr+NnAvmsFY gW6YF7i9830hQnaePnVqZ/C32krdnVrolGC9rUO37qHgGGkCZC3LGpbVLC0sq1hWsjSzrGBZzrKM ZSnLEpbFLItYmlgaWRpYFrLUsSxgmc9SyzKPZS7LHJYalmqW2SxVLJUsFSzlLGUsPpZSllksJSwz WWawFLMUsXhZPCzTWaaxuFkKWQpYprLks+SxTGGZzDKJZSJLLssElhyWbJbxLC4WJ0sWSyZLBss4 FgdLOstYlktZxrCMZhnFMpIljWUEy3CWYSxDWVJZLmEZwjKYJYVlEEsySxJLIsvFLANZBrBcxJLA Es/Sn8XO0o8ljsXGYmXpyxLL0ofFwtKbpRdLDEtPlmiWKJZIlh4sESxmFhNLOEsYi5EllMXAEsIS zBLEEsgSwOLP4seiZ9GxSCyiW6QuljMsnSx/spxmOcXyL5Y/WH5n+Y3lV5ZfWH5m+YnlR5YfWL5n +Y7lJMu3LN+wfM3yFcuXLF+wfM7yGcunLJ+wfMxyguU4y0csx1g+ZPmA5SjL+yzvsbzL8g7L2yxv sbzJ8gbLEZbXWV5jOczyKssrLC+zvMTyIssLLM+zPMfyLMszLIdYnmZ5iuVJloMsT7A8zvIYy6Ms j7AcYNnP0sGyj2Uvy8MsD7HsYVFY2llklgdZHmC5n+U+ljaWe1nuYbmbZTfLLpa7WO5kuYPldpbb WHay7GDZznIryy0sN7PcxHIjyw0s17NsY7mO5VqWrSzXsFzNsoXlKpYrWTazXMGyiaWV5XKWjSwb WC5jWc+yjmUtyxqW1SwtLKtYVrI0s6xgWc6yjGUpyxKWxSyLWJpYGlkaWOpZFrLUsSxgmc9SyzKP ZS7LHJYalmqW2SxVLJUsFSzlLGUsPpZSllksJSwzWWawFLMUsXhZPCzTWaaxuFkKWQpYprLksUxh mcwykSWXZQJLDks2y3gWF4uTJYslc4/62zJ+a1b6jrXid2albxRiDbVWK31HodVCrVUUK5W+oSg2 U2sFxXKKZRRLldhxGLJEic1ELKZYRNFEfY3UaqCop+JCJTYDE+ooFlDMpyG1FPMo5ip9nBg5h6KG oppiNkWV0icLQyqpVUFRTlFG4aMopZhFUULzZlJrBkUxRRGFl8JDMZ1iGoWbopCigGIqRT5FHsUU iskUkygmUuRSTFAsOTiHHIpsxTIBrfEULsWSi5ZTsUxEZFFkUmRQ3zia56BIp3ljKS6lGEMjR1OM oukjKdIoRlAMpxhGiw2lSKVVLqEYQjGYFkuhGETzkimSKBIpLqYYSDGA4iJaOoEintbsT2Gn6EdL x1HYaJ6Voi9FLEUfCgtFb6X3ZGxWL4oYpfcUtHpSRFMxiiKSij0oIijM1GeiCKdiGIWRIpT6DBQh FMHUF0QRSBGg9MrDo/srvfIRfhR6KuqoJVEILaQuijPaEKmTWn9SnKY4RX3/otYfFL9T/EbxqxJT aO2QflFiChA/U+snih8pfqC+76n1HcVJim+p7xuKr6n4FcWXFF9QfE5DPqPWp9T6hFofU5ygOE59 H1Eco+KHFB9QHKV4n4a8R613Kd5Rek7Hqbyt9JyGeIviTSq+QXGE4nWK12jIYYpXqfgKxcsUL1G8 SENeoHieis9RPEvxDMUhiqdp5FPUepLiIMUT1Pc4xWNUfJTiEYoDFPspOmjkPmrtpXiY4iGKPUp0 Ok5aUaKLEe0UMsWDFA9Q3E9xH0Ubxb1KNN71pXtolbspdlPfLoq7KO6kuIPidorbKHZS7KDFttMq t1LcQn03U9xEcSPFDTThempto7iO4lrq20qrXENxNfVtobiK4kqKzRRX0MhN1GqluJxiI8UGisuU KB/Ofb0SVYZYR7FWiapCaw3FaiXKjVaLEoUfNtIqJWo4YiVFM01fQfOWUyxToiowZClNX0KxmGIR RRNFI0UDLV1P0xdS1ClR5VhlAS02n0bWUsyjmEsxh6KG5lVTzKYjq6LplRQVNLKcoozCR1FKMYui hE56Jh3ZDIpiOukiWtpLD+ShmE6HO40eyE2rFFIUUEylyFciHTixPCVS3dYpSqT6gp2sRK5FTFIi kxETaUguxQQlEr9ISDnUyqYYT0WXErkSfU4lcgMiS4lchchUIlsQGUqECzGOwkGRTjFWicDvBdKl 1BqjmL1ojaYYpZjV19FIijTFPB6tEYrZgxiumIsQw6hvKEWqYk5C8RIaOUQxqyc2WDGrb0gpFINo ejI9QhJFIi12McVAWmwAxUUUCRTxilndpf4UdlqzH60ZR4vZaBUrRV+aF0vRh8JC0Zuil2KaiTVj FFMJoqdimoWIpoiiiKToQRFBE8w0wUTFcIowCiNFKI000MgQKgZTBFEEUgTQSH8a6UdFPYWOQqIQ jq7wMqvKmfBya2d4hfVP+GlwCvwLtT9Q+x38Bn4Fv6D+M/gJfT+i/QP4HnwHTqL+LfgGfV+j/RX4 EnwBPg+bbf0srNr6KfgEfAxOoHYc+RE4Bj5E+wPkUfA+eA+8a5xrfcc4xPo28i3jPOubxgTrG+AI /HVjovU1cBi8iv5XUHvZWGt9Cf4i/AX488Y51ueMNdZnjdXWZ4yzrYcw92ms9xR4Eji6DuL+CfA4 eCx0ofXR0HrrI6EN1gOhjdb9oAPsQ30veBh9D6FvD2oKaAcyeNCw1PqAYZn1fsMK632GZmubYaX1 XnAPuBvsBrvAXYZk653IO8DtmHMbcqdhrnUHfDv8VnAL/GasdRPWuhFr3YDa9WAbuA5cC7aCazDv aqy3JWSy9aqQKdYrQ2ZbN4fcZb0iZLd1vT7euk6fZl0rpVnXuFvcq9ta3Kvcze6Vbc1uQ7NkaLY0 5zYvb25rPtrsiAgIWeFe5l7etsy91L3YvaRtsfuA7jJRpVvvGONe1Nbk9muKbGps0v/SJLU1SVlN 0uAmSSeaTE22Jn1oo7ve3dBW7xb1efUt9XK932i5/ni9TtRLIR1dB/fUW/q6kI4V9UaTa6F7gbuu bYF7flWtew4OsCZttru6bba7Kq3CXdlW4S5PK3P70krds9JmukvaZrpnpBW5i9uK3N40j3s6xk9L K3S72wrdBWn57qlt+e4paZPdk1GflJbrntiW656Qlu3Oact2j09zuZ04edHH1MfWR29SD2ByHxyJ sEgZgy0Oy3HLDxY/YZEtBy36iPDe1t66geG9pMwpvaQFvVb1uqqXPjzmcIzOETMwyRXe83DPj3p+ 39Ovh6PnwEEuEW2KtkXro9Rzi55UqJ7bnuj0LMohw7RznRRtT3CFR0nhUdYondMaJQnzcfMPZn3U E6bDJl14uBQe3hWuc4RjeHiYNUyn3nWF6R1hQ0a4wo1Wo0696zLqox1GVNSDvyg0r9AVbrAadO50 wxSDzmFIz3Q5DMmDXUIv2ST8lx8TQh+kHo0UZXV1SGJPtOQvdUhb2gsLEhNzO4LE1Fw5KK9YljbK 8QXqvSO/SA7YKAt3UbGnXZKu9LZLusxCOTI3v4ja6zdvFhmxuXJsgUfeGevNlVsgDlW6ICK2PVpk eBNLGpoaEhMbS3BX0tCYqH2jJTWpLdzQge+GRrTVLwTaQu35+xsNw7hZDbhpy9Dqfz/lv6BH+i84 xn/4IbYLPEU947p060SFbi1YA1aDFrAKrATNYAVYDpaBpWAJWAwWgSbQCBrAQlAHFoD5oBbMA3PB HFADqsFsUAUqQQUoB2XAB0rBLFACZoIZoBgUAS/wgOlgGnCDQlAApoJ8kAemgMlgEpgIcsEEkAOy wXjgAk6QBTJBBhgHHCAdjAWXgjFgNBgFRoI0MAIMB8PAUJAKLgFDwGCQAgaBZJAEEsHFYCAYAC4C CSAe9Ad20A/EARuwgr4gFvQBFtAb9AIxoCeIBlEgEvQAEcAMTCAchAEjCAUGEAKCQRAIBAHAH/iN 68K9HuiABISokFCTzoBO8Cc4DU6Bf4E/wO/gN/Ar+AX8DH4CP4IfwPfgO3ASfAu+AV+Dr8CX4Avw OfgMfAo+AR+DE+A4+AgcAx+CD8BR8D54D7wL3gFvg7fAm+ANcAS8Dl4Dh8Gr4BXwMngJvAheAM+D 58Cz4BlwCDwNngJPgoPgCfA4eAw8Ch4BB8B+0AH2gb3gYfAQ2AMU0A5k8CB4ANwP7gNt4F5wD7gb 7Aa7wF3gTnAHuB3cBnaCHWA7uBXcAm4GN4EbwQ3gerANXAeuBVvBNeBqsAVcBa4Em8EVYBNoBZeD jWADuAysFxXjWqR1sLVgDVgNWsAqsBI0gxVgOVgGloIlYDFYBJpAI2gA9WAhqAMLwHxQC+aBuWAO qAHVYDaoApWgApSDMuADpWAWKAEzwQxQDIqAF3jAdDANuEEhKABTQR6YAiaDiSAXTAA5IBuMBy7g BFkgU1T8w9+m/+mH5/2nH+A//PhiZpWofzEkxJmt5/6RkMgTc0SDaMHXZWKz2CqeEEdFmVgLu1Hs FLvEPUIWT4oXxDvnzfp/Ns4s9a8Vofp9IkD0EKLrVNfJM7tAh3/YOZWtaPXws/1V6TJ1fXdB7bsz W7tMZzoCIkSINteoO4LVfpY6u07h52uAMHYNV9u6DfBw7ZF+DNx+5sEzu887gTyRL4pEsZghZopS 4cP5V4hqUYOdmSvmiVoxX2vNR99seBVaszAK7yWa/zVqgagTC0S9aBRNYhG+6uAN3S21b6HWbhKL 8bVELBXLxHKxQjR33y/WKivQs0yrLkHPSrEKV2a1WKMZJ1XWinViPa7aBrFRXI4r9vety8+OahWb xBW4zleKq8Tf+ebzeraILeJqcQ2eD9eK68Q2cQOeFzeLWy6oXq/VbxLbxQ48Z9QZ16GyQ7Nt4nrx qHhWPCweEA+KvdpelmNvaUd4X6q0na7DHqzAOa8954hpNxef3a2V2A31vFu7z3sJ9m/NOTMWde+j untrMVLdndbu66Cu0txd4Z3YgjMj/+s81T1Sz+Gq886TZ/xfVfWM1X26BfvFO6Pu2TbUbvpf1XNH nOvbxK14Bd6Ge3VXVbsdTrZD83Pr28+O3an13SHuFHfhWuwWqnFSZRdqu8XdeG3fK9rEffj6y881 6n1A3K9dOVm0C0XsEQ/hSu4V+0SHVv9PfQ/ivePCOXu611LOrrJfHBCP4BnyuDiId5qn8MWVx1B7 ort6SBtF7afwt5SHtFFq71N4bj2Hd6gXxUviZXFYPIPWq9r982i9Jo6IN8Q7khH2uvgK953iNf9P RZgYhz+8PICrcYsoESWO8RWzSmbOKC7yetyFBVPz86ZMnjQxd0JO9niXMyszY5wjfeylY0aPGpk2 YviwlEHJSQMS4vvb+1ljIs2mcKMhJDgoMMDfT4/fbJOcdlepTU4olf0S7NnZyWrb7kPBd06hVLah 5Dp/jGxT5/nQdd5IB0ZWXTDSQSMdZ0dKJtsYMSY5yea02+RXsuy2Dqko3wPfnGX32uSTmk/S3C9B axjRiIvDDJszpjrLJkulNqfsWlTd6izNSk6S2g0hmfbMypDkJNEeYoAaYPIAe127NGCspIlugHNU u04EGdWHlfXxTl+FnJfvcWZZ4uK8Wk1kamvJAZlyoLaWrUbGMYtNtvakg61XdJhEWWliaIW9wjfD I+t9mNSqd7a2bpDNifJAe5Y8cNmnMdjASjnJnuWUE+04sNypZx9Akv3jTXZb668CB28/+S2O+pyK r7sSEG/6Vaid6ime3SZZ8rELHBuOEOcXF6cey6YOhyhDQ27J91DbJsosinCkJHplXanac5B7otxq Twv3nJ1easfOOu3O0u7vRdUxckuZLTkJV1b7jpf94tFvk/UJpWXl1Wr6KlvtWThD7KUoxIc2WRCH r3szne2DUzDeV4qTqFG3Id8jp9jr5Eh7Bu02Clgk3llT4NGmUNUpR2bKorS8e5ac4sRcPEWcreqF UQ9QXcue79kvUruOtw+1WfakiqHCqx6HHJ2Ji5LgbPVUVMnWUksFnp9VNo8lTnZ4sX1eu6fSq14l u0keeBwPhxsuoDYL53bBaB6M05YD44NsHp1F71WvFgo2F+7sGWPQYZIDqKle0YwxNo9kETwMj9I9 QrXz1kFDH5+ZjclITM3MtsThya3d/sMhWegEcBhy0Nlj8sNB+P91TPQ4f3toNFo9oIE2Z2XWOQd4 3qJoaAfYvdq/P06duhfdm4FDCFIvZ7Z6DslJOrgN3UGyDuepldSrGGOTRZ7NY6+0e+14DjnyPOrF Ufdau765BXb1g0Htanc/SwrPa1F/GvXJIi630MMN9TMb2ZWoXVf1smrt8Vr7bDP7gu4c7ra1Btlz C1rVB7d3LyhseAXh4gQk5Pg2pUUMxYvVhTdKu8tnt5lsrlZfR1dLWWu7w9Fa5yytHoWXQas9p6LV XuAZg2upve6bLcvUh44QuVJuYUZyEt57Mtrt0sb8doe0saDIsx9/oG/bWOhRdPhQtDTD294ffZ79 NiEcWlWnVtWiOsSmNtSVpqIRpI237HcI0aL1+mkFrV2Oz2W1Gg1CTRLlHTqqmXicDjU/qjm0mhc3 vMJiqnEJ8D7stFWol2eFt7q11Ku+uEQ0LiW+JVmyjxWyzj4WH+UGhMoh9soM2WDPUOvpaj2d6gFq PdCeIUvREjanA+9JraV2vE/hKefBR+RePDtM6rNfF2/r6Ooq9MS9YjnpjcNLYgYo8sjBifg54B8/ AePGq5SiPF5uKfepxyHceKmrr8ycci9eC7wghuTIwVghuHsFjHBpc9SnIyaV49rgAmrzW9CQW7yy N1F9UE+NekQ2m0kW2fZRuOy0pn+C+kAp3tYI+yXqExtD5ZD4DWoE49gEPqTWKhY08WB4w1XPKDAU R15uR1d5qQ1XwE+UF+CpTu+lIep1Q6USb4l+CZUaIZbuTqGelj7eYAyRgwdhQXyrbhiEBfEd6MWm qCevtTZ0D8Bjm2QDjijhnK3snoDdQVeOeiz43oCDV4c+qS6T3yGm2pfgrVE9aO2hAtEtG+NzfHjz p/kGVOxpPBlrBcWrJXWNQ1QNVM88FPuujy/s6NptX6q+A/AtOcmu/nBQn5jCsh9PbOFtvbAgFycm JwVdWDVq5dbWIOO/n0D7FWQ8m+oqNid+1gjhp/5vLIfxkAh8qbdQ/HsqFBl3tiLw++ltqPjjX5gN +iP415ge/7/LSDFJTBbFjwojPjaJFqOkhx+OysoKSg58HB+J6IQNH6oECUnKdIT76Yz7evdOt+8b FrBZb87pkJIfSg/cjI8L0zuPdb6a0nnsZMTIlJNSyocnjp0w/fiqeWRK6ok3TwwZLJnjzBqRYbrA wMgAe79BumEXJQxPTb1krG7Y0AR7vzCdVhs6fMRYfeolfXV6jKTKWJ3alvRH/izST+kM0K20p09L 9e/bOzzSGOCv6xMTkTwm3lRQHD9mUGygPjBA7x8UOGBERr/cec5+7weaY6OiYyOCgiJio6NizYGd R/3DTv3kH3Y602/e6Wv1AaNnpPfX3xASpPMLCOjoG9Pr4tFxOdPCe5j8DD1M5uigwAhz6ICsGZ2X RfVR1+gTFUVrdU5Stxe7GtG90wH4TVVMd3kmOIsSM33zasrqa/4HYwZ03QplbmRzdHJlYW0KZW5k b2JqCjMzIDAgb2JqCjU5MjIKZW5kb2JqCjM0IDAgb2JqCihyYWRleHQgY2hhcnRlci1taWxlc3Rv bmVzKQplbmRvYmoKMzUgMCBvYmoKKE1hYyBPUyBYIDEwLjcuMiBRdWFydHogUERGQ29udGV4dCkK ZW5kb2JqCjM2IDAgb2JqCihNYXVyaWNpbykKZW5kb2JqCjM3IDAgb2JqCigpCmVuZG9iagozOCAw IG9iagooV29yZCkKZW5kb2JqCjM5IDAgb2JqCihEOjIwMTIwMTIzMjE0OTU1WjAwJzAwJykKZW5k b2JqCjQwIDAgb2JqCigpCmVuZG9iago0MSAwIG9iagpbICgpIF0KZW5kb2JqCjEgMCBvYmoKPDwg L1RpdGxlIDM0IDAgUiAvQXV0aG9yIDM2IDAgUiAvU3ViamVjdCAzNyAwIFIgL1Byb2R1Y2VyIDM1 IDAgUiAvQ3JlYXRvcgozOCAwIFIgL0NyZWF0aW9uRGF0ZSAzOSAwIFIgL01vZERhdGUgMzkgMCBS IC9LZXl3b3JkcyA0MCAwIFIgL0FBUEw6S2V5d29yZHMKNDEgMCBSID4+CmVuZG9iagp4cmVmCjAg NDIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDYyNTE4IDAwMDAwIG4gCjAwMDAwMDY4NjcgMDAw MDAgbiAKMDAwMDAxODU0NCAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDY4NDcg MDAwMDAgbiAKMDAwMDAwNjk3MSAwMDAwMCBuIAowMDAwMDA5ODE5IDAwMDAwIG4gCjAwMDAwNDM0 MTQgMDAwMDAgbiAKMDAwMDAxODY5MSAwMDAwMCBuIAowMDAwMDA3MDgzIDAwMDAwIG4gCjAwMDAw MDk3OTggMDAwMDAgbiAKMDAwMDAxNjkwMyAwMDAwMCBuIAowMDAwMDA5ODU1IDAwMDAwIG4gCjAw MDAwMTY4ODIgMDAwMDAgbiAKMDAwMDAxNzAxMCAwMDAwMCBuIAowMDAwMDE4MzIzIDAwMDAwIG4g CjAwMDAwMTcxMjMgMDAwMDAgbiAKMDAwMDAxODMwMiAwMDAwMCBuIAowMDAwMDE4NDMwIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA1NTUwOCAwMDAwMCBuIAowMDAwMDE4NjQxIDAw MDAwIG4gCjAwMDAwMTkxNzIgMDAwMDAgbiAKMDAwMDAxOTQzMiAwMDAwMCBuIAowMDAwMDQzMzky IDAwMDAwIG4gCjAwMDAwNDM4MDIgMDAwMDAgbiAKMDAwMDA0NDA2OSAwMDAwMCBuIAowMDAwMDU1 NDg2IDAwMDAwIG4gCjAwMDAwNTYwMDAgMDAwMDAgbiAKMDAwMDA1NTY3MSAwMDAwMCBuIAowMDAw MDU1OTgwIDAwMDAwIG4gCjAwMDAwNTYyMzUgMDAwMDAgbiAKMDAwMDA2MjI0OCAwMDAwMCBuIAow MDAwMDYyMjY5IDAwMDAwIG4gCjAwMDAwNjIzMTMgMDAwMDAgbiAKMDAwMDA2MjM2NSAwMDAwMCBu IAowMDAwMDYyMzkyIDAwMDAwIG4gCjAwMDAwNjI0MTEgMDAwMDAgbiAKMDAwMDA2MjQzNCAwMDAw MCBuIAowMDAwMDYyNDc2IDAwMDAwIG4gCjAwMDAwNjI0OTUgMDAwMDAgbiAKdHJhaWxlcgo8PCAv U2l6ZSA0MiAvUm9vdCAyMiAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPDRlMWJmZmRkMmM4Nzk0MGVm ODI1ZmE1OTY5ZDE0YWQ5Pgo8NGUxYmZmZGQyYzg3OTQwZWY4MjVmYTU5NjlkMTRhZDk+IF0gPj4K c3RhcnR4cmVmCjYyNjkzCiUlRU9GCg== --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: application/pdf; name="radext charter-milestones (marked).pdf" Content-Description: radext charter-milestones (marked).pdf Content-Disposition: attachment; filename="radext charter-milestones (marked).pdf"; size=103869; creation-date="Mon, 23 Jan 2012 22:11:41 GMT"; modification-date="Mon, 23 Jan 2012 22:11:41 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVnduSHDeSpu/jKXLvSDMplXHKw9xpRXUbx7bnQLK3x2xm L9hUSeIsRapFqjWzT7/fD3ecIiOzIpNVYlE0VUYgEB4OwOH+w+EA/rb619XfVod1v131/Xo/bDb9 ajz0626/2g379X71y83qL6u3q6++ed+uXr1fbdaH4bBpD9u5q+b9q9XQD+t2u2q32/VuNwxcdOvd MG5X265fbwbR+z5/sx0P6+1q2LdrsuYcf2mKL642/IPy3/hku9/vdcs/vx5hshvHdrVrD+vDuB9W r35a/c8Xq90YstlP8+Kn1VcvXrTrzapdvfh+9e+rR08er77crLvVo5t48T5evIoXv8SL14/5Hnl/ ftyE3w8x4Z0/eOu/K/+N6d/HhL8EUv3qUXzyy+PGvv9/px+JtH6Y0Pyj3yeuIqlfnaufH6/+z+rF P66+fUEFp2Y9VcVlo4aqOlnF3ZZWP9DksYqbmSpeTar4ESV/8Z+389JMBew8L6m5t4f9ejPutt7c m/Vmc9g3LxDANlDwH+OqKxr+xY+PEQI1O39hcrt69IwmoHW/5oc0SUbXPHoaHv3ZHj23R5b9W7v5 r0Dhw+PVGKnRcryPHEEMCYEyTdQ2j8p0IyFx8MerRzTosHqEHKTX7AUEwFjkAzT+l33jWUV19ejX 8JdGT5l+I1Oi8SYwYH/5KDS+TyytHr163JDTSBjDlsdI2/ctxSoqFRauLSUXqikKu5oprFWRUbbi W0pqiCS1zUVSi57Z7PZDT9/s9/uuH3V1OHTtuD1IFc0rjH6DZhrQExMJOik3DQpjqTQfqcvz0txv 9utDz5cjL96zkOa2PawWSPMzhJb2f4K07leP/oycmjTsG5TVCn2DcJmgcU21k4mG4Bolh9DZNUJC Ok3DX8tPE5Pnb+Ev6oVr5Hny9Ltr1E0TbMiZhjut6fvDYb3f7aZ1dbLdpOiXttuFWmjYoFG2HUbt WAsN/RIt9IGa/5I+SaUn6c86e9YUH/F4Tv5VjUHSO3hE4LHv3brbYofdcIra9yvV6e4QOsNcJrPW ZnAhOLbr7dgaxV6mdrMet1swQwuCGPjdtEb2d+jG2RDs9+ttWxuCbq7rNCCA0hDcmE77+eXb7+Zb 4bTlbDIcukqU91tAS7+lJp353O83h1nmBV9K5o1pWZ63Zj7on9yh1un/P15angLeHZUHxOM69XTX bLtRIO+QylNYZfTzVI85HCvL8wFjoP6A4gndApv0Jfrpw0u7x9goGZWjH0+k4F9iXT1x5akfPoT0 oLGoi7/aK1g6vflhQh8dmQg20on6KHlm+uRpaTiuPersyCKdrr0OZNwhCfO1d6s2efQFzX0PUKvr dustZnKuf93KFAj75XffmWje0Ji0hP2dimYTxh5LKve8Ke3G3XrfdrNdag/ovx0YvoJbDN1/IwRw K8ngB5M5NDKTugGQ6cfySdxyPokvd/RCBOgVheTHc2BduQnvJkpGwnLrE/RZI/DTUtm72BqcQEP9 YT3uZclqTfQprCpAaL3b7nMTFlrk0C0SuR9MDVLldHa7NqxJq6Y+/bugzG273u+H2bLMaERGT1Pz 9MXKdZarwqi5ioJkwDDTf+5KQBibt90wTgUkDLgWmap3jDtoDfoEf9/eaJBCN5MeaI4Gq7PA5whU HwOf2kgZNpBM79Yd49Z2u1/v9rsuYh+DNb1Efyc449lmAZLacYBGzDR062FfEzrGR9j3Q/tQ8NHu sG53FT6a14dTAXwviUOnvZIcJrXniabhTHVV+lCWGqP83vWna07LYtnfV9ox5DfLzjfs0StTmUF/ hjGvjT/QkogSf11FW+ZSiTppZ/i9K2BX2zd4XNIn/NHc14UnyOcFtS/aRzy3bppgGaLC91L683Vg Eu6Sxrmso95i6IZhvd21jIPqhq009hRhqWKPIMJlne0UpkmdbYcBZnzR7vv1btNpcGDeujDQOO4j OAhHvIx5CNEBmg6b4YoRxPkKyyMFrqQGCrA9r4qnYPupGlYqzAdtSLMk5DsEilRXzJ64SiM7T/d3 JXBkdjiKgLuIiSwCZV4i5YgQ1en5Jx2o1t9ymvJGQs1zvjWuIq/fr2pkPU9eXSQXxVlWhyHR6dbW aPWMN3AIfM3Pznxm3D39s6U+t9Svntitlc+5BeF82W5StRX8LOsuKO+m9kgfDVkQqluHLP0GT247 oNhrqai6kTs100Blthstsb3nJbTHnRA875GXi4HPdzc/G+Z5h25EFlTJas+3hn4Men/xuCENTcDf l5bd/lqSWhRFqxbFNaim4+5bu/s3+3nBD9SVv3kkHyZN/0d+3J4fO5+XqBgUyy0tqLbifwZIgPxB TozaVCc3RRMmCpKbgtwbhlVZxUQvhb1wzktxhJ7Ot2DWMQPjmQGoYS5yc+Qtga6/0c2oRno97jp8 wZg5qpk+RefhL+3IX3okedS4tBCNmjL9yZLc/0cz8ZzXaZ7Sz0e/5nUj9bLw6lm65aeXWmvyuSf2 bUvyr6KBjAa07ZqZjMU9dzKXdNTuNY6bH7K0ewDN5gAiret62nMrPKPaODKAMz1XklFpF7X7aWdy e2hBmMw+TXgROl6Gsl5JvXqPpeUdNklXkkhT0cS0An9lOUiyG/otEMSuLVOFiRJ0Kwn4h2jsZc11 YRfoQMrbgyb66mZRVSzziX4RbZabmg+U0krMX7dJr4ODy2/cakUL54ZKAwyEN1jV9F5hZlSLIWtw kRdmzy2u6h4N6ZaaOiZ/yckHVbV6nn9IOYCDmNll9XokYsfqb0k36BmY4Yx9EN2gB/PhCp/rBifm MarOqelYapFGm1c1QfNl7UhXLmq6uWz6+kjlZLCgbi7lsjkwWtoy+73pTpga1T1TSBik+VyGYY8x 7yCP2u9skBjlHjbXGCRrESSf6re/VDzXdAwsgOn+1eOGFDcN1nj2mpmUaGr0QpluLzPQIn2dWhO/ zDmTfNRvzpvkFq/qKL+FV4Cj/qmVqLD+UitxoWrM6IAYhRFvREYHCyet/4BKRA2hoVA81CqWAn1D CjWZ0n8Cr/MY3ZaS7PEX4QVaj9fsZctjKZaHBuMtMIVPC8e5ZntqOWl58tDM/AVXkNMmraUIubEH xiNtSyZeQ5PaXLN9UqICj5i5RAmOyIR4wJ19wa6ROVLs2vII2zZO1L+ZHqcasW8a2zbDY3msaFZ8 S2GkBBMYkcTpMyvI1/yQJghMsZ4G/jSy4eZ5klZk9Zy0HonIsZbPmufM3MBhtx7HjtG+i84nFONO k4Wo+sRLIcb9otiL12p+Df58OPuGZpKtjcl+60NY2krNgFgpj9+9DqY72XVaVfKEhCsrbV+8EZ4F eVGiW2v/xJs3M3kDgcK0nI2MuriBO5pyCNM87X7dHsZuMoo5ZTRaTWxgkX7XYUwLbMMXX7Twvl0y jFkIZ5tjOBuhLe1Mg1ZwVlCMFlTT8WMZ1Jzkc6eePxIuNDHgkTozP+rMmBl1Zu7ozPxVZ+aHzuxD V24YEOldJ4H+ypT8XbRGyBeeSGTRORVPfsOAiA8ikjOitGTIcawpluDBDjkZh4N6Z9V2U4NXIa+l Bm/W9p4eFnUoq12P7a1ZsaHA3FxcxRRwcDod/L33emwCbWR/Pcn7NY0TWi+4rOLAAFukVlS7oEFc V9Tzwz7nO/Wh8QJObN6jxePMck3NxxdRdblGc6b8Tf+wOwrj8EYiBjsrf4qR0lfiCMWfQmGZ+Bzp ofOwqN+PcqHMNc1CHT6rgNGmFbs2rbvE/YNeO4PJsYyNJHu70VQ04VI7rOFEcUo4vw+lrt0/5O41 8XGsOE3VnjPfswJ/2kxnhIerattv94WPed4PUOFOJD4qTtc/703ZBDXURC2DAKJYXMtUGso1ZKU1 TU/6vDIvqX2ay2NDz7XOaQ3Q4s0/dMSybL1C3JJMtVGqhnuMstNIoG01WjtqnBOj08SVBwvHKLtv g5LBGYpSeeFONg2A/mJdWK5QnvzDpC9YePXtmh/vpf6djFxsdx3R1wxNF1Up2PZUANy13bI2Q6GJ B7yyI7iwb5d2y5HZ1hBylrslsjLumOEP/fg+euW4x/QQLLwIPH+5zFN4od7FOzYMI9N2kZe5DrFo 2u52QZIYmSt83oO6xVvTEzo75YVKamnPaazMlCu01deYYBzA9hfdzzX6iPERxoG/GFUUFWNWrmUg TWtxA7LnL5qJF7BwpPMyMArrSTr6DbtoJIyckTByqDDyWLreah79yUgLzdHtntMj+TGCRtzI2otG BLXKp5nU5S/aEoJGquKSEQcP0MT8Lbk0zngZju0zRs5yUqoACFXCsiQlE5Zu9C2/UTDKRgfKMCdY w2DXHlvW6z2M58VB0yuMR4apOJzQ1WcUyzLRPKfjkiEddxhShj2FIe2PRXM6QYdoxjGlY0AfPQaY 14RhhaCXScwzftDeGiFQ40/s7qk9k1Dx7Lk98xecmI9PEUXhuC/sBc/yGvHwkYN+ZmEhMiXE91pW G5gZOa4JhYcJuzp1TywLFZwwIvcbAxg49mdImvwV8FjhsuW26JzdP22jhNXalkj82H6ouYblOCdk iQ57ykjNy1I99XveXmoUgmwfSl60NEjDkPsZzaIPaQj0jUtAaBVr6/CEfkySQzKaNGfWIABxYXqD tPeWj77PjQNCibNpN9IkuPxIcFGhElzuEFz+Sm75kdyyXsS+4dn/QBoi8Y3leI+4kdFyVJ/y8Bt0 r74oKTdFRO4zzEyoQ3dG8GaRx5ElvU30JGQsJWOZRwjvqieDDUUkKBUng0diwE7EZNn44RzuOOLw vOBlJYbVn8ReLQhkfNTtt+O9gJDddt0TKIvhrxmreufU3D9aCIhmhkznQMiO9hhGAnAmvKh3zsTA H3FFJR0Q4SsmdYGx50ecJ1YOsdZj27cVw59KtbWY7H27RbXVDWmVt8RR17Mwk+ozY8jfftyNk3uq NweMsN5jUz4fttv9bBef19urC5Z0dptxvd/07bRwn0JKO5wIQ0ec2mxFL4HKw3bXW8VxVVXxuNlv llbhhRqo2+Jr3gcdeaSBlk7Go4IEb2BRP4fqLrrEaiS08lday7uzn639rO+pqH1HIGFPpPWkhc5L C+bpSHPMGqcjrRZ1B1pkdo2HtMSW8MeRpc2Kh6ytk9maY+tE5oG1jL+rr4pV03hpK4h9WASxXwAu AQMgTfABkIC/QFqgBeujuWYww1/LYyMXatsGeSnd8thQCvDB0zc+fIrUAngh3SjbbKe9BTCBjuUH nXCdFBP5jRqUTbWF72aujJr9tZxA6kQN5DahZk8tXaUIi4QoqXGiUSMVAcjnNasOK/Ap0pCALY3t WGFsmXiBJCufPRZc4xN/EFDj1yqvD9+gg/Elu6ZHcq1udRxHf0oJX7Do+zCsx80Wf0UtJVW3mg6/ xOtRt5rh5UJtlvFU35bRdRUvRwDhfmBL9uOc4SXXy70OlrMfx3nJg+U5P07mCsFh2DXvx5H0IVdf P7H5sKfBG/Hnpcr7YnU576HCo7jpBxZIjmdq+ajFny+TviMez7tH2s3AdhjsaXGOl1y399riLYvX gRG5XooWX7Zg/GSc6Z9ob7TNNIQUjwI60Bx45q7DVYI3BbWHDiRFOpD30IHcoAP5++FxQybUW3oZ Zc01atRIcP2bPUb7kRXtZw+4tkxx6fmKQazl/HvxgZIc9id8UnRQP5BG93NtrBinRuFNCFYqv2vX 9kVsAmWCAu9aOpRnhrBL1FnECJjzWYwwL/QdwaRgzaPGrdRcFjTrxPekcjv2gGF3BQYYdQeUi7g9 LBlgLI3oa7DQGDHazVrP51JMJKxpgBJkStJDA5m0mQBaw+lvFBUT2FJIAAgmHvw1gTFqv/HNmTae RYJHRuu2VpYSAwf21JkCCUe0CJOYDD61iY2ofb+yJg/92XMtg4sd2+bMBhIa2XO+jBntt8wh27Uh kDBrnLlh+lQ8sTEvDeHYX0OF9C8wz19/RVHw6+uDaQpuaEesz4/vfqX5uNXSfGW9sd/vbgzYGYG3 N/5YL7G21vI4oNJnZ5p2pvse1Uhs2FMQf777tgSFYifovl5Tn3CGR4uwGKHTfWte5B+YWfM0taS0 2jQCgyoW1EWrajQopV8s4onDQa29D1E0tA+tSD9UZvC6fmKAwwqdXJCiO+rpyjPTL8NteCmFYHiq fJHKa+QX62ca+CK/seLcWPI5qbtKDU9rbKkaPpK189ij39DpAvY4bscFTjLa8a/vvD9Y5xC6w1x+ zQ9GW55j7p6GPgbG081ze0RkLzWdtpnwnNbvXqr5eXpjpG+sU9sHNLaBimX0T79TR7+yL573tA7a eKKjZWJbuXaq2mqqk2bb6m5UvnRAj6sZfpjTPh7+m3o+Hv6TG0/TzOhf8nJ+v7Qjs3S+xvJYqmXR maBkWqm0cJlGjJ9yVeD91/UDWpuOHx6xJsL6KWZa0uIZ16vpcsqJqkGawkxHqSamisC/FvXOailP aCFbQVLzFFVSneofsUK46nFF5DwqZpCSzZaTty8S+Y/dU6Yb2FRm3OGe9oa9uivMmMgLhaxjCdBm 6DA/x0K2bObtlhVMcSoMuQAo6k5Nx4/MBj+IIcZKbcYNiokb2Rdu1IApjabliQQT+DAz7ZWyV5SK tyJxFB2EnJVqoXlcCO/ffWUvg2LIb9ev1FtgyWhYmpdG7lWerC8UpbwhzXldMBCeudeGTrGZrhaZ u9GeQYR3wswtXmttGlmj4RPac8BeTyKk0adaS35/2nM4sCg4B0hX9uZ3wgZJkw/7LsQcZk3ejrsl UxN/QcwYEKHMhOVYy2GDsBaRe0qayaR+EF7yYfXBDO/vyZTLb74Z8OPH4lwtjB+vv3LVsnvpXe0y Sc9mFCvoRNf3H1QF1Yt24a89RxlYvduIl2vUF9fM/3NNg/HX8qDjSMfM0CjCXmFzIZ6iW0g3NOYA LLxFIxo1LNYzuOC1r03zPLG7b+3u38wR9MIoBF91/DCSAu/nd6o0Ri3nu1A8dDIfNie5FcYKYHkS WzBt7Fohy5yqoLDRF3TKt6zwqQqMAn9RxOSE8jILfKF165mf3GirKRyUpXR8WiUwogTqbfCWDfSW h9YHFOdhVQzBJLlUvaTZf8KYzWwmMuaJi6NhL2yFtt2yDHzYrYa65J+2FXosVpdAdcVLHoa4i/jL q93V5xw2aYJicF4+oR5NExSRl8JELfMixshr7BHGqdjfNGhNBpp0cv5ilAxPkQkJJQVQx1+USEpB Ou9FHbRyxo3MVRwXcrNwSYXgJT2GsujnzWsfKvm9d6S1gUGKJEz4gh/TdHrltefxh05PKJKHPpDy 3inL025sTQEP/VNoXofF+pHSp95ep1VyKG9RQvfKbDhdPPLh2/U+OM6C6wn/6OtFJQyvNjJgYsK/ wjeXNduRayXE05+MptemK6zjnrba+S4Lh0vmN49YOY/DM9zo2Cy93qFoxsuTFQlWzubxvnMfKhiC ZvrhLXzyy85rOYDnGbVKj5DJpwmf2B3dinx/tpvn9sjePfLaBuc6meW11Uv+RcYm3Ng7Rs0eW0rl DTKPLrMw6QWklob++QYJ5deYLx28ll7tVUPQNlmNuu12+u6tkbHXv6u8UT++g4Nl4nOh+VGEzV57 vDFjY5vLmR+lkp/ffSTQ9uX8uLy9M6uPplzhJYyrj6Qc0Crq7tSyjaKlhbjxCFVqHk2r7kyar5mk xUkD1CnNMlgSjaUkJ+eEfJM2/5S/9d9JuUHplqF6HCqjGRBoqQm+4RxJ32gs79/yVOMJAYG4FF5i s+K5ouc8sPm1cntErtGpOXd6/uPfNVJfhA8WLzWxkipWquqrnlQ3aNRCkuO2FzODnQu1j+DsoR0O xGib9HxCwJA14aafbFvBbNOSace/vjSlwSCFdnP985L2kNSaoqBBGCxZtndqTPTRz67vqHHu/mo/ prDs2rRaqX2SbpM+s8c/ijSqkb7Cx+1F+6Y9t5S3P1i2Z3x6opGbE754UfXsfzD5/cZeNuoIGhmM qpefiRhK/M6e53LTTa1U9tdeceaR3ULA4uL3GQG7VFUyr70f2almqBv1k6rKnvimift7oaqk5qhZ 1xzv5ai8l1pjJoGFizqXZY7TJV3BFa0rSOwqbNPgmXnanRvmZvhrGgsB5TrpvqApLZcrtvcM58hh ZJ6bDFqGUCHhrItCHXstGXFXxghrovC/jYITdx0a8pVbJS+r31NqD03pc+4BhcXrlmplM4thWr+V VE6gVvMRsfDnxmwtW0Nw8k6beHEVjAFfGMj1HBsLrKMi+YtqQ6/QljjtgID8tWtLp+1IoWXISY3z lwrnr6U/f2L65Z/vSaw7Il03B6LoJ2JdVfsUoXxEtZ9bgqAty3b4NyesnKj1KVPApjO1rjoua31d 1OdlG1CfHzuECJKhHVMhHoL11iYDm+wGsaiDJSorTQ1KcWDSpAryD/WJWZ2dwfvCYwI+lLuyBQTL G2hs/q7QQlJNUjbQ1OgVPWR+LE+TSWfcu2hz05Xz5pzaSQUELcft4XzI7JSxwPpanLCUpsvliqme KfyY/iMPndb4VBnix5wqLCzTjZdabDbnPbDZ5mrSkOc7KQrkysHxuU6aIGG/G5lST741CdXM4Him ly6EhKGqqeMSEgraIXX8XQQJLSvtBxn7+2saJt9PAIS2Nmep5WEVa+dBdP9xZEFx2j3ovNR8eS9S k7yg/RlesnW/16Dd5AWNvBTWfVnQ7kkvqK2Bx3ijGDD5qBX+2rW5QVEUpGiQQya7sUyANmm6iAUI s2XoTFbSsVwWfQlyJAW1iUsA0Sb//wvYzT5gOS3dchpl/JRQgDL5XwRkYdQsJ93C0B95UF/Qt3dR c6QbDwW7AVAmtoxdDx1Gq/MF+2sPjJ6VErhrFpg8xpdtnmt8WemNL/IvU6IlwAznWN1mmVlB0XKu YWz2uXhARLDa+0j1dqUSJZLspLMzK9GBgCkFKOWonxklOuUKqPOr6TOPw6zOdHiGdNFEX5uQPbG7 p0FrBs9ik2PKpEnNwfcOsTJBIOmfKgrPjRA1wSMfn798+/KHG21wSFLc1doyvMOQy6pD76JmzPE2 tzTjhqV0h75b9XXVnddq1zfjOVvYbZhq2LGl9YQXA1hLpvyf/guVS8dY31dtseaeje7A1J++trLQ EyVYLMOuWu7IBlxvj86N8LI9cl7u0gYkfYyuM81W6mxG8/TOUrubhkREyW/6GLBKHtsT3DRxyoOw 2DVOraSILcX0qlGY2oFGIsa7fIW/pR0oKdu78EweK4XRNE1uKXiysD+WYtQKc8h71aRgqgoezFWF duZLVUHxYeYirZFDq87PLnV4FzZss8Zy++Wid73SOCd6uRu06P56veeMyyt3CNSqzS7FGDYqVwOo 6FwnRBgNTsPz131N9VkxSCHVTRXrLRpWPzQK2bHa/PXpAYrN0o3a6W9U/R3NJfKq8tmQkBunqlEW d0YvpMWTWTwDcqMMCCPvGgWEUWgI668nFf+eG0iiR5QmeP9lgxDBuYIYRY0bIW+kjBf7a48Dk/Eg G6et4Wf6un+WDywTxkuHc+ylc2g3SKNLwBwSmQ6cPgKJnDNhWRpZyoalqA7wPT5PasoVSIRz5aho cACixF+7fvfW/drUOInoFSrXMhDDHvz/BBDZw6OpzUgkTW2WRH52h/rNF4GyHjVxXuFH+zhtLVhi b0XAYo/8AI6Xfuc/PgGggamiaGbnKpbKwqWolFODOLMTWajrf2oUf1dUyiFdil0uZWFeM1VcnZy3 dD1lqoYqp2u6drEb9c0wnc0Dy1RoIps0Sr3ZnruuoIV54HrAJ0QXbtlT8WRETT1W/LnCsef+nffo rmVqoRQFDmsPFurcfoIsEtoTOMsqtKr6p6LguyHe6xg5qYWOPWo0L7PIj7EQq12oLhNWi7zkwdLC tY8FQAFjVADlG4NmCBxDboNdtDa5bBhso3bLY1jG8qQh9DJJuLDEbc9WqQemgI9LvHSnLOsaX2PV MPlm/Nxsu8GTtNedzjuVW9eKgL+au2s0rtYzPFqgNOrPzAQ7A0/s7mnorxqE0m2fG2/2Hf926JUs IrDEsluGJwltGCP23K69VI5QPDexLXzISk8LL2urSa8No1H12hPzVnL477ccuTxpqxO9NoC4sJfG 1W6F07u95V5LNIwc/nlUs2E/welGkjPQ8hcpOaszIBlVa26qL9HPAkU8oWkwkapublTdKe1P3Bws lAl0NpaP8DHkl34BqHInE8C7Tom2JE1ikOgJpnHjHCGvy9rv0r426uAxVlYrgqiYJKnabwp77mkC jE1b13tGBFNelvvWIzoyCOMLAmmyBMwcAN38QH1SubQwj2zdLz2EJrDMaaHhSw8v+zF6eewNBqXk rYI03nmU20uCPxMdD8q4MUjG32VtWPbBRa49doViL7BpvVVtOHWifQSgXuTa0wnIt8+PTLkSoDa0 7A1BxwgtpL9lm03AsTXIu7cWYmiN9F3dZo7IY5OLoDU5eptr+94f6XRYDMv099CSN96wxsmPjqst x1v7rjF245z7ox+s0aNYae7GSvarvWR/fULGnpgvUmvNl8nJhX2dU71ZEo7vcNI2lZwc9XUq5kpd vWjg1XFmUVsdUbdwHq0aN1VhVqUA/fUmNoc1sDtt3/0aNUEchf0QB0X2trW2vSPNTuvJiiMbxaZp YXDPkygULxdNyxlp3x7AReLnn/FAy1rzcFnblzoCdJ3s9IndAhXowK7jwyrW9yJEu7DtL5TDbKcB ervqNKiFYXXel60mPcT2baWO5YYnqtwa0LP/IC//VbV769ilHdgjkJiy7rhEM/sET/sYWu81ZZEH RhAAiRIK1So4xMMRQXDP1LeURht3CSHwCnvU6Ad3on5eh4cGH7gVeuEHVSc61Ip+XvADVPFPErQf Dmzyhx58IHzCi04Nu1qy4zw7A5HnQMCcEgwkiNq/stKTSJ+CnsMG6aF6J5VeqbMJyLt/6MnyC6BU CT1nBGDClfa+iqssMAuq4jfejrOrGbw1vW38DX8htoI3iiAq7RdayuJ94x2fdAKexxveE7FFhag8 447G1HgGV7Y24+LuqWX5sz17bs+cijPlcoMRFBeCtPnzfEid8YpDIIJknJxd7NilQptUdHVTnBOL 1VJEe6Gm69isa2Av08RLHrsv1XQ/mP0yMGHXNCa1GIGFISPZjpu//WoZqHXdShTIGGGQmZovlvbG S4u6QwX2rDuK1X61V3d29XY0d/8O8G6Rm03znU1+fPNc8ZRsDrVngeHcBlfPv5mYxC9jzCX7cW9X Oy1XHmQNu37gjL4VG1+y1SAjWlI6tpsiBYMVUt6snodT1iIB7Zxxkhrv8qZmaw8HaLEIepvvjdJX 37xvg+0+VwBNo3M8AtsTE2zEsZbECLLO46eZtDfBi7qXld/iQ+vY3klJ43qr7hBfbZQ2Jfdm9SMb e/w79br6bkF1qW3bkZjgsRk4AJ7K6UIRlbJKKW9UaKKkymK32iZ7kqd6C/Z+DNWsdm412B85BLMf aSoVio1/VfjjtDcc/MHXh54jpzxfM7JtWK/a2jL/Ne55VKSw3uoAUeinXDDCLNmWWstpSMN+Nx6g FalzsjwbHuu4ishXTHlFSVXbQOxtTHtDGrsfHXT+lKc1nLxhrcjseaBOnpgSeRCtmMbq/sCraKU0 KxG0IvVYO5mHmPIqtG63+m1B06onIB+sH9R51dYP6nvJD77akd1ZU55+w1FfbPHEweGEJoSbHacO 2eWIBdRLZOFIsPBiojDSt+ggRIzpm+nuFb0R8Y33CEXX4x0Q9ZgW+msiqM7L5mZEklg6vZhvhtTI VqRAlXnJwjfSnWpJ/fu8OkEgcyPsCUxEvpqfirQzjUWuWxuLSsuCFRtwRrgLET0p3KKVhdt4pVaO +CfNdvWR6KAw6GqI6lbb8bQ9Fkz7xemUQMYO4Vic8kjq1E0V1745DINtJxSvM0X1lh1bV1uoz24M Rtx+ZvDwn+TDxDVlgDZc/IJxsyRtW2JXAivhIbAj/D7XIrBwJVQTLl4J4IYrYaJwQeBYHgcsZNwH TJnxkdZp231HQV78pFkJznVCY+kEif+Rx8x3Rp3F/UYdsBhLq62tQ4HSxVeP2SaOWksJY8zylddQ epIuIrWUlVUVgcgQ63IXicSs//Knsga1wZ9E245FQ6eFlSJy47MxwX4VzgzFRFyIKFx0pDdRGjpo zURH7sBwvif6XMLmP9YGxDmkWnpCe1MVBp3sGugkZBTSQdEMgv4hDLspVxaIr/7l5pdXNz9/+PXl m9Uvrylb3PeFj7EMpqdIAz0fE1By9tXTn9rmybvyINZlSAaLG4DAPJKhOQ+HTmZztQjJqJIcyehs K0cfhmTQfBcimUBtgmTYGqwNOjTQvgDJyJhr0RVzBhnJSHdO06SjWA8NwiiRzACuD1tXRiQTsk3J XYFkKBCbtmfcQgWGlIxtsCTsjl8jmW4D4i3eCnkqOgWSwSVcIRlg0Y4zxiokE9NKZR/Tshrno2ya 2BbYZqfhDpivVPZb+q+iGUokQ9u3YQ/VhGRG8BTS3GSD4ynQyigippVIJqZlU+LUEYyIUCIPpcGM vJZGyEtUGEcvNbQSmvL6ugTJSHYNVWxZUsp/iFp1T+1kHOJ5SBFMgQMk0KGM+lFAQo5nwjHrIKOA pHXEKb41oaFEjMMoClCT7hzUpPsMapqUFhBLJGg3OtRdOMyRTeLG4U3iNeGbMZbFMFS8uwLfAOj6 npWuJb65qAkLMYqNWuKbKN5LRB7kl7CM8TBW+MZ5lVLIImj8kzbFNwjwHr1a4RtOU9lObdRieEOT 78J44icd6pRRAhbqYcMbZ/ye4M1i6p8NvGHwsB1Rt3cHbzQEqqONtDjtvtCNAGnY8zmAp3g9hOgb DljYVtxUTEzleHYKcRnmuTfvjcb+tfeGc22u9N6MIdbevDfawy7dX4B55L3hwJ61kAwjoE6nqsix VKegyjvOIdUQeAsW2XNgi5Ioyk7OHH9Ro+CjFy/323DUkvw2GjW63yakrFIKfhvwJtimKDApAf/E t5RHdNJb5/w2mPEa6oSEUumHhKjfm62GyezaWWh8VLrsWwVy2FFKHbHEOOxu3odTvBzjNFsqTKe5 FoPqmFJinJhWYpyYFs1JwymlRj2mrLbOQglxIqelHYrlieN/Sqgqyfgm3F4DbhpOcUKgAq7RZQFp dBvQzHbPGH7D2i67OxgaoirD/Y574YuIZvZEYlZoZk+YbnbRpDtHM+lecMRcNE1KCwAmEgw38WsR zWwjN3odF07iNRFTMQKQ0cUVGEYrP7ZUUWw06t5l6VwLoQdnW6iAyjynzrJfsJJh3l8kw8Zd5qQh GFb8HiMWZjPCJqTJI0Ms/7Dn7OLoGo/e5AhZwrTZOY8MwLILA4djyDKZoGrwOXyER8adFO6RYbOT j/TIZMZ14h1iITcAP3fjkXHqtwOiTwlZtpd4ZBCdHUPuhFiYrT4QbHW9QyYEaFbL9u7VIXMbZDlm Zwwnh51FL4h0OL/Bwn34+1bRAvze/BdeIv3mnby4i/t6KU+I+1CavWDZQxAIiTbNZmke7I8TCmfT rIOpOeFg4lhM9vGSi6konFxMq+Bi+urZzZuXH17//eabd2/e/fL6p5sPv7x+ZbQiogt+WEd62ZXG hNZG27hkV9pMVdH7p6HtCq6gcPaX+UWKhBOWlBCIxa9XnpU+xuGFRKadLdVqS4EFvK2YOF6zv/ak ymZfUg3nevtXVFqYtFsGMu/NscZUI8gnzQ9GhIk1WDY/mLxqCWAxnbbT+VKOOJ1S1Oi3zkho5nLD fElEikIEltSkJJDBwPENvXxvCWP2iqE4lOBU2SbEokuNKJjFk4M7wkkzOIQfylemUEJSNF0Yy4zJ a3fY0OKtkKd8izwnJgcBejg7B+qgnByMaaWZjmkRba62GNLtTiepun8BWthuzZmWLjU2AT/olJsS brIAdrcbOe8hudSqeUHc1CXI5FmJL7mNmGS1jZRySvxexpaZr4wXMvcRW5LiNZHhZUxJCHMSUsMk gg0JQ++yKfHkPtvjB3OEqcsCYepWGLLZo1YywtwPnQFGR5hsfS6Eaa/iL8P2CGGyKjfOIx5oguDj Eo5t0p1DzHSfIeYqpQXUmCjaXfzeqybcJ34cYyZuI8ZcqSABY+riDMYsnPHVPCCTYxv1v4wyaQWX oXNtlaV2rq0y1oztd06OoTWR48xDJcfOa8lX5N9RZ3C82jygBs8s0Dryk50CnWGG+RzoZC/8YauO cSvoVFTUItBpm9OEGSvMRfhlGrAGnSyf/EjQeYrxuwGdi6l/StB50TQgGi1MlSXU+dHTgJwPwRHd THQE0XlI04AFZw9vGvDASLRyiTUKoQgplwOWIqCpG3ZQ8inGC1ximgnrGOVamAyHZfTyiTVHSWhr You28tIrHEG5lERhpJA09RreVFpNDGxxuVesw3cBGOGLMWArpDQpBTCiE0HIk8tMirxiVZ6aTgFY pnOA+FmI/6kBS0wrFX1Mi/AEsMD4DRRfzAEyWwqCqQDLKNYE7QrAQoAMdnqPKzMCFuKqOK2DeY9k bGIKdjAZpZRW4JeUliBLpJ7nABMPGcTAvfNaGiAvEV/EaoZYKS91MQcY6yGBmAXRTAnEsGVKnP7T 7ikFiAmbqWjS7wA8TuFLB5oxOL0cwxDHkPALW6yH8Kcm4Ze237CFoNy34cpxS7gW5jC3mD0LiCRS MJ+XaAMUDbvE7+o9/GGRqURE7AaooovLocrI3o7ES9dQZUmLNAR3mLwmqUgp5ZRezHVOgqFlEpwg d5aKAqokXgtJKdLClF6GKmNPyTJO0RQs62MP1wKVkWN8tgcmxz83oHKS8TsBKsupf0qgso/oL+LB M/FKkpudQVyPV8I6Muvd7qZzwcGjIut1wh/F4BXQjDlgvoaY0d8tXukEO3FGb8LOWadYOaV3iiyj DM3ETMgKjo0nvYClMNjiSnw/xSZe3L37uxby4BkyZ9Dbm9+IPku3pePppTvmtGZKL9gz8zGtg1fJ SDwN11q+l8+kP1Go3HQYJwX3Zow54x+bToQyULFtQCiGMWO+sXdvibYnzdh5Zo4vraEg7uyJ3X1L Ibn7N0vUKUfkdxeZEUl+suwHWxCgNrLzlY5SI7pd5ZEWu8V7aKFu0REw6z1UqElfb9mD1/3EXHXZ 5Drmm4aiuYi+YxGRNStrEziSiWsmBlJKsVkBz/NmBdx4PB8NTW4qhyRW5hfva43lH1kHkx7jdeW6 DAO01+yDlm7kqHheZtTo5MKCb64tvaRjizSP6ZAzt9BtYoZ1apk8dONifWdJRapXBPepCUrhlQ0b +ljBkaDklS09r3DOo3oR3BJR0o78OgavYPoOZInwsANHT19cBT9r+xwKWnY0W0vLwlltqOXPvYZ+ /tk6kHUmy+jVZkmlY5/asUpijf5tjTl2mkU5qF6sJJfrDC0uh2FbXM7FGR6TIhFbtmTqNhkDSuMS usXVP6fKIluuXo0rQqbRU5Oa8zp+q9mN5sU/rr59QfjrJSJV8HiLSC2Y3BgZnjEYKe3ujPKem9ww sbC/tjQ4tUY4HoE760i+dvtHL3ha60+Gf7KO6er9uSl0y6eFWOTwXSPDdViURVqqQSSOW5PVdy6m dkeW22RRkNygR68Yk+3lvco7zc1LY+it9k6AH7fBLgm2rYLl+I9HoRf+Ly+vl/4/HodUy+L2na0y 11aEyVK/TzyL0/bEc+RpHGIwNbq/2CWyJb7S3SvtyIGR8f7iORzCm0dCyxX8OTDPIJd7lQLBfqOT RAFfrFJieMqAn2EiA5VuS8RQfFHZqhfJdJE/RCqZomjiZStvhi0CmqbgDxkZMZMnVoBSek3gpLfe NMdvnZjAYfFOqEcVvPBFeFoeTTYpX/KHjAjSjj0N8mhy1Lq9iTsEDysxMBrExxebseXUpO4AYk/u EI7xY68YlLqWq4jEGFNKd0hMy+4QaPmb2R0SqeeUyEPhDoms5jEuJfTyJG9IKnMae6eUS7whatjo pdCaxHxd+EPwWnikUMvauewRUXfB4RBihlqGR0EccZu0CtWvAobaAR1stHUVvSG6Lr0hujdviFOw 2RrRDu/g/QjfdE9I4ia5QgKnwRcSro6cIczW9Ps92bUwNC6iKOdtRiLsNkxGlPM2x+2BZFp74Gtw 71Sq/bn2yKITJTpLb5Ly7LuL1JNYkmdGep3TLCYc6m5pNMQkulmyuGXFQvaG0JCKbr7aGaJYOCJG HKzliBsNE2zhTQn3H86sDQp1nvG7cYYspl7WDsYxzFGl9Vfp4n4Wb13kDEFntTrVoJi12Q1aXH21 MwTR2/6O4c0L0Kcv3hoLzh7erE07AOUKdLKjT183Z7PTdLvZcKaCVvH2UnzSHlCnrADFuoepN5Rm TCKk0pJAANhNWdmt4IPsp5Lwq41Ky7mmtCJCuSDE5KBJrNVOxicWrkygePLhh8mcWGSYOYQpnPSW MpVvkeMEPsHAM97rCAop8UlMKzV8TIswAwjBytCB7ZdjCrQwSGHf+5RGILVwHwzEXKTg0R6ZWUjw ZCBadpBnMdoYwrg9pYAnKS3DE2h5vgRGEvWYAq3AQQlOIp+l2YmlydYwljhaw1xXl6CTNFcDfjD4 SyxIuC7RiZ4ZBhkUFRGXm6u7JHSCQFCPlmskjqZEJyDSTpEn0nG6iuhE1yU60b2hk0jB76BtczXw xjcjOoncZHQiTg2d6OoInWAEjtCJVgvE5iAwSgG+QeBy2kUNkifPkvAWUzUpbZHwFoAl8lBO1URe S0HJaRN8MrBIgzWMLCovVpcLn/RTKxNjmW8LK1EQ2ee4+sr5PsJVdwNPrFJuJ/65oBPJjeB6DU5Y /DoVm6UzNQPbqbCE/wGGlJScPUBwMhIkf9fghGMHu6Yw1YqlXR4Bq4kOBpQRY/zU9JMUDII2mtFa oAKc9CzrDmGj8UVlq0m9aS7ynsiMURR5TxLMiClNSgEWcS6J8kR0phR5UvJbIU9Fp0Ank2gSLd7q WTNVopOUVij4lFagDBDUdldEkwxCZzutSCywiHaqUd8r8QmbYxM4W4S/DtoE6lAEk3gClCI2YH+l kAdCCUDEpGTmhkg5pjTalSl8vzCQic/C6Axsv6LSFMRjzUQOwtK3UFfXoZOx21HLQhDCEjsKkuNA dO+4g8CajE7oL9SBPSHWN7wj3wmj9Ak6YZFZoM2z4G8xBKHrEp3o3vBIpOB30I7oRN+M6ETBOuIm oxNxarR1dTk6GVhUdtgEgYuNBMh0wVnUIBmdJKEs0ElKuwvhjbyWfOW0KTrR4n85VKfoZGplloIT VmnhS0zLZSrvycz8yyLviaZOPcI1+hPufuubyPjtCOKarW+WU/9s8Alqa9NxIFYBUNi35iO2vhkU +Dgy+YpRYalbGGXf5+Lw5d6TkrMHCFC0jL0AKHuMTnAFXDy9s9+l6Flp+ybdXxrxCtRkcTox+YRY yLgS8TpNQlsz5B8JDFhtccTtuhCpqPMwhh4ZSK8qX00Nb8flIGXU6uUVVjXUFHM36RZyFFbTYUVx SVFOy68MOT925pTbZFD9aRV74TZJaaVuj/kyMAEf7ZjkSiCkGdg7EOtZAxMautMouQQmzI5xqrPW jwOxtCUgceM4wFHB2XESU0poEtNKbBLTspWL1GMKhsx5KMFJ5LW0ObFEBfLx2sngJNbDdeBk22dw ousSnOjeIYhmypPrhL6SwAmbS4Z3BE52rButXSc7HB7mOtFVdJ3ougQnujc4Ein4XXCD6Lpp9c0I TrbOTQYn4jQCn6vAyXZg8UEQuthI7E7owrOoQQpwkhskCg8Y1pttkQBn10nioUTWkdeSr5w2BSeI 416R8yU4IQx9d7ganWjam0AcNzGfETpxxu8JnSym/inRyWEKAs8EukrFDLhQ7hCdoAl3GnU/PHRS cPYA0YmthY0LiFnweC06ObDK0Kc/2nYzQMnvL0UnzIWxPy7wBOduOJUR5qZpUtiCJYqPxRVgZ0ko DQWCaY2vhmxTctfgk5YlZCOrRR2fFLfCJy27BvI0F5jncpZY/pAhv34Gn4QFF0yplPgkppXqPaZl fKJ9RNhsvMAn7G67EVIr1Tvh5UwA1fiEwIC+w0pmfEKIAeP1Ep/ElBKfxLQSn8S0bOgi9ZjSDJGH Ep9EXkuzE0uU8UksdcYnMeU6fLIbNIFmzhNdl/hE94ZPtA484xN6S8IneyKk9I7wyV4zpMW+ew2e 3IhPdBXxia5LfKJ7QySRgt9BOzpP9M2ITyI3GZ+IU8MnurrCeaJVbNrRtFgwjGo24VnUIAU+yQ2S 8UlMWyTABT6JPJQCHHkt+cppU3zCjA57RdX45GM21sM5y8oCYf7jBcMP23nijN8TPFlM/bOBJ0jO fofyvDvnCU5PxSI8PHSSGXuA4GSPF6twnRyudp0cNEqy2AyFf8RbjPdFUzttx1bAwhdEtYZNbZlN sSTWEXoS5r7TzjYKjcA1wgYtijVk/Z/5qKt8E2oBmTQXHX2gRYgADXeclHeub5tYVpgY95rUscx6 nF89CUpWsL/W/HjGJNhwSyo1uidlREJA83ZgCiCnEKEGDFAQZkxrIMxc+STUhBAOnDTFwmCiM9nv BL2bjUpMyYgEWp6rRCQxLeKP1RCpFynOQ0YkzRB5LQ1NLFFGJF7oCEhSXRV4hMDPvMPl2b1N2j3r 9WIgrK5LPMI9S3wD0mA8nvEIHYT6tCcH97Eo10GTogUeIQUvh/lLuApLfLWVhlJLPKJ7QyCRgt9B 2/AIWCfsCec4xbghXBYzL7ZCKQyPqAyL8EjYjBu8p9NEqHqaUT5JHGW+ffN1rZHEFHmLEdQfJ7nl Hr+RzVJAnPOjGNiBMCXFn5V+ko/CIdpuL2D7zw2HOOP3hEMWU/9scAjKqtXEZoFDCIH9mCgTpvi3 Ogjh4QGRgrMHiEQOwXQmN0nLcgBM6cVTOLynmQ1gQ8to3e4uBSFyhuhcN7aGB3L4Lr6e1qQ0OUMI oJZx1WpJ38cXewsKwpLGV5VtSu4KGEJxhNRawRwvXr43F4lcJ1584BD7MuX8wUOS81OtJ6dwCKHk aK9qZc4Q00o8EtMi1MDwM2PJVFYBPohJU3x5xiOrnvmtXoNhkfIDmzj+G8yntfRxBodt6Fn6xPAg 2pUmpWQ8Ai3PVeCRlJZsW6IeU6DlPGQ8whEUxmppbWJ5MhyJZY54BEjktVUAEiZulwIS9phzQNIQ D6R44BxdonuHHUDrDEjoJxGQcOKcOVUAJN2GnWpKQNJ0G9waAZCEK3eQhOsCkIT7ADUSBb8Lzg5d wxvf1DtapSO0K24yIBGnBkh0tQiQVLGvUKO1g8jFNrqsPQr/SG6PKDrIpbfRIukt/CPH0ps4LcUk cn+ESiSLIfD7zmAJO6ns85rXz2j2xhm/J1iymPrnAks4AI7loWHiz7cpwRP/UbCEhaTTvWBP7t/x +x6rVHL28GBJZ2a0gCU6DQ9leOHmrzo7LNhtwh8x0rq5FJWwYGNPvCVgQ/os7OrkSU1KYokLWwkD R5ioYGmxbaOGF0IRbmWmKakASDgS8oIlOcxCB3wRjnhkLFneoh7lDmq81NyG/WA5RUDv6Gnx7kks goEHfukozZ/yjmUprdDmKS1DCsajnF+XV+EQ6Mv6mrDFUwE8wpE01WxNL77322IZTg+Q27d4VZJB iSnlfq8xTYWLC0dTWrJqiXqRosOOtoGUD8Yjp4FUSvPyZOKxbiIWSbUFLYUHLTsBUsMUxwjE0ZbX GYuAJHgWsAjrTM0L4XfsiOHOEU4tU8taeqv59NI5AlLWdA9RtOEqYhGlllhE94Y+IgW/C44Ou6ZD hnfAJYmbhEUCpwGLhKtFWATnCAAiVbRaWyKXvSOXNUgGI0ksC/9ISlskvhmMJB5KLE2Ie+BVMjfl /xiN7EBZikW7KzSCcmFwFD3unw8Ycb7vB4ssJv7ZQBHEhoM+785B0muKQbsuPDgHScnZA0QiXYiB yEhEO7xfg0S0Dbw8CKy7kC7g5lIkwonI7h/B16IAEbwtnsR+FpYEEtGewHKOKLLQVgcDTsw5kjLF 99gHIb4XY1s5Nqre9eiUc591k0IiPUtEQ7nKW2ENpmQaK6hMaoAgnpnbOvMJr8iq3zHZEhxBBRKJ aaUqj2kZiWhvSvZvLVAHxlH7t5bOblwizF4yBBat6BYBR2w2u2LFTY+W16ggIxFLqICI55FN8A0s 4mvZSETKRYp9v8IhzqcqLZmXWJpMPJY44xBPuRKH6JDdiEN0XeIQ3TvCAP4knwiBOX3CIfEkdPlE OrV9hUM6PBmGQ3QVcYiuSxyie0MbkYLfBf+GX/NN84mAaZybjEPEqeEQXV2BQwD5061b+4sapMAh sYlKHBLTFglvgUMiDyUOibxWguL8H+MQyZK2Kr4zHLJl7zOQvRuUzwiIOOP3hEQWU/9soAgzoBwU f4crbtgtaM35KL8bFqntWfQTp+MYJ+yc37yVTede/KdtwqcjuS84KufezmPk7Gg5RyJEUQ+/BKKo H+jsakclQhXsZBHvLgskYb1NZ0d3RmAB7WkS6hvFzeYPOFUySOm0sFEx8v4m6GjmzYhSlp+SQ3RM ACIOUzhjMUzYGGxhgkaLIIvStkSIZljD80n+Hxu5oNKyxIwJCOsjLLZag9PHtFLbx7QIOJqekIZW G2jFFE4HYjfQQdtKFmmEbjHLU3tNAG/siZFjXBttt8fOcDnGlSNOPaWcwYlpJVqJaRF0QMupxxRo OQ/FDE7itbRCsUQRrlBGr50MV2LKhW4TokUY/HaIRoIrus5wxZ4ZXNEmfRmu0E0SXMElhIB5LkbU NVxh8irAFbBEcLUYpNB1CVd0b6BEw08o2OZqHbQDxGHaRl3T4QrXzk2GK+LcaOvqCK7curmahhGD 4vlKt0kUnpkGAZxEcBqrf65BjoV6RoALcBKb+7wAR14rvox/mmIS49qzPxv4ro5xDWtwrt1fjdXo 7C00xG07K7zyoPdXO8n4nWxgspz6Z4NXEJ3dHu1ZBJd83ArhnpiIVmrn4flOCs4eoO9EwWQZmOAN kN1HH146i0NQQqBzYD4AItf4TjT1w+iHEznDQhpATp2CCmpxSmDrGOhr/bCtJ2nZu4QtOvOLylaT ipM4bNO4xHUiuMXBB7ZUusU17CWrU/DjMH8ellNbgam1A5s9CamEV5TBXqFaPeWkGwWUhUKt1t/0 Ma1U7Z5WqHahJmawChxCMBojYk1AZHUP/mTBR41NYJ/dcg/Qos21Phhjy0wa44hsXmJKiU1iWolN PK2YL3DqhYsk8lBik8hraXK8RIUpjDWRTWFMuQSbqF0Nm3BKX8Imui6xie4NdShuJ2MTekrCJgxM EjYJ6LRypWinAvtO2LPA8YOuS2yie8MmTsGxCbQTNtE39Y5wSuQmYxNxathEV1dgEyKm9uqwJTb5 +AbJwhMb6U4E2HktBcX5n8Emajnpiakr5WpoglICR+OaPI57fdjQ5BTjdwNNFlP/bKAJaovIr2pa 5yOhCQsBNN57eMgkM/YAgUnY/hnNJL+HvAPDRR4T1bZ5TAaf1Gm78YAr4ZpZHYYkbKTBwD5sYUpT QtuT2OMT4EkSWpq1aIT5YTxRPuy9FSbw/Uy+MteEVsQmFwSYtHjyBTO02aawW33PbvNd2PbFCgtn 3COCMb/uy/fPRJmwupltVjkxLqt0S4JoARpCrgJrEI9LbRXrb1gwAN4nxqFAJDo9rtPAWKR8YkdO p81+U6y/6bR8YsNIIXEQU8qpnZgGrTR8TmnJN5KoFynGQzW547wGWjF2IJYoUScaVVXD5whq10YU nnDl1A4iQzs6ZuA645Gm0zPDIzrNKOMROkjCI1pYFn0lW82GVnhki4dDtJtOV3FqR9clHtG9IY1I we5EW+8Ig+ibhkfEl3GT8Yg4NTyiqyM8MrfVaxViojMcDAOnFoqSw1eLNJevaWsUEzvePMhbXH8T W+wiycWVZZJLaQopNTYLliLnR04SSaFtJM7cvo6hIeL9Y9bfyEEVjmmbwSEPeh1wZPwIQN0NDvFq uZ3654JD5GvnCHMh2BTo+nE4ROqPlXUPEIiUnBVI5P8DpaUpgQplbmRzdHJlYW0KZW5kb2JqCjUg MCBvYmoKMTY0ODkKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAv UmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQo+ PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VD IC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCj4+IC9Gb250IDw8IC9UVDMuMSAx MSAwIFIgL1RUMi4wIDkgMCBSIC9UVDEuMCA4IDAgUiAvVFQ0LjAgMTIgMCBSID4+IC9YT2JqZWN0 Cjw8IC9JbTEgMTMgMCBSID4+ID4+CmVuZG9iagoxMyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgOSAvSW50ZXJw b2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSAxNSAwIFIgL0ludGVudCAvUmVsYXRpdmVDb2xvcmltZXRy aWMgL1NNYXNrIDE2IDAgUiAvQml0c1BlckNvbXBvbmVudAo4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Afv/n1KgUPKSoBGqVa+Q1QC1oIkAZTVqEWqACrQaXpn1vUHWterUd616qBqI AsuJb5znvrWb/ka/7TVQOxABFcw48hWuy7DztcOst64L3sJFsDIg5mCVIkYQAEyTIikKZW5kc3Ry ZWFtCmVuZG9iagoxNCAwIG9iago5NgplbmRvYmoKMTYgMCBvYmoKPDwgL0xlbmd0aCAxNyAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMiAvSGVpZ2h0IDkgL0NvbG9y U3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFVjMENADAIAtmim7MuFWJr5HVcCECH4kNI AqgYc6GNfdB1h+N5/j6H/VN8AbxeO+sKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iago1MAplbmRv YmoKMTggMCBvYmoKPDwgL0xlbmd0aCAxOSAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0Ig L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VBTXF8ffzGwvtF2WImXpvbcFpC69 SJUmCsvuAktZ1mUXsDdEBSKKiAhWJChiwGgoEiuiWAgIFuwBCSJKDEYRFZXMxhz19zsn+f1O3h93 PvN995535977zhkAKAEhAmEOrABAtlAijvT3ZsbFJzDxvQAGRIADNgBwuLmi0Ci/aICuQF82Mxd1 kvFfCwLg9S2AWgCuWwSEM5l/6f/vQ5ErEksAgMLRADseP5eLciHKWfkSkUyfRJmekiljGCNjMZog yqoyTvvE5n/6fGJPGfOyhTzUR5aziJfNk3EXyhvzpHyUkRCUi/IE/HyUb6CsnyXNFqD8BmV6Np+T CwCGItMlfG46ytYoU8TRkWyU5wJAoKR9xSlfsYRfgOYJADtHtEQsSEuXMI25JkwbZ2cWM4Cfn8WX SCzCOdxMjpjHZOdkizjCJQB8+mZZFFCS1ZaJFtnRxtnR0cLWEi3/5/WPm5+9/hlkvf3k8TLiz55B jJ4v2pfYL1pOLQCsKbQ2W75oKTsBaFsPgOrdL5r+PgDkCwFo7fvqexiyeUmXSEQuVlb5+fmWAj7X UlbQz+t/Onz2/Hv46jxL2Xmfa8f04adypFkSpqyo3JysHKmYmSvicPlMi/8e4n8d+FVaX+VhHslP 5Yv5QvSoGHTKBMI0tN1CnkAiyBEyBcK/6/C/DPsqBxl+mmsUaHUfAT3JEij00QHyaw/A0MgASdyD 7kCf+xZCjAGymxerPfZp7lFG9/+0/2HgMvQVzhWkMWUyOzKayZWK82SM3gmZwQISkAd0oAa0gB4w BhbAFjgBV+AJfEEQCAPRIB4sAlyQDrKBGOSD5WANKAIlYAvYDqrBXlAHGkATOAbawElwDlwEV8E1 cBPcA0NgFDwDk+A1mIEgCA9RIRqkBmlDBpAZZAuxIHfIFwqBIqF4KBlKg4SQFFoOrYNKoHKoGtoP NUDfQyegc9BlqB+6Aw1D49Dv0DsYgSkwHdaEDWErmAV7wcFwNLwQToMXw0vhQngzXAXXwkfgVvgc fBW+CQ/Bz+ApBCBkhIHoIBYIC2EjYUgCkoqIkZVIMVKJ1CJNSAfSjVxHhpAJ5C0Gh6FhmBgLjCsm ADMfw8UsxqzElGKqMYcwrZguzHXMMGYS8xFLxWpgzbAu2EBsHDYNm48twlZi67Et2AvYm9hR7Gsc DsfAGeGccAG4eFwGbhmuFLcb14w7i+vHjeCm8Hi8Gt4M74YPw3PwEnwRfif+CP4MfgA/in9DIBO0 CbYEP0ICQUhYS6gkHCacJgwQxggzRAWiAdGFGEbkEZcQy4h1xA5iH3GUOENSJBmR3EjRpAzSGlIV qYl0gXSf9JJMJuuSnckRZAF5NbmKfJR8iTxMfktRophS2JREipSymXKQcpZyh/KSSqUaUj2pCVQJ dTO1gXqe+pD6Ro4mZykXKMeTWyVXI9cqNyD3XJ4obyDvJb9Ifql8pfxx+T75CQWigqECW4GjsFKh RuGEwqDClCJN0UYxTDFbsVTxsOJlxSdKeCVDJV8lnlKh0gGl80ojNISmR2PTuLR1tDraBdooHUc3 ogfSM+gl9O/ovfRJZSVle+UY5QLlGuVTykMMhGHICGRkMcoYxxi3GO9UNFW8VPgqm1SaVAZUplXn qHqq8lWLVZtVb6q+U2Oq+aplqm1Va1N7oI5RN1WPUM9X36N+QX1iDn2O6xzunOI5x+bc1YA1TDUi NZZpHNDo0ZjS1NL01xRp7tQ8rzmhxdDy1MrQqtA6rTWuTdN21xZoV2if0X7KVGZ6MbOYVcwu5qSO hk6AjlRnv06vzoyuke583bW6zboP9Eh6LL1UvQq9Tr1JfW39UP3l+o36dw2IBiyDdIMdBt0G04ZG hrGGGwzbDJ8YqRoFGi01ajS6b0w19jBebFxrfMMEZ8IyyTTZbXLNFDZ1ME03rTHtM4PNHM0EZrvN +s2x5s7mQvNa80ELioWXRZ5Fo8WwJcMyxHKtZZvlcyt9qwSrrVbdVh+tHayzrOus79ko2QTZrLXp sPnd1tSWa1tje8OOaudnt8qu3e6FvZk9336P/W0HmkOowwaHTocPjk6OYscmx3Enfadkp11Ogyw6 K5xVyrrkjHX2dl7lfNL5rYuji8TlmMtvrhauma6HXZ/MNZrLn1s3d8RN143jtt9tyJ3pnuy+z33I Q8eD41Hr8chTz5PnWe855mXileF1xOu5t7W32LvFe5rtwl7BPuuD+Pj7FPv0+ir5zvet9n3op+uX 5tfoN+nv4L/M/2wANiA4YGvAYKBmIDewIXAyyCloRVBXMCU4Krg6+FGIaYg4pCMUDg0K3RZ6f57B POG8tjAQFhi2LexBuFH44vAfI3AR4RE1EY8jbSKXR3ZH0aKSog5HvY72ji6LvjffeL50fmeMfExi TEPMdKxPbHnsUJxV3Iq4q/Hq8YL49gR8QkxCfcLUAt8F2xeMJjokFiXeWmi0sGDh5UXqi7IWnUqS T+IkHU/GJscmH05+zwnj1HKmUgJTdqVMctncHdxnPE9eBW+c78Yv54+luqWWpz5Jc0vbljae7pFe mT4hYAuqBS8yAjL2ZkxnhmUezJzNis1qziZkJ2efECoJM4VdOVo5BTn9IjNRkWhoscvi7YsnxcHi +lwod2Fuu4SO/kz1SI2l66XDee55NXlv8mPyjxcoFggLepaYLtm0ZGyp39Jvl2GWcZd1LtdZvmb5 8AqvFftXQitTVnau0ltVuGp0tf/qQ2tIazLX/LTWem352lfrYtd1FGoWri4cWe+/vrFIrkhcNLjB dcPejZiNgo29m+w27dz0sZhXfKXEuqSy5H0pt/TKNzbfVH0zuzl1c2+ZY9meLbgtwi23tnpsPVSu WL60fGRb6LbWCmZFccWr7UnbL1faV+7dQdoh3TFUFVLVvlN/55ad76vTq2/WeNc079LYtWnX9G7e 7oE9nnua9mruLdn7bp9g3+39/vtbaw1rKw/gDuQdeFwXU9f9Levbhnr1+pL6DweFB4cORR7qanBq aDiscbisEW6UNo4fSTxy7Tuf79qbLJr2NzOaS46Co9KjT79P/v7WseBjncdZx5t+MPhhVwutpbgV al3SOtmW3jbUHt/efyLoRGeHa0fLj5Y/Hjypc7LmlPKpstOk04WnZ88sPTN1VnR24lzauZHOpM57 5+PO3+iK6Oq9EHzh0kW/i+e7vbrPXHK7dPKyy+UTV1hX2q46Xm3tcehp+cnhp5Zex97WPqe+9mvO 1zr65/afHvAYOHfd5/rFG4E3rt6cd7P/1vxbtwcTB4du824/uZN158XdvLsz91bfx94vfqDwoPKh xsPan01+bh5yHDo17DPc8yjq0b0R7sizX3J/eT9a+Jj6uHJMe6zhie2Tk+N+49eeLng6+kz0bGai 6FfFX3c9N37+w2+ev/VMxk2OvhC/mP299KXay4Ov7F91ToVPPXyd/XpmuviN2ptDb1lvu9/Fvhub yX+Pf1/1weRDx8fgj/dns2dn/wADmPP8CmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoKMjYxNQpl bmRvYmoKMTUgMCBvYmoKWyAvSUNDQmFzZWQgMTggMCBSIF0KZW5kb2JqCjIwIDAgb2JqCjw8IC9M ZW5ndGggMjEgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AZ2Wd1RT2RaHz703vdASIiAl9Bp6CSDSO0gVBFGJSYBQAoaEJnZEBUYU ESlWZFTAAUeHImNFFAuDgmLXCfIQUMbBUURF5d2MawnvrTXz3pr9x1nf2ee319ln733XugBQ/IIE wnRYAYA0oVgU7uvBXBITy8T3AhgQAQ5YAcDhZmYER/hEAtT8vT2ZmahIxrP27i6AZLvbLL9QJnPW /3+RIjdDJAYACkXVNjx+JhflApRTs8UZMv8EyvSVKTKGMTIWoQmirCLjxK9s9qfmK7vJmJcm5KEa Wc4ZvDSejLtQ3pol4aOMBKFcmCXgZ6N8B2W9VEmaAOX3KNPT+JxMADAUmV/M5yahbIkyRRQZ7ony AgAIlMQ5vHIOi/k5aJ4AeKZn5IoEiUliphHXmGnl6Mhm+vGzU/liMSuUw03hiHhMz/S0DI4wF4Cv b5ZFASVZbZloke2tHO3tWdbmaPm/2d8eflP9Pch6+1XxJuzPnkGMnlnfbOysL70WAPYkWpsds76V VQC0bQZA5eGsT+8gAPIFALTenPMehmxeksTiDCcLi+zsbHMBn2suK+g3+5+Cb8q/hjn3mcvu+1Y7 phc/gSNJFTNlReWmp6ZLRMzMDA6Xz2T99xD/48A5ac3Jwyycn8AX8YXoVVHolAmEiWi7hTyBWJAu ZAqEf9Xhfxg2JwcZfp1rFGh1XwB9hTlQuEkHyG89AEMjAyRuP3oCfetbEDEKyL68aK2Rr3OPMnr+ 5/ofC1yKbuFMQSJT5vYMj2RyJaIsGaPfhGzBAhKQB3SgCjSBLjACLGANHIAzcAPeIACEgEgQA5YD LkgCaUAEskE+2AAKQTHYAXaDanAA1IF60AROgjZwBlwEV8ANcAsMgEdACobBSzAB3oFpCILwEBWi QaqQFqQPmULWEBtaCHlDQVA4FAPFQ4mQEJJA+dAmqBgqg6qhQ1A99CN0GroIXYP6oAfQIDQG/QF9 hBGYAtNhDdgAtoDZsDscCEfCy+BEeBWcBxfA2+FKuBY+DrfCF+Eb8AAshV/CkwhAyAgD0UZYCBvx REKQWCQBESFrkSKkAqlFmpAOpBu5jUiRceQDBoehYZgYFsYZ44dZjOFiVmHWYkow1ZhjmFZMF+Y2 ZhAzgfmCpWLVsaZYJ6w/dgk2EZuNLcRWYI9gW7CXsQPYYew7HA7HwBniHHB+uBhcMm41rgS3D9eM u4Drww3hJvF4vCreFO+CD8Fz8GJ8Ib4Kfxx/Ht+PH8a/J5AJWgRrgg8hliAkbCRUEBoI5wj9hBHC NFGBqE90IoYQecRcYimxjthBvEkcJk6TFEmGJBdSJCmZtIFUSWoiXSY9Jr0hk8k6ZEdyGFlAXk+u JJ8gXyUPkj9QlCgmFE9KHEVC2U45SrlAeUB5Q6VSDahu1FiqmLqdWk+9RH1KfS9HkzOX85fjya2T q5FrleuXeyVPlNeXd5dfLp8nXyF/Sv6m/LgCUcFAwVOBo7BWoUbhtMI9hUlFmqKVYohimmKJYoPi NcVRJbySgZK3Ek+pQOmw0iWlIRpC06V50ri0TbQ62mXaMB1HN6T705PpxfQf6L30CWUlZVvlKOUc 5Rrls8pSBsIwYPgzUhmljJOMu4yP8zTmuc/jz9s2r2le/7wplfkqbip8lSKVZpUBlY+qTFVv1RTV naptqk/UMGomamFq2Wr71S6rjc+nz3eez51fNP/k/IfqsLqJerj6avXD6j3qkxqaGr4aGRpVGpc0 xjUZmm6ayZrlmuc0x7RoWgu1BFrlWue1XjCVme7MVGYls4s5oa2u7act0T6k3as9rWOos1hno06z zhNdki5bN0G3XLdTd0JPSy9YL1+vUe+hPlGfrZ+kv0e/W3/KwNAg2mCLQZvBqKGKob9hnmGj4WMj qpGr0SqjWqM7xjhjtnGK8T7jWyawiZ1JkkmNyU1T2NTeVGC6z7TPDGvmaCY0qzW7x6Kw3FlZrEbW oDnDPMh8o3mb+SsLPYtYi50W3RZfLO0sUy3rLB9ZKVkFWG206rD6w9rEmmtdY33HhmrjY7POpt3m ta2pLd92v+19O5pdsN0Wu067z/YO9iL7JvsxBz2HeIe9DvfYdHYou4R91RHr6OG4zvGM4wcneyex 00mn351ZzinODc6jCwwX8BfULRhy0XHhuBxykS5kLoxfeHCh1FXbleNa6/rMTdeN53bEbcTd2D3Z /bj7Kw9LD5FHi8eUp5PnGs8LXoiXr1eRV6+3kvdi72rvpz46Pok+jT4Tvna+q30v+GH9Av12+t3z 1/Dn+tf7TwQ4BKwJ6AqkBEYEVgc+CzIJEgV1BMPBAcG7gh8v0l8kXNQWAkL8Q3aFPAk1DF0V+nMY Liw0rCbsebhVeH54dwQtYkVEQ8S7SI/I0shHi40WSxZ3RslHxUXVR01Fe0WXRUuXWCxZs+RGjFqM IKY9Fh8bFXskdnKp99LdS4fj7OIK4+4uM1yWs+zacrXlqcvPrpBfwVlxKh4bHx3fEP+JE8Kp5Uyu 9F+5d+UE15O7h/uS58Yr543xXfhl/JEEl4SyhNFEl8RdiWNJrkkVSeMCT0G14HWyX/KB5KmUkJSj KTOp0anNaYS0+LTTQiVhirArXTM9J70vwzSjMEO6ymnV7lUTokDRkUwoc1lmu5iO/kz1SIwkmyWD WQuzarLeZ0dln8pRzBHm9OSa5G7LHcnzyft+NWY1d3Vnvnb+hvzBNe5rDq2F1q5c27lOd13BuuH1 vuuPbSBtSNnwy0bLjWUb326K3tRRoFGwvmBos+/mxkK5QlHhvS3OWw5sxWwVbO3dZrOtatuXIl7R 9WLL4oriTyXckuvfWX1X+d3M9oTtvaX2pft34HYId9zd6brzWJliWV7Z0K7gXa3lzPKi8re7V+y+ VmFbcWAPaY9kj7QyqLK9Sq9qR9Wn6qTqgRqPmua96nu37Z3ax9vXv99tf9MBjQPFBz4eFBy8f8j3 UGutQW3FYdzhrMPP66Lqur9nf19/RO1I8ZHPR4VHpcfCj3XVO9TXN6g3lDbCjZLGseNxx2/94PVD exOr6VAzo7n4BDghOfHix/gf754MPNl5in2q6Sf9n/a20FqKWqHW3NaJtqQ2aXtMe9/pgNOdHc4d LT+b/3z0jPaZmrPKZ0vPkc4VnJs5n3d+8kLGhfGLiReHOld0Prq05NKdrrCu3suBl69e8blyqdu9 +/xVl6tnrjldO32dfb3thv2N1h67npZf7H5p6bXvbb3pcLP9luOtjr4Ffef6Xfsv3va6feWO/50b A4sG+u4uvnv/Xtw96X3e/dEHqQ9eP8x6OP1o/WPs46InCk8qnqo/rf3V+Ndmqb307KDXYM+ziGeP hrhDL/+V+a9PwwXPqc8rRrRG6ketR8+M+YzderH0xfDLjJfT44W/Kf6295XRq59+d/u9Z2LJxPBr 0euZP0reqL45+tb2bedk6OTTd2nvpqeK3qu+P/aB/aH7Y/THkensT/hPlZ+NP3d8CfzyeCZtZubf 94Tz+wplbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjI2MTIKZW5kb2JqCjcgMCBvYmoKWyAvSUND QmFzZWQgMjAgMCBSIF0KZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ae2dW5MUR3bH3/tTlF8cELFq6trd5TcWSQ42dhUyM1o/ aPcBhpGQjQAJYdn+9P6d/Oetbt3VPQOSw4aI6aqsrJO3c/nnyZNZPxX/UvxU9NtmVzTN9tCWZVN0 fbOtD8W+PWwPxc+3xb8Wb4pHT95Xxc37otz2bV9W/W7uavP+pmibdlvtimq32+73bctFvd233a7Y 1c22bI3ed6nMquu3u6I9VFuyphz/uslKLEr+Q/kniqwOh4Pd8t9fd1Sy7rqq2Nfdtm1ox82PxR+v eV6WfV1c32zayr3gf65/LB5dX9fbsqiK6++Kb4sHz98/5PpB8bDoige/Piw+a4oHt6/dnf7qCdk2 MdvL2/9wL/l8b9/9yHu8fvvmF/eiXnn7XX7z5tan/vywaDe+PP/eW0vjdeX4AmJ18eA/XRHvbvXs B0drVM7z1w83FKvXnqnuX/JDRZ/oLm/cO1F6q7qL4Ev9vPn+YfH3zfWfii+uGZ3IE0vjk3OE693F 8an7w7btujaOz0bjc3RUrEHX/3a6Lpsxdx6vS+KVqtv2/YBXDtXmGu49wSvvP6hz3w1+3uqO3oV1 YACNLuPJ+PN38JiWkfRGb9zqh763EfP5jEDxgGHh7/OHG3uSJ/lcnoLI+TQVp6TnogkHQ0bv34qY qunf99nyAuAOK9PXTdRu9NJ/6ZFr/cZT9WX7Niifp+p76ZXeUotuZqr3vSrmKYmEcqtenoDx/q54 AEf/vVjDqWdyR72vt3V9QJMMuWPAE5uR/ljLqRM9WpSbVVqt3G27bsCpbYNWG3LquFZotV+sN001 2CDwS68GHuPuFxtdfm/4Mf4onnFxKB48ZiT2xYPPdff0G/1e8UPqdm3H+8ZuotE4LpYVmps+r4v9 sLG/acfvDjvsWFN7czKoSxGZAIuAEXnw2Tp1NcME9Myi6tyZVeyqfRHq8huqzl2z3TXl/hDrkpnZ tlmjOp+aVYOLhj9og4EwbxwUubvZOTSgjqasY31930VYMBSgNKIRFhx42Znc5yghExn3FzFCu8tm vvigtFvZWMSDbHrnK9pqMMLDiQVCpuXNfI8IKfer5x5i6PbF7e0bXQUr/u6tyr19qfRfHC3EftCh wnZ379B6d9jumxoc5wXjN2TGaMd3e1BmHYXUBvej2PGnzooa5zKowx/6HgV64BE2s9RPrR89ei8b 5i25N7svlcPbSZgKuj7tvV5bhA7GUmJBytWbt6LmCeh9T3pYnh45CgFh/PxwY4wqCkIL/ua9r8mf 9ewxP+Q0zqbg91vXbhG8Jg28+kpmXJZ7tZVeUoqbebxfM+RV03bFaOwXFLQTZwe21+DJpbqcmnvs dntmTE2dlExV9RMrPaNkfkVc6VSGEWDz76FLMcQoBv7COvxlPMhj6IdOpsdJ+pVO5ofxin/1gG5n dECpvIHld39tgPNyRJX8aGPYhKfKTzopgC1SVCbcw7XSrcSNAQbo662UHugr/x8cHdVnRJ/aiv5b x3Zqt9ry30PK5FS6ai7KeZ2VAs9/nGlL22/76oDtHQ7tMTZzg7OGzc4EpknddXum6AN119drbO9z hg31pL9vP/hJKv2L8XnzPb3KL2bObBGDyl8GhmFWhlnr9Ob29mUwPC+YFkBdZJ66979AFcCsX4hn /Y8yRLv6vQp5++Gd7Jge+0qpqvA3lfnAHNWq5uaoq5D/mXJc77pt3dXoFN/BvwvbhvulLQeDfSeg ZSaKTjQTxU/NAPGzrXT7h2IBno3fci+Ht/zLhdk2Gx/RMpG8fJTMhzSv+c2T1O4PQNBhzyyK5Mag OVy1RiTP5Jhq1253O/NZ+bokzV/OzM9mNP9if7uujKM06O+dOni7toPP1DN1VW1LQ1OhUXNzn/FU 8w4dvGoCvKvReXU7V5XUq59oGqaq/IbKIc3CBr0C7gVvrDEEX8mu/4pUYGCfgelQ3J+js7n75iqo cey8bLvss2y47K3whZDFFFPoKfwJOYoATeBQkGngWtRUAyEXlD05Rf+FwxpKVx5RoCbksXc3PufJ mlCWGqh6qlzVFljNU6GrUVmUoqexXevU2LlS1uFnr/DoHOHsTy5k1WHbHIKQiZ0m8HVcKZxMiwx0 BKHaOG88vtQIYzAi4mTOG681PhoNjaT4Qvn/4Llsw3iKg8R9ovlrzmYiJJaYZk0sHaolkCvmhCVg DF0rXRSWwG+ohFVL757JThNLhJo84iSqu5KFlq4pdoMxXDCKXlHSFR/BKCacWh5YJmqTTazKw4Sd kvZ2czRbibli0ECNdDM8wJyEa2QXZIHnWlMfOjVqJtIZCtLRB/yl43kLPuGaLuev3iW/nMY8hWfQ IuIQhhRqelclwiakqFx4DAp5HhzcpPAu1K6dpnyi+e7Xj7K0P7tcVyribw9c7Z9htlGCjz/X79UX T3Txt4fusUiCoSCv6qhw0fhGef27vix/p2r4IrcZKtjc5wLOgSW6Hfw1GNQF/tJQWi+t4a8zNWfk r+5wyJ3ig7qMtdQdfLPH8En0zR6rS2Lxjyp3ERWEumSCt84N8bl0lPSbnAHe3YDkITewJX+RpGit dS21qJeVR0yrFFlTpVwhMQFV5ApUhSG762ytV46rVxaYxeOzDv0yByI/Eb+wvLFt+n4/rovZ2hnl OK5VUo5SaphJtIXUpVLUzVJeUoVSjqytxZyoCBQcOVFhj/UjVcN4kSnXuzb8DLlKYGh5jH/grEFK MQPHl3/qttt27b6LXfMbAuykYvb9tjKUlkcTrEHYL/1qAJ2Jzmdskh8FabFZsvO3bB58YJTI8fx7 W/S/Q8cemTDX5bY97Nuim2vMnEHejEIjBgEMiDzVf+VjFBBo8/Ao0S+RWJN8S7BA92iD3HS72yHJ viWrWGTlqtyZVqgyh+B+N9erSPIaFvEw57gkf/fQA9somAIjAim6pvORZ7xv5JH8m2sfpsqz2gsO 8yD0YG+yItQX89sxm1g3mOW2quMozenbT2QTkyDvgC/7ZpdsosKCTq7/TUJ8bl+iP63jNufHyLCU zOIpnqGSedahbsDrRFL1ddXt+mUB7vfbpq5a2N434niHYmGXPF7rYruCnu6q7a6zccQdWuJ7Kbcd zq6yrAo0StOXrYnMiiiuPErosh5Iw4gltxWWVT2wUvAnM61pHTdxlFYs03fH6zhQrmsh8mIdqdmE k47UMSzfj+q43nP0jWbg4AVgQURw4EG0CSmoH4cNE1pUTqULWKKJIn5E+aGP0FOkCCfqWjmNvkOL PFX6EYxJHik/79wSNM1W1jaDlbXHzuyqHP1VC7BdmGr9Va2fOvWqdijPG4eGpXandVcetSzSWadp JzZoyopJYSwPc22SSxBkEYY503qE4I3DhpIujlPwvz14hglhaL7kh/54oruWqS53tRJtUSDd/e0h ehGjc61UC9biId2DqUmA4ERU4T11ACEq2643yONlcRVQYLgvmq5eNkhNaZOSuh/XccHtNjNIGW/f z6qx5EAyJv4lLAAmEEfrqbhekiH5Z1qA5Ec5B4oo51jOXbyM5Jy/wBXpixnJOGmmNi4E+YgxNdmQ 0djRv/ttvyMYuWG23tcuZlkBxGa+nFvNOdaiuSN/hxc0mbueAKzS7N5Je3dP/JvsXdO7pd5MgF00 80nYcuuXVW+/RwLB62/9PKNwS6hKQyqRV/394OcrDCy5fWyRTxtGM/tYJiPhdLNNBvSWqQzG1FQG dE1lcNfWqImZMZ4JRbqnzquIW+8bm+9f2nk+4ku95MOt4Hta+isKkEa99d30ygeNz4R+KcdT95Yn gYGDhKgiXkTvqO9Fekxyba85aJAHyl+qjgil77EOo14beNXGSsg8qZ9UZeI9ITL3rCrSr5+0iq2h ZBw8E+ZbGQv0DPnBZD5pnYLE1MJviBB/WaznrxbI4CKUKPyDjaWFXM/HAqGN9YJ0OFm9LJ47Mz/G VctTl2ZPd9To3tAdmSOlmV0MGMBj/F0/0EYDEv4Hz5bFGNAa+8Ho2A+tMo2DHNkP9kuJc36qk6ZF u1smpmU4A4imxaa61rwGm1FblEbYj+IshbaomCkKMynyV4QLTE2L6b5PPJVqcAulwJJFOXeTSfp7 jRAtTlNosZ+mDDtyPsQDT3Zdlp1p8EEdgUblDNfMeElf/2Cey6qEf4Anxg5gFfvxPOL5xzMOitkY 58M4fiV7L5DzL3qinpqn/dqTU5EuSM441/NjoMAEKqPrKfyAkFrqD69/CCm+JMf3znFjVTTji6yH TAayE/+b/eUhM5s8eJ87XvxGz64udt5O5X/NSNZtBRAnWGc0kmNuG0i9yfOduO28SXHdEiR+QCpH dTRuWxlXZ9bcMNYbi8H+pGCn3iMhO5zmXlIyoIihXDHTuzEegkGMh/mhJdgYdwMDw4u0yzgxPqKB KcnEgCc3xuL8mjrmB9tEFv/MbQhy/EuaL8Q/8tlXd9l9IZ2u3R72tsFx0mcrTfRXiBjtBNwhblSf vybdWG3Fs2ouJBONbjGBdX81L6IT6GK6NqZrxkWvkB5NOt5aWe47zZQG5mxJLqI5q/stkfM2U9rb 3NQMVZopObfgcKZUsxmAzZy/C3OGT7JPG3UkvHMCMFA1AIywj+I/3ZgyUCjUeTz/SQW7J56j7XAV d75hmWSvDC00MTPr4KGTNyg38uF4q+TzBCDljZO3KyauEBi+/wfiPIPVuTDmempLYKGTbnCbMbZl jy2ZDvV8j4yH+ju0mymo3LS6SHTXTcOHLK16/5V7wYVjeutb+L77rviKTEgx6sAs7tMC7iG379Ow uc7T9ak+SPYXZR2Ogu9YHCdQUQbC4a0a/sn4LVerYljxn3iDQfNAWVSGOQIS8d3gKsZU3g/zeep4 zre/pGbmwV6D+e2blinCdFhXml9ndmnzi9uwW4pmc2/bqaPQnhcMcxmLNgTJtDWrOqO2jOFO3Hu+ uFIz4x65J3Dd9ExGqhK/46S/58zfDLien2kiB/MzzdzlOzv9OtvvE+1VxaJea/YKk25rU8FeaTY1 nX6Rv3a5wkLWb+jZI8q6I8o6U+vrPHuATH8UABACJn/OfiFTUTiZbHdE5p4Ly/KvEGnLqB9ACNnR MSTdPkdCUC968v1bzhGwZFEarPqbzjAaEiy/cyTc+US/g0QFvPVvvPMbSpTnhX5UjK7VinzvyHIT nsn9ZvoWsPU5PyCmp67ONsHh5kqPtpngH41AOJv3FpRYyXEXti2yGw7rouC7/cJ0+5p5zqSOYYF2 qS67bVMdWLf1dZlbLB2LtbHApC6z0rqohpbUfpLWkmk90mqRPixRnXKWtBwZsTuw7J3gJRqL0I9a 4n2PgSWqIqeHtAdOD9kdDl4qiUYyJeJ/tN2bzREIkM4M+eeHVM7Bfv2amXYJMLj75bAQJdC9LiHm wOq6BJCX+w0Z/uJIIGpIh3sQSNmxDS7B7LS7sL397iLQMoMeskS7dx77H2etGjZv2WQQ+8mz1qCf PGvFfhqzFp1dd+i6dsfsYsdyTLdDK+MpYI+yW2epcxZzSz3Ha5VGjwWeA6OXnIwrLZoPfKQfUSH0 Yuq8eRHb79kGX+05ssaX6PnlLHGvOF9i1+F3iB3RILCHHrKhI86U/KraGULex2oNOmJNTNKJ5X1Y z1mLtCkVFqTLYF7Mf/Bccwcart0T9irxnB1i/B0sBM13bNWzuas3QTynYz9LumuJbEcYX5s65myr C4NWtAu5fIaQ0Zhog9yC0JwNUnaTZ95Shj9yg7qgGzHBeq7rDy+cuQxHCsgm6m/YXqnVI39CkN59 9+FFbklleH0QnvZKvoWlTzFzQ0xq2QMIQ59fYi+iUNtGOIuKuzeZZmNDdgDHwur42Jwxr79cpn2J d5Np3w/3J9LTflgZZgjrIY5fwzL8GPfCe2ETgp4ZdiIs229XwETBo8wf+QsLsv6PO4Br9CJ/YaiY /oMjCdshD3pL+eE9ikI1xPwUDh1sHSlATkOS7hqmJl1vqYLIA9RUOvOJeuNcaySpMLJCWi+oQiKq AkRUJPIUXX9NNAMlq175DhG9MCJHMVcqTVTVcJVmKRvfkLx837tfOvl+skL09hW7dogBae/Ac1H0 Gs4ImrWnZ5qRZE9ZruLAj6E9XWNGLpc9X+LdZC90xP0J36UdkZnEU2qY0yy2ezYDcnSeev18G9Ue dn6CJasC28PvOrDOWxgnRyTC2fFvsDCDE/D8bPFrWSxkFsP/1s6asY2c4Y0rPRWx529e+umkP4nG pAHBRRpM5awRhxJXUN8hDsMuOAtWRXGocfPPWaKLpaE2+Yqxp7JEH1cafIl3kwbfD/cnDJf2QyYM oMXGKfrO/d27v8KKOB94arAJW4F94gbYBAPB03JVoJl1jZWAv+R1MvzEC1gJXpDeZqcKWVHrZEJL 8xeBIAXtzXUkR36lCP6ThxQKJqdSMFJshRbSRRAwWL4wvabCVLAy6TU9BaBBTgW7DtiskQSi1Gzf yaFoh509kIQx6LFS8jl8lATEqrO4twjK2COKVifkIJzpedYsi8DFvh1ZhclKy7hyd0JkvsS7yUHo hSgIrhfO1AZpilXZ0Q+jXlijDY5slv6r4/M/O/bUjvmvco4VW+WcjHZGMMSTOQPmKbAn3BsXEeHq x+6tICPGnnl+iZNEy94NEhTkxWRKddBbYnOTkSB3qvMKEQ2x3SMRhZCIhiKNtFJEOm+2JO6dC43S td4a0aTSV1mzRS3vUKVYkzZJWVBuprROWvA4/S5xcNXRi2RrkWvDrn+m3rbgQw/bD8NgP7Zmh8oa PqMvGHyGXSjb8imJDrDc4HL7oVPsEXjXfsyLxI/tOT7ZHI7jdfau9c25y7zQVh1sQTmqoODiuFQL NUR5mv984OL4qFoolHgnLRT6ISqh0A+X6qFQq0E/3FEPPXXC7Izcxh8fJjMmofLWTzeSISkTyZCu c3WkPBh2pFC0JaP6K1UjakqBjaPE5zIq6QdPMvkSfRbtJRf8je+eqaCyMMF571EN7+4tyGba13Ob yGYsn7w767G3Dxh+qvOu0K02bUU3IbnW+dxFL4979CYu3NjtMwk+/ZThbu1Wm29gi1sX3D1u3wBs pNDf+U3sAWw0FpB0OAo2XEyKuXSX40bjFLThnL++HJnZiZhTufFa/8VT0FDi3cQ89EKU8zuBDYKe tzsMyn0KuYlRwMscH47A5dZetl1CJhEkkAshkwg+zkyp3kr5Q9jSMoIwZL0OQWxgeNE5AvITRInQ KGqPpBPCqUHSLXMIwpq3DkGYHjuGIELzVFaGIHjPDgNhBqGKCbZIt6qv1ZvqZVUm9iMviyD6gAaq x5XHq2oenzTqAaM0HHNtsV0ZS607gOCv4FMY5/FXUi+q6j/qBw+bKSCaQmWpGvlCivUZjaPpQFHS eYFrRizmoUe5pnEx5yqUYuEMZdMXoUGXyG1UXlwQCjpFKWda56S+WONq037VT+AzaHyJl3RDXJFq fD9E7XVnlHJpP2TCA883Tgd17m/uM3jh4L8kKIo8+XV9pgZxwaozGmQo82L4p0M3gbgePSLh/BGw DUtHWARR1VFSK72qp9IBECVP1mYIRoVhyhAUD/WVCgNSIiiZSgpDPnUJIZloBH/VV3mPTSHZPzq9 L6JfOnHVEWqzMAyaR7Q8T9eIN8uZJpGI9x34Oop3s2eFeYJNLhZuItcmy81roPfl2MSXeDfhDr0Q pftu2ISVLk7WyQ3JukMIlxwhJ00YBRLfUrHpRiX73lhYGkzAlemywjaeibPFnZJICYeOOWLijKjJ Ek/lVdz/+AgCkkuSo12csIrOSJaQ6yOywVNK4W+QxrTvy8+9VC1IkykvQERVRSkWkRA5Swna7QIE hMhehWZzTSQruiifn6lEdWVekwWFZr0cFJrhz9gorlXhWQR0kj8ixGELHsdmhGAec8PMxwnHcEzP HyFOmOJtrmV9bluJir+iz+lwAJAlwwJ2ZzjIKoxutNuCjrVfesFmX7SJv57QIO2X/5IrpqCnjJx/ SB/a3Xe/rNGONdqxq9lt2AybujBzkwBY3865iRv7/oZtgxkv3V+sHzmdtB2cU004zsfVj77Eu+lH 3w9RPd4Z/FzaD0saEnb7PCmU4AvRBE3yKPEhPM14UHpI0iWx1Ms5jNBr0n+5yggayGDHsTkYHJ8r VSs/zLgiOaotDaHa/dGJRmqH02QmQQ6OPFGtpUzyYwhUUyk9EcpVmQqYanClWGFBAQaldHrOZNDj ULFhqBkO5EDKxl6fRSmr7PtqOQYJ7HWxJ5Q4su6Trsc0vsS7iVnoiPuTs7mOWKNvjsjZXxAhD+E3 3taJxSRt4l5vlHUz5c/HjtEjGoDF+UQG8iTrJg6XdI4+fkBOpStnFG0E6WlkW7evIezTciHvfs9W 3fJVFI4pK8Jw+an+gG1zdOQ2I3yWjMO8s7DmSBW+r4c0zHX3xDU3lgtbB5SEn1YttHMIbqzX9LIG IaoWekopepprBPWdcIau7a1wxm8OU64G4MY0nnpceURfoxXfolz0iB2t+CQOiAu4nRuQhkXdXd/W 454bDMi4vxb1SIn/Zs5aX6xGWB8dflXiYwfPNr7Eu6kR3w/3p0Xm+mGVFpH851ZVPCO7qXRZWHHp dXB+4QhTTvGbuDrnWHEdsgC/JQ53EWi8K65mko+8SF+EsoyHyc9bPOWvcoqa6CTVZwg8O/s9VzGL HM3XMrCMbHsIQykVc/xbm/lRvAsqprNveNaomCGHrJ/hHVExziWjbpJyGaoY32V0hobkmIoZDkA+ YHpLDBGVBTSXVYyptiMqxlyjK1RMizTs+TDruOcGKibX+XP7UIK7pGYPKto+ixsJUOXSGYGtpE1C R9bI1sUek1DinXRM7Ih7UzKhWgPv+5qOGISkSiEALGAOOC6bGLMXZ/qNXOKJAARVW4xKP84cnz3c hNnivLRWnPHQNBwKOR3cdSsKqw5CTYBnURtVfJvusCd8MNRk1aCfBDwVQbrsSejGZP9fG2UMx0ak KcPhpdseuiYx3KoBwTAFhrMtXlEb7e1Y2TXuiWN7d5cPTaQcfUG6Ppjay3dmzgGhsRI9Ft+28A27 uIsolHgKoKOs3ew1dI+qzIY6uoZDZPnctovrC0MxPFJodjPfoiIPJxYZaev1tAfP24DsMLy4bBQy n1aTlw1RDL4LHeb5ab0kJrhjYCmDO0RlChYpUE62XMgA0HSK0aUi+ETrqGKnNGtk9AXNyulZlVPY E5acCzyZYcnn/vg/ACFORVAPf2kVf/E+4hpC1rh+xiQX+HH70wfloCdwzd7atJan4fg/LEx8Q9dZ THn6ZpzIhwjxYUx5jGuxUt+ASfmZxLUYKdXj7Yq4Fn0dfL7/Gs5Lruzrr2cNS6Z/PMNlEuYQb3bQ lwlQdm7XrJDlM7IY++JOqPTHggW5mQpZIh/V4I5J5CwomxRD290/hHfHWSIcnQEsOLBWbqpi8ftq SQ9iTlliyRZ2OBtmzfz+T+BY8zsymzklOJjWrjxwpod9V9YKO9dCzA/8nnOO+5YDxEZkbQlgxS77 B2xTTkZovgg+f3uoek6ZHBVxXOTrU2TBUBUIGbBxYYdEm8ARPiXfMsdpyYnZbhe1M9CJo9wnli9k 2MCExzg2mYWQe2IX7ollk12YsOyc6R67WDDdwS5ofvaF03RPNEP26+8hBziUiXS0HBbWolk1B8aY DnV/ZUp4/xT/c2YgO3btRPXhcDtGnT0fcbxWdc2s0DyUX0vmHrmwmus/0wI29CnNVpLQ51RHETeI pjQ8cso1aph0qW3yoH3R7lBkXsFTnBdQMlMACdRyzMoLXNNeMjHF5a8KEFGREDmloA1cHlPvdLAp CB25hK3lWoRULxXjy9QDva0yRY+YNcpXmc+gR42/XDFDbjCl7d6mKwNeOeGyoJgAupJNCBLGkSKo 2nSewacTsWgUOP+EL21Nl+7uScCSTWBxkJPFs6hrO5BpfMzcjIB9qWGEm06JBHFpjFHPAPmyzjUJ 8diXecVtJ5LudpzRM6J/kW0Aal9iYw+cH9BXKOdQhwXkPwhqtR31gQlPtJFd9CWH0DITTuO1+eP1 8VOjTZYi/Wm7QBEeO1jYbjQzuOr4OAVTDw4z0Flwmgc6XEQ79xXGlHr4bC1WPp0rdz+S4pl/nS3y mU+bouNnTiSTM+RS46J1QQZPTWNjPbAbplrZ/GZgu2Dfj6XeKNX/IDz2EKVqWf1PgSk6JUz2xRw4 AZQyrOZxlHLaJWIW3TZXjsjS+jmDOzMx+b/qoG3YNlYSFDHuueMDkknmwCVCOFg5OxcwwQp7+/wR kGM9leR5zVygZXNygufr4cmc3kdp6jM4SycGLSjuaBh8ZeaU5tj05EptgWy0B0OysgcnfbLMFc5Q m/NVODQEtGGTOBlJ3ZzcwgvTlaFhqHLLEDqX8T3jyzDJYgxHejVfzljCxGEDiwHTtjYxYf2/6/m0 2sBdFXljofob4EHLKTF0VSDD0ZGdO4Q0MzxHa2P8bl3OWQlYpkAnHjZ1j9OkIJ/rTFPIfdo2TccY UfIHaC5Lc7JZEzZb+fHBL0Ds4GxgOCYKo8Q1wJy/TAD4qxRdo7LI81hZtRMbcI8RA9zzACDIC1q6 yMlh27RmCbZfY9/swMXWljTOYdvT9s2JgzHHWO39PsybN/vLoR98XLre8/2b0ICkUOZGGvs8UChM iP1ODqa2DBMzNP7qWgM0Hem4MDX+fi2zNV7W2Oes8Qwww7zvSzf7WzNxI8SxrQ5g2uGgrNZQaeIW RL6u622/r+2EuU8s9HHi1rB29kkmbjh6AKb3M3E7paRZtfE96kB0uE4zO1+Zc2d2C2SjAR+SlQGf TE7HYHSVsy/O14ZFHOe9zCrP1zwZ3XPIZmCQnl2GdQOjC5/t3TTtbkY3kuHgVc4Ni8O81guef6cm TLDiUpOXhamxNC+GnOzJp+gzT2zlDPJd/ubiGls5HJozZjhaScI+xsgO82ihC7VnhqmdnHIsRH2O UeQH3UqSHiw5FfODHMxAbq7/dGwJBL3GEhKhNLVvxxxoTiLh9/auMJAcT442GVFd6J0xKP+/HANI DAYLHlixI+Mx7q98EpOsWJDFuvbLSEHPRmlZ9vBPpORcYfwWn22F+6HcvNQHnp9cmTJY1kbF1ZOR WeCoUiF2V00+N4Bn0SxCbSeCMxdq7NshBfc1LeV+36Poi9fF1SQAZJESb9p7xEcbHWJW/Y2IHK8v kwTivsuuPmxqPoDaMMX4MaQwe1fKa3OE2WwEt5KL6ibBPp3gXHshiycTXtq8Ll6hzr6l84qXK/rE JNac1dYFdJKakm4hx+GU7qlrKLf4emJme5oy032vXAfa6FWm/joQNN+htU8YcaBN3W5+nCTxUse6 FB8jICJPuUiwOStbZXHn0XJgWZbCeiMHvG4gHnPxZQlihGpHKrxJND2xQ3y7JBJn50Vjx3inSvkU aLW4EHe2ldb2qbhcr0ljEtg3nFwQ0lqsyd7VK1DPUlQHRyvkalVX6pXyhRYl6r7RqQq+r27cSNbF ryuHke9Sms6sS1gpXb/mmvko38nZuGd8GdL0NV1GOB/P3B1Q48ZfcwIv9VU631m2FyMF0HFt7+zr jbu6gZD56SwVVrCzPo2ouzdB48pT8HfQtnfsCQLo3mkbq5dqkyhYK0TbrqwnTDBPydQmdXPDmaww 0I95z58xGlAKDOGHZ8rMVD8x10nO3TSBG3LO9dXMGSQmCZRYRZqyQ4Tgwr5hPmFn+fEdABeQU9Xt wZ1YnfvjovgZMCxZupFDP1wniuzV3DX0kr4/P3fOMq5+JFkbG//CZEsnQDOz1sXPQAtd3cQrsIWS gJLuvGiOZnG/V/F9YIt/y74F4h6aE9pdsEth6Hde0QAP9VMD+CAnfhu6qPToo9lap9iXq/8hOdRW ds9p6nkvhVazxq8GPfLdAGC3hI3tMx8+iVl9Frfw6DojPvknTyQmmEffUQvlff2XvOPMkWsaZlci nxwdjyLDkFiMZlnBQnyDlA80IKqZJ3fFKW2ec0wj7olnIwBTnANnKRgTHW68ph8PNHBJRxayjWVg VAUM6Rr/DLA0TvmZtNNWYdfIBwshbpx9wElztgdlWh14gYXDQX3GQNSAosoFFFMrejKW6FCAgw4g qQOL6Hx1A3NjXce+4Hi63bdAWgdUsLWPnryvivsHKnZ4630ClZbTLAZAxdVbn7w9ArDe32xc++2E /QhYximvCyadtik2hyzYX87ld8t0HrNMKF2AWVoUboAhoIr8Fr1sR3w6UGfgzG4FYRzA4TZ7l6cZ ZtGsNmAWzrZkNeWAEckgg0/LdX/IlwESwmJ2/X6TpSAjiEsGWkqqaAd+GqUAWko+rrAHcSS7wuFJ WOB2k2rgU6CVbFRIMzsSQEtISzbRU8+sZKiD0Qqghc8gUFOjFFPUmoy2b3FmJUMfXAZa2rpnEAVa uKb0AFoMTHA+g4MpNqoJtCAY9IGe8DEK946BmQ6/m6GdRKEzXOfAkV0F0GLXOWixe0ETTyHcVRWg zgMYyrR3HLTxtUmgxWoaAFFPOYugZRgplzraTn0sHcOltNPDsWlC5yeGCCk5aglpx1gXWn6wE1Oq BjnrhnrmTJLSxriFA/5YKR7ilqZqduNp4mrYUhF8Zt94+F8LW3wDTgOLi2DLauq/d9gC45wCLSw/ p2+sz/tBE2gp+YyufdDpdwJahtVZgCoOOm3sGxcheiZ+meY4MuHFGWRyZGl8lQvF+s7Un1nXjk/m dajty1wojlLuQtkcQybHvawjHEKdRiko7VXIZPzeJd6UAboYIhPIXYpMht4UC+zcdTsamuECpdHU DD34tKTMS9x5fWkIw2OOumcUge+5Q6UmtArQ4UiFbHy7CB+ZwWDvrCHuF2CHgMYqhJTcnxLSoBWh SUyLVq4O1LMUV4XcnRJq6kgFbBLaE4nbrk7rG4oLM/jQW5dhk46DsgM2seuETXDdce8RCN/oTtgE 0YjYZIcDIzhU+K7PyKHCF+YcNtkQ5ynniDlU7DrHJnYv1BEo+DvnHNG1lSlsQr18bRI2sZoKm9hV hk2OSlaCijX+0dKcDplH5bwBycBiGKIcnYS0VeybgHWsQ4ZPYl0zfJKljfCJcWN3MHdK5le5Cz6x 49WBOx8XneBM8V/sui9niqo9wSSdOyyeD77dxZWylvZRRBJ9H4+8QykmdIselZgluEli1uBR6UI/ TpwvRzwqpq8qVigzh8q+ZQNLO8a0J0JpIzap2fGxw0GeYxOLDptDBQiiQwVFcmCccqjY6X4D98YC VAoOlVF1BrWYrB9lIWpnYpOPt7xDVCoQJWGTQ2lelPOXdw7Yl7i8oxsRWe01SeszfHSBeGUqNUlC 5/mFHj4Wz0ZjKpoWevxrrzczr1221LNhqcd3T1i9sVuMh5Z6QjvjUk94ar/+Xe82cf6v4VJPjZcF r5z53jNk4NMy7R7zBSiyqTmImB2JcrW59R/bu+Y2lOXanZ0RnCntOimCmB1n4ld82S2gE8wpMCBb 6/H3mdPEp+S4RO8kDOKpZlYwlJ05TGIdc2sTWhJhSWhtsoIhxRnj73BAnrfOs2v30WXCNaOXHB52 L1gCEMpgicVqB5eJfRgqwBJ018hlssfRIZeJXQWXiV3nsMTuBT48hXCHOye4TKxMwRLYy9cmwRKr qWCJXWWwZOyKXHCZ1GzGa+2TcDksCUxzbEBgNs+SESfGlAyWxLT7YNxQ17xeKc3BEscebrnH9v2U 5r0fw5LcZ2/R12vdJvWe6bQD+j8W7NZIiyVmo/T10dz8rlrtcR+u0WJGMLDh99zVHh9ueGS1JzRg gqzmVnt8rMn61Z4V1MeWD/sbWhtxxmi1x50qPLvas7EdN8Oui0QCNokJfrUnlTfAJq7rTNO41R5j nM7iDifgZMw5q8EJGzJYQ86/Ju22ZQ1ggWehleDE4ji1r2+62jNa7g6BHHG1p/bVER+gGMry6GrP GCyx2pPWeRaAEMEO5f6AN3nY9LkWR6HJA2mWyLKvl4iJMVlrAvuJF/BeKoDNTrBE7gjibNwtRyQx ZeSbAF3tHAJMnPnMgE9B9zor3Fu8rsuDjSTrAR8/SxR22BpH8KQU1vX2ZiWYYcVcrBKzpGMaMCZx iieqMSONqXRrJZ25DlzxIQVSxGbSmzav9bmgRV121QHtH9L4uiDnMgGqrc9FPaWoCpDKk1xNIZXS Qnsicd/iWAHdY2c2tmB+eoHv0de3P9/cvvvlw/PXxc8/jDgT6Z2NMXp09QpI9Io1xHV4+MjKYWb2 VvvnmpIuNaBmsRcYRu7RCIA+d282n+4g5iLk4F7AjgM+bOzjvX0dzOEF/5xVVkOJeg49IhWMTEbP BVWpPKi7O3BAz65Yq4+7BwsQFe0K8ilMDiko0dM9+V159r49t3v7sff9va9vRs+1UOWF9gZMEQG7 W6EmNmleRI1Xe5RnEHyUjO1tZKhLWwRGRGt9ttv/yHDC1tIyD7bbbfFt9fckpTGWzcKxGE5xjKne OfYxnWaIyrWXI1wGcxjmBHEOs46S868emFw4PrDVMd2MQtQg5s9wIGIjO8PBPCO9qSu+qc5Z6eb8 mSS9tt0uhsBYqLOYixonJ9DKxWPF90gakzpzzdf8Eg3fbIcPDtRG7cluYUs8vPbUtZZbZtQxsz1N mZ1X1+KJInRKExVmQMbPg8lLSDMNGJyfPi1zRDE9YwnRpiDBZUpN3H7UfPLCsZkcBLRz2jTks9ih puuhFahbkNgODZ3qFVLyCUxIy6cwPi2bsnjqaT3Xju50dcgnMaGuOTb1LYIWI2yBcDY/dL2TMHNI MTFbO4lxY+nWY/fOoehIgr+sV9Ikxu41idmjz5Jvdb+3iYKeHJoDg+mvOTp0GKx2wCMq2nZlExJj U7vOJzF2r0kMMZZuGuTvnJ/UT28oM0xiQm3SJMZqKtp2FRRODFZbkq40z7SDDneO6bI0zzyXD0hi njBI98HAoa55vXwaQzH2rYbNMONJjDvg6ZKYtbDXe+Kn/F8zi7F4PtssMfYP388s5jT1324Ww0dV hhOeY7MYOKe3DZzDWcye4PYsZm1w4NG8QU8uVjMbpQsCx6CbPV9E3J9iEqPaeC4YzCvGA5Qv/i60 EdCNvZOhtu2q4q3VVNfB1IhkPp7bFr+hM+1hSbmv0Mho3nOj8ntiVhx0sqh83VzqtmWV3U6eyLy2 PgVlKqcta3ruIFMSQnR+zOJ9toQ4i8yZqMfBQfloe8IFaBKOTQdkdItNQrdjmEMbvcs2PR1kziLd WE9OMWVERbCBaxDoFpJyk+FzJYDDpsmeb/9GyEMz6QH3FeuYRngA0zkDiEYqQB6LReqI3EyQx+KO DqjFYLU2tn/SpeSQJ6TlkCekJdsZqIcUaPk65JAn1DW3ZKFFCfL4RgfEQ+C7+uocwGPD6IEI+/Cz awdeFJ0PMLGPQLpAtwPHyCTAg1BEwNN7T69B+d6Qbhadv2Fi5GZvzOzsKgAeu84Bj0P0LoQtUBDI Mdr2jkXkW5kB8ITaJMBjNfVgiqsJ4EG5TqYTFlkZhoN3bWiN37IkzzlrRiNzosfRCHxjew4cM98D 5/pqDqqkmk+RDlxoB6GNgc54QTBOOUyTH3N2shi9t8NsxjABnDM2EPghV3lr3S7roQX+eLH58JFr wASozeEcP3k+w1u7mnr0nq3w1t5TbL7HOe40VRfGP8A5zimUvLU1cys7aj/DOXeLza/RfnuAkxhn Hud4DlqJcyw4fslZeyo0f1obVumWHZ1y2zNUs8c8/sv/AEI/n+QKZW5kc3RyZWFtCmVuZG9iagoy NCAwIG9iagoxMTc1NwplbmRvYmoKMjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAg UiAvUmVzb3VyY2VzIDI1IDAgUiAvQ29udGVudHMgMjMgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3 OTJdID4+CmVuZG9iagoyNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JT cGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDMuMSAxMSAwIFIKL1RUNS4wIDI3IDAg UiAvVFQyLjAgOSAwIFIgL1RUMS4wIDggMCBSIC9UVDQuMCAxMiAwIFIgPj4gL1NoYWRpbmcgPDwg L1NoMQoyNiAwIFIgPj4gPj4KZW5kb2JqCjI2IDAgb2JqCjw8IC9Db2xvclNwYWNlIDcgMCBSIC9T aGFkaW5nVHlwZSAyIC9Db29yZHMgWyAyOTY2IDI3MTIgMjk2NiAyNzQyIF0gL0RvbWFpbgpbIDAg MSBdIC9FeHRlbmQgWyBmYWxzZSBmYWxzZSBdIC9GdW5jdGlvbiAyOCAwIFIgPj4KZW5kb2JqCjI4 IDAgb2JqCjw8IC9MZW5ndGggMjkgMCBSIC9GdW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4 IC9TaXplIFsgMTM2NSBdIC9Eb21haW4KWyAwIDEgXSAvUmFuZ2UgWyAwLjMyOTQxMTggMC42NzA1 ODgzIDAuNzkyMTU2OSAwLjkzMzMzMzMgMC44NTQ5MDIgMC45MDk4MDM5Cl0gL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBZcFT2BAGAEDRbNu1tGwbW8aWbdvGn7lsa9m2bdu27Zd6uN89 58ePX77LN/pKX+QzfaKP8oHe0zt5S2/otbyil/RCntMzeipP6LE8oof0QO7TPbord+g23ZKbdIOu yzW6SlfkMl2ii3KBztM5OUtn5DSdopNygo7TMTlKR+iwHKKDdED20z7aK3toN+2SnbRDttM22ipb aDNtko20gdbLOlpLa2Q1raKVsoKW0zJZSktosSyihbKA5tP/Mo/m0hyZTbNopsyg6TRNptIUmiyT aCJNkPE0TsbSGBoto2gkjZD/aDgNk6E0hAbLIBpIA6Q/9aO+0ocCqHdAQG/qRT2lB3WnbtKVulBn 6UQdqYO0p3bUVtpQa2olLakFNZdm1FSaUGNqJA2pAdWXelSX6khtqkU1pQZVp2pSlapQZalEFaUC lady8i/9Q2WlDJWmUlKSSlBxKUZFqYj8TX9RYSlEBamA5Kd8kpfyUG7JRTkph2SnbJRVslBmyiQZ KQOll3SUltJIakolKSkF/SnJKRkllSSUmP6QRJSQEkh8ikdxJQ7FplgSk2JQdIlGUSUKRaZIEpEi UHgJR2EpjISmUBRSQlBwCiZBKQgFlkC//QSUfffrCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoK NDY3CmVuZG9iagozMSAwIG9iago8PCAvTGVuZ3RoIDMyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHVnN+THMdtx9/nr5i83T1wOT97ZvzmUE6VXHEiiZfKg8oP9kkqOnWULZJO Uvnr/QHQ6O7Z2R+zRzKSxNLuDLYHje5GA18APfdT/XX9U70c+lD3/WEemqavx6U/dHM9DfNhrt99 X/9n/WP98tX7tn58XzeHZViadgmnrqr3j/XQD4c21G0Ih2kaBi66wzSMoQ5df2gG4feD9jnOh25c unrqukNoeGQMhy50Q4s0A3I0XbXpu+31P/oO8GyWmau56ZeOx+n7J27beZ6bWv/Fazqau3Fs6Wk4 9E0zV49v639+oG3TDvUDIrfaPn49vK1fPjx0h6Zu64cf6m/ruz/86b4e67t39/Uf64ff1797QH46 Cs00D33VHPp57vqxh7YgyRiW87JM3aGfpobJjbLUJstKhOpIhLv6vn74L+v39BCn4TCGjo6P2DLE Zumqa2O865q2u9bHwpSEbhlSH3EaV6LXF0Rnys4vn6iOLVSgg+6wTKhG2x/QRVE1W1XVnTTzkE/N fMUcD21ULGOzHEI/dms2O9S+KtReNURkbA9hbAutbZj5gLomtW2zirftSGs2QdLxvm0P8zKFSzpu enVmdGd0vG3DYWiW6XhxRMfbZY+Sf/Mv93VX371C1+b6briv+/oOneBzvq/S9Z+V8hdt8/6+HmrR Tdrb9d/1V2vz9r5+AT9r+uG+nuo7Pufq7ntt9J1+2sNsLzpI7GhpFPv1q3s2omy+UN/9VVv+TT// qmLZU1uer/Up6dG5/ahPWb/G33gKpZJh0G8xCXmrn95yfRPQynZMM247udq9HeKSleo+T4cQpqSo Yv/MVt5gn29Q1Mw/2eK2OUwNEmxs8cYPeD+nZyfb3Jbd2ITh+TZ3UR1rG1VHzHBzX/HZnjTGt20a me55mjHGayEvL2FhKM3PnHU82WLewh9NdGN/0dSJxWQEyI7tmbArzTzMNR5u6IYbTV218vC+ssnU uVLsM3Xe+rqp845Oq1A2aXH2oqs0k3bVp+G3v/mtGoEvvlQr8B9mEsyomCH5bzUJ36shMWNgv37x oLbwX/Xn9Bj2AU7X7EK7NIduAUXdpFQv8qKfmQ2UaWkWPPxal/Yb+C9sbGYw15a6WllqLKbZza1V PWepzbbSwVTd/U4n/X917sxSGx+bYPMH0TnYD/ZwaaqfdMHq+wpR3CRfn/ke2DBNQDqfoluxlUAC t4RhWcBOp1BpaQkrRcQXYM15JJgtZCM2d4VKwYfXIBvq/VtmFw/LvGadVIskluG0Fk1YCRwMUxQ7 PTVFJYarQMA74CfxwtjN+MI1W4Ofm7Fs8C0WLOv/RaN3fj7nALKemyzDLnh6gzFnlcZekN96vS47 C7ZEYcz3wV9RvV7hb3foMhowWHl1dmQeFuKsxGXtEbLP/whMkTbH1iNk/gn8ptYbj1BuJQ0u93qE 9RKImg39Rs1KPY6R3JcYpxfY8fVXDcJ9ociili90Qr5qvIe0/fCBHfYCCIrp4hN0K79iQOXrAyZM vrGqLwQMf3lf5c14eg+2M/Ft3wPV15vljCJVGoXe7XIQzdhvtvYZB3G8B7EnFxzEGspvHITEB+Zd zjkIfr02L92IFQkSwmxWt91nEL9ioVgLfDtm0YyjXb9XD89SQQfu8ymuqr57jdPhC6Eh4YbSz0Yx duUD37DMbXVHqIQmvLo+pr5nrdsWMHBhrY+XorS3K5cE2muvgvPokp4TRCaXFGZSJmvQ3o179te/ P2pMaL7cNKJTIABoR0ew8hZJXtMFMNQ0LN1UuySn/NSlebOhkHRizgbBxX0LfDo2ppdzAGLKLgJj Ya4LsjWDZqyFfzaD3npjBjcdeW7ptnAmAWaftCLm2pkDwOSh2FvAXK0CfEN19mlAmp1CdG67ybaW Lf4Pur/KNoA6dty/WUfAaW6sqV2XWJD9irYYa6OzLaGYdgmQrGJCoPzVsKP8Wt/9n2pjeoq+jG4C 2VMm7g673U3BEKFP7ymdzD5nr93upvkQOnDFEdtfjd0WGzf3pLR8AIXa/VLttrhzFv6aGRq6ma04 PN8MpRxPtkONJCNTiifbifNwbGMeHCV5gL7LDin/dqT3ephbMuwxIX+W+2n0kn3EJMaPBY4J7FGl GvQrWmYSZJgTiSD+KcPgyzbXEeG3PNiyPk31nZUeXr2WnMZ5AF2/fnUU87ygvdYCdOTTTJVBs1Bd P5BWptqx8Pm27jpcA7et3D7Vr7U24Y9KOHWKD4Ou5EEemw+jJH9hFPp8a4xy0eSS5O8fq8BuJ4DS XOISiDrf1hvSk8SmMa09iiuDQPpn5kqy/vrY05bTU/2GJOK3TGX93Y4ZkuXsAoOq+mbMQ4NQJ8IT LTqdszh4CCQMj1qUj1QihUytrGorQdwICqZmYtlPLf+8PUFjiAurA1xmjFYmqqQ6xbRLUp3iTxdG rVcZhdUIfUAnC1qDnupkpecaZqtvejg576Y/tCMVgiyVU6gOjSTxZ7bs5LQnaP1hWHoJNu3JamAz TipV5E6bRFEJhJNTXE7h5LQ4Gjg5by+MZQmc8qiL2tX/s2NFxRz3oi9MEXqVLp+4nKXAIuCI/5sF /e2AS1T34l2PwvEf06m/UuXAAzYtq2n3JB15nF3gjIZObuhLLh7rrg+DXqIgFGBgbb/IFqTqZk9X dhd561P82nvf8qjcu2SJkQitHciFTMjr6usrNgK9y/NNcam1rVbQov48FevpWrZvXbIGub6e0OFC O5171mrXjVKHo6xMfCFrlP8p1ghES9ii7Ch0cpKKaEspdmBn1rDsW/ZaAWglTEibUUx9s1B0VRvu 15mhlLHgZ5Z+Mksfvx7eVieqpdhMYimJkfXiHbDLrh7TFRjMSPhhbQQy1O/X4DX7BYAWn3rjVxJu ayug3dp7X5c/4pIsP2M6LCPz00TYxowyKUcOa9/kXGdeVpR9zARENpyXcRKIloRQ3fXHv6SmsYkC GJ2K9MtvIpNEmJ2b9/fVH8ppE1csWh0I9dCagaL/jNLM1AzFFx2wiFThj7XmStEjao2YRrSm4aCA qY2YDk1rYsuFhX1FpDAU1fYvLE4HxxPL2zWIn+SKXROOA94YqtUekxJUp/HKgImb5yBZhY04HAkg zbqS5xi/kxb5vegjXaKNqTMFCecRm09ZRDGVuF7FAoZiLsTmt6KYgTMajj8ikAHo7AcyorYGZMCE kdHQY//9dgNkzgsvaWc9OYKpmLBYkmnG4WxITzW1jHbQuhsHOUTXIJGZ5kSFVLLsSWzdiSdvxjLD wNGICkyQRieEOhGwqCg8hDzgoVdw44/QYvXIJSzTsMk70usllnFa6QcircAyuL9umOzsDQ5N8rfs w5GwqvADgeTuOLCNhFdEQWEmwTu2bUYzQTSAB5MrckKBZZwkDiXCDSe5h6mcc/Y5qf/CjyY5S9/k o3Hm1eSzkLGMU27BMoK7I76YFIo4oBmABwJNmJkCjESagZVeTkiAggTnsG3qRzhxOTYR5ERQg80D 1EwCgSI6GnuDPYZs0l2EN36PWiRo4jSDLomjApnUnzwvMAhRIsYZTEQAUcJKcQQRSMU7BTvlGSQc 6KmTMGnhqsCOG2dVTF/erGCXFg6zGVXaFy4vZQnivdUJJc+qKknQlZIj1wkld1kLuZL8G7ADMseW MLJjsHMc1+4FO2EZD43GEHpILKMFnNZxxhHvIGfDzIXfhnZAOZU996lQjgu+QSLjQiDezuQcPgLm 7Od+EeckaPIyor1EGH0eHQqlX9KFo5jU1AHP6HM5ORNvegHwiOZwEu8E4jlWnb2IJ8yiOtTeCsQj 5xROIYxnIJ7qCPEcxX6es0iI50iclRTHmiypeS9UflSG5jw8uDlDM5LvOMY2kbI3T1PAGwJbCWVj nkbKAnJ7I7xJSRli16Unh1bkaZyECbQ8DZk+te0pS5Na5CxNIj07SyNHPwWlx7RN3TsBp2JZmjzW mKUpWyj2iYQLyCYAjzo5yVggm0QrjL7TMrIJE9MwiaNNiIXMYTdLYFDQwhgzWCWNDTq1S4FsAtO+ kN/J0MYpJbZxWgluIi3H9SEY9+Qk6+AylOjGZS2dURxRztT4qOEVc0WJcgu6EW1VdDP20dMf3xfo JrUxFDMU6IaNU8WUTSD0T7iIReAAr2V8HNwEz7Nox+kughu/L8GN0wy+OEPFMqm3iG0QxLHNGAV0 bFMl+RXbpLubsU0dONQyt8NQvS2W8sKy0Soh3qjUm2Vj+rKKueqfUPNCWc+qufDKqm+yMisZh0X5 odlhT5FGEzlB9q8UC0ps03bDvDkZvxvcsNPJ7nrS/lcEbqLgnwnc7Ob+c4Kb4RZwg3VrO2zsJp3z bHATSCbKyfdfCLg5IY6ec78IcyJgt7Iy6SVgInVrMmpQGv0EB3HN5zrXM3Iiou0oIAXSAlSV1A9O YACpe0aSOH5yQstE8B5JIwcZxpmAnWPdgM2BoDxTeN2F4E/NQ2pFiZl8pFiaRMK/LyGWJow35kuS JiOOPQpgFGHFyw/yWgodxlbwmiTLMlPFdBqvqHAEiXoHby5E7pmiIgirkiSSiliZ5uPJzG1iCgmU AKc3eozierrs5Vffv3v8/m8f/v6np/rdX47gLcHSyXLey9dvuvr9G8Lhfbj1Qh6O/LO/wLMrDydb gdcAKJNRrcNUWx0QCpMKxIsU8dmsSocdTzQoArwCuYcJqCAt9J6E9AgsSreGUvG+TulGYWRFFmMp 1UvBf9ZtHfweF7zMKFGmAAgXBKHDKrXCREiXwfn6fRvxsXCxFiqasLDbKHnlLPPYvFsfv3v0VAzV 9O/ZI6qiPwvaLaop9iZafJYfHKOH/DiKJBFZ/LIXjgi8Yub+cDjU33Z/zOFMWUpGhz62hCyLLmBH lphN7UGFJV81UyirsTdAUW48Ww1wdF4UktOtMbosN3OZApOm5VW+NgCGjkmyfTUwkaSLnoUS0xAL yPEx2hw/pkHBcwrIJFabPCTUu0oED02KUVposmohO6IgFAVke1ksFpADEocJY1aGJk5jiF7kTe0y GpP5kHpmQeGtxVYi+AKzDeOhlbfQhJcnXVkttHEpuA9gSeonVcaNkQKvjC+dVoYmTsuIMHIvghWX oQxNKLmrrCWWjCMqMG6cCXh5aOJzc0toYqaOfH5AEqkJo2DYpHzP7KSEqbeBIiEHHZN4jZlX2TMa kMQAZeKIjdyrjaP1JMcypCTtAYq8hSodWnfpLgYo6R6VilnTKtE0JnGGdhN7Y00sYHFp5HGSsUnW xCyNRcOUdOdG7erGzItKoV+4rsKUm5awUCNfVNTUz1Ek9d6l8oUqRxkUh7h6R1lZ1I380I7DFBR4 WtiAZZgi9eZjqLk7SpGapCYIPmsK9vMVnEMcwCZa+SQV5/3cL0Yrnmf9JCXnFJvEC32hUqvTlzKw AxBpxNpughQvoApm0APNlzFDjJjBMVhOORBVxCibEu//X8l5K83OirOUEo4rzmfK2wuJ5J6DSKu+ ALJNM02boefqtoElwiE5sW1natcBz3m07rs64arPVtyeOHG7TgDfjK9kB2p9O0ENskQg8XR7YwIY MEFQPTlcorq9JlC0lkNp4hgzysJEB07X5Meeqs1jtxe2yRFmfCReZUUQ060HG4uRchaoeERblDwg 2CGqZKezcxnQKAZeQqxIKt1NJDlMIszg4FHXCExyz0KJs5W3qEqAxenFQAKP/nM7Tk9R1ZsSwKoC ddkwIEMWyiklwHJaCbCc5r4MXpG7UwiAogwlwHJZSy/oI/IkYsW7/zo1GV9FwnPgVTWNciZVkZVc FqBKbhVPTRIYeSF7mgyOMZ/6IwexBU4RgFh1m1cfgFNTgadmIKICMO0k3UU8le4znqqdZgf1EkcF TKm/CKiSPBFQubCOp2oZhkApHWmBoi7UjcpTe4GYIpAhKXO9cZlAkHk5j5cJ+3h2mbJCxTZPRcUh krJiOueCckKlo5jFOUKXfAufOoDhldN6vBzH+wTyL8bNF067Bf6OS6sxzBY9ZQdgryd8XAE7Fr5/ 9Orr48cd03PBN6jp0xSw47Rc534RNaVi9OcpYKfS9p4CNorDsfYVfJoGyf65i96ZcsnwiT/R00ny pcBPP2cBey3OxczuL7GAPXMewGuzlh8aYxZt31sGCbyMHMB1IERyKN3eCF6IGvUtA3lfhCwgRvSY gge2FBGS64lhCDFF5A/lVwwS5Zm1a45eWYoU8KKvHCQCfs9q18VILUHkj2gLSRAVhLPgRV7taHW8 2dQ7rYQvTnPTXgXSoNPQCgpx/CIrQahbwhcOzjaSTC/hCwBxZlsV8EXOt1MBKOCLU0r44rQSvjjN vRup5cjdKaxjlKGEL1HU0i36eDJ68TFn+OKUG/GLncubASeKLiKISfcFkkk0QywTic9GU9qkf2TL aDoo4pklppsUCfH7gjqu0kOSjs7poXQX4Yzfgw0SAnGaZXycoaKZ1FtEMy6NaJukh+Yoaz6hl8ai 6aF0dzOwQdVEP1RJ86ruWME6+Hr5CsIq6nuZHXLaJX2H15G+w2ur7y7pSrGi9Ft0g/bqKzmfLDnE 3z/Rv8NgPupXVMKOgl8HIM95DYFj1Dot17n/nPAm3FLCxsp1jZ5+IGKxNxI+Et7gbzhevnoj4eeE N1txTuRsjk/qrXI2VsLmkyQeL9xQwuYTiGqf64xOLmHLG3GSdpNo3kvITsM+pCK203IxmncoFt6l cAKeSE6fScIt0dQX6Ql2MTVexWaohJExeNcqNqurVRsXQb2aUuCVqtjeCl6p0Oy0XIxO3GN5WuVS GeCVStYuK7wyLQ4oM49z4yLAKlLEpsufAzifGUtZy2fWsfufv469yPmwVR07UbQIbXXsRItlad6E FEApJR6tYy+kYZVLKmWT/tJaoJZ5rA1n3Cll6zORK9hTS6CxlL34Pd7YStmJgj/2Unaixco0hQjj 6/exZ1Q0UaJ0wkWr2S5/rmanEXrPPi/u2XeGVqmaHfd6NM+3VbP7opr99T8A8mw6BQplbmRzdHJl YW0KZW5kb2JqCjMyIDAgb2JqCjUyMjQKZW5kb2JqCjMwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzMyAwIFIgL0NvbnRlbnRzIDMxIDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMzMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQzLjEgMTEgMCBSCi9U VDUuMCAyNyAwIFIgL1RUMi4wIDkgMCBSIC9UVDQuMCAxMiAwIFIgL1RUNi4xIDM1IDAgUiA+PiAv U2hhZGluZyA8PCAvU2gyCjM2IDAgUiAvU2gzIDM3IDAgUiA+PiA+PgplbmRvYmoKMzYgMCBvYmoK PDwgL0NvbG9yU3BhY2UgNyAwIFIgL1NoYWRpbmdUeXBlIDIgL0Nvb3JkcyBbIDI5NjYgNjAyIDI5 NjYgNjMyIF0gL0RvbWFpbgpbIDAgMSBdIC9FeHRlbmQgWyBmYWxzZSBmYWxzZSBdIC9GdW5jdGlv biAzOCAwIFIgPj4KZW5kb2JqCjM3IDAgb2JqCjw8IC9Db2xvclNwYWNlIDcgMCBSIC9TaGFkaW5n VHlwZSAyIC9Db29yZHMgWyAyOTY2IDkyOSAyOTY2IDk1OSBdIC9Eb21haW4KWyAwIDEgXSAvRXh0 ZW5kIFsgZmFsc2UgZmFsc2UgXSAvRnVuY3Rpb24gMzkgMCBSID4+CmVuZG9iagozOCAwIG9iago8 PCAvTGVuZ3RoIDQwIDAgUiAvRnVuY3Rpb25UeXBlIDAgL0JpdHNQZXJTYW1wbGUgOCAvU2l6ZSBb IDEzNjUgXSAvRG9tYWluClsgMCAxIF0gL1JhbmdlIFsgMC4zOTIxNTY5IDAuNjk4MDM5MiAwLjYz MTM3MjYgMC44NDcwNTg4IDEgMSBdIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4AV3C QxAgBgAEwbmcbdu2bdu2bdu2bdu2bdu2nUfy2Nquhv8FCID95x90wIDoQIGwgQOjgwRBBw2KDRYM HTw4OkQIbMiQ6FCh0KFDY8OEQYcNiw4XDhs+PDpCBHTEiNhIkdCRI2OjREFHjYqOFg0bPTo6Rgx0 zJjYWLHQsWOj48TBxo2LjhcPHT8+NkECdMKE6ESJsIkTo5MkQSdNik2WDJ08OTpFCmzKlOhUqbCp U6PTpEGnTYtNlw6dPj06QwZsxozoTJnQmTNjs2RBZ82KzpYNmz07OkcOdM6c2Fy50Llzo/PkwebN i86XD5s/P7pAAXTBgthChdCFC6OLFMEWLYouVgxdvDi2RAl0yZLoUqWwpUujy5RBly2LLVcOXb48 ukIFbMWK6EqV0JUrY6tUQVetiq1WDV29OrpGDWzNmuhatdC1a2Pr1EHXrYuuVw9bvz66QQN0w4bY Ro3QjRujmzTBNm2KbtYM3bw5tkULdMuW2Fat0K1bo9u0wbZti27XDt2+PbZDB3THjuhOnbCdO6O7 dEF37Yrt1g3dvTu6Rw9sz57oXr3QvXtj+/RB9+2L7tcP278/esAA7MCB6EGD0IMHY4cMQQ8dih42 DDt8OHrECPTIkdhRo9CjR6PHjMGOHYseNw49fjx2wgT0xInoSZOwkyejp0zBTp2KnjYNPX06dsYM 9MyZ6FmzsLNno+fMQc+di503Dz1/PnrBAuzChehFi9CLF2OXLEEvXYpetgy7fDl6xQrsypXoVavQ q1dj16xBr12LXrcOu349esMG9MaN2E2b0Js3o7dswW7dit62Db19O3bHDvTOnehdu7C7d6P37EHv 3Yvdtw+9fz/2wAH0wYPoQ4ewhw+jjxxBHz2KPXYMffw4+sQJ7MmT6FOn0KdPY8+cQZ89iz53Dnv+ PPrCBfTFi9hLl9CXL2OvXEFfvYq+dg17/Tr6xg30zZvYW7fQt2+j79zB3r2LvncPff8+9sED9MOH 6EePsI8fo588QT99in32DP38OfrFC+zLl+hXr7CvX6PfvEG/fYt99w79/j36wwfsx4/oT5/Qnz9j v3xBf/2K/vYN+/07+scP9M+f2F+/0L9/o//8wf79y3//BRVJT/gKZW5kc3RyZWFtCmVuZG9iago0 MCAwIG9iago4NDAKZW5kb2JqCjM5IDAgb2JqCjw8IC9MZW5ndGggNDEgMCBSIC9GdW5jdGlvblR5 cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsgMTM2NSBdIC9Eb21haW4KWyAwIDEgXSAvUmFu Z2UgWyAwLjM5MjE1NjkgMC42OTgwMzkyIDAuNjMxMzcyNiAwLjg0NzA1ODggMSAxIF0gL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBXcJDECAGAATBuZxt27Zt27Zt27Zt27Zt27adR/LY 2q6G/wUIgP3nH3TAgOhAgbCBA6ODBEEHDYoNFgwdPDg6RAhsyJDoUKHQoUNjw4RBhw2LDhcOGz48 OkIEdMSI2EiR0JEjY6NEQUeNio4WDRs9OjpGDHTMmNhYsdCxY6PjxMHGjYuOFw8dPz42QQJ0woTo RImwiROjkyRBJ02KTZYMnTw5OkUKbMqU6FSpsKlTo9OkQadNi02XDp0+PTpDBmzGjOhMmdCZM2Oz ZEFnzYrOlg2bPTs6Rw50zpzYXLnQuXOj8+TB5s2LzpcPmz8/ukABdMGC2EKF0IULo4sUwRYtii5W DF28OLZECXTJkuhSpbClS6PLlEGXLYstVw5dvjy6QgVsxYroSpXQlStjq1RBV62KrVYNXb06ukYN bM2a6Fq10LVrY+vUQdeti65XD1u/PrpBA3TDhthGjdCNG6ObNME2bYpu1gzdvDm2RQt0y5bYVq3Q rVuj27TBtm2LbtcO3b49tkMHdMeO6E6dsJ07o7t0QXftiu3WDd29O7pHD2zPnuhevdC9e2P79EH3 7Yvu1w/bvz96wADswIHoQYPQgwdjhwxBDx2KHjYMO3w4esQI9MiR2FGj0KNHo8eMwY4dix43Dj1+ PHbCBPTEiehJk7CTJ6OnTMFOnYqeNg09fTp2xgz0zJnoWbOws2ej58xBz52LnTcPPX8+esEC7MKF 6EWL0IsXY5csQS9dil62DLt8OXrFCuzKlehVq9CrV2PXrEGvXYtetw67fj16wwb0xo3YTZvQmzej t2zBbt2K3rYNvX07dscO9M6d6F27sLt3o/fsQe/di923D71/P/bAAfTBg+hDh7CHD6OPHEEfPYo9 dgx9/Dj6xAnsyZPoU6fQp09jz5xBnz2LPncOe/48+sIF9MWL2EuX0JcvY69cQV+9ir52DXv9OvrG DfTNm9hbt9C3b6Pv3MHevYu+dw99/z72wQP0w4foR4+wjx+jnzxBP32KffYM/fw5+sUL7MuX6Fev sK9fo9+8Qb99i333Dv3+PfrDB+zHj+hPn9CfP2O/fEF//Yr+9g37/Tv6xw/0z5/YX7/Qv3+j//zB /v3Lf/8FFUlP+AplbmRzdHJlYW0KZW5kb2JqCjQxIDAgb2JqCjg0MAplbmRvYmoKMyAwIG9iago8 PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDMgL0tpZHMgWyAy IDAgUiAyMiAwIFIgMzAgMCBSCl0gPj4KZW5kb2JqCjQyIDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9n IC9QYWdlcyAzIDAgUiAvVmVyc2lvbiAvMS40ID4+CmVuZG9iagoxMSAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9BV1lSUVkrTHVjaWRhR3JhbmRlIC9G b250RGVzY3JpcHRvcgo0MyAwIFIgL1RvVW5pY29kZSA0NCAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFz dENoYXIgMzMgL1dpZHRocyBbIDAgXSA+PgplbmRvYmoKNDQgMCBvYmoKPDwgL0xlbmd0aCA0NSAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDBbsMgDIbvPIWP3aEi6RkhTZ0q 5bB2WtYHIOBESAsghxzy9jMs7aQh+cD/+zM/lufurQs+g/ygaHvMMPrgCJe4kkUYcPJBtCdw3ub9 VjU7myQkw/22ZJy7MEZQSgDIT0aWTBscXl0c8KVoN3JIPkxwuJ/7qvRrSt84Y8jQCK3B4cjj3k26 mhlBVvTYOfZ93o5M/XV8bQmBEzHR/kay0eGSjEUyYUKhmkary0ULDO6ftQPDuHeeWq1KNXxq/8Mp aPniM5JdiThN3UMNWgL4gM9VpZjKg7V+AG2acBAKZW5kc3RyZWFtCmVuZG9iago0NSAwIG9iagoy MjMKZW5kb2JqCjQzIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0FX WVJRWStMdWNpZGFHcmFuZGUgL0ZsYWdzIDQgL0ZvbnRCQm94ClstMTA2NyAtNzM3IDE2NDEgMTE2 Ml0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5NjcgL0Rlc2NlbnQgLTIxMSAvQ2FwSGVpZ2h0Cjcy MyAvU3RlbVYgMTAzIC9YSGVpZ2h0IDUzMCAvU3RlbUggNzcgL0F2Z1dpZHRoIC00OTAgL01heFdp ZHRoIDE2NDAgL0ZvbnRGaWxlMgo0NiAwIFIgPj4KZW5kb2JqCjQ2IDAgb2JqCjw8IC9MZW5ndGgg NDcgMCBSIC9MZW5ndGgxIDg5MjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVoL eFRFlj5Vt/PuTnceHZI0JLdpAsgNhIePBFvoPDojRDAJQbtBoRs6EFAgkvBG0qKB2OADfDCfOoo7 s/PtY5SbThw7q5isLn6yO+4g62tWF1DHx7crO4zriN/o0vvXvbcbksn4sZ/u3s6pv+qcOqdOnTpV 997udG7c1EoWCpNEjUuC7atIu8argPKV64Ltetv5LbB45eZOWW9npxOl/nJV++p1ejt/iMgya/Xt 2xL6op+nrTUY0uUk9K9uA0NvsyuBE9rWdW7V284vgem3b1hpyMcXop26LrjVGJ/eR1teH1zXqvcf 3wOc3L6ho9NoB7T2xlajP/MRmY8QA5fTFrLSjZSGlo2m0w6ilDOWWZgv0+SpLPWRmOWL5Vb3H5gD 08LV3/XKiwKPn7KfO7/5jw6LM2MBmhlafyGA3bQXLzRiziXnN5+vtTiTEiEVF4/RHUqMVoNuBS1S qrPBrCcbiFMXryPG53I39BQ+h7ujTPndC/w6MK9DI7+UjkJmA3G2l/VEi0s9MXZvn62giqqzWQ/Z QJzdzbphS2H3GLiHdUe5En6BdcHsabbTs4qdPlMwZuybb6HYsbPAYd1RuqNih7RjZ9EbJ8HavAXF unYUt29Acdv6Asfy9V238dvWd20s7tyUbx+7ei2KVWtQtLblOx5oPdx6olVqbeu+o7ioo2B7bZFz G4gPSM3SfIxsOyrVUyOIk0eqimZlVw3Eh6TKaLZR6cswVzVWZ0lTiUnTpRlYAYV/yf+L0oEfRV/i Soy/3/dSCHPl7/XNmF0lMOqaJKygkp+vVX4TnVVlVKZMMypOl1EZU2RUsnO0yoloDio8zLcK96oV 3kmNII7Q3orarahl8RvIAboNJKHVgFYDcT6bm6iASnklMBc4k88QwebTDawAloA/jc+IlpTKMUBu QdUAO88+ikpKZrXMviTGfsf+U2ixswZ+buB/GPgZ+1SEgX0CNAE/BqJ//B/ZR31ZcL16HBiMNqPc I0TsYXZQM/iQgQfZg5QKxQPANOADQDHg/exBTHlwEE1G7SjDQsBujh40KTG2KHpAwI3RQwKu7uuS FCRYVTS3sKo6g01gZZpTNpajoclz7bcI39eNX3PPJ8XFVY89LilPPG5SHj+UqTwEewcOpioHYekR 0I8PceXRQ5Jy+BB76tCRQ4OHpBel66V5YnLSvGg3V0RK1PbZcqpKX5KwCeiMKKWrpCsRNbk6V5pF 00EeUCPIJM2S8oUT0kwDK6R89KwYRBO7ENkjgzg/Fz2aivz5MDqYLobgH0THTNZS4IMociHGz0T3 ZkJ+um/QhKnyd/pcZSK/3onasWjofzIKl6ot/FV+TMSTv8yHNPx7A/cL31/km/kWMRW+xZgKv0Of Ct8opqKVHh5IGA1EM7M068ujYwq1yrLohCu0yhJNrzqfL9UURWnl81EW8Hk0EcQpg0+lIhCHe0o0 x67pXdFnyalCtrlEth3l47kslps7uRw1KcdhT8YZUoJSbK5SXcq+Yr/WFvIMe45kcrLT7LnoRKcc Y6ejJc6q6mL2b+x9LWveM/BfDfyNge+ydzQD77C3tX5vszeRXeogmoy9xd7UmP+iMddUZ7GTmMeA KNlJQ/aGJsOIJ6I4BAaQ378W+a0Msp/Sz0D9ICl+hv08mmfHMrD72H5twH0GRoAirW+K7sExwRZH wxKgJbonBdAc3SugKdojoDHaI2QLo90CbhALFWOV0b0CZkQHBXO8zsz2ZEH4x29MyjeiU3zIk/kH kZhfsTNfMdHM6LWPrfJ8jJQXrWlHLNYqeOrpb+wP9Lf3h/uH+k/0n+k/15/RfyRU+tmnJuXeSJoS 2Zeq7AdB5fn7p8+suv8+DAn1/PtKXFX37ePKvu50ZfddJuUuMYf4UF94/gJhvy88t1bHK6t0nDxN G9ccHueqCu/iStcuzarHfKd3XtWdaOyCJWFa7oHpHsxwLxh7ulOVu+/JVO4BtneHu/lgN6vOlBZJ LZQtNUpNKBdKN4oyKoVKqxdLN0gLyCo5pLHSODJLVskm5QDNkkXKBk4CXkEWyQm5C1gCuQycRG7J CSoBOUBWkJnc/Bn+LD9CZv40/wv+U+CT/Cl+GDgAfIEsvA/y54Aq5FHgAHT6QKrQBT0NehJ0F99N 2XwX70K5k98pSs3fTXw734G9YuM5PBd2LTybW4GMcy6RmV1gcY57P07yHHocxEVfnPU2ego0CDoN SsHJbaG5oC6QRKXsAvZNEXQd8CkPNu3AIviRB7KBLKBUECM3+rrZUfYSG8R4vSzK+oDPsiNMBR4H /hNZ2CuQHwMOQf4y8Dh0XgENCV1QL+hZ0Dq2nm2AXpCtYCuBy9hyFtDaq6JjSkura9gqmgvqAkls G6Q7YK0DWpuA7dDaCNwGSx2gdmERtAoUBC0DlbOpZGUT2SSUk9kVlM2mMAVlISsCJ5flocxndnAK 2BiUKSwVJWcSSmxhUXr+CqlyIW51XGMvvNpuv8qee6XdOstunmnPmGFPnW6XKuw0zT5xUvbkSdYp Sna5Yh3vyp7gspaUZsulVqstx5yRmWVOTUs3S6YUMyJtJsmTV+wiKa80VRpbWmqda+2ySrLESqUb pUEpLpkcbJylMK3YYreNseSa8i0POli5e4p7snuie4J7vFt2l7gd7kK33Z3rtroz3KluyU3uxllM zW2ghpYaNY8BF9Wos5SGmCQ3qzOVBjWjcamvl7H7/eCqvCfGqEU19cQ4ILd2yVJfjBUJcbdjQMxb bQh03+fv5VSjsh7VtcgnwNPkU+WemI1afL2c1fj9fvWahkbUqcavjFNDDegWHudXZ4rKg+P81KDO blIdrhpl5NUhGB2dGlyU9U6e6FWneINquTdQd5GtKIQGHPaqF7zBGOOuYcJExxHGEmxgBy6jGeM7 vTG+HWb4rtHNJPVi0kJvTLoBXaVG0bWzgyVlo1Q6OsFkWjlSqg3euQmODJOAgasDYRCqIh4aXFJo bnfoArpUTElLCW4CLxnkkmkbNoVWh8JqfQ6/oqiFqgtJklAwLApgMbZT9q6ti7E7ddilQ5cOYR3u 0mG3DnfrcI8O3Trs0WGvDj063CvAmBmeSq7VuNytw3U6zNFhrg4eHap1qNGhVoc6Hbw61OvwIwGI G+bW0Zshsr+xuaZBTW8GNS5Vi11ovIbG1WiYXTWUqlAR3oxeo7JEqb/I6KVpDok3Moq/p5WfJeoX NsW1OtGFdwXv+1zi3UuQ6fsYEbrHCAdq/Nr4gfiXNEhtlB+vjv84/vmoZnfHd9FpOknHqZ+eocfp FOrH6CUaoL+lj1B/FbVn6BFaAe2f0U+oG/g39DQ9TBvBFyg4x/7UNps8jHeeztMhVk3zgSOvh2Hl 4ZHMP9v+JF48iuxUfDztpJ18E/8tbcLnMVj8BR2+pOca1P+SOvD+e4ydpRXsRVqF+fRQiB7gjfF/ TzlOBdJWvPJsMB0WmTDsepR8tI1C0hPx3yNPrGmNuKkeif9evEsPu76r3waMnbgGaD/LpF2I2wy8 mT9GNQnBcEQMz2MOKzGX3fgcwmr04bMT4x64tGdqnWgl/E4nPVsTeZQivmvAFf8UtFWrHhPxNjL2 A9qMEdw0Fa9z1ngp8ub6eGt8W/wn8aPIBrH6PzeyYhCtv6YD7BA8WEG30E38V3ixE60NaN9E89k4 ZqEnYfsqbZRkYewqSWeIHBdXwj+TEUVjb8FL/Ypfm6ixg7gxn6fX6BWKaf48QQcpQmHEoRP5vYQa 4ftsfC2h9/tYy2Hh+cU+y6gFuYcLOTgH8zmVsC0w5S1t7xvf3fyJf2LvH5Ne1nVEFPXrQqJC9DpW Ut8NPYjGJsRjJVb2vLZ7xPodw6o9jVxLyG5KSl/V1lb0n0MzhRfx2fFdiP0/0820gffhgeVu6PVc HCpZ+wW4iUwupFNsTlIyvPJ98n4n9tAxenSYwW66lVqHcUY0RsZvhHiUZspZPDo+jFX7Jcbbgc/O UToNIL+PIU7bqYmqaS/W8RT2Rxv2cAgRP8lkrM8bOMVGu4KwewKrskFaJRmrPFo3ZIj4jHKlnNWZ 6cRMyPxk7ia66rmbaA3DOSkSvctykR8P0bvIiWfoeZwlqwUXWaxf/7s12k3raYrxIY+ned717mtn V1Vec/VVV86aOWN6xbSp5cqUKyZPmlg2wTXeKZeWjBvrKC4qHFNgz8/LzbFZsy3mrMyM9LTUFJOE 5/lyVqgW1vq8a9Wi2gDuhXUum6yaF55bUKFSrsPpypFnVfinGr3UFEWlvAY1H8985Kn0q6nKyC4L VanM9oUTygscslc1leHPNT8YUic3+5wu29uOpNwPs2pxrc/pdKi8DH/zIMLf/KAcUm2N4EOgceap 1OgTFIt/WAkmVTr9KJt9akmiiUfRUZwcwI4aGuHmQhax9ZqLautUyu8l84cq2UW3c5WElzB1Mh6N y2yoadaoQmX5X6gsT2X2BZjS8CGE2pnKUWLgDa11eUNrENFQ4GJMz+kRdcoROdLsy5nlcDo1p/Ek 0uTrzcqsddW2ZmIWeGgGg3ozs8DJEgwsS3svM89hWoWbvbPxxJ1uQfhyhbteQWtVz74AKq46xA2S vIsSvCTvv1REUNM7EbppNaaNqabWqmm6E/Ia1RNUaZ/cWz4U2Y8n/hUBxRxyhYK3+FQpCKd6SSrz trWoYxsal4AFJ0CBNlksd51WiMWTvW1yBG3RN4DSVQfV4fxQW2tApAkLuOogy6j17XUOOfBK4tvr VXMU1QJ1y/bfOqSIt3CNLJqRyF5ZPYxXkUukTtEHSVA4tVyOeF0YDca8a2vEilUkl03LxnkhbXE8 +4KyGl6xFjHDX3B/Iv+dEZtq/sqJ1cH6QFPsDhFgQaHAWjGVtdA0AeTIvlZtqvu1qSFfxWOnIKGI 7KfF0F7i87a5vIinMSACAn2pbKSu06kWKUIxEvEKF4MheC8ig78iPKzDDb2BPeFQGPypVT0tGlCL tgYY0ROs8xssowMkJqyD6gnU+f1iUvoCqGlle1OmueSIMJpWpuYrNuc/QDY0tbyh2eetE9mJnrzW d93ZQsdZ1PGil2CzQvSJVJwVQRKSRa6GJj0L2kR8RBFo0TcwomasPLoa/TWrrxc6Xoduvas+EInU u+T6SCASjMXDK1yyzRXpNZsj7d6ArO18Bv7f7XOo9fv9qi3QxmZjkUW+1eMJPq9pqVieerktCA7+ 5rqclQ5nDkzrfXByjC429hkyHnkv9lnE9jlmbMaJ5JDrxfESw6ngUG2VYpvCk8U+7IOVGMIb0grs D7zmcofYKZK/zLtmkREghxNDagkjzr0mgwsjTqfYQ/tiHlqBhhpu8ultmVY4ouSpULB2ASEZSkjs i4UknJAk1QMurFWheM3WcuLP5TTO82Q+R3JcuXKVOMzhHf7mhdShFszx60o1HRHTljuv1ic5uOiC GndIopap4JbgVscomqKICU7JiM0ln3CpNkVNqfUNOdx+2ZaDA5Ilk8GwKNLUdsJ1nIlDlPJtKnOr rEBsK8KhijDi0B9TCWFSUfZGAkb2XTo/dBW9Q23JfaTPAhtXTBJhsLmwbx16PHJyXWKqvxLZrt/g 1JSyerGpsDZaxOb71Wxxs1OzP9cKTM5R65NxDGHbNmkV2Su3iVVX5UCddh74HUKeYMfiZwJ14vzz IdHQxWHkN7IcYTP2hBGGhhZfotbsu9Ox3T8Vv4qVN8QoA3dS8Z1MjMW7Y1Q3bgC/s0nLl0HcUi7L 3jV1GBCNxeVgTHGidlM5clOkvs/lF3eSeaGILJI/hGlpCEFrxF+BfF3kw3mJr2qcqsfvSFZb/f7Z sHOzsAMVdI/4YWGtYQGosSr+G5185Q04qSY2+nDYhuuQ6HViC2O6Q9hVQ2LGYiL+pKfw+M41hYbP S+CzfwrkS3UryNUwTPgjEWFzkc+FNI9EHBHMw2jjG56RDI/BiJFQwcS9MRZuhC7ApT0feF1Ol4i8 vw5D3YK4J04p/Pb43RFelvQbmsvh7TItwoEfKMLBy4nwisuK8Mqkp8MiHILPK0WEW0ePsMonfkeM Lw2pRw+pZ5SQrhoW0tXfHdK2pKPwag3ca9NCuvYHCultlxPS2y8rpOuSng4L6Xr4vE6EdMPoIf2/ SNr2YRG+47sjvDHpN5zsgLcbtQh3/kAR3nQ5Ed58WRHekvR0WIS3wuctIsLb/v8ivP2SCOOHTWa8 eKGiV81gmsEU/8mQEMokg4M3JHxDgA9+Jkmj/OdTuYkEVbz+5utaMWO6M8eZU4aC4b3wW48U/jac Qt+QxxSGJn6A0a54Jd5TR7uEXB+R4Yd2vZZKeUTVN/ubm/zKDZtWrgkFf7QxuD6kvXbrPYQlG2hs 3LgEI1k3+vwPaEuB3wplbmRzdHJlYW0KZW5kb2JqCjQ3IDAgb2JqCjQ3NDkKZW5kb2JqCjI3IDAg b2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1pKWERUTitU YWhvbWEgL0ZvbnREZXNjcmlwdG9yCjQ4IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rpbmcg L0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgOTMgL1dpZHRocyBbIDMxMwowIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDMwMyAwIDAgNTQ2IDU0NiA1NDYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzgzIDAg MzgzIF0gPj4KZW5kb2JqCjQ4IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5h bWUgL1pKWERUTitUYWhvbWEgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTQ0IC0yMDcgMTMzOCAxMDAw XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDEwMDAgL0Rlc2NlbnQgLTIwNyAvQ2FwSGVpZ2h0IDc0 MiAvU3RlbVYgOTcgL1hIZWlnaHQKNTYxIC9TdGVtSCA4NiAvQXZnV2lkdGggNDQ0IC9NYXhXaWR0 aCAxMzkxIC9Gb250RmlsZTIgNDkgMCBSID4+CmVuZG9iago0OSAwIG9iago8PCAvTGVuZ3RoIDUw IDAgUiAvTGVuZ3RoMSA1MTI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AcU4a3Bb 5ZXnu1eS9Yj1svySbN8rX9uxLTtyJFu2HMe6tiUDNZunk0pOHCRbchSXYAU7bSCUuLvbhlVSEqZs gaUDmc5uKLSQ6+uQym4e3tJhWrY0AVqYoaEESgvtNE2GGTpAi9XzXckmYdJ2pn/2k8497/Od73zn Pqfu3JuAFTANLIiju2MpUIZpENGDo1+c4nO85gIA885YaufuHK87CaC+d+ftd43leNNfANiTyUQs nuMBefAlUZDjSSvimuTuqX053kR5/vaJ0bze9B7y1t2xffn54SLV3xHbncjZF71D+dTE5FSelxC3 pu5M5O1JGPP50vW8EYCglRaiUAAbQQUMmEGENZhpm/pe5IiiJ17vnSf+vfs2U9cH4NAq4Z9ZmK+g xMnQ+29njy9G9M9qaSQd+uQGclqyGAEw8Nnj2VP6Z5VIeaWCtHMgkonZ+mafmCETcqnDlyF7ZtlO 59EeO9mD5i143ICQQngc4RzCmwgaMOExgHAbwgEEVXaBbJYrKn1zSIzK1iKFWCd7W/NETR0GXzfb VcKZzpBtcAWBwdmHZsvtdPah2eJiBctms+IRmdXpqSCVTy9F06PBh+XiHDEi24oVycjSvJuWiJ2y 26eodsrGOoUYk3WFChFbIhKyN2eTkOsbFVVCruQxyYRsL+foTDF5/ca8T3cgT5TnVhibLVLSjc0a CmmWt8n1HsVivbx1KEfM+tf4WnpKyHpc5Xqs4nps3hQepxFwi0gczAgMXMDjJUqRuJyKKxP3y0U2 JUi/XFKSJ7AaNKde2UJL+yMk9EZF0i2XlinEWtmABGkhbtHg4d59L86993ILx58mftxHP8b3y2wZ 16Mna4gHm4wj7YgLEbcRj2zj3D0rkCfER7xgRGkrYhvi1cQrmzlxnnTAUdIhuhnTr92/ZsTXq2t8 L70W4F59zc5N/4L8AhH3Gkm9Rl74SSP3wk/8HS8Qw4+DP2Yy2YVTF3UW3/qXCZJildzg8ZllXhbl DXJKnpaPyZJ8Qb4k6xfkqzK1Fvc/iwvigsS0ldvKrN9y2xam41wjN3GOPH7uxDmmfa6Yc/+AnD5b yp05W8KdPVPMzc9t4k7NNXDfn/NwGYS5Nj/XFfBwawNrue6Ak+sLVHK9gU1cD4KIEGjzcB5vnPO2 tXJtrYNca1sVd6H1UuvVVjaT/ePsydqbfZnspdmTZgHxH0XjSZ3Jd9J+M3fhDnJpj7IK3cO0Offg sjLZ/xV1KSs2wwR2BE3ffofO6ks9QsSd6JYamx47NiaNqU4kziWU1f0qjl4T3zjwDWbiKEndTw4c fvwwM32MwMiGkYURVoylYox5G7/t6DY2abuZm0Votlm4Jlst57L5uUZbEfdm/ZV65nw9RWy9zcw9 xvdxnK2KcyLmbV3c4/ZNnN1xE+ewd3F2m4crRr8iWw9ntdk5C0LKRkRbT58PNMRE8O8mATJBDpAT 5Bw5T66QLNGbgJjADQGYgANwAs7BebgCWdDrde2ciTGxzHnmPJtlsqxqRaFfrfKzjJ+Af4OaZNBb sg7AwGCvVEQQb+6d0XlcA1J8U+9Xv/71SumbA5vC0nRlJKNFm7BEJHJ/RNIObM6T4MIxOYX/ySmJ DUmaUDImaYTgJGWMlDEKQSQkE6VNQpBItlBSsglB1yR1XR4YQxmT+eGanMxb5DSwd9n0GoJOjJYK IlMuQCdFgiaUzEW4dqLJqakbBsrFnFSW48KraiiJB1yGYg2aKo1NfVX9kuoe1TD7Mp6MkH03+9bi vsX4YoR9FFbi1fmb8BTMwfPws+UL9mn4oUJ/EWRYgP9bllPiK/AgHIefwuu4TUvjYXgMvgv0HvQQ Ul8mY+QeOApU+t/wJDwDszAPzy0Z/038CqnM655jbCSXwe9gBfMSmST3Y+SHoBd/z1/jfx/ep/34 +ycGyTK3sAFmiPkp8x/MBNOeC8HcjatbYF9mn4Bb8bcAr8LZGwT/CvmIfART8Bus2wvkP5nn4Xvw BHwV7oMHcNX/g9wEHIQj8Cgc+6y3Jq22qN6/TpqBp+FrsB1+iZX+EXp8DTaj/iGMBfBl0IMdOHU0 7/EUfDtP/b8j1Q7mWazWg8yLbC9zmpFYN6NiT5MHsN8+ZlX4lBGFCOZ/K9ZhDAawHsfhO3AaJXQc xs6S4X7sDzr24O+/4EP4N+YptN8Le9lvsatRdxrWwgjZT7To7YdT5DF4G4bwl8ILxdvkOaw+eqpO i2s6/R3tvrZWr2d1i3tVc5OrsaF+ZV1tjVDt5LmqygqHvbystKTYVmS1mE3GwhUGvU5boFGrWIZA E5HK+sIz5QUuh9PpjDTnefv1vMTWmt93SmC9zshxvdFMxWf4ys/wVcv8OglsUr/QF6SBZ6D/txIU ScQmAZ2FFP0LzpTPJBQfF0K7pPK+eDSKHkHBzEv9V935VJSEZwz6PqEvoW9ughm9AUkDUmibmiH9 3UQhmP5Q5wwD2sLmJsnqkpjaEIVxSTwURUII4tJRU/SpBu8vh69VAbrljADNFIpImj6pQJmX3yWJ MQkO8TNNC+nDGTOMRF0r4kI8tj0ssTEs6gywtaEkXoURUYgmeUmF8yoHB0r4UJJPI0/NongUguh1 QzmKdX3hg84Fh2RFHJIsLukm9Lzp7nccbDpUtounbDp9kJeObQxfq3VSm0gkUtbcxKdDAk4UbG4K jfdipcvczU20BGSpNPHoOM1lPEbzDI3z6UMJJdfDSm6KaSiJGxP7R1bpdCguhOKxOJ0Go/dJ4qCC YHCIloMPYemCkbwob4AalaKJBiNYa5oY3sz6UBsSYkHsQdqny5JoXoKC0JKSp3neIolRiR/lJdgU FtC5gx4SHZAe7aB9jGFIc9PAhk+9JHWtWeDTH4BEosLlP9CMP5XE8hJNrfkDoMp+oT+aTvcLfH86 mo5lstMjAm8W0jMDA+lUKIqzbsBbLcrnDzmk/sMRyRxNkk6sPe2A/k3hgMNpwXXk2A1LLGBLYWNh C9Pbt6oW/7fkEe4FDIbx2UOCLeGIAwsZpvQg0jlMGwkbtwP3OF82WqMEXSxOROk86XTS7jyUEWEE 912a3hjO8TyMOGQQ3S7cjyjVLCxpirdQzfSSZtk9KuDmnFTed4olbd3y32QuKQolOyVS8nfUiZxe KuoLsw6GNjxSjIOllN6FZ3qXVOpCut6Vxm25IEhml6QOLzi6IrzZglcAunubhYGNQ2E+lF7ugpwk v1LaB9jqQiyZzp9itOlvLKWPRrmC047FU/oQVnx6ZBybBv+xw/Ty40ybpf4/OR3OtEWw8n53pJm+ UhJgpvGN+HY4q9oBbyPsRoixZjiOMIJX+Ny7JeCbtQbvbwA8dCs1Q/KGg1GkLL6lqm+o/+eFGnQt UNw54KAD79S/IUfIKfI6yvB2QJVowiKyfV/DqICC+8U3XlQOq1ucFqelFg8ErT6eVsOfKQYk6Brx WYE8jU8xLNhFE7OVaN1qAs30gZch7uHLwxC4jBEEi5c8feUK2hG8nwGbUb+KdekSq9WnNBoda2Az 6AjkBKrRXWfgCc9OswzLGgstVr972HvZ73F73cP4WvxJV8DrxpgNpA1zavP42r0WJ5v5pJEYF99/ 5AHdo0T7MPvb+z5/18c/pPnh1wqVSn0V6mBS9Nqra0tdnMvZpfaV+oVb1f2ltwiDpUPObdWJ0qhj qvRLjv38geoim804X84wtfNES88tsdxgbq+r0zoDFesrmIqS2pIKvPGTBYbQd45ZfWE743YN7yn1 unHBXrcLc/QEkFjdMoxJdpP2btLWWrdyFRGqNQVGUiCgzOvBe7PCocCpUv1l16g0+NQ9K6uF7e1t uz2N68oM3W+MXvhDQ01tsnPHuyHm4ks7vjf8g7f2de/gqqocNkuL5efcmjfOfP7BQM9099hFka41 ln2L/T2uVYRHxC+UGOt0DcUNgk/nsXYKrc1tnSFd0Po5Idgc7NyiGyoZErY0bV+9uXNUFzWOmuLl u4S9upRxj+kuobLY5mubi3aQjg6noaAA5g1MbW3DvFPvW+O0+GwWtsbtDDimHYxD69BGa0gNrYKh sL0Gq+BVimAt9bsv4wsOFoGCsoWXrX4/VoRcV4PSKkLLUFxF8pQRi1S3ss1bhRXyLRfORdqQzRWR ZH23t7bcVLGi581E4qG1vX3f3uP+wqpVnaFAT2Zv6uKAMfDz8bX7G+ob3Y2Nk31beg8+2VRdt13d Zy+2NRW9IvgbXC33bds/X27UNblcB2OJJ3uC/b66V1YNrmxqGt+4MVlVVXp8+u6OjWV2G63p8cV9 zDMaG54bdWKp+gxDNGeIgQXQcEDMhCcbiIr2udfdhculvU6wK4sRmGc++ZDRLj5BIov7Cr515KN/ pdFGMNq4Eq1aLFKdKSAsjcbhlysaiZ4xXdjcy5GUDncy4598iFGewGj7jmjuPbL0DSq7FTDoDQb9 hMWCBT8wFEMJXnVExYaAFTOgQ4MfJmDoc+Hg4DrXYCw5sTsGfwUKL9WmCmVuZHN0cmVhbQplbmRv YmoKNTAgMCBvYmoKMzM1NQplbmRvYmoKMTIgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUg L1RydWVUeXBlIC9CYXNlRm9udCAvQ0VBWlhDK1RhaG9tYS1Cb2xkIC9Gb250RGVzY3JpcHRvcgo1 MSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFy IDExNiAvV2lkdGhzIFsgMjkzCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMzYzIDAgMCAwIDAgMCAwIDAgMCAwIDc1NwowIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYyOSA1OTQgMCAwCjAg MCAwIDAgMzAyIDAgMCAwIDAgMCAwIDAgNDE2IF0gPj4KZW5kb2JqCjUxIDAgb2JqCjw8IC9UeXBl IC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0NFQVpYQytUYWhvbWEtQm9sZCAvRmxhZ3MgMzIg L0ZvbnRCQm94ClstNjk4IC0yMTYgMTYyNSAxMDY1XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDEw MDAgL0Rlc2NlbnQgLTIwNyAvQ2FwSGVpZ2h0Cjc0MiAvU3RlbVYgMCAvWEhlaWdodCA1NjUgL0F2 Z1dpZHRoIDUwNiAvTWF4V2lkdGggMTY3NiAvRm9udEZpbGUyIDUyIDAgUiA+PgplbmRvYmoKNTIg MCBvYmoKPDwgL0xlbmd0aCA1MyAwIFIgL0xlbmd0aDEgNjAyNCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHtWH10FFWWv7equtMf6fRXpZN0k1R3Op1AOiHfCQnRVOh0AIMYIGgHCHZD EpIgJpio6NmR7Doy2sTFI87+wY7KeDyze5hVKhUHwd1ZAqzHj9UVnFVnPDo4s46zIiysg9mzIJ29 r7qC0TPOnpl/9p+t7vvu73689+6771b16xq76+4+yIRx4EHeuiMxAtrl+i6xk1vvGfOnZVMbgGDq H9m2Iy1nrgIwerbdcV9/WnZvAuD/daAv0ZuW4Uvi9QOkSMtYS7xoYMfYrrTsYn7+O4a36nb3CpJd OxK79PnhA2a/M7GjL+2fw/yLRoZHx3S5knjtyF19uj/GKJ5zX5ezAJC8TPC3kAv9xDlwgAzraSWD 3CkwkMzsBm7fgt5fXbrd3vwF+Eza8M+//ZEW58lTPz50ZXuq3QamPeRrph7pi/qZMNUNYBu4sv3K Olt6Jt2oMdNk1+2tORyyKfAatQ5qZaLHiHhowS/gdo1m4DTOgDA7jWE101Z/jECZGlqkAzGQBlNm R718FBeqXq+mWDhlszFFaKq9XeOq5NcMIdW3QAfZHh3YnTqwZGqgUC0p0UFBQRpMWSxsmMKpzEzG A1M5eYzzak6O5sCreWzik5itFkg6sIgacKvU99jsCfSo69brYPUtOohGdRCJ6GARWxo5TxUVsxk8 al4eKaYJeNLxelRnOl6Pak7nI0+tqtJ88qbKylinPFVK5yVPzU8vIG8uUNcUDUMuLjU3Pa5LXb1a 6+xSo8t1ECrWgT6Tay7zkmq1aiZJpfyysKS5aCTV7dY1eqCSlkYsQVSrJZrSqLpcmgenLkzvH06V LGLBcFOURuI4F2WRmpuruRapdkf9TzELDeAEifJimLJpOy1MUWzURVDNLLvTBPRECWrzDbrmppvS YOq2buZboZpZ9CfQpJrZbp1Asyqn825Od2KaxZW6qaRUB4VFOtCKi/mI2ZpGVIvSJlEtZhVzAsWp THe9vTULa6iEa6iEa6iYJXQCogPtUEvYrgqdEosYZMmaWz/7qSSd+8wrVX6Gn4pe6eJ5h/QfRDAj z3BHZ8fl3BlrZv0MeqUL562S49K+S5x8fuT88fP80dnpqSsOsZ643PTfLrH+t594pU/qvJL8PgXc 8nM8816L9O57Xmn8HXyHWPy9kfe4118rlV5/rXHJ62h9te1VTvkAqfuRD+juGXmbQfmhty3u+qKJ romxie9OPDuhTPzTRIZ8ChuOOaVBohNEx4n+keinRP9A9Pe3OqWXjvmknxA+cswrvUh0lOgYxdLc 4pRuILqRqI0oQrSsJVtqJZIJt9Q5peoaUaqpE6W6WlGqJX6wToskUGelnd7Z1FR/difKO83u+n0j ygh3dhjlYVrt6Ts1L8+dLPb+x/qVfl7eZrbXP92HSq9mWtrLHgoH0f995ftcy+N4+77d+zj/o9OP cv7t8nYOBlD7dg7EB/jdCazcKG/cvXF8o7DkB06JpeJ3P8ik/i+jPIWTtDOKmC0dFp3S80TPEf2d aJV+LGZJh4jCpU5ppBTLyrOkctEmPeWPSJJYIAWI+8Vm6QVvkfS0t0/yeaul3d59Xs4rFkqvuFdI 2WKF5Bb9UqVLdnW6HnMJI65x12kX7xJzJScRiNgpxsURka/MQjCiHelbgS04jLvxMB7Ht/AizqLF DlRcFdACw7AbDsNxeAsuwixYLOYGyc7Zee4t7i1+lpvlBaYxm0olwVAqcXyxlGlrNAiNPNeI0Nhp wKM0muLqgI6uZYobia9bNmmuDncovWuXPfToo/nKX3WsjSnj+d1HTeQTU1DBv+xWTB3rdAhh/Rod C4+OjY4pfFQxRgcSijHYNsqELCZkMSErqtiZYA+2oSJGBxSRtGPh8NjdbAit0cYa1UcMh0cJjtI1 xhoS2Jcc72YNEPz2a3QUyT4K2gjMczSMzFtTaD3Tvcf+0CDfPvy3WlisYfrlLTCKhkuGM8IeYSv/ Iv3KwuyvZz9M7Ur1prr5v6ZfX8BbMY5DeA/+xdyPJG7GbRp+FhO4He+d02t8FfyENvl9+Df4z+v6 WRToGZNH8m/QDd/Rev8Mfgln4TJcRQM60YvB697fBg7A87rpXTzKZWjYAhPc0/AKpuAAfSIQoWjO cX/GP8Qz+x74Dj3X2Pnlj754G7cPN3H3wkH8IRfhYtyH3KH5g6AJVtHa78LH52vTGD0o0a3QhO24 FrdgEi9yNdgKn8Lv4Bplwo0SvESnpI/hPHJoQhFvwke4m7mrmMIhY9LgFD6fPyYO4gpaySYcxQEc gBnC68h+AJ6g9k46/3lBuj5vGE7QXlVhJr+FU/lV/P385wYLr9JR6Qx4jQ7uMtdPN+Fu2E+fbujG cojDg/Dn8Cbl/xJ+CYu0PD5JHtvpc1bYKtzHv4IqncFuhX7iP4MN+BhshUdofTdjHvfPIMIU9xv4 IfwCN/GtsJ+/D0/SCu04TJXzBPX6AKZgn3Bm/or+H/9fZEB4P2NBxnl4Dh4mOoQvCkcM78Bn8CP4 BeyAl2W5a0VT89KmxiUN9XW1NdVVlRWLy8vCpYsWlhSHioKFAb9UkL/A583LzfFki26X02HPsmVa LWZThtEg8HRaLkMlNxKbzMsI+wKBQHe5Lnu/Lit8yPF5QAHX15x8X3eaXPANOf8bcsF1ebUCotIe jLSxgSeh/RMF3AqKCrBZ0H0zzaRHEu0dCkYHlbxIbzxOPdqCDr/SfqlCD0ULeNJqiQQjfZbyMpi0 WAlaCZHvyCS234ga4NqjTZMcmGzlZYorrHChKKMhRd4bJxBso6WTxf2VhX6uJ+abgLqlnYDcNISK MaJkaPP6BxU5ocBe/2TZdHLiqAO2xMOZvcHexKaYwicoqZPAh6ID9PNGjFF8wK8INK/W+Ejjjw74 kyQztzi1wTbq9Xv1pDZHYt8LTPsUF/Go4gwry6nn8vs/9vHJaO6gn4nJ5Pf8ysE1sfnWAPPp7u7O LS/zJ6NBmqitvCw6tIwynVtRXsZSgHOp6Y0PsViGEizO6JA/ubdPi3VCi01zjQ7QxiT+N69kMtob jPYmetk0NHpEkbs0Bl0bWDr8UUpdW7eu0h3IImiWeFs35ZoFRqeECFmjwUQb1SCr0+uauK4hRXTO 6GdxrlTkuOLf6ldgbSxInZewpm8JJLcuYXVMw2B5WUfnV70UQ8gR9Ce/AAXjwQvnWcRfaRK6xhhy fAHM2B5sjyeT7UF/ezKeTNDRekvQ7wgmJzs6kiPROM3aSWcY0r+016e0T3QrjvgANlHuWQW0r421 +AJOWkda7JwTgUqKCotKmJ2LhBB9V+qM9gK6YnQEVGB9rNtHiYwx3EU4zVkhUeEuoT3W08Zy1McW SxMxrMNAgFXn3qMybKF9V8bXxNKyH7b4VJArwrQfcWaZnrNkr2eW8TnL9e7xIG3OC+w/N2QrpuLr X7vD444ONCno+QPmvrRdcUdivI9jBU+I8/EMWcJ0pzcrOWHCC8NJ2pbTQcURVgyxaV9zt9/hpCcA 2711wY41G2L+aPJ6FaQ1+kpZHVCpBxMDSf0WY0X/+7XszJlOOKtYuqX3UsbHtwxR0dA3McEeP4Gk Q2mfCfgCSWfQ5W+soFBZVTtOB1+jk6ubHmsOBZu1ZaP2TKP5Vyp8zhIysmj/pBn0RepLoufYsskg PrxmUsaH122IHaPTn//hrpjKIReJL+vuLmevYBA4ekPD/TucMtrhgMEM9cI01HJDsIdfB9m0XdqL EuKZYIQXiPvpPQ3bxj/2mntDM78fP1/4E7BA74rmX8b5AuH0KRIgSJ9VcJBOozvxcTxHFvpFY2bq wBPLl+1GTgCiSpChk3QVPW9++CZUUFNVGXAGnCFq6H8QXBk3wFXGgQC9dTpFTUjYqo2yUM7DU5zB eMpgcpj9ZjrDKkagk7EfeazoqblW3QMtF1ouVFUiG5E+XCj1FG5hxL2Pj1x9Eh+hEQ/Qae4NOs9l QT60yOFu162+fm7QJhh5WybnqTPxOXUZJpMd7dn30j5sk2SpU+JyxIzeAsfMhR7H5Z4L6Wl6qip7 UOQyjEKQpqoWcjwuQ21xSXFxMOisqa5vqK83vHFk71jq4oHUYvyXJ9G1a/+h1Hjf4Kq/GcvIeOC5 1Zvi3G9Pp16MdYQNZxbevDl14p39Z5aWmr7cZK5qeoPirJ/9lfCgUQQP5TYily+1Lc1fZVuVP+I2 BEszHQ08a7LB1+oU0BRYZrKIOeiF4VCBzzpSRJE6rl2rrmb5oG9VZTjcEwjUGY0ZRmOwkHPWsvBq qj05lHQnRVxozBY9FLTwYOqZwtsCpWsbpz9aFbnh+URsZwduTj3j7Sp4YHffzsWb714gO0QRb0TL /p93rlwfKsFfXi3kSmxO5akfPVFEUdfO/lp4XNgDBRCCbXIwZKu1tXK3CK22dUWj3P3ZJi8LO9Rs tULhjUbhYC7m0oNyKsvRwLicZ7Y25OY6ZTDn5Uley84SewmGrF5+pNgxQ9vruHyhhv4LU0Prabng aqygzQ73GPzgdECA2uyAx5PjYSuh9TXUOLUFu7UFZnAvp06mnsNmXEB/G4RraFiyuHzX8hvuqQqv zAmFl9/YeF8+n+jtHzUWYCXm0SF8Repc6toDqwclyefzuMucqbPOfLvdyX00PHb/ILtv91DzMe0Q DyVHOKS/NF7t7USWOasB0SBUGmRDp4HvcVKc4QvQQtsQoErBj1PP4GbqRiNkz57jbzI8Cz6IydlW FpnJZBNaLBmG3FyxBcy5VpYVv9nRYLXmt+Tfks8ZLTZvht0oGf08bwTewR/meZ6Kn5V/RY+TMkPv pwi2kFxTQSVqKCyucwbratj9kB1winP5qck2Grnad0/t2UP/R9ekDnP2rOVtCza6ChrHPcqrnO0y tqaOX07dtTQWDC7KtfyX3Um7q12zI/BaGn2jZa+QebqrSmA5rIBb4DbNjuDSn2dGQhCJtm6IRcJd iYHhHYnyZcN39P4PqqKNYgplbmRzdHJlYW0KZW5kb2JqCjUzIDAgb2JqCjM3MDkKZW5kb2JqCjM1 IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1BNSkxD UytDYWxpYnJpIC9Gb250RGVzY3JpcHRvcgo1NCAwIFIgL1RvVW5pY29kZSA1NSAwIFIgL0ZpcnN0 Q2hhciAzMyAvTGFzdENoYXIgMzMgL1dpZHRocyBbIDIyNiBdID4+CmVuZG9iago1NSAwIG9iago8 PCAvTGVuZ3RoIDU2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkM9qxCAQ xu8+xRy3h0WTWyEIZctCDv1D0z6A0UlWaFQm5pC372jDFnrwA7+Z3/g58tI/98FnkO8U7YAZJh8c 4Ro3sggjzj6IpgXnbT5u1bOLSUIyPOxrxqUPU4SuEwDyg5E10w6nJxdHfCjeGzkkH2Y4fV2G6gxb St+4YMighNbgcOJxLya9mgVBVvTcO677vJ+Z+uv43BMCJ2Ki+Y1ko8M1GYtkwoyiU0p316sWGNy/ 0gGMk70ZEl3baG5Wj8DiWFrFYlQlj54yo/z1ns1uRByrLqQmLkl8wPvOUkzl5Xp+ANXucWUKZW5k c3RyZWFtCmVuZG9iago1NiAwIG9iagoyMzMKZW5kb2JqCjU0IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvRm9udE5hbWUgL1BNSkxDUytDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJveCBb LTUwMyAtMzA3IDEyNDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAt MjY5IC9DYXBIZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9N YXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNTcgMCBSID4+CmVuZG9iago1NyAwIG9iago8PCAvTGVu Z3RoIDU4IDAgUiAvTGVuZ3RoMSAxMzYxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAHVm3dAU2fbxp+TsEMgICAaMcEjVAuIFgeOSgSCIA4QogkoEpagoshwo7iqxdra2tqtdqktbT0c 24pdWmv3sLV7a/eye71a5LvOubmt+r19vz++f/oGfrl+z/2MnPOcJGBKG+ubKoVJtAijGFxe660T +i1lD6J3+aJGO7XjqoXw7VNVN7uW2hevEyKw9+x5S6uonfKiEFJ6daW3gtriT+TwahSoLQ1F9q+u bVxC7ZSdyIB5C8q7+1OOoO1X613S/fjifbTt8721lUjchllwZ6+rr+zul9xYznJ+2+/r89shOCTM Mkh2YRFPCn9hQCYLrBi2RVojfNCr9ftu79j8+wths0LH/Cp6BaAgxCPfrMD5CPHMhj2bTp/q3BT4 rf9DaAZiBbphnv/2zneFCNp5+tSpnYHf6it1d+phUAON9g7DugcCo6UJkLUsa1hWs7SwrGJZydLM soJlOcsylqUsS1gWsyxiaWJpZGlgWchSx7KAZT5LLcs8lrksc1hqWKpZZrNUsVSyVLCUs5SxeFlK WWaxlLDMZJnBUsxSxOJhcbNMZ5nG4mIpZClgmcqSz5LHMoVlMsskloksuSwTWHJYslnGs2SxOFky WTJY0lnGsThY0ljGslzKMoZlNMsolpEsqSwjWIazDGMZypLCcgnLEJbBLMksg1iSWBJZElguZhnI MoDlIpZ4ljiW/iwySz+WWBY7i42lL0sMSx8WK0tvll4s0Sw9WaJYIlkiWHqwhLOEsVhYQllCWMws wSwmliCWQJYAFn8WPxZfFh8WI4uBRWIR3SJ1sZxh6WT5k+U0yymWf7H8wfI7y28sv7L8wvIzy08s P7L8wPI9y3csJ1m+ZfmG5WuWr1i+ZPmC5XOWz1g+ZfmE5WOWEyzHWT5i+ZDlA5b3Wd5jeZflHZa3 Wd5ieZPlDZbXWV5jOcbyKssrLEdZXmZ5ieVFlhdYnmd5juVZlmdYnmZ5iuUIy5Msh1meYDnEcpDl cZbHWB5leYTlYZYDLB0s+1keYnmQ5QGWfSwqSzuLwrKX5X6W+1juZWljuYflbpY9LLtZdrHcxXIn yx0st7PcxrKTZQfLdpZbWW5huZnlJpYbWW5guZ5lG8t1LNeybGW5huVqli0sV7FcybKZ5QqWTSyt LJezbGTZwHIZy3qWdSxrWdawrGZpYVnFspKlmWUFy3KWZSxLWZawLGZZxNLE0sjSwFLPspCljmUB y3yWWpZ5LHNZ5rDUsFSzzGapYqlkqWApZylj8bKUssxiKWGZyTKDpZiliMXD4maZzjKNxcVSyFLA MpUlj2UKy2SWiSy5LBNYcliyWcazZLE4WTJZMvZpvy3jt2a171gbfmdW+0Yi1lBrtdp3FFot1FpF sVLtG4xiM7VWUCynWEaxVI0ZhyFL1JgMxGKKRRRN1NdIrQaKeiouVGPSMaGOYgHFfBpSSzGPYq7a x4mRcyhqKKopZlNUqX0yMaSSWhUU5RRlFF6KUopZFCU0bya1ZlAUUxRReCjcFNMpplG4KAopCiim UuRT5FFMoZhMMYliIkUuxQTVmoNzyKHIVq0T0BpPkaVac9FyqtaJiEyKDIp06htH8xwUaTRvLMWl FGNo5GiKUTR9JEUqxQiK4RTDaLGhFCm0yiUUQygG02LJFINoXhJFIkUCxcUUAykGUFxES8dTxNGa /Slkin60dCyFnebZKPpSxFD0obBS9FZ7T8Zm9aKIVntPQasnRRQVIykiqNiDIpwijPosFKFUDKEw UwRTn4kiiCKQ+gIo/Cn81F55eHRftVc+wofCSEUDtSQKoYfURXFGHyJ1UutPitMUp6jvX9T6g+J3 it8oflWjC20d0i9qdAHiZ2r9RPEjxQ/U9z21vqM4SfEt9X1D8TUVv6L4kuILis9pyGfU+pRan1Dr Y4oTFMep7yOKD6n4AcX7FO9RvEtD3qHW2xRvqT2n41TeVHtOQ7xB8ToVX6M4RvEqxSs05CjFy1R8 ieJFihconqchz1E8S8VnKJ6meIriCMWTNPIwtZ6gOERxkPoep3iMio9SPELxMMUBig4auZ9aD1E8 SPEAxT41Kg0nrapRxYh2CoViL8X9FPdR3EvRRnGPGoV3feluWmUPxW7q20VxF8WdFHdQ3E5xG8VO ih202HZa5VaKW6jvZoqbKG6kuIEmXE+tbRTXUVxLfVtplWsorqa+LRRXUVxJsZniChq5iVqtFJdT bKTYQHGZGunFua9XI8sQ6yjWqpFVaK2hWK1GutBqUSPxw0ZapUYOR6ykaKbpK2jecoplamQFhiyl 6UsoFlMsomiiaKRooKXrafpCijo1shyrLKDF5tPIWop5FHMp5lDU0Lxqitl0ZFU0vZKigkaWU5RR eClKKWZRlNBJz6Qjm0FRTCddREt76IHcFNPpcKfRA7lolUKKAoqpFPlqhAMnlqdGaNs6RY3QXrCT 1Yi1iElqRBJiIg3JpZigRuAXCSmHWtkU46mYpUasRJ9TjdiAyFQjViEy1IgWRLoanoUYR+GgSKMY q4bj9wLpUmqNUcM8aI2mGKWGaa+jkRSpath4tEaoYW7EcDWsCDGM+oZSpKhhiSheQiOHqGHaiQ1W w7Q3pGSKQTQ9iR4hkSKBFruYYiAtNoDiIop4ijg1TNul/hQyrdmP1oylxey0io2iL82LoehDYaXo TdFLtczEmtGqpQTRU7XMQkRRRFJEUPSgCKcJYTTBQsVQihAKM0UwjTTRyCAqBlIEUPhT+NFIXxrp Q0UjhYFCohCOrtAym8aZ0HJbZ2iF7U/4aXAK/Au1P1D7HfwGfgW/oP4z+Al9P6L9A/gefAdOov4t +AZ9X6P9FfgSfAE+D5lt+yyk2vYp+AR8DE6gdhz5EfgQfID2+8j3wLvgHfC2ea7tLfMQ25vIN8zz bK+b422vgWPwV80JtlfAUfAy+l9C7UVzre0F+PPw5+DPmufYnjHX2J42V9ueMs+2HcHcJ7HeYfAE cHQdwv1B8Dh4LHih7dHgetsjwQ22h4MbbQdAB9iP+kPgQfQ9gL59qKmgHShgr2mp7X7TMtt9phW2 e03NtjbTSts94G6wB+wGu8BdpiTbncg7wO2Ycxtyp2mubQd8O/xWcAv8Zqx1E9a6EWvdgNr1YBu4 DlwLtoJrMO9qrLclaLLtqqAptiuDZts2B91luyJot229Mc62zphqWyul2ta4Wlyr21pcq1zNrpVt zS5Ts2RqtjbnNi9vbmt+r9kR7he0wrXMtbxtmWupa7FrSdti18OGy0SVYb1jjGtRW5PLpymiqbHJ +EuT1NYkZTZJg5skg2iyNNmbjMGNrnpXQ1u9S9Tn1bfUK/U+o5X64/UGUS8FdXQd2ldv7ZuFdKyo N1uyFroWuOraFrjmV9W65uAAa1Jnu6rbZruqUitclW0VrvLUMpc3tdQ1K3Wmq6RtpmtGapGruK3I 5Ul1u6Zj/LTUQperrdBVkJrvmtqW75qSOtk1GfVJqbmuiW25rgmp2a6ctmzX+NQslxMnL/pY+tj7 GC3aAUzugyMRVil9sNVhPW79weojrIr1kNUYHtrb1tswMLSXlDGll7Sg16peV/UyhkYfjTY4ogcm ZoX2PNrzo57f9/Tp4eg5cFCWiLJE2aOMkdq5RU0q1M5tX1RaJuWQYfq5ToqS47NCI6XQSFukwWmL lETY8bAfwoyRBy1HLYbQUCk0tCvU4AjF8NAQW4hBu+sKMTpChozICjXbzAbtrstsjHKYUdEO/qLg vMKsUJPNZHClmaaYDA5TWkaWw5Q0OEsYJbuE//JjQRgDtKORIm1ZHZLYFyX5Sh3SlvbCgoSE3I4A MTVXCcgrVqSNSlyBdu/IL1L8NirCVVTsbpekKz3tkiGjUInIzS+i9vrNm0V6TK4SU+BWdsZ4cpUW iEOTLoiIaY8S6Z6EkoamhoSExhLclTQ0JujfaElNWgs3dOC7oRFt7QuBttB6/v5GwzBuVgNu+jK0 +t9P+S/okf4LjvEffojtAk9R97guwzpRYVgL1oDVoAWsAitBM1gBloNlYClYAhaDRaAJNIIGsBDU gQVgPqgF88BcMAfUgGowG1SBSlABykEZ8IJSMAuUgJlgBigGRcAD3GA6mAZcoBAUgKkgH+SBKWAy mAQmglwwAeSAbDAeZAEnyAQZIB2MAw6QBsaCS8EYMBqMAiNBKhgBhoNhYChIAZeAIWAwSAaDQBJI BAngYjAQDAAXgXgQB/oDGfQDscAObKAviAF9gBX0Br1ANOgJokAkiAA9QDgIAxYQCkKAGQQDEwgC gSAA+AM/4At8xnXh3ggMQAJCVEioSWdAJ/gTnAanwL/AH+B38Bv4FfwCfgY/gR/BD+B78B04Cb4F 34CvwVfgS/AF+Bx8Bj4Fn4CPwQlwHHwEPgQfgPfBe+Bd8A54G7wF3gRvgNfBa+AYeBW8Ao6Cl8FL 4EXwAngePAeeBc+Ap8FT4Ah4EhwGT4BD4CB4HDwGHgWPgIfBAdAB9oOHwIPgAbAPqKAdKGAvuB/c B+4FbeAecDfYA3aDXeAucCe4A9wObgM7wQ6wHdwKbgE3g5vAjeAGcD3YBq4D14Kt4BpwNdgCrgJX gs3gCrAJtILLwUawAVwG1ouKcS3SOthasAasBi1gFVgJmsEKsBwsA0vBErAYLAJNoBE0gHqwENSB BWA+qAXzwFwwB9SAajAbVIFKUAHKQRnwglIwC5SAmWAGKAZFwAPcYDqYBlygEBSAqSAPTAGTwUSQ CyaAHJANxoMs4ASZIENU/MPfpv/ph+f5px/gP/z4omeVaH8xJMSZref+kZDIE3NEg2jB12Vis9gq Dor3RJlYC7tR7BS7xN1CEU+I58Rb5836fzbOLPWtFcHG/cJP9BCi61TXyTO7QIdvyDmVrWj18LH/ VemydH13Qe27M1u7LGc6/MJFkD7XbDiG1X6WOrtO4eernzB3Ddfahg3wUP2RfvTffmbvmd3nnUCe yBdFoljMEDNFqfDi/CtEtajBzswV80StmK+35qNvNrwKrVkYhfcS3f8atUDUiQWiXjSKJrEIX3Xw hu6W1rdQbzeJxfhaIpaKZWK5WCGau+8X65UV6FmmV5egZ6VYhSuzWqzRjZMqa8U6sR5XbYPYKC7H Ffv71uVnR7WKTeIKXOcrxVXi73zzeT1bxBZxtbgGz4drxXVim7gBz4ubxS0XVK/X6zeJ7WIHnjPa jOtQ2aHbNnG9eFQ8LR4U94u94iF9L8uxt7QjvC9V+k7XYQ9W4JzXnnPEtJuLz+7WSuyGdt6t3ee9 BPu35pwZi7r3Udu9tRip7U5r93XQVmnurvBObMGZkf91ntoeaedw1XnnyTP+r6p2xto+3YL94p3R 9mwbajf9r+q5I871beJWvAJvw722q5rdDifbofu59e1nx+7U++4Qd4q7cC12C804qbILtd1iD17b 94g2cS++/vJzjXrvF/fpV04R7UIV+8QDuJIPif2iQ6//p769eO+4cM6+7rXUs6scEA+LR/AMeVwc wjvNYXxx5THUDnZXj+ijqH0Yf0t5RB+l9R7Gc+sZvEM9L14QL4qj4im0Xtbvn0XrFXFMvCbeksyw V8VXuO8Ur/h+KkLEOPzh5cO4GreIElHiGF8xq2TmjOIij9tVWDA1P2/K5EkTcyfkZI/PcmZmpI9z pI29dMzoUSNTRwwfljwoKXFAfFx/uZ8tOiLMEmo2BQUG+Pv5+hjxm22iU84qtSvxpYpPvJydnaS1 ZS8K3nMKpYodpazzxyh2bZ4XXeeNdGBk1QUjHTTScXakZLGPEWOSEu1O2a68lCnbO6SifDd8c6bs sSsndZ+ku0+83jCjERuLGXZndHWmXZFK7U4la1F1q7M0MylRajcFZcgZlUFJiaI9yAQ1wZQBcl27 NGCspIthgHNUu0EEmLWHVYxxTm+FkpfvdmZaY2M9ek1k6GspfhmKv76WvUbBMYtN9vbEQ61XdFhE WWlCcIVc4Z3hVoxeTGo1OltbNyhhCcpAOVMZuOzTaGxgpZIoZzqVBBkHljv17ANIim+cRba3/ipw 8PLJb3HU51S83RW/OMuvQuvUTvHsNimSl13g2HCEOL/YWO1YNnU4RBkaSku+m9p2UWZVhSM5waMY SrWeQ9wT6dJ6Wrjn7PRSGTvrlJ2l3d+LqqOVljJ7UiKurP4dp/jEod+uGONLy8qrtfRWtsqZOEPs pSjEhzaZEIe3ezOd7YOTMd5bipOo0bYh360ky3VKhJxOu40CFolz1hS49SlUdSoRGYooLe+epSQ7 MRdPEWerdmG0A9TWkvPdB0RK1/H2oXbrvhQxVHi041CiMnBR4p2t7ooqxVZqrcDzs8rutsYqDg+2 zyO7Kz3aVZItysDjeDjccAH1WTi3C0bzYJy24h8XYHcbrEaPdrVQsGfhTk4fgw6L4kdN7Yqmj7G7 JavgYXiU7hGanbcOGsa4jGxMRmJqRrY1Fk9u/fYfDslKJ4DDUALOHpMPDsL3r2Oix/nbQ6PR2gEN tDsrM885wPMWRUM/wO7V/v1xGrS96N4MHEKAdjmztXNISjTA7egOUAw4T72kXcVouyLy7G65UvbI eA458tzaxdH2Wr++uQWy9sGgfrW7nyWF57WoP5X6FBGbW+jmhvaZjZKVoF9X7bLq7fF6+2wz+4Lu HO62twbIuQWt2oPL3QsKO15BuDh+8TneTanhQ/FizcIbpZzlle0We1art6Orpay13eForXOWVo/C y6BVzqlolQvcY3At9dd9s3WZ9tDhIlfKLUxPSsR7T3q7LG3Mb3dIGwuK3AfwB/r2jYVu1YAPRUvT Pe390ec+YBfCoVcNWlUrakPsWkNbaSoaAfp46wGHEC16r49e0Nvl+FxWr9Eg1CRR3mGgmoXHGVDz oZpDr3lwwyssuhqXAO/DTnuFdnlWeKpbSz3ai0tE4VLiW1IkeaxQDPJYfJTrF6wEyZXpiklO1+pp Wj2N6n5a3V9OV6QoCZvTgfek1lIZ71N4yrnxEbkHzw6L9uw3xNk7uroK3bEvWU96YvGSmAGK3Epg An4O+MZNwLjxGqUoj1dayr3acQgXXuraKzOn3IPXAi+IITlKIFYI7F4BI7L0OdrTEZPKcW1wAfX5 LWgoLR7Fk6A9qLtGOyK73aKIbHkULjut6RuvPVCypzVcvkR7YmOoEhS3QYtAHJvAh9R6xYomHgxv uNoZ+QfjyMtldJWX2nEFfER5AZ7q9F4apF03VCrxlugTX6kTZO3uFNppGeNM5iAlcBAWxLfmpkFY EN/+HmyKdvJ6a0P3ADy2RTHhiOLP2cruCdgddOVox4LvDTh4begT2jL5HWKqvARvjdpB6w/lj27F HJfjxZs/zTehIqfyZKwVEKeVtDWOUNVfO/Ng7LsxrrCja7e8VHsH4FtSoqz9cNCemMJ6AE9s4Wm9 sKAUJyQlBlxYNevl1tYA87+fQPsVYD6b2ip2J37WCOGj/W8sR/GQCHxpt2D8eyoYGXu2IvD76W2o +OJfmA3GY/jXmBH/v8tIMUlMFsWPCjM+NokSo6QHH4zMzAxI8n8cH4kYhB0fqgQIScpwhPoYzPt7 906T9w/z22wMy+mQkh5I89+MjwvTOj/sfDm588OT4SOTT0rJH5z48ITlx5fDRiannHj9xJDBUlhs mE5EiMHfP8JP7jfIMOyi+OEpKZeMNQwbGi/3CzHotaHDR4w1plzS12DESKqMNWhtyXjszyLjlE4/ w0o5bVqKb9/eoRFmP19Dn+jwpDFxloLiuDGDYvyN/n5G3wD/ASPS++XOc/Z71z8sJjIqJjwgIDwm KjImzL/zPd+QUz/5hpzO8Jl3+lqj3+gZaf2NNwQFGHz8/Dr6Rve6eHRszrTQHhYfUw9LWFSAf3hY 8IDMGZ2XRfbR1ugTGUlrdU7Sthe7Gt690374TVXkTZowMaMgIcM7r6asvuZ/ABmTduUKZW5kc3Ry ZWFtCmVuZG9iago1OCAwIG9iago1OTIxCmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T dWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1pESUJZUStBcmlhbC1Cb2xkTVQgL0ZvbnREZXNj cmlwdG9yCjU5IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAv TGFzdENoYXIgMTE3IC9XaWR0aHMgWyAyNzgKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDcyMgowIDAgNzc4IDAgMCAw IDAgMCA4MzMgMCAwIDAgMCAwIDAgMCAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDU1 NiA2MTEKNTU2IDMzMyA2MTEgMCAyNzggMCA1NTYgMjc4IDAgNjExIDYxMSA2MTEgMCAzODkgNTU2 IDMzMyA2MTEgXSA+PgplbmRvYmoKNTkgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9G b250TmFtZSAvWkRJQllRK0FyaWFsLUJvbGRNVCAvRmxhZ3MgMzIgL0ZvbnRCQm94ClstNjI4IC0z NzYgMjAwMCAxMDE4XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9D YXBIZWlnaHQKNzE2IC9TdGVtViAxNDUgL0xlYWRpbmcgMzMgL1hIZWlnaHQgNTE5IC9TdGVtSCAx MjEgL0F2Z1dpZHRoIDQ3OSAvTWF4V2lkdGgKMjAwMCAvRm9udEZpbGUyIDYwIDAgUiA+PgplbmRv YmoKNjAgMCBvYmoKPDwgL0xlbmd0aCA2MSAwIFIgL0xlbmd0aDEgMTU4MDQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBpXsJfFTV2fc5525zZ5/JZLYsM5NJJiGTkJBMCIFIbiCJYETC agZNCUsQ3EgExB1ckeAS942WaF0o2DKZACYsNWpduliptlZ9a+VtsaiVT9oiWiUz3//cCahtf+/3 +75vwrnP2f5nec5znvOc517WXrGui5jJRiIQbdllS7qJ/gsOgfxs2ZVrg5l0VhkhyqIV3Rddlkn7 bydE+v1Fl169IpMOPUtIzoMru5Ysz6TJKdCJK5GRSdMYaOHKy9ZelUkHO0HbL129bKw8dB3S4y9b ctVY/+QPSAcvX3JZFyh+Z92PR0n36jVr9SQ5qwm0rfuKrrH6tJ0Qx5vfTVsJoajlJn8n9eRuIhNG 7KSCLMBM6tmLREKal0u2C38ya9PLi231nxt8Br35J/5cn8cjLz+2dMFXX50atRNDIeqqen1eAJwy NXUemW4nX3311TX2TE+85PTPPTB/Y6NFeJbsQkDHeAYR+hHAaOHZQcVSpQ2BOl06TbqjVcPpEeHZ 5ORqPb/8/qqNB4SdZDGpRvbO5AKevXNQa+LVdw5WT8nQigk6TRoyxYqrKtDoB6wCgRHbWGw26N0I 2xCeR5AxoJ3kA4Q0giBsF55ItgTQ8FNoyNboEp7CFDU830BIIwgY/VOYy1Pks7EcEaP64aBq5t3/ UEflCD8EyoanHWEjwi6ENxAkshrPbQhpBAGxJ1D2BGHCE8LjSXvA3mgUfkA2IDDhUWKjlATQ+sOD dp03jwzasqq0RrvwAGlDYCQhzCIjCAzN3gPYPYShemuyfILOwtZBo7XKjvpbMOgtGMgWdNmPJ9XT GmK8/pbBLDcf/M1Jm0PHXZusjGUig3ZvVRu4cBWhQpdwOQmTgHADaD7oMtA80KXCcmLRx6kN2uxV G9FfA6o3CNlkHIobBTepAm0S/CRHr7Yuac30sy5ZUlqFGU8XvHoVm2AhMVQ1CEqyKhDcL2g6828f VE18fLcn7dlVB4VbBYW4UGsjankCtoOCEWts1Gcyf1C1VPU1moX5mOZ8sCWAMVJwmT814fIkGmp0 CM1CLjZDQLhEyCPZoC1Cvk6fER4nLUh/fzCSGxjZL9yno+7ljaL7qRnRmjposVaNNKrCVJQmhLuw AHfpnfcNRiZVkcaIUEIqERh4vAGxDYjZhV7EerFqvVipXqxULwbVC+kjwmaUbEadCuEa0i2sJ30I 2xDnYpWdBEP5ZshOFpZUDQs+wQvG2PeDlRS5/kHVykfmTTqz9GreQbO1quGgsIbMRmCY8tpBj7dq 9X6hVJ9K2aA3hwO6kxDXg4InszRoyc2X5KCQC0ZwxuQJ+cnsQKIxgDQX5ACh7BfsEGcSe4v9ji83 ewNpTn85Rl8fo7/O0PQIO5TZFOxNTg835rIP0dhi9j7Zhhhj+9lLpBINvMeG+Oqzd9kwaQB9B+nl oMOg1aD7kqHXAkNsaBAEY38saXHzybKXktGKsUigaCziyRmLON1VjUXsRfYCyUUTvwctBH2BjZAC 0OdBvaAjbC15DXQPqyFTQHeP0Z+xA1zE2XNsL5kEOpi08iEkkgonu5IyJz9JkkyqrSJwgP2E7SR+ VP1xMuJH4fbBSGHAth/tUfYUW5vMCzgbjexx2k5PoFI/eYdT4mRPJGt5I33JA8HAMOtjfZq3VivS yrWnhcqiyvLKp4VgUbA8WBt8OthoZ3dBgWxj2L9sC561JMggPQgaQh/bnBRrE42jmBOfFyMb8ezX Y514dusxgqddj/HS43qsgd1KZiMwtHEDwgaEjQg3EhHPaxCuRbgO4Xo9Zy1i6xDWQ5t0A9ENRDcQ 3TqiG4huILqB6NYRvOduILp1RCcQnUB0AtGpIzqB6ASiE4hOHcHH2wlEp45oA6INiDYg2nREGxBt QLQB0aYj2oBoA6JNR2hAaEBoQGg6QgNCA0IDQtMRGhAaEJqOqASiEohKICp1RCUQlUBUAlGpIyqB qASiUkcEgQgCEQQiqCOCQASBCAIR1BFBIIJABHWEHQg7EHYg7DrCDoQdCDsQdh1hB8IOhF1HHAbi MBCHgTisIw4DcRiIw0Ac1hGHgTgMxGG2fkA41PgyIIcAOQTIIR1yCJBDgBwC5JAOOQTIIUAOjU2d M4ILzAiwI8COADuiY0eAHQF2BNgRHTuCmiPAjujYBBAJIBJAJHREAogEEAkgEjoiAUQCiISO6Aei H4h+IPp1RD8Q/UD0A9GvI/qB6AeiX0f0AdEHRB8QfTqiD4g+IPqA6NMRfUD0AdGnI/6vl4bdSNsN OGvZRjpOpxvIpzq9gbyj0+vJgE6vI0/r9Fpyk06vIbU6XU8iOsVS63QtCRhoMlBra3RDBcxGWIyw GmEbwi6E5xEUPfYGYh8gpFmNViDalNnKNmWX8rwi7VIOK8wmz5a3ybvk52Vpl3xYZsHGHGbR9ShU C7kbOEo24PkZAg4RPBv0WAOLod8Y9GwN/mIspjmOBT8rpW+U0udL6a5SencpbVTZ2VTUNV2Q1DIw gLZr5sjUwDsItZHiqdBMd+391BNIRiYGhuiBDBmnRZH8FGEA4WmEmxBqEaoQyhGKEAIItZFSwNq1 grEmD4AWI4QQggi1xO2Gmeh0GLRhZqFPD75sISrvp7gEuP3J4kqQoWTxbJDnksVLA40q3UuKuVVE 92BT7QTdlQwcQfGPM+TZZGA/UtuTgRhIR7J4PMgFyeLXA40WuoAERA6dP0bnYcF5em4ysBDV5iQD 40CiyeIIr12KjopQOg4W9RFQxHV0YaancDIwBbULkoE6XttAivnCU5mU68OTEOdpYRAD+myYtotU MwWOBe4LfIrx/hWMhXi8GxwSQd4oGqILNWPgQPkPULkxkGw08vo4HwbGaILTPYGnizYHHkNbtGhv 4JHA+MBd5UMGZN+JcW/Wu0gGbgoOsZ1aVmBjoDKwtvxIYE3gnMCSwNxARxHyk4ELAwf4MEmctrOd ewNtaHAmZlGUDJxdhLFgiC2BqwNaoDhQFzzA+Usm8a4hyeUHOAdIVab3MvC3tAi9JwMLaoeoQytV jit9ygXKNGWKElYKlHwlT3EZnAa7wWowG4wGg0E2iAZmIAbXUPqwFuX3BJesXxdkkSdEPW5nPI4H noRRAyPnkESW0Mpa502jrYmRZaR1aTBxcl54iBrnLEpI4Wk04WwlrfOnJSZFW4eU9NxEbbQ1obRd 0D5A6V1x5CbY7UOUzG8fommedWtOwjkdheTWO3OGCaW+W++Mx4nXfWWDt8E51VHX0vQfHp16ZmdT 9Juf99vRvMSDrfPaEzvy4okqHknnxVsTN84LXtg+zGzM0tw0zKycxNuHxW5ma57L88XupjiqHdGr QZqtqEaKOUE1wzQS5NWgT6bxalijTL0I4KgX4gT1jBYS0etFjBa9nkh5vYF3gs1NA0E8UKeIkHf0 Ou8UkW/VgcQA2zQQwQO1wkHazmvR9nBQH9g4vaFAAFXK8UAVCntPbyhA9c4SFd9UKRqrUnOmSo3e l5AZj94Mf6AZV8npOq4S1PmGkf9vsa5pUTo4Yd0NLzV3hZs7w81dCJ2JLVeu9CY2Lg0GB25YxwuC CSHSuXTZSk6XdCXWhbuaEjeEm4IDE3TcvxS/xIsnhJsGyEvN89sHXtK6mpITtAnN4SVN8cGG+vbG 7/S1+Uxf7fX/oa963lg776tBx/1LX428uIH31cj7auR9NWgNel/Nq7jct7UPGMi0+HSsK6eDzGSE DHfmhOLT3PbuqVygh6eEvDfk7BMJ3U5M0XjCHJ6WsCDwovLG8kZehH3Gi6zIto0VeW+YEsrZR7eP FdmR7QhPI6cXgnB8a6JmTmsiNG9ROxeVhAYW/Kc1W8N/erGXNK9qwj+k1+ph7Zq1p1vklPCa//5b +59+69atW7MWj3XRNYS0JkrntSYmzsFIFAVddTbFkTf+dJ4g6HkDqto8lB5BYRSDoGt5dzwWpVFw UDMSmSisX+5XGL9FrB3051WtPgi7YQMCrsNsfRKuBF60frCgCLclVKmoyVBcV3k66Q9VoYfBWkA5 LcpQzVGOSF9RX3lfbX9Rf3l/rYzSvU8jM/A0P0qTFU8LZG10zWlmILo2DmZjWLy/x5O5eXrH/TwS jcaja6jOr9P1v6F6PpLfMBZz1H9r9OY5v3UO48mjYDovxXpkel/HU/yXiehY8FkHIRe1Mik9iz++ +SEFV9E+kquHZ0iuGMEdi6SPnA6pVekjvIxT9gk0OTxIPIz9kuRZ8ntaQoNkkH5FPORL6qMTyExI 5xe4T+wio+QBXO/nkwepkxTiNrqAzKQi6kTJHfSx9JXpj8lZ5F7yRPo5elN6B8rvJq+QLzGCP+LE rCXnof4C0kU+Fj4k8fSjxEA2EROZQuZSN1lC3sbf5xjHfeR+8lN6XfpL9OoiN6G9etJIGtMvpE+R UnKH2Ce9o+4h95D9VE4vS6+ChVRAelk0/Xb6AxIhcfJD8izGFKUj4gwSIpeQW8nD1Ce8gtgD5EmS ombWIUyXnkdPM8lCcjlZT3rJDvIL6qRt0jvS8fS16aOQwixSgjGtIh/TGjqLPSWa01PT75ELyDB5 DfPlfyPiBeIz0gWphvT30y/i9v0cNdID9AWpSrpr9Mb04+mfwF8ZIRPAkfPQz1JyM3mB/Jz8jfyd bUhvIDPIPPT8Ms2jQRoBx99mPnYDu0F4i4zHbDsw2nVkG0mQJNlH9pOD4M1/kcPkQ+qiOfQcupTe Q//OzGw5e0N4TNgt/Fak4o/A7zApAo/WkqfIXvIr8jp5g0pov5K20YvpavoQ/T49zBLsU/aFaBBv Fr8WR6VI6nDq6/R56c9x5/aTc8k1ZAN4+0MySHaTX5PfwSv5D3KS2ukkupI+ThP0MP2UqayAzWbd 7EHcnn8snCfcI7wg1ojTxEvE18X3pNukLcoSJXXq6dR9qR+nfpN+Lv0byI4V7UfgwFlFboRUPEWe J2+h9XfJ++RPXH7Q/hS6iH4Pvayht9P76Y/py/Q39BPMEhYH/grYFNaEXlezK8Cnm9h97H70/gb3 dMBJ8T77K/tckIQCYaLQIzwuJIQh4ZDwF9EuRsTx4gRxtrhITGNlqqSzpXnSdmmn9KJ0XK6Xl8vd 8kfKTcothl+Nlo7+MUVSK1OJ1CBk1wBJugac+AGBExC82E9+AY7+GiM+TE5gFfw0RIsx7jraQlvp LHo+vZB20ZvoJnovfZg+Rp+gP8EMMAemYOxR1sjmsSWsi93CNrE74cvYzfaxn7O34VA5hpF7hLAQ FSYIM4VFwgXC5ZjDWrjybgFn7xF2CG8IbwlHhY+EY1g1j5gvrhOvER8RnxF3i7+RzpUuw98T0vPS iPQb6ZR0SmayX86VK+SL5e3ynxRZmai0KZuV3yr/MHTTXFqKkQch+2d+zIc9mM92MJe4gR5Ddh5u HTbMPIp1mIdd8Q/SIKSwLlZejrFlM5+YxeGyJiZgCK6l+0kNfZlskJkAw1A8TJL0D+yw+BI7i/yO dlKf+IxwufQLFiI7oY362AG2n04ju1k9W8i2CoR+iFPxQ8j7VeR+egldQ3bSY3QyvZ7W0g3kt8wt zKO3kPr0E0ykKp1JjxOMgNwoLiffOzOF/xihdfDOf5z6gWgRr4N+GiIPYkWfJR/QH5GvqJT+FNpN gDZaAi1zB+T9VsK1Xgf22QbsRx80yKXyG2Q3leFDr5WniteQ4+Sf5GNpHyRqGrTp0dQq8Qfin9O1 6XLsMOwysh37biU5GzvmQ0jJQaR56kLsdCN0CZyPpI0sgvPsemi9e9KJ9Nb0zemr06vJL4H9ipbR r2g/dsQQEPXwe72GXfIu3YJ9ePZ/nN7/MTO1nIyQT6iXFtEq7Idj0pVSn7RD2i39VHpdngBu30Ie g0T/CdJsxAyWkd+QT8gX1IC18ZEyEsN4J2Hs7eRSFhcOkunUT7qxZ0ugx6eNzWQNWrkJ3NuK/XwQ e+M49MSF5KfwnzHqwYyWoX8D2mkFnxeTNeRprODNdBA5y6G1S8lfMW8rnQT3QBnR0NKD0FojGNMf yF/A7bQ+rjLohSa6EG19Qc4ny9HDRNJGB7ACe0kdNGuT8Cvwu5DayTRaQJ8ErhM71Arnd530Z8pI Weq89CS2SjiIMyaN/H6cXjnkLNqDUdgwj1GSTWeTmtRcjOEtKogJ+qY+ikdYV3qTsD51Kfkl+RHW RBOvVJoI0Rrnaw1Tz6qfMrluUm1NrLpqQmXF+PKyaOm4kuJIUWG4IBQM5Ofl5vh9Xo8725XldNht VovZZFQNiiyJAqOkrDnc0hlMRDoTYiQ8Y0Y5T4eXIGPJtzI6E0FktXy3TiLIcUtQ9J2aGmqu+Jea WqamdqYmtQfrSX15WbA5HEy83hQODtFFc3CbSNzZFI4HE8f0+Cw93qfHLYiHQgAEm70rm4IJ2hls TrRcubK3ubOpvIwOmIzTw9O7jOVlZMBoQtSEWMIT7h6gnqlUjzBP8+QBRgwWTDHhDzc1J3xhQNGM UNS8ZHmibU57c1NOKBQvL0vQ6cvCSxOEW79RvQqZrneTkKcnFL2b4CpYtwmyJThQNtJ7x5CdLO2M mpeHly+5sD0hLEEbzQlHFP02JTzXHPF+k0TjsJM3fbs0R+ht9q4K8sq9vZuCiZE57d/C5oR4C/E4 2gCWFbV09rag6zuwUq38SpVgt8bbE/RWdInLQpE+q8z8MjeZos6Lgwk1PC28svfiTiyNvzdB5l4d Svr92nD6MPE3B3vnt4dDiYaccHxJU+6Ai/TOvXrQpwV93y0pLxuwOzKMHbDaxiJmy7cjXWB6pkyP 6dV5rHXuGc5SPsbwTNjjieCyIEbSHsacJvFH1yTSu2wSFgC/OAUqsRwrsiqhTu/stU/m+ZgiTUhF 9nCw93MCCQgf+/S7OUvGcuQi++eEF3I5OSNqCbrkdDwRjSZKS7mIKNOxphjjVD1dU1525RCbGO62 wzcyERdB0gbeLolPrgD7QyG+wFuGNLIUicTGOe2ZdJAszUkSrQL3JdbJS7CAmZLsBbxk4+mSM/DO MCR5N/dbkOyEIXLmn83uzmpeOTlB3f9DcVemvHVeuBW3m2Bzb+eY1LbO/04qU84ZCr6hbCyWyJre LuQw5PEYyxH0UgjlhYvOVEGi3ZwQi/BP5oPG7hAglHoGDbYk7J0zMs+4MRQa2zL/jhlSDN8CDaWP c5ROvoGNzSIxOTo2zsyoE1O+k/7O6My9Qut8aBzWOn9Rb6/xO2Ut0GW9vS3hYEtvZ++SofTGpeGg Pdw7zJ5hz/R2N0MLZRZ0KL1vS06i5Y44prKSTobYMjJtIExvnzOg0dtxfR2Giyl4+/z2JKNseue0 +EAhytqHg1C5ei47k8vrBHmKtFIIepIZ9KKcYY2QjXpdUc/Q08vgXtLzMpWQR8myIZbJs+v14vF4 OQx+eLbqcHd6ldwv15Gl8g5yj3InUcQ1ZCbCAvHPZD5oI9tBvDyOuvchvVmnfyb3IG8uwha8tNyE /ErUCyB9JyFomIsdwW1AxslCSBC3gUyOnv3/9eDOOLym/FYbcBb820/6txwYb8hTYOWqsE5MiJsR LDgfCU5FO3GAOnEHcuFew38T8beTnseuEh4R+6Wp0l75gFJvKDVcqzrUs9UDxpgxaSo0v2o53/JL 1MYhB07iDyNTyLTdjKZkZYg1aFlEElMCMSpiihKfQZZSTDhAI0TFxcJLvFH7yfrR+vPsJ+pnjdaT BsTtp/CYUBlyhBxFeMATSU4FhZFTmkS+JkFxBH3htkikJbjT2uEB3aBVl0glxrM9XWKXWSr11Hlm uOPulW6pzjMxZ1POI9KDJingKMJaZzmLbHaDr3iXQhXuJlBNMQzxDi1rY4gGQ5UhFnI4gyRor7Qz +xDbMhicMM8bxdA6+Nhm2Tt6TkZ7Zh3TB8kHOqGSdPTQjqxQlcftdma7YHfjLxyijuqq2qmsJhaJ FEfC97O85zpvHOosr10x6+alT46+RUvev652xuL6+kvnTd0j7cuNvJg6+us9N/cvay0NiC+eqrE6 F768Y8feFU79K5Gl6aPSQektSNA7Wsuk/Nb8hcqVhivNtxpuMd/quSVHlT1yjtPjzClxlHhL/CX5 hhmmC8T56iLTxeK14jXetf691r32Vy2v2H9vP2q3CrlykGDqWsBfh3fIpIhR6s4tl1WnZnXGnK2z s2iWlu2NZQ3REq3UXW6DrU6DvsXILnYuZIFgUGD+YEFlASvwFfcbqc0YMFYaBSO4OBi6YVuGW+DR efaOk5xp9hPHehzOugqs7OiJaMeRaMMxB1KjPdF6ZHMG0o4OWhNyyGK4oBAsc9ZOrA6KHikSCRfI 2XZnddXE2hqhgd3Qkdq25y+pHc+ODN/5JnXQ6rLUe4GdG1/88KMDHfuns5wvRocWbX6BXvTWh3T5 4pkf/qL20utP/j31derrmbF9mOc9EH4f5MXMvJrJJEQMEZMgClSA8tLU3MkxY3DylJgKR/jgGNWe zB2PXDxk1WD8s/qpURRVozGL5Yp2NWAMszIxqFYYL2IrxS71YuN6dpX4pLrDuEfdZzypfmV0bxP7 1G3GV9SfG3/P3hHfVt81HmUfiR+qnxgt69WrjDezO8Sb1TuMfUxpN3Wxi8WL1JXGK9nVotLEWsUm tdV4vuF8td2oeI0V1hibLMbUKcYGqyIwsyirqjGb+UWPqgzIbPr8di3ARMGoSmZFqZKt5ipsQbvA DG0GS8zEH/osrSZLzKBZi2Mm/kDWVs3OIyaDgB1GmWKEYmior2/AwnjqMt6lDlpxzP7bYzwjZyg9 RStHL0HRoKpVgugSBBFuT2OVwBBlaEYwi4yZjUZVVQwBK7UOUcsgt3/3sUlEwm67oCMmcdHzzJsf k6oUTdlgoIaDG7AKB01Bk5kNsUmaE1pEQ0WioRKpCpipmTdjmbAOiuJEz7Fo1F7/v+z1fp99tGe0 p97vtY9Go8iwH+nB4EExfox2kzQ+uun6n20a7+UkGp9QiXcVWfPgvTekDw+YgpMmxSF3/NdzBZ8q ifZ0VEPVUK50cMl33EP34yai0AOpY6n3U39O/VHad8orfPRVi3jT1zfwAJlSoEy3cJmiac0ZFaJy 0FRtEolMTZp/cgyexo2DoJz5p2nSVwMZO6qp/ryY0YeH+XSK8BS4c1iLu/NiYhAPBcssm/0kWx1H ilTlY+NR8xfqP41fmKVXpZ8bXzW/R34LqXrb/An5UFV3ij+UdhqfMu8XB6X9xj3m10R1vFggVRiD 5sfE+6THjA+YDRlh2W2gVgt3gw5aQ3xwI5qKCIQixIe8dTAjL1u1bC49y3nKJEMJKBARVZcQyMg3 EkKxi+tydr9oEqXgULpyUIaADKWrtAsFYg4SgbEg3irhvZtRlqQqk9FlwqVIVpSgQXUZDKpoMpvH RAmdCGYcIqJZkIwmRcXbKUWRJBEiRTNCRQxWj8dfAZkZopWaMSgfNB3UKvgeRtIc5B4vRn2W7y3L KCG/b9Zoh987Our3jXZ4z2vuavrLGQnhcsL/9NFjAo66OjyJgwvOrG9LzpgAnZYjeIAhSbrYZDaI 7sPt6QjRUBakJguUUtqVeoJWvE/NMIrpf9PS1NbUK6k/pN6HBDmEz07hNIMUzfh6CKfYzPRH8FRN hQevivZoKxW/IVfKc/vPyZmRO7Pov+wfONSJvhbf+ZEVvosit0Xu9d3nf9o/nPOq/7Ucsyxbst2y z10sj8uO+9az29jT8h75Fdn8fOxdO8srrJrgKLMUatHxsUKtoAQPX15sdeGpQlbYkscXvdJqi52V R0mePS+R9888MS+vjFYTDbk2HKmMLAhpuY6GkJZjx8Prj4XgZd8jKmaLsYzLDsp0imKdokYZamia y5Q/IWIYp5ZY4gHzNjPDDk5jE2tWd8zsnx2jsU7snLsqwabqcaHFHvqBh872LPas9ggeX/WqxrED 5IpZx7DZO/gpEsUWReoINw6w/aMN9Q3Y8tETHdEjOFc6eqIZsU5W5NGe+LFMYpgUpkeey8mLzS9c Xsg6ovEOICCpgtVeX49jm/Z08JO7eOLE6iq3O1twuT0hHNXFshwuiNTEJk6sxaET4ycQlXGiZ7vc ONCRWUO70tE33zgw1CrkFKU+MdkVYcaTHU8eXPjYvS+f27a6dT793sRPCmvbm85trrab2J/GP3p/ fPNzqaE7bj03t9ZnaGlJ3r7oztbcomDunOYpqTedVd7i+ikLqyK1hV3gygJIQwOkwUf+W5vTbos7 YcTYVjlXua/3Xu17iD1kfsX+ivf39re9H8sfGz7O+jj7SzlrUtak7HOc57hbvHHzKrMy2VnrrvUK 66X1tk3SbbbNvu3OZ9zDzr1u1cpXzZsT43SP0xWzVlt4ji8/plObI2bZBx+gEWvodJiIhqpEQz1S 3Ye12octLKIo6FEoz6UhUmHhEUtoNjS9P0cJuXz+9szy8dP/ZMesY9ETx6L82MepH+WnfxQ0YzL1 dNCxA55zdmKtxBlPHHaC5RAnpP5qXTZ71fUbLmlbkU1d0ROvf5z6K3Ufe/FD9mnVvPn37Di49YLV FT99ER47ERq66BluD84H77g9aMN7hz6t3BmX48a4c6F7oTee+7DyiPqlqnbnb8xnk4WYeXJ2zHeO 0GQ+J7vJ94iquvj7I8nk5+JrNSlWG5bC6BlntUToEB2n2WzEf3c+zbeHDL689npdQPkMe2DfHBut 50oFf8cajunGTE/H9HbNskpeZVzlXOFe4V2VK3fAo1IzNkGYMx4cMy4Pn3ZGwsQlqa8bBxY9B1vl xeRN1DfqrGi6Zsntt1y0fNPWC+JwN0NfU9/9zH6qe8e5lz/15HOPb8N8GzHfYsiKi+TSHw4Te/pL rcVU94j6qOVB+3bpGeN+db9lyG8wuOgMdrbcYpydv92yV97rf9X4mvlt4zvmL5UvLJZcW262hl2S rVkdMVv289lvZAvZXCps+Q06tXpA2Z2a2WZ1tlk7rczqdVJU2OvLidFqJzckB/OCMZ0WjMvQaHmG enN1qtmgUvrBUpjqjCx2OsHmQdHk9HJ2F5oUEqIV2RkhqshfnL86f1u+mG8LGTSLLQaGj2mEaMai hFCdgPl9jL81dHm1EleDV8u34QE15OX6imvleMMof31HnBgcajj5IFFJp6jHafJ01RPQH/ynAwgK nHV8MkkPJ4lB1ThVTzaGGvTXdfEjXIt06N1bNXDJyju18u6tGpilHwdxmLfRKMwKHC/V/LjoIR1R ykU8WByp4TJOhJCbC0AWN3IV2cO+ot6JH+9K/fXWVdT11jHqlEc14aYl0xYVC1ctvLC+ntK5FY8+ vuee9yEL0dSrqYPXb5lBL71mw/TpeAVL8Y6FsL/ghuAmQ1rVRJGWikF70BEXN3olg/i8l2W7Hczl dDusWbjlWbMoPmVzqQabiS42pU3MxBfCKFOHzU3TburmyXz+6cdxNC1nuYxqdYNhNoxJwVBir3As djDHEBU1izUrwlyLSb97xM3c4Nle1Rxz+zxXDbNVuNTh0hTtqZ/Fb3KnOupPdPiOEC+2SUdP/ShC Ax51VTb8xnRxVjXXutgcCle62dnV2WEYYmHv1rpH1l21JjJ96lk1b76ZOrpVjLTddsu8wp/Z6+a0 vn/qOWGmvvdTc8RO/RStoOdpS9fnbcpjTrOle8Jtlo0TxCANs7BQSatZtaDR6Wy6cIEt7ooXLRy3 MBqvuMT2pePLLOcUS7V7Skl1Waulyd1a0lR23DzqMd6Fc8tktphKzZZiq9uTXW4xe9yit5DvgD36 DtAF3+rQhWTQZM7QktLMBggXZeiEWGYjqNk5+uG3WAKLkwFbMSdWYzlnuClb8frk0nGmiN/LlY7q 8/n9d0+gE6CChvCCvLow5PRVntE+J8b0j/2YffQIV0BQP9CwuikbHTsQh+Eth43n0DvH18Ux7Iwj UVg8kG1utPGgGOz8Egt13NGj6y3bKteqoovGrYiuqoDeIh0eyc1VlX721UBHjwmwBxc2l5WFgzgs s3QVntFlV9NGQ17Jwstri7IsN4y8ff1SSp9/eSNVpnbvvzv19z+durnzortuX9l1c0vxpOz8kHtC +HuPPbvn7t9RE/X/+IFTZx/Yd3H98F1WdvOPvv/4D57q/z4Uxn0QxGeh17lPYf0wUWG5NDiMDZra prKNakIdUQ+pn6lSQO1UN6j9yJAEWYHDQYAW18ghvBUQSAdcE7IkK6KRKTgzsHqaGiqMiT5DQ0ad R8dcD1yTc/EUJJgJ+KcL5xXRLH4nQLiP+lJH8WZrLxVTp74+R4x8/R62yGa8/VqMEZrIP4aJkH5/ 0OJo0M3q633lMQUXsSy5WF0h7zI+b3xN/aXxPaNxntApMIviVVvk8w1XytJe9QPxmHhK/FyWzlPO M6yQrxfvEB8Tt0qPyo8qjxqMAdEpR8WoVCqXKqWGCkur2CoZYZeoeL9glIyqIIsmSZS5A8ZkMii4 jRtN4hC7TPNLFYa6AHwdXRZmitCNhPIrv8/ccO2YmcXn7bOf7PFCrXJ7GKKEJ2cDv0MZrrf/zFB/ 2qIS0q8l1VCMnDaBe8gVsKpwaeL3JfxTHJvxBm0mXZR6gN6a+k3q85th8J6kV6auG/0efX9z6ll0 /c1qzhvmV0JtHF9LqU1iG6UE3mUekj6TpIDUKW2Q+pEhYUpwHDEhQvlO01eN+MR/W7WxdeJjwRpJ +75qQV+48YtxaAU32aZ5lSxP1iLDSoOIT+pihpi9ydBk+9guyXzv5TkUXIjMJhOOfUYjbqIFC2O7 8Dk/GsFuRL/ugsJYn7ffy7q9x73sMy/1Gk0RM+6345IWC65wI5oNkH4zPQ6N4fOMjQ83S/iMsEPh 3OLXzJN6hu7jyjD5tMUQCjngKYLek7Mxg1A29GA+yxbjqaOFc+pmro1C6KQtb3U8OjvA8p/tmtR2 SzIVECNbd09fecu1XP/NhS3wKGZqgeX4kDbjI3rU8EXWF9niq+wjiTl9kk9lcfvCrIXuuPch9rD8 sOEh85D6O/Zf0h/U35mPSkfljyz2Zwy/ZL+SXzK8YpbWGTbLtxgEB1dPRpOHs8glKq46xd+Z053D cqwhXFa/Zer1nOQusYwBdFqTqKvsK2D/rPKKtANqBD6ymBPTItkuAjdPpOhbOmNu7+jWv9FY6uef 3pv6opcGH7z88gceuPzyB1nBHVTuTb362d9SL92S3v6D7dv7t27fzue7JXWp+BDma4et96g2flLW jCzmjAl1lrqsWE6TMNMyM6sp55856kJ54Rkb8KTyzxx8ZylzKy8pKdzm09wmE97TeUIGfzfsO8c4 q9UWsdt1o8/UTTaiJ19eQ8akhUerHgtpP8LtPt0DqKtcriFwk6Bcd66QV3zb5iNwC2bzI42btbhV FHOzD6p0zOrbQuXqn1w8TFnq1HD73bOxxO67Viy96bZlF92OpW1bnvpjajR1MvVuy4LRj4XhwZ3f H3zmiW0QyE2ECLX63LdrJQ9JVLXSedIKaZ0kVDjbrSut3U7RqNrMATO725w2swbzbDMzD7H12jhF gXwLTDaWENWuVqrdqqj6Nzi3Odli5wbnLuchp+i0kwi/To/TTAwfXvfz+7SjYZjmZg50nOdnxPlk h29W5kjH4QPprsM7Uc6KHnz+5cHnXzX8kzBj1SQsPsQ7w4nM4S47aD+X6OmXNHXGzz/7rClzK8TI Q5c01Xw+vnFH6m+YYyXk2Y45lrIXtRHZIYcNxR6HJ/yw82HXQ8UPlKqKq8XFnPstw9ZXQx+Gv7Sc LJDHWRZYuiwPmB5yPlMwbFYaw1phU+SiguWRTc5NrtsKbi5UayPNcovpHMtsW0toWoFSUFgcqTXX hGoKasI1hYpslBxqyGspNhcUFISVwgKtbI35KtfV2VeOW1d6e/YtpY9mP1C6u2B32LKR3u25w/tI 6Y9KE2WyJ+TWQuGYW8vF17du+gHMp2pDqK3o7iJWpHnzYkV+fjnWPNBybWW0soxWlNGy/FClndqr aUi3Hmxqg05RJaPjVEuM+KJXDXEVfQqmqX4THtMg3Pt8gnusjpGMWtZqZEpl6qaRgomhltB8Gvcs p6s8J+G78jDRHypgJVkWMyvxL8a3Qi0lpjY/9bdkKbC/8I+bAqdDR0/OMClI/3IQ1ktoKEMLuDs0 v5CnDw8GCmN62sddAXBT5SByiYVOLGgpeNhyf8HPCn5bIIcKzBZR9PN5cPuIVHNLadBT3gCqG9N6 uqAoxqmW58cNAU4bDR8qiZ10Iz1O4WeyI9WJix1HZrlRk1JtFvyTi8XjIuNTcGto2l3t0dCuR4OF 7tFqamMe7unwaEXj8EC7Nk9AdyqIngV+Ddrb5qdt/rSfjU2+h7sP9B8c0jjx4ZnmXOU3VM6QsUuB ftLBU9CDXwc3+rlb4eeaanI22ErwCA2lP91rqTO7zHU8mjTXgUOfDJjq9GsAPgiMw7LKKuKmPlwH MfgXIHSwc3HJzfi3uWcBFiX/ZgC2VaSS+p2XL7ustsiVPTP17AU3vPfhe78tSX3hWNy+ujKYG6Ev xNtPfPbuKK2Izl1QklsRzHY5WqcufKT3wF1bJkydFnCH87NzV5zTetu9byawiwLpj9g90vdxJryu jQsSmMHGcbbJ1nOscZviyyZewZ1NPM4sF/U4mYt6BVUxKmYYn1SzEU+/J+EROkFG4JeBuZ/ERRwq c5Bk83c6uCebTXB+VxBSQRdDS/ALQYlXiHicC7IbXNtcu1xCp2ujq891yHXcJRGX3RV0VbpEuAiu 6h8zPa5oTdRCT0yBnhgmrvTIpHjmtoB3LfYT+m3hmP4uCDe0IzBVHdVjt4UOiquBS+ephzMNbpsa R7imuqbIwa4ZMRXnFp/jXXrdudfUmdQbb6R+MXI4Nf+maG7Oe6XVc5onPEDfOPzWk6nN4M+d0DLz 8G2Sm2zVPOc7LnI8KAmq7JPrWb0DX7c7jjLFxqfqEE1uYsx24SKE21AkO5twBWl161ZC5sr0P1gJ qoGLum4eGOhx+C6/ax582zbIHDFnTLCMddCRcR1EMEmY3PqtcSKPCudNPrjqkh3nUl9gbsOMK0qp b9uCpd/b8SDrT3kPd02Zve4IHYF5yt/L8QfuAsXk95nYvzz5//cQSDG+zKkkk0kTvtY7G18AzcRn /ufiS5vZZA6Zi68WF+D95fn4Loj/KHEi8B//YpIsapo5LT4n2njFqiWXlk9bfenyWfNR9L8B6sO4 hwplbmRzdHJlYW0KZW5kb2JqCjYxIDAgb2JqCjExMzI1CmVuZG9iago5IDAgb2JqCjw8IC9UeXBl IC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0dYVVhCTitBcmlhbE1UIC9Gb250 RGVzY3JpcHRvcgo2MiAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIg MzIgL0xhc3RDaGFyIDEyMiAvV2lkdGhzIFsgMjc4CjAgMCAwIDAgMCA2NjcgMCAzMzMgMzMzIDAg MCAyNzggMzMzIDI3OCAyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1Ngo1NTYgNTU2 IDI3OCAwIDAgMCAwIDAgMCA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggMCAyNzggNTAwIDAg NTU2IDgzMyA3MjIKNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyAwIDAgMCAw IDAgMCAwIDAgNTU2IDU1NiA1MDAgNTU2IDU1NgoyNzggNTU2IDU1NiAyMjIgMCA1MDAgMjIyIDgz MyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwCjUwMCA1MDAgXSA+ PgplbmRvYmoKNjIgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvR1hV WEJOK0FyaWFsTVQgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTY2NSAtMzI1IDIwMDAgMTAwNl0KL0l0 YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAvQ2FwSGVpZ2h0IDcxNiAvU3Rl bVYgOTUgL0xlYWRpbmcKMzMgL1hIZWlnaHQgNTE5IC9TdGVtSCA4NCAvQXZnV2lkdGggNDQxIC9N YXhXaWR0aCAyMDAwIC9Gb250RmlsZTIgNjMgMCBSID4+CmVuZG9iago2MyAwIG9iago8PCAvTGVu Z3RoIDY0IDAgUiAvTGVuZ3RoMSAzMzY4MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGMvQlgFEX2P15V3T330XNPZiZzZJIJYQKBJBACkTRHQETuwwSJBLlB5Aig4kFQOUQUdFe8BW88 kBACBmSXqKzuqiysuu56sy6eK8rusqwKmfw/VT0B3P3+f99vhqp6XV3TXVXvqPdevRqWLV0+i9hI E5GINmPh9MVE/IWOo/j9jBXL4vq1PUiIYeLsxXMW6teeq3B99ZyrrputX0eqCJm9ce6s6TP1a3IW Zd+5qNCvaTnK/LkLl12rX+d8RAg1XbVoRvZ+uBX1axdOvzb7foL7JH719IWz9Pa38Pr44kWNy/Tr m3+LcvvipbOy7WktIdZf//zagVeg1WDyD1JFHiZGwohKSshkQuTn5Vyi4JrfV5xTf7H/6X7TnFX/ MoVN4vGP/bWwOwd+8+CVl/20s2OOSkw2XJpFe34D3zMOzIwmQ1Ty086fVqr6m/idrr/B+8hEqdvu VDB29IBURI4hMamoJZ0b2ycVSrktA2Jam5Tc7faVOgf1kOJ4YonI48gXIe1EOogkk2lSFHdV5KuQ mpB2Ih1EOopkIAQ5vxtHWoS0FekYkkHKlSIt8Zg6qFDKwXdzMF6nFCDfI3UiSSSGvARpDNI0pE1I W5EMoh2vWYS0Cukg0kkkA9GkQMvdZeh7oOV2Ueyef1WpuJyuX06tF5e7L6vTy1Hj9HLoCL1Zf71Z 73K9uudgvSws1kt3QWkTHr7bYi9tH+SX/BikHx1fjJyyQ8RJKYmRbZKPNCMxCV0VNZrk3p2fKt16 UJIJlZhEyUwS62yXaIvdVTrIwjrZ98RNYuw7dkK/w07sdrhKtw66hH1GdiIdRJLYZ/j8hf2FrGLH +Jwjr0bainQQ6QjS90gGdgyfT/H5hH1CnOxjUoJUjTQNaSvSQaTvkYzsY+Qq+4hTjMg5XI3E2EfI VfYhhvUhcif7ANAH7IPOdvZOS0Vl6T4BpEuyQKwgCwTCWcDtL21jb7f8WASKSgHToKiXpDwykJRJ eS0FvWNtUrClal6sjf11dzwd2zaoF3uXNCMx9ORdvPldEkcai9SAtBjJAOg9QO+RJqTNSNuQmpFA ZchVpDh7A+ktpPdILyQNaSySiR1twWva2JGW1ODYID/7PXudBDDjh9lvRfkWe02Ub7LfiPJ3KKO4 /wZ7rSUaI4OsuE/wHRWlirIE9xX28u58d6xzkIsdxAzGkJcgVSONQZqGtAnJwA6yvJaZMTce8hJ5 AzwcYy3ka1E+RR4zEW1+TEsNAQHGeZbqfxEgZFvjW1NMS225H5c8S915NyCepW7dCIhnqZWrAfEs ddUKQDxLzZwPiGepKdMA8Sw1ZiIgZG3skRfzC2MVYxbQ+CAnuwazdA1m6RrM0jVEZtfwD/lR5n18 sKV7d8zYA1q6qHusaT9tOkCbxtOmx2jTLNp0E21aTZuqaNMVtClNmyK0KUqbNNr0Eu2HqWiiWuvP Liu1IG16gzbtoE2NtClFmwpoUz5titMKrY0lWkaA61DUiGL3IM50LLH7ooGQPk6WwIwmQPMJyISD yI8gdYorDY3ieXrjnCgv83Z3r9ave/YvXTToYvYqvvgq0PAq+RRJBoJeBRm9ioe8isc5kVcjTUNq R/oeqRPJgNZ5GMcmkTuRlyBVI01DWoX0PZJBdOd7dIWRRch5F3eKjpUgr0Yaw6/Yq/jk4ZNgCS1X jahp9WJpU4Q6o3RMtDPKKojfD7nsdplcbdS+99/2H/5tJ+ZBZnYn20RygYjN2XJTy4+5sTZ6X0vq pdggH72XRGVQHa0kKVqAsh9pFNd9SMTE68tJhD2HsrQlMhlfc7akimP7qYN/a2/sx8jx2NeRNgbw q8hLsT/F22TaEvsjap7bG3s3clvsdyVtJtQcSLVRFPvjoum+SL/YjjdE09W48UBL7CZe7I3dGBke WxARN2bpN65oxJXmjI1PTYldjOcNjVwZ0xrxzL2x6sgVsSq9VR/+nb2xXuhCWge7o7NFEfHSZFQ8 cFJFG52rFRu3GGuNY4x9jaXGYmPCGDPmGsNGr8ltUk0Ok81kMZlMBpNsYiZi8rZ1HtPSfNXzGsTi ZwBBUyILWIWEoVzMICeMmhi5hDR7pJFs5ITBdGRz+wwy8sp48+kJyTZqGTelWUkOps3ukWTkxMHN /dIj24yd45sr0iObjWMvr91F6Z11qG1m69somVjbRjt51Zpws3tI7T5CqWvNHWFedltzR10dCfpX VAer3QNdlcOG/g9Zg6hsGJo+/xc8D6aD6dzmLSMn1DY/m1vXXMqBzty6kc2/mBCfWruP/oOerBm6 j/6dF3W1+6SB9B8143m9NHBoXd3INjpZtCNx+ne0A8WgQDsTFmbejsRNUb3dA3q7Anwf7fJ5gXZm MykQ7QrMZtFOprzdrsb8mqG78pGhTSBOGkWbxkD8wjZvFKBNATK08TeRN0SbN/xNvE3zQPGYSARN osjQhIZIRDSJ0JBoInq+SzQpyTa57VyT28SbJL03og3P8Bj7sa429mNoc8FE/r/BWYPTabp7QN2M qTWzkjUNyZpZSA3Nt6+YG2xuujIe3zWjjt+IN0uphitnzOXl9FnNdclZQ5tnJIfGdw0Q3/uP21P5 7QHJobvI1JqJtbumarOGtgzQBtQkpw+t2z18bHnFz95127l3lY/9H941lj+snL9ruPjef7yrgt8e zt9Vwd9Vwd81XBsu3kUEjY+t3WUig+uGAH+83M2sFtBrQzhRN9ivLh4oiHdAInhTeD+0le3Emq5r tiUHN9uROF33GNRjEL8FnuK3HKh2Zm8FbxqQCO+n27O3VFS7koNJetnyxuUkWDNvqP6vEX+oWrac o0LP07zuf/xDk5pmbfpQrluPbO4+YWRz9bgptbuMRtQ2DK1DXf+uOqu1pq2zXa/sicr+vKEknWvI 66p4ndmcbfjftCD6hGrMzj4oGi/tplqULiONdVJzdOREBlEwcQqmYeqU2v3Qpfgi0ViHATbSNG3s ehofh4CJXkMw7MautGx5FsrOxbJsKZo2pkm6sWtKuh6X5pMlMjFXy9IQbcp+koMUUp4mOXKKwP7p /BLpK15m5nV+xe/zkn0DQdeWTbBJyA46j+wgB8kr9CS+tZPsI62Eq0BDyUPkBvJLsg7L2hTU3EbG 46Og/pc0p7MVlsmjWDAfJYfR9jJyE9lP/DTY+TVZRdZI7+Bba4id5JFBZCxZRO6gl3YuJ1PJp/It pIJcSq4mi2lTZ23nnZ13dz5BniT7pN92dhArCZEZ+Bzu/E75c+dHpAe+cQ+5n3xK7zbvIRre0oSW D5Ol5AGpXqadczp/Qg8S5Br0QSajyGHaztJ4+izyJQ3SG6QheMrjnc2dh9AqQurJXPIA2U/70OEs oUztHNV5mPjxjmvx1PtJC9mLTxv5FfmA2pSTnU90niQ5pJiMwHhaye9pu5TpWJ2pxrwpmKUiUok7 i8ivyevkKE3Sl9kixaaUKpqysvNd4iW9yST09ml88wv6b3YTPquk1+RhnYOJA/NyF59t8hvyFxqi JXQMncyK2CL2iLSUmPDG3vjMJPMw3/fh6Z+AjPYyGzsiPS4/J58x5GaOdTqAkRR5kDxMXqZ2jDRO G+nN9D36VzaETWMPss+kX8rPyG8bp2PUV5CF5A7yHPk3ddN+dBy9nM6lN9B19C56Pz1Mj9Kv2CA2 kS1g30tzpSXSr+TB+EyQG+VblLXK7YavMrWZQ5k/ZP7dWdq5lowDPaxG7+8hj2Bk+8gR8j4+n5LP qEKt1IFPnCboJHo9PjfRO+hjdDt9hrbiLUfpZ/RrLEn/omcYVlpmYGEoP1wFSrKl0DB/yR5iR/A5 yr5lP0oBKU9KS32kKqlOWoRerZM247NH+oscko/InZjnUmWLslXZrjynvKKcNNiMN2ONf+vs4x3d Oz7JkMz6zJZMS6a18y/EBxxi9YAJVoXeT8dnPvC9BRS3k7xDbZi7EO1OB9JLMTPT6Hy6hF6LmbyV PkCfFH1/gR7ALP2Jfo8+21lE9Lkn68MGszH4XMFmsSVQxu5mrew99pNklKySU/JJ3aXhUr00S1om XSdtkZqlt6SPpc+k09JZfDplixyT8+SUnJaHy9Pk5fIj8pfyl8pU5U3lc4PFsNCw1tBm+Du0moHG scZxxnrjJuNe47umBlDnq2QPeREUeO6PHpNWSzXSHnInK5NzYML8HvQ8jcyURjFQKttO17MbaSvL V641DGAD6GhyUk5hrl9jW9lpNkAaRUfSCWQ+660/0OCVnwVUJb9KTsgHMLbf48nXGmz0Jva9wUZa oCNVQkf6jdRLTktvkg+kT6lRfpR8KFtogJ5gT0tjQQW/kgcqtSQhPURekJbQG8keVkOI5YxpI+h4 NH0WcmEiLaU/SJ1Qg0eDiiqkv5JbyAL2Z3ICfLye3EtnynPInaSM3kC+JE+BK4qUqw3dDT76OzZP 3sA8tJUw+RmMrpLmU0nxkltpvfSA4Xv2PllOjsgW8on0PHp/hL0gjZJPKuPpXHDAjWQtWdK5mlyn 1Mpv0zlEopNJgXwM0u0GqVROoFwFqTIVMm0vuHs/5MAgaRRqgqCcS0EXkyAhHsDnPsgJGRQ0Dzx+ GaTY70mrYSJrI3MUB4XUgafmzcx4MqXzKXJ/5xxydefdpAfkwbrOG/DE7eRzsolsp2sy15PFMCXf B29fqgxjR5RhnT3YBvY+m8C2/By/mO0CGiTf4PMCMDNQeYlskP9EJpDqzo2dfwR1d4OEvZ9cCYX1 OEb5Hd5wsdROyjKj2a7OYdJijPdTMq7z6c4YtZC5nVeRMeQAedKokOnGNHDcTN/GeK8ns9j4zmXS rMw8zMMmzIKG2VoO+XObNmTSxEFa9cCLqgb0r+xX0ae8rLR3r5KePYrT3Yu6FaYK8pN5iXgsmhsJ h3KCAb/P63G7VKfDbrNazCajQZElRklxTXJYQ7w51dAsp5IXX9yDXyeno2L6BRUNzXFUDft5m+Y4 /9503PpZSw0tZ/9HS01vqZ1rSdV4FanqURyvScabDw9NxtvolHG1gO8YmqyLN58Q8CgBbxawHXAi gS/Ea4Jzh8abaUO8pnnYirkbahqG9iimu6yWIckhsyw9iskuixWgFVBzILl4Fw0MpAJggZr+uxgx 2THE5lByaE1zThJfxWOkgprpM5vHjqutGRpOJOp6FDfTITOSVzYTrimlRRMyRLym2TCk2SheE58H HaeZ3B7fVdy+YWObSq5sSNtmJmdOn1rbLE3HM2qaXWm8d2hzYOXx4PlLPBw62boL74alDTXBeXHe eMOGdfHmbeNqL/huOMGfUFeHZ+C7rGBYw4ZhePVGYGok18Wb2Zq62ma6Bq+EYlkgRqWPT9d6Cxrm x5vNycHJuRvmNwA1oQ3NZPx1iZZQSNvXeYyEauIbJtYmE83V4WTd9KGRXV6yYfx1u3O0eM7P7/Qo 3qW69Ind5XBmAZv9QmAWJl2/JyDRnEMjx5+bWcr7mBwBTbA5PiOOntQmMaZ+PJvVj2yY0Q8IwF8d xbeaZwIj85rNQxo2qP15PYZIm5UCNRnf8C8CCkie+PbnNdOzNYYC9V+E3+R0co7Umun0Lrg5nW7u 3p2TiHEIcIo+DhTXfXoUr2hjyeRiFfYzNxrIWMzt9Lr+JZj+RIIj+PY2jVyJi+amcbX6dZxcGW4h Wgl0a9bA77R33fFN4neauu6c+3pDEpTcyu1Z4ms2pc79c6p+T83c/s3U//+4PUu/P3JCciRU43jN hoYs1Y6c+LMr/T6fUMwb7mWhZs+QWinMUMchFpbEXV1D7moCdbnW1iwX4J9BEPXMNqMJVClqaHxY s9pwsZ7XWRKJLM/8b19q6zzJvyWK81/LDqO5fzrbUb3bzQN+dv2z7tk2SCMnQuQwaPYbNlh+dg+k pvdyRLYAxcPQT8SHNJNJ4MwC/IPJ0Y+nunCzhinDnYngIlFdF85e/qxhOPulOvxx6uxRPAwyc8OG Ycn4sA0NG6a3dTZdmYyryQ372CvslQ2LayDtdMJp69x/e7h52MY6zNhc2h/swcjgXUm6ftwuja6f MKV2H1wc8fUTa1sYZUMaBtftyse92n1xQjRRy3gtr+RN4vyCjKQYZAszifbhfRohTeKuLCrE9Qx4 N0Sd3gh1lMxoY3qd2tWOoU7W6zRRx8fHZcyQibVZtAiC4KwHGsIODR7DdQxlMqllz5IbRKokz6Ic hPr9/J7cSCYhfYpUhTQZKYTE60YhTUeC/komoe0+ZXJnB561RXmdzEZ6BPBj8l/JdkMlWYj7B2GV VqDtFsOz5D7cfwj1M9DmEcCPopyKtr2ysNl4B+yrycSM9pcgrcV3x6IchjQSz/KgHIy0jr5O1uPe epS34LnreB3S0Gx5McayBver8Z181N0COIR3cIeUEymB1I0QTARnXoKdLgNpRxknl2dreC3UHySJ W9z4U9DGCNvBTCywoWywuxzEib0jF3ETj2jRlXmhM/hhrwWFXkxIGLoxgUsRjm28IQE4jyRJPimA fVEo+tH1Tb0sIt1JGjZKD9ITulIvWCqElJIyUk76kL6w7PrBLupPBkDbvgiO/WpoEoOyD/ARH7XQ S+jD9H16loXYeKmX9Ii8W9lmGGvsYQqarja3Wd62EusfbY/aB9o/cwx1bHXOcb6vjlLvdhe6z3q2 eHN8Y/xP+M8E7ggOz5kd+jYyKXdoNBr9AZ7K1Ynr8kbm/Sbflb+p4OnUhsIF3UYVBYseTC8qpsVH e3zay9s7VTq+bBh6AnWET5fC586IyXYlXAXI4AkkZ+NS+1lNIWdIXG7n92s7P1EKlXcwM8WkL71I ++1K31L/0sDKnitL1vqfKvmYmLbkPu5nt5Xc0pfdErk1wVr9tCEwPcH8Ps0/n0jPRj/ws8ZIYy5b HloaZsvJ9X62IXBLmD3je8HPboluiLMNllsi7M34a4XssP+VMNsfes3L5vXd72fzArPK2KwSOrls al82rGxKjI3yDw6zXqHKGEuF8+OM9OgR7dHTYiFhvz/XF/f74/H9lh5ei6VHqkil5UXR/pI1vDY3 eUWDZ7Fnm0cq8Wge5vkod1OQBtvYFC2SMzC6NJ5Lc/v1K7pim53at/W+Im6kxvkVS+4LptXT9SdO 1Z9QT9UfP3WiHgXg46T6+InqE+scPdOOG9VDRkfVOgcv1CoB9O5F6//7j2SrCgyGZF5hqk9534oU z8tKoSwqtG9FwGD0B4wp2rdvn/JUMs/g8/oDlBp4WVbaVzpc9/bKv9y6YOcLMwYfeXjLwczfqLFH zku9xs9qum5hJrq8ZtrwEdOTSToqs/fu2XfePG7Hjhkz7rvh/vUfTlh65+BbX21b/YdfZnbVLuvW fsPayzcNk9bUzK0eOe2KoXkju3f0ofdfds+IuvZZ4KobMuNYAzCtkos0S6ETG2luo0lV22jZbrLV YUKpuYxbHVcQSZXikiQ973p4o5ikjtMn1NMnSHVVdRUfP00xV3lF34oygxEfn0rpp/f8ftSUA6uv K7womabpzLgD9Afq+O6DjjNH6zZseelXmVgm/rP3z9Js3Vg3lZktKiVuM++BZatEUbZip/MKB9a2 VlVlkwD80Op0CuB4q90ugG81p8XCJjkdMQdzPO/O9pH7jP6jn54kcZUXpvAp80NrV1nHappO511U uHL1gSmjjmTG0WP0Lwf2bdkw5e0zHR98l/lHxoRePpv5hN4CT4uFjN5jAfs8Z2ijY7UUlaoYA2tX EQu2MaUqYuhn7D8GVugi2FTbwGrbrI9ykjpVf+q4eqJKrSLVPFdPqB0nqMtd2btXWZ8yn9dgLOzb t2Lv4bGXlVYC74eX3J4alTOdy7xBtI3NZwvBkcVazmK2WGKj6Ci8MklYSFmMBjny4juC6dHq8Xr1 C1Iy6kTvXmQJrff0SfgGsSLatmcPl6b7ka1D7yVSoAUZ72yV3sWdRN6G+9tk0cvTIHV0UO/U/sOH D/PvwoPGKkEfEpmwj0idn7R4K1lb5yda3Ft5r0SZtFXaiS3cFYR60RoiRiIW6SvCvgLensHL5d0r Mf4q9dQJVaeVdUrPdD14iNNMOu2jZZQ+szlTm6N8+xOewMikzi9ll9IOesylk3ZhhZ5Yq1lCUVnx Ru32gLmt8yuBew5oORz5ZhexcWogfpsNuY3XkRIg/jCywxgPH1F4l+G/n3QKTzJMwpO+ABUJ4Dst x2oF5CIqryGqzcZzXnfukeef2WqI56gRkCWUB+uvoe77kdxITmy4XCkb1rH11vXO3zkUs9EaZDWe S32X5AwJT/RM9U3NGR9eYFxgneG5yrcgpyF8HbvGsMK60rnOcJ9xi/q74AfsPcN71g+doXMDbzRr iWR5LzMlZtXMzJtjrkYCNUtzoDaOpYaRzdHXbxeMmQZf1i9Jc1TyodP6JXD/9eN/FKmuzqO6uQzy u0H8QjJ5VC5vXCpkkNEwacE721a0LBs8/51H373urn3P3HDDM8/cdMMl9ewdKtOLnp+2O9P5QSaT eXXHfS/ShzP3fn8SPrX5381by2nlUyDwDHBnITu1uKTZXeUL5FVsE7vfhCAOaiYGhUlmhdoYfcMi em/hYyI0ju9ik0pwN4BvNJdAaEQg1CEQilnWcji6unAi8BOyKZrdWa50zUQvhcbhh2RKjnU/raJr iM4aS9KQ6ln/MWamalQHGLE6UEld4EBaT+rTiaTLYDD2AReWsTOtg96ZeO9nJcvk6wfeEHth+BvT +NiqQMtGjC1KX8/Sktml2oMej2GSva3zVKvLJYDvNLOqAop6lSgn0QBvEI3yu9GIA3eiIFDkbewl zcYsgQBiPlyMxWOQBiXvHub5YVJygne2mueH4HQIZ9mAv9DmdjPxQs3sdAHS33NMs7o9bFLUy+v4 s1vwaM4qViubBOBbTczi//Q2ziP8ffxt4mVa3wHKAMNLykHDS8bXTb+LGEfY6mwTHQtsMx0r3Ss9 t7kPuD8PfR4+GbIdtL7oYWFs4eaqUdXwaziNjSB+E0ozsBWKWlSTwfBGJOSNREKmSAjSwhSKSPao 2sae2D3GRbHBG9zDR0DEdDgps1kaA+9gtjmt05fYahInKu2n2Vx7quHcXcRWMZntZ/nYxt20Syd2 yJXTaS5esBB1VFWf6Kg/7nJzzCLrWq51SStYgHNAP1JP65fW1RX4EqkKYLxr+eVCWKzNoAT8k41n K1ig4PEHvt9+//U3P0T3eX74wzunL376lcemRnfsGFQ1o/2mQ5/PXvCLhzZ4jrz/zY7aZw88sX56 b1DK5M4vZD8oJU3rsoiz5gQ1TsXBCKGcVNM2XNCipMXutDmjFkuRLxqRo0URpcietNuCOVj+4hA9 bFLcmOJY5M1TJVygHS7hH+KurK7GInIC1HLiNfU1d6V6KF3KE4hF66bY/fYa+1q7XOO6zLUiLI33 X6XO9870L7df511r3+C9Lfyk3aLEJb4vbLXa7A7ZSPFeLDVP7NYwgJfgdisidtqn1WbzycH97AmS w+Zqheilgm7a3Y3T4oviLB7klBxvMjamhGxKUZJSUww9PvUiv5Pa3CPYRvu15LxD99N+WEjaNet5 aVXcRu/O4jB9QmCRy6xTabEEAY9AIwanCnzq6ASrQoSBW+mSOk+Fn8ssoTcZK86BYiHlso2vqTwn ybzU5NbYPQtW7XzsxrJLvW5rY9va+fM2elsT37xw7RsLZs+8eXPmq/de7qS3BO9f13zzDY96H2HX 3jjj5ltvje95fU7LzGkP9Yz+6s72zL++gIgNQQaoyn7INztNaX3dtba5tgdsz9h+Z1MulS61/1KW 3KBxYjNIRsVilYzEBmZ/Q5K9kiRLdsJsdtkovYSwFxOU8W2ahcgympA3LHIbm/2ioli03Fi5pUsS AuALE5sE4DuxQlnaaIVmN2p5yXJjU6KPcbMTSzFm1e4tJ0yFBSvh+pj4DoDjezkW2B5HG90oZvrb dLpeCMJTXLxUqV+oQg6qp6pOV7kq+SRXVq7rmZaxOjudTky32PWzY813V0LGvatZyyqlvB6Vkpyb W8UfUQdkoI3mtWnWSlvT2Eqblqq05UVQ9qjkDdJ1MDD60DJXmS/pklyUbem4lT38i9dea830odOe lPaeveTJzKNg6ns6FoDw+NqfUJ6CjJ2scw6iBTA+O58EGnFYoj5fxM0lp9Upy9GI3UGJMYj1QmgE AhBcxtd9ziV8/QMRdRwCZ3DGKHIL2esU+cjQdbkbcrd4nva8anvP9mHYZPYEHd1DkrmX0su6H3JM AneoHovP7fG84XB6HR6vw2kHi2ge3hHNsQ2KpsOp+Wi2Uy86ZfoOZx9INS3Ou+eapi5SV6mbVFkF kwQFkwQpCapBhs7qTBLcHHcfoH0QGXcPiKpfi2PP/8QsCFi5kFnOs0s91yjBI2Kg9a7KknqIhePr TD3TCrBIgFHBNeCbJdC2fsY24BVPwpeQIPOIz2uEJpCa9Cvf/Vfd3Lpj42Ubuz1zJ3u/48Uxt97V Tk3L7jj12w7apG64/dBjD7SMqfazvz+fWTE1c/oPr9/VcoxrbaOAOR9kXi7pTsdkpV7MSWPYWJJo uFtUg5Vlx5IYVvKiXrslSkmBiinQNTg1GlD5gh8QMi8A9ADOanCH3z2s/qYLk7DEDtVzTPZYkEOH GjXf0Jyh8SnuifEF0kzjTNN898z4MtPyyBrT2sh7pnf9LmOcc0ChzhOGSUkh8HhVQtww8huF8WQ8 wW+4eC/H2hn6GabvTOOIhNAzd/UZ+mw/zU32FDSqApGwUVRYIxjFyRe5lqhuLrZwMRellZq/OjAt sCiwKiAHoJQaJgX8/KWBNpa/O60raeDEE3zlEjJP19R0SVdSz1U2vkpx9uHSro4aYa1w1cxg5AuU G7INyCIutQJXfuo9LwkN0pndweIRCyYPmnQlG3RgTmvHNUdv/Uvm+MO3fbXj446KMXeOXvrEY9ev fFae4Jjfa1Svgd99NKMh8++3N5y4CZthN9BnXt7+ytmP65+ta3vkvp07MQHTIe/82FO3k8Wa45Cd yvjHTLIZsoxzYS9GZbPN3ihJjE/JGLFESyzkNDWa/0bGAPfTmFSNYhFdBeUxB4JIUPFo2ENLqkad OjFaPc21MW4Z8NW70iVkEMa/RFgwBiIZjMm+bnfFdGnPxsyJkX2d+6Sb/3mb/NOOjfdk3JkzbR/u oN/Q1x/iHosJoMAcUGAAPpxejOg02Goj4WhPLiOhh7FJPXu6E1GD0i3qtkfNNr7AQvk/BTEJIO3k 9iUnQwC64sQBcdMZxFqpG58C4K0AZMlXyvfZuJ7lE0/0CfL1ZclXt0IuMEUgj9InKsGVWYvkRdER YXzwjgDgHTkuLBMOiLrs+7n6i9ee1fJ4Q/5aTlz8hTznIz0/vi6WwbuokId6T4RNxDmooo+fFvlH +EekvrB93Usx98J25Y30BnmZaYl1qW25fWXgdrKBbpTXmlZbb7Wttd8ReMv1msedB05picRDvIjH S3jRI44V/5gWLYrbSDRIbOjGtp70fE+ijQfN1NzG5mhqutGpxaHxw8vgVJ3M2Ubv2lsabGyG6Yz7 LfmNvi5FPu7TfMy3ufc5k0b3yHANIasguCvrS/jg+KKV5RjONdDslpAldXX0vKvlnCZA4HzxCN+K 7m+RLmQdOn/xVV8cbP9mwcJ1d2ROv/9+5vRdV65dMHfNbbPnrO8/YvOE1dt33LzqaSlcdN/8bR98 um32vUXFh9Yf6CSUtm96mU6ce+st02asu/Vs56jNY55quvnZ7V22LKfJKKTiC7rV8KI1hiWgwIUF 4LRAMl8JxOIO4KTWjWM06BIodQnr0xV0Faet3aLcszHGITkcXjKWUqFG2lVYFZSvNBCqisD4oXR9 KUis/kSpmBhgnhOiyqXox7/hRCcM6gs6cX7t1LqLxdMlqPj/560/f9d/vApvOv8irbx/6FK/lrzc f1lytnSVf2FoTnJl6MboxtDt0Qf8z4QOhL7xfxE/Hfdc5H/Ev8Mv9S+aaWCFfN1NgpiCibgh3i06 xjGNL7IRPjz6zlhdJLfyTiB0s5JYIZFdP19WNxdzOd3KxbTrHC25NBdzbc5K3npd2+SCl8vdc2tn l9gl9fCfwEgWCuZA1qe8kEtblATCFju83GRO0S5/HXTQxTv8N0yfcOPYvrTvSwv3nqXG1zaduH7l 3x97/gP25pPLrm155oYbH6UT1JVXX7rqz4ttwckLqOnPn1L1gcxf4Vv6MrP7hYNS+YN7Dz20ESIX K+k+mD9rEcPEfbT9oEfAv200M0OVLFVRgwzPDfQawuKYi0dNWd/SEi4/YQ0IlAt28MCrJCHtgxNH qjt8+OzTcOYwRBkRpQ76q5E46Jy91OGENw2K4j9as8APghBRc0qr44TIZaRhkiLyErWXOsc019yg rpc2q79TXjO0qydVq0mpQwjPWHWutVn9p+2f9n86zLJNtssOCdvgiizDujAZjEYbYBNiVeBPgvdO cwrLPm60eXGLSRBqP2iQZpCqcdnmxbfMUUUxRQ2SoY0t1sw40fG1hj0ctp9awXBWzW2Lk1lGafxY hMR8KkubZSojRlazjrW1Gz+1SZtt1MavVafxiJGtMjYZmfEXzvf+JDxxS3Kw+uBfEDMWylFBBcHq qtCJ6uNwy+Ef90+loTut64lwU5RiUqEdr1MPHXIcOrRO0UuInJHNVkTQRbFN2Co7JZNxPwxf0vkD l0J1dCnXt/hfEh6upJSQPAkpVWgwSqzsD6z24+c6Hnz0ffr3+4flRcqU/T8NowcyQ9kUumXfNXfc zlezLVh5vwamXEKj8uwjMnAynPuhZHlYcnJydrLRfKvZMC+0XFlsbrTeotxiNRT6zVKwsHvUn2s2 e9zR7t2LikgkN4p5i8EBQUzBlMHG/acG2BVaGV/DDG7O8gYDn3mDiT8dIDBu8PIlxTCxIGWL8G/Y LLydjdOFj7eyhYpzo3Hhtonz+8ApF2ZZgLdFzU+wHs8B8Ntw8YbnAKpPD5jKPVX6BNVj5YcigItR MP/0PxA0t+aRIMyqYKZUlrgqIekprHrMPPfYlLkSF9h5DpakiVLdlE8lYXSUVnDeTQHewlLb32yc PWfNpsuaXt6Y+QW9aHW/S0YOu/mRzId04RWpIVP6T7xnY2aHsr9u36wrniorPNA0Z1dDb2m8yz97 1IhFRWe2GW39Fgwbfx22eyiZ3fmlsgLe0Fzyzp4ZbH4ugyDmyoIY31faNA7FSal9BqJcluU2kVtz N5MHlOekJ+37pFb76/aj5HjuP3NdDneuKzdX6m7o5uoeiceG2yd7L/NNzpmrLMi93n27+wHpfscD ke30Cbbd9UeHB/E2IdWrhmRw5ict3SqF8O/RrVJ1EiqHPVGbFI7KZjXlvISk4lgbQrFAKm6iJmgl hkmmnOgMzDZ0rnT9KK5xIefeEthGLjGZUEW5hxDK5lIaMMjJvHxMnDu/rFTG3gT0TgPzed3cwpZb X7ko8+rnJzJ/enAnHfLKR7R4wMGyV37xzF+nLvxi7eOfMdb7+zMv06vf/hx+22Nv9th292OZ7+96 KfP1hgNcrj0C2TMFFO3E3H2ulcRjdIhJp06XGnUSE7pspjHhJjELojJbOEWZ4WTQ1TQuICCSQrFc 9f9Mev8GDQrU/NBFetH/JL0sGXKtIktyvXsNuU7rK4WNiKBXEEMvG3KCoSAzWC3gA4tk8Pm9fo9f MoSlQIK6HciCpkiC+i2uBCJcsZnQHX+raT2n0AD2GKCwM9BnQaI062sqBFU+Qn98bspNdcsaR6+8 6/CazC5aedeTvWtG3XvV6B2Zt5T9vtxLr8wcOfR0JvPM9NIdfXvXfP3UF//uzs+WPQbJwONZreQe zWdQoiaT0UgkmbO5xRy1EhOsmnYcrHCXGydKl8QtcTuzhOyy+f88Z5xvf86utgGX6wQkmLOeu08F HZ06nj43aVk+xd6BC0ZlNj0m5599REqf/aN0q7J/R6b6+Yx9B+ciKEfyGozBTO7Q0mIMm7D91jUM DOGhODzqjIWs/4d+a1YhZwSxQ8hk/qv7Fo5yTv/63/n+Y1cvK2LquYy5sO/bpY/Pfs6aO8byfvff 0TEbvV4I3t8H3i+gHi0U9oZ9rKGQXmHyULeUn08S7gArIEADn/44n0Js5QWiDgkWh5nSVGFBPrbP MK7CBuGm4Sp+dvXlFA7W/kAITLH6hvn32dKmQlqYm4pbqEWogpac1IwsJsDEo9R6IUExHnQewvGc wyMNQsY1l5dI3AUAgh4qJ8ORUCQnIhlsKbXAl4qlTAUISisI2nMTxO/0JNDY64kbcZWnFCRoxArK 9rqQRc2JBMmXkIkIblA4NnSEA0jMKKd1OOX6FLh+Jj2wtdmTQXzw3UCvW4YAqXBJl7KFmzJHt/05 s7V1Nx374VZK707tTFy5d9GaV65J9FtH2V03nRzIqp+nHceWNu6jV/z5PdrYOqftl70WN40ad+uY 9VsPZX5oml5BXcDHQZDSalCRRN7aQxF6xvg2wO5+F4ntgN1l5XrZo5dedivSy2SBXuZG9TIYEiW0 X7U8rmxWdirAEtSUTdi/ayZyCfZWxmJj4yRR3HFUbiaS2G2wilUumF39vu1a/bifTl8GNeHMIHGx Njwmv1d3wYoHn1lLExSZ+rolS6s6sooCPHKgR06EZa6Dr3ClAGOs6PxSmo4xusgzmjqLzTEsY8sN 6+3rXQazoLRWKye0NhrSrHLUaTanLBZTyspdYrxnAuAdAsD5QgD6csVrNOGcsNbHPTSOLfKxngaP 7KEpMBFczvra/U0XN32UFaAj3Xu7RnJCrV+ir+Fcb8KKciKN7pP6rG+2bx8MRLgqUgN2GhfPGDG/ 2yt1L9/88mG6Lbj9hiGNN0n/OJvT9sb8T7hE4PpOd4xTIQs1G2WyFFWIKc7VOva05jQyoCSOZv8H beN0V4/PiXzDf4n8L+p1uaVPdsK35RX2Nib8nzvwivsQieNET1R2vMsHaeo8rQsZk8OO/RVwKNAM AITwndaNQzY3ny/FaZNw7JiZzFYHMZmZxWoQWMBeopj5n/YKFKiY4C+69rr0nWzUnNUph5tr3Ejn u4zV7e3q0aPtfCsjDQcm+C5NujYyY0ZBWQaRSyKXRa6I3AStXkty2mNCMILpuURx8FzX6i1C08Ni oSv9+MIPWoyrZyls0MUt7nKnyBSbRKgDy4oJ6wsfOH+mAPijLC+xyYizUdlkzU50CSxehPHojyXc +ZA+VQLhiymvroJc4oOBE4+PRvzpp0LC2irCnCYvC5vkFba1tt9iKm0jbCOcUpFcYC921EqXyyvs 1zrW2U1Wppgq7X0dY9hICU5A0yj7YIflPna/tMW4xbRdetpocDOnw9FLYV5FYSbY0r0UE0CTbbxz PNVgRphMZosVHOxw4LC4mTW4m9zMvZ9thwe2d4sSR9BDb81iM1vimm2VlVr3Y5AOasUd1gbjwwz3 Rdy5WKXYx5r8YlxpUJoUCAW2fbdrAHgjh+/211cFO8AU3L4AHDp3cbwe1gamgQvQrk8INgi3Otbd KIwOFOCi88bFr4it8wx21d6DAfeesC1GNttgeHSD4bGP2Dt/2OWwcIsj66x/d2+i0lGcEA77vRWV jtIKAe7pgdqsUz5dB+uELMEuWF0dlmvqD/StoAlX0oXDHK77EFl+eS9/DvzzVHkpM3lnplbZf+Yf d1089kHp7E/D5DfP9JGPneHMCLebEgOnmOmNu9yQJ+2axeMrNwVtfuEd+0pLcMgE8y5uNMHQMzGj JJnMMmNmo0mW4gYDGEiXnAD+gW0MsImic1Jb57+1ECc1pT5upXHrWGuDdbG1yapYTdBkQF7YFcDL /heZkFUNZCGD8cj/Eg0WjrAuQwSbI1g4IdSy2yN8cwQkC4Ma+8SV62SBId2LwyMhjr1oc5Wb4shA wXW9e3HVDzhoNWnDKmHQtu8dVmnSSnWwtNKYlyPiJvbmACzVQV6b1KMprMlKo8OL5OHXp/Z6AObq YC5AHwd/2OXTN1WEksl5R7AOUFhGIWqBu4del9j+189mgLDV8iogq+lME9e9Z0Bz+Vh5F5FxYfKG NjbkpF7V6w0HwmFZVmWvNWANy88E9jpec0iBQDDM4rmaa4xnTEAL1Sq15svUSa5pnimBacHJocvC twfuZ2pOVJLcUavZl+JxU3y94IIOgL7+ATgpVhAA3wiJAUD3cgH4CYQB2WEMNSEEy5niODQIDOmi IyfSZa/oBouu5UBmjNKtFm7/wV6B0eJRSaJU5uq1sFoqVLhoENzDYLSQGXQ97fsmHfZca2bvwSOZ /dt/S3P/9CENX/f1Xb/P/Im9QRfSh1/JPPnRp5lte35Lp/w68+/MEVpOw7up9ReZz3V7Re4AddtJ kLRoxbNcC7xspDrSe7l6uVe22uCPc5BAkKvdxOROmWDZgtZFpAhE6SlNaHCmUDxE8S8UtP+v69d/ qLH/rYXnXLiMpXWreYmYHD4xXbYyV2O5OiaMjyhMN5ZIuGCI8K1SYXewortHXXV33XeZ32XW0+sP PFJ/ae9bM7cp+x3uWXsXvpTp6HheohtXTb3FZ+eU8yh4HKYx5iCPntUSbquDuvtGpsRmmxbGYHLy 9cIkcqPI80H3AvEiJIKvdtxpIGogIHTA3db52W53qBzlyd15heXw0322O7ewHDspooTXW5S4/+fd uSn9PtqL+yj5fW0EgALHJZFL4hOsUyMLI0vN1zquc66xrHfea3/G2eb8yvGlU8VqF3c5vS6X0+W0 md04dRXyWwzw4dltStBs9gdCOVEER7TrQT+BAEnkCXwGg06nwxRNOR6Cq0QPNwJwWizQAI5peXxk BoNwktTH8xfnN+VL+XnB/yuOdWr/n+RRcsD2/zJVsmp+zvEg0CwWjSyu0xBWcIxgQaWw5HmwA9/z 4+jXF9ZszoWE2KW1mDRnpVPt73L3R1UdXSJWDAdiuUI5lS7IJzeSQ4tUqnlepBjSOYHD14kudwts Wk9S6slATklBWmIbPvEo23DorZVvvDOq26RLO0+9Munqy3okRv6FPrpmy+h7H8/0UvaP+e11D72X W5A/enlmCe1968Z+VmPHcqms4rrhc0X00FTs4PwN9lUv5tMKZ0gz5EZpmSwXFPaRKiNDpBHGS3Nr YkPzhxVOkOqMU3Mv63abx5HkzksuekB4OlDQBaS6gMIuAI2BQ72xDqCxDqCxDqDxaW0Yb9TNnspn +VJhQV8nThcX1JRMiU9OTiq4yjrfvsAx2zsreJ11pX2l80Z1eX5jwVppg/U2+wbnHeqa/FsK7rZv cW7xRbNhQj0SKXc4FTKniqBak6KQWy7tncIxTUbsPa4L3xZm4QK/vUe0sIAWKH4shKc03esa7WGO Rv2S8NSkYcfV6yYdL+phqgUQHaF/sB1akO+wW5UE/ClhHD3CySMDLcjPQx2M63CPEJ7IJm2CHDqB M5/CQBWrrErjdCxtoIvpZmqAEdGseXrwVyp4NXp8iTlFimgRF+EOB5sE4JRm508qCpViTDQFDv1W 3AKA6YMABJB17mJTFnI9p3fWYK0fdRw0B4+r8PSdd0EhviN9nGen+IhAxhid8PJhQYUnPkvCKCDz PRVRBitSl2T5hWKDh++A8hha7qfyeQN+bLjy2A/46PNTU1+0T/vtjYuenTB26oDMVePmzbnpH798 /Me1yn7njmeaH63sR9+vbVq59szDr2f+eT/9k3r1HZcNbhxaMycZmJ6ueHzWopdnzntrteP2O1df PqasbEG3AXtWLD/SuOxrgmH1grWyH1LRiFNidoVFMeFwWuDIF7a5GncLs4XSFw1xykr41hale6gw XyBNNCsnV2LKekv/IWQj9JnPugzHs6gR7pcMajiAJ5r23n9eTYGvAiql2nG8/guuQeqiv3cvHmjB PS/Mk8mVN2TCin3Hjp/+yXv7KFb/PPTWS97XLClnrVxr+p1J9nPB54cOVS4PMA2TLzGtcD6lfOU0 2ghzYXO31WD2pqB06PoZgKx+xoRZi+tjWoQv2qw+7qdx/1g/a/Av9jfhR4DswmHBn87VQYsw2WAw 6A5iAXBKAfCTvuRZhHqGa109A5C13Cz1Pq6enffcYM8cTo+s0alrA2K1S8P7AFNT1wKE1Sm2xF1y wyszM2fe/X3mp8WvDN9x43t7lf1nd32cOfv4ndT+tTTmbMvBPVe+IuJW4YkiyjDMkYUOzEYvuBUK lwJf3S1EMZsUypSSj7GLdthVVoY5rwah8n3U/BKFdifdpAJLia2XrcF2m+k282Zbu+2kzRq3jbUh tMVqYtmtPzO1wZDCI6urxa4Cvm0xm+MmxWsyKXAHxJniZUwx41Vfxy2wTGaZ6CwGdQIhPt0qx5po k2kzftGD72zYmdatchqjm3CalcEqoZorroxVWC9YI5uVduWkosAiWb/b2oAFhVskS46Dm3gK8rgx LCShnBPY9+B2R3azg+916FaHF5ZFC3ECE39vMbshL/7eAsMMyh2sD/zVoVk3GCB9hQGCsC7ElAql jAcrJLDdIeyJMsoGdfz2bXpjz1heD7rxtQ64NM78qWnxtdfKRXBtcOGA3+VawXUL+qGWKiIpV5E7 FawkfV2V7r7BEWS4a4R7eLCWXOaqdV8WVO8z3efMTqRWptJQTtpXrpTbhipDbSN9E5WJtst9M5WZ tgW+Zcoy2/U+p+LjlqsbZ6OdOM0jJl1gLSCkZ2VlWItKMuxDgxGTb4EP0Wx3OJ02nOJ0+/yBYBBb 0VW7cdw9zkub28VLbYoP5gd+6YjF8WMqFKE8iskU9QW9Pl/QbTOboz43QLcL8chx1eVVVZfbbDMF fYoTe7mEoUuKFESoi9lsMiGImwXdbhc2ZkKBQEgdZKbjSJzYkPuQNKLQcXvj3J2fk9NGb9+lKwb1 oZxRHTAnO0I5HcHRNbOGfnFOJ+gyJ7k+ACHKBalIMF1GXWhc8o2t86YmRCs/ynAIWRXPBHRhBmQ7 gWwXpwm3hW9b6xRQgMru5ykga7A6ULPbpikaGnGiWFoPgvDoBOFxw870YDcMzlCDkdJHMte//ml+ qB9OUH/z9phkpMcXr2aufinzZqEx4M38Drxafe89f8uXPukIZb795+2t0gswaOo3xmcNP/M4qIdz 7AhQj4ft0YqwGuVQv5UVuYs8/WiF1M/Uz9zP3t/Rx13hsbg9cXei3M0zHB04thsl1FNRIvxDlOCx Y9pVuCHzVhLPrqHXWFlKLjJ2s3Z3pNx95f6m/lb+xItNE+V601TrFMdE9xw6S55vWmCd55jlXi6v NHGd4Br3NZ618gbjBss9cpvpRfdr8u9Mf5L/bHrf8Z77S/kr01eOL9zFUCMR5WyD60j189xq4jlY 7YfdHMiqDlYbIrPUoAXb/PjCV5qDQ6oBx/EhlRjkCMxTjmMsj7wIa/WgZrOZ8sPHEhYaD44j26mq 2l0IYrNizpjdKtk8Fis1qMxjtng8cWJG1L1ZQtRT3CZ5bTYJEgnxPMxjx1JPTCUIbwN1xm0IVsaW 6rQX45bNlnaLhEjEtj3TssKnTbMYWjV1rHpElXBwZJpmiZMcr++VBBc+6dGnOM3WBz/POVF/oh6A IFvugeMUq+frlJ+RKI9bw5/TyamyyiSIs6vQifRQnbB+dVvnnCtJKLRWKLTWnErKldlguBIqySct 4UqPXsiYxr3hSlNeuBK4b2+JcOdIuxaLVHqg+EpIdoc/UOVx+wMXmWAhVEkyINgun2g94U7Pc1da bbmJiyjJTVRZLRxiHLJ5AqjzBFDHIQbovOrCoXNdBAzNG9oMzj2ck5RdLGFmFRnbl9QyIdl7CC18 p6ODpU9mNsUSvX2Zzews+3Vm/fLqsZfRNR2jzv7IrD36jI1mKLfSLun8So7IA3FmrYL10IrNdnP3 HHuoe5G9e3c4ynwV4f7dR3Svt9d3n2+f172h1wb72qIH/A+GnrH7unEDh6/jUHxxnoJDT+U8221v zkvdDuUc6fa27+NupqF+ilD2UyBXKCZuaI5dIQF9ONdM4texQCyYLu5eXilXFo+QLy6ebKpLzzbN S6+wrUNw7I/2H9OuinIHldWS/PJAacIbnFa0qIgVRUoc1Y5Njq2OToey1bHT8T3iW8RZDvCp7sEG gD1nHlHvEDExDgMPgkJIiIRoumf3Bu9BbLkR6tMpLSTUpppCS2lEshZNV6cT2GfQtAoSsA2+7TIS vtW9TPky12Nx4zgGL4BTYhZQ8xHX0AyT8sWLcK3rY/lt7HLNUajxCOd4qldqZ0qpBOEI7RfGw3t7 uYac6s3rNHsUIU6V7ZVsWyWthH15ShvEnxgoCOaV5B80HDGwmKHawAxYbmBFYljIg8KihAeV13As GMC5yMW+j6F3v/M+qiXYvU3DSZWG6x0H1brIrKoj/fnn3FY4jkh+PXha3KpfcmIJuIkzlDAauFrN b4h4ULJEnE3jh9KwNck/CHfhqrSxcCBUbWjWfh8/lJZMIRDPAWcC3wZGI6lq5r75Ow8Mb7y4z4IP 5tCymvWrrsttDl599Lb1z45VzYG8A5HAlYcWTS1dOG/uY6ncWyYNe27N6NWjvQ57KL/AcnWPi+qW BJfcPlKbfknPa0+eWXNRP/pxt4jabVTJxQ2Xj7noGlD0WlA09y3yU0BN2oNUsTnzlT5KjaJUx5pj LBZD3ERkcGRxbHPM0N9T5a9CsNGloXpTvb3WWe+/IjTfdJV9rvNq/9Wh9tj7tg8CH+R85vk28G3O X3OPxTpjOXGlxFni7aVUOzXlUudYZbbyQe6/5J9Um+pzyAZGwhEsUBZfxGEN5h+1UtWqwf/YZJX1 /WmroFGr2JmGaOA7DsK/f1LQkHB0cCoFcEwo87xGK+H4tC6Dp44I4iOyUO/LpALG2ikssG20mZ6k coxW41dxcOwNOzbcVABwVsvl5EUFqVChgFM3JxXokyAVvmqgqQDOan7+agp6Qu7lr6A50eEVP1Oj QTjYd8KuIagHxlcXCYFUOAHhn4i14JQCObWULMHhmDIXLC24k1QE1BdKMLRACHoQHe3xdOvSXVfu XKJl/vGrAwtY+aS7Vjz/5PIVzyv7O/61acymNxoz32fee5huOTjp9sNvHn3tMNbusZ1fSScgr0J0 SlbbLnesclKnlfLNtsXY0ZPdEasxGJHxyzo+o4mP3ihGb4RtDBh+NuR8ayF9+N3XhImMyGCcgKgX JyCGm200FhniGRKY4JkQaPA0BB5kD0oP2J9QnwjZTPYcy3w2T5qvLLcttjfZn7LtMe+17LHZ/Nh2 +CuTHHnTnIucq5ySEwcintWu6yV2ABvQrc3YEjyGnUAzcTqtMAG7+hhB1/MdJj7ZjrwwxpdvTceg HUJ30wSCNIGdiwVOQgInIyK+/CNGGjNWIzTJwRsZLbyRUYhXY+9w+aGsxQes6MxfvzR7bFwExfer O7H0VPrEUjF27P0i9FutP45/wm4G3uoQzAEzGP5QcdrrnI3MMSdV7cr9/oUPMv9e+vVtOz6K7cxZ NWX9s0/cOv9Ouibw4hGaSy3PU7Z656PhBVe9+s57r9zM15hhwNmn4EhEJNFJ2hMWJtsL7OX2oXal j7dP5DI20TLeOyEyh81UZplneBsi7bF3lT96Ps753PO59/vA33I+F5znj8XSIc6uI0Ocd7FDnG/v 6e/P+thHshr7MO+IyGWWyfY59s8NX/p/oqccKvVJDisCXcKgBxcBS0rWYBkPoHQWqOpRF1UR3Nfg anKBNTlN6AzqcnPOgWMRixYXsi4DpyCXYFjUwpTlM+5y8BnH9XeCSwH8oA3m2HEtc+cfROTYp8ZO o8xRNMYoGaOC5IScNuIkIidIgTaxLBnF6mPMiZaPvYDT6peMOnGOuzjTYUcIW/UIOzgBzQ3pPJ/x /ZhEH+CLezV0hIHnENt9js+kfrMOrfrj8vnv3tKwpWR3R/z55Sue3H79tY+ufWTjmce3UmnDuEHM 8dMw5n7rjZdf++CtQxxnIyFFo+AzH3A2QQvESMSHrZl6pd48yTpLWqAsMs+ymmDo8FO0YiaOa+M5 lBvheaH7feUn7+mQ3NvdP6d3ZJB7VGhQZJwbZxcj090LQ9Mj1xqu9Z1mp4MqfvzMaQ8Exvq5D0Dy R5yb1W0IjVflcMRixC8XPMuPcXRJs3ZwA+YdB4TpPR5weECDCvaRcH8A0A+6ANB3noV2Zi7sXt6M AwShGJbX3QWpcl5qg/gyG6Mxf5mab9Tyu5d3YQoboMCOjikMBLDOYDhOCAbz86FxTF0oE+vTozqO j1bhb0JAOv6Ec4FvzGcPVlR1LKkSKrY4T8HDz/gKyuOlBIvpGw9eY0L4HWhCxOsbpCv2F3+37+vM 99T70R/x+2Bnv7K0rJmxseMDNs7Wb/JtNzxDJwceb8UZCQk/xtUt80nmRzW+c/9ces/aIXOfghTx AIVN8IcGqF2Les3UmVOS0ysHx4BzHrQ9ZH/GbgrZu9mbc9pz5Bw+H91CsfJck12yOSMW6mNpr0fG Ly5btnqpt9OjyYECGb86dTfEEp/E3v3KeamlI7HyzYTmaJxNcjQ72IR4hYeqm/BQ5XHGIcVCkxKM w8Uv8XLKx/e5jiaAL0QoM2p+EmchyOPBnAN0P0mQ0/jtJdgAepgAn1mwAT96dAqqP/wQJ2AGYDeU B16dQPS/CFTxIqrZbDSYoCGpcNoTl8EZxu9npbuvxkFt8MlSbHX1KeuDs+ZYkiDWuOfPx88XtWzd 6gndsuLSqeF+peOHHjkiPbBxyYLyYZe5H7YMa7hy49nZ4IjBmXHSN+AIHpG9SGuwWhVvsbXAe6m1 xmsw5+bkFltT3uJkpbWv9xLrMO9kY611rvUny798jp7J4sKByYGFlxZuLt5WbOyb6FtUXTzMOixR UzQxMbFonnFGYkZRQ3FT8QeFXyW+S35f6Ar4Db42tqu1W8RjFCuJGofjkK8jTaSdHIXzsI3dqJUq kYjTUpMXsVn8vrKCMktBMHg0QNWAFmgINAXkYjjJ2KRiERcXEGJNaJRCrAWEWOOHS8Qhz290scZb 8cMmWbEG4Kx2CSf6wDInLSB5sfyDziPOT52dTjnmrHaOwUInOMYJGYbDDzhbgFz49vSDUrzeMMmZ ky5eluDiDQZdFpEQbziJ9B8SruP4aX4mCYwjQquP678OgA27JQEeDCcUyEJwDQ8y5Ajs0xUkcmFk /uyd1tIhy25cH3TQFc0fnrz6D3ccWPnUrA+3/fqb+5+68YbtO1Zeu702NK6gdOaUiubbadXH91G6 8b6ms/N/OHLtc1L3P7QffOvV117lPqZ1CKbl0XJeOn0fjme37/YFyrE5e4yfhzVMKpD74Bfk9ttl UdU/kFMeMMEo90rw/TkjitGLkL8Cs1bWt7zTTNvN1I8ZZpP8EGAISewmci9nEJiS32ouPnEIfsYk mrF1LWoRN8JZxQyWQs4XGGxyA0Joo7g+jYgQAKOFMzZQ3re82X/Szxb7t/mb/Z1+2c+8Bfpmt4o+ nMR44CE6Ch1E5qwmBCoHtIDgUl2tRBgvOLRry/snXR/E0UO8B34DvJyM9g0HGs9ZFPwMkr7vnT5n TQg+FUfI+TqFZYq7lAR3OgwOY4HDYAtTuwl8iUOu6fRqAqamiMgVWiIc8AglEAHyBp9rXetN7Ste GNm6fMHYO6qgEv7j7vonHuqYxh5dd/2EO2/seAk8uR6Iwi1ofUZyWLvC3JePYIx5s3mbudncbv7U fNJsJOaYebG5ybw1W3XM3Gm2xHAaHr/ChzPlBukmbCIriI83GAsUIm+Vt8nNcrt8TDa0yydlRuS4 fBRXsqzrymwSgOy8IdocKJMREIJcSDbc0yUbAN0LD+AsIkIwh/Jo03/OHkK4hBe+Wg/A56YW90ss XZIWYfiYlfWtra3y344cOeOTU2c+4HSJMUs/YMxWNl0LcxsQa5JhsmGKWXLa/6mcNiD4hZMXvD76 pil8sToAItIBkOxXmth0nSRdY2FuQ9yTKIcf6+Rud2E5Wp1sRenGfhIqEqJCuxU1BllWZEOFebis FBh6WGot10jLLR9IfzUYnzLQpCFlLDBVGvqZq+1j7HVynaHWWGe+Ub5Oud/8muFt+T3DccPXxn8b fjT53BYLAuVkhvA+eDNxAZdmgdGAMA+DhE07xYKAG4sFiJG5w1tWuJvVaiU46UqdOFSHOYcXIQ++ bKeWiAstWJi6xtBmLPTWAsIKYBMRWo1f7WOg8YzWW9A4BgzqFiYQERgjMIRA00Jtxq/PcfrOsdn/ khg++wJJxVWvUdzvjSUeZ+54nPn5vVSoYdg9hR+cn3tFGdR/4kU1VZmqJJFnvXH2kQhQNt8qMcQk 86AP6NjAM3xOmsVcnFtpNuFULBD2SUtuJYp3W+Ki2JXQgzZwVhYRN0uwGyu8VAY4nxIiOKTFz4tP WlTenBfiyiaKXdZsxEcddyDxV7k/lqnJ68fbvN4qkeFbp1uC/Mvf7grrzRHYo1v5fNtM8CV8TXAy GUGJ9NmvM/PpwU8yj66Ci/UAbc6s6JjJYiszl3O6vAVZheDFv+5VBCOCgtp3V/TTgyXL++hlr956 macHU2oFEKtOBANtVT5V5DHITipSTFmMwKhOBb/Czn8dRRdk/ElAZ7vmwwq+ldB2mFPsQqnGLVlg mHOnMHqzxrKOa13vwK/TAMtdrAmgU+jvALI8SkbLP+dRoGoptA7Bppw1+RX/4xLrllYRaomxY60w pKAbJOnrPK5Kj1cBR+kAWOrP2iirvbxAPi4fN/8l8Hlc+aNyOs4CpnjSHAzH4TZNRiMGH186jdSQ ROyX5WgB3VywrYAVwIfqKNiMnzyQ+fBcCDAQ9gncUZysXV4ugmCA4PciuBhyMU7ULogA5MIRhXt6 RAi3UrLaOq3XbMGCzWEaFo8L80VIPC4sHofr7zQXf1xYrAZhYWCiNqMvQmF4MQyTcK17uMJteB7+ 946yZAE9SsB72wiL4ajRGMhl/h0dGxfyn/BWEb/gP/6ULFpOaV7+YCLEJRHrLMnJL2ij1+5OcLSc 0x+AAOGH6Dh+LjYbNeddWrjoEL5i+CC4kghNUTAx2JXr4l0LErZsUl6bK0zddl/XgsQjYHT8+riW iP0HZPqyJPTFCxeoR0ufmr/i3thNbzzy7O7k1IGLf9laO/PS1f3l1D2jp11Zu3/n3o5C9vBV0/rf 80THvazl2mvHPnBXx/ucV7hu8QXoxU9v1DyKZPCw7Wqb+lfpS89J6bTHgDXjpFYFgrlOpfepR4PH gp1BOW7yOrx+N3QLavDbLXaHzZEfFPpEUOgWVqFVWIVWAbdRVquwiiXKmseRKZxJQquwCq0C1z/q CLUKrQLXp3E+CuLVKhQXK+1ECONobNy0ayGuYQRPBtni4LZgc7A9KAdxHsnnF7x5Gj9honPeeRa8 ULHQWfC8YgEVFFjWFQvdl8Vf4f5PRWV0QPwaDWc38QcuhPLP/ZdIF/7xH0biOxo4l3JO2/AbXGaL yWLEqQs1BSs+TJ0WdxbJPOwc4hSedPy6AMcv91YKxOooXvfY8o8bHh2rWlq7L7i48Wk5de/OmsWj Sm/saGRrr1446O63OsS5lKGwkQuBRTvJoQv2+sRvWmCz4CvBZIg1+kpr5KtKjrjhNlpybMMNF5sm G+pMcwzzTKZytb+7v79PsEYd6R7prwlOVaaax6v17nr/+OBCZaF5prrQvdA/M3gN9ZkNiv1yCVuV lsttV0mzlFmWq2yWQEQ2uiAyvPlhoeOHBRkYoYHorgujcFpkHV58VefshtsnRf8EwPEgAI50AO2a J7+gvBfO2hlVYxyui96fQkbw+hHcZAbsyCc2ByQQEee/8BMUkD4EnUAuTOUs1wr5w39WCXjW8Egu DhjpHeKmM5B6DnknYDjX48ejzlWc/+0h7tfgy5Z5gjLBfKVypVnmaxNv6BHH17G/JUzoC5X/oU/c 9psPqf/6v93+aebEvpZ1a1t2r1nXgh8/LrxzReYvHYf/djONUvtbb771h9+8+QY6tC4zT04Ag26c vb9Su9Om/n+NXQt0lOWZ/r9/Zv7bXP7LTOaay2SSyQyZSGguYAKaX0QDpBLuJRAsLoqbgCIQESRF OIv1RlHxbIHT7pEKK3LqLrdAuJSVtZWKbiq7gla6VPYIFmndZXtStpZmss/7zSSCdc/Zgfnn+/+5 ZOa7vN/3Pu/zPt8txm1Gi+Fsiu+NiyXxEZ6yopqCmqLxRY/EX4grjaHG2OTQ5FibMs/THmqPdSqL PR3GQ6HFsRPx9wPnw+ej7xdfDFwsvhAfjAfLnBkjU1DvbDTAkDDmGpfcvy3KGm7TB5CDIGIpCIhY 8EXKT2vM0GxtgbZOc8Z5E8Z5c2Ld9inUKlDXGm9InJMdz2t6UFvylR01IQqX7TKqbK2L+WvFWisp CF+PDA8Bwtwa5wFhDokOA8LXuDXm2HEOEOacIphIdGUWKQEgzG4kVuQMMQDhr8LBWP3TeCRbO4QG +2m48fEGciEcuYqUiUTqYZzqqZ2Nm//66dOdj368Zu7zI81XV6768a6uFfuyHa7jz06btnFw647s 9ee+2Thw3bGz72fvnn33nQ8JqZqY7XBcQBsaQiEbbW9yixmxMjxWbBFXe6SmgqZIS+SF4u3Frjp/ XaypeIJ/QgzAbmyhf2FsQfG64jPSWetT6TPPlbAxQkx4MmDL1nsmiXd75ood4keeX4U/CX4W+TT2 Z1GHgkEgCiTRJwWAPAm+kK8WQhTGaZ0Zuq0v0NfpzmLucEMKgtxg7nDDCORxRJ073Dp3uHEVEyk1 pR6kmY9MBV+H8Jc3UUXrXeZf4ojlNMwIL8SR+9oyH2Ayx4XlSFHxzV7212CIA/3kbnylYaD6BgUr jvdyXARu9U3oYVXlllnHs/+19P21by17ZaD09VUrXt2z8tEd2Q5RGTuFjWTy9uzfvLrpT3c6/qGv 76c/P/PBz2mGexJNcxKtYgqn7LHVfmY4WZmzznknRPIXObuckmoqqqJ6/abqFRwKc/MhIWhq+gVk HybifuYXE+b/7cEOr/X+aJs3eLCgR/J56IYVBe/DQo4fnFvkT7GahxBybnYwmYzDQmJ+/3LK6qI+ C6eVrxMaBOPUUz5Oqp+/nLLyct03hxwhN8l88pXbO5rm3Xv7+PFj7w0UOyt+tGxi465Uc9OC5QNn qBaagHzvQy2McoTsNc5EINGoTlYnlM9OPJDoVjepG8pf9f+46k2HVw1Fw6FRLVUfhFwxZImIRg3T wu1Ku9qutbvbPe3eTqVT7dQ63Z2eTm9PRU9KT1WUp8pHjC6fq7W576+4P91V1gUq6UvaDz2b01uq /nbUTm23Z0dqJ3ame6siiFBtbiWaGCqUDRXKhwr8NWRC+GuowF9DBf4aKhRRMNsqbpirpJIezRmN VxQ43SOLohTsSESqqPJLIk2R1si3I3si70UkPVISWRr5OOIsiTwfESPH0TYF6Bcc07WxIgeFgSGp wsA+B6LADGgAYqo5EAjW0aNt+Mw6xka2Fy0pEosKC2SsiijUyh1wSoKBR00m0k8W0Fk40l0ClmJ5 xPaH62ro7dUcl+TrW5qBgVFitOAYp3dG4vSuCHccIxzXjSBMu18ur8RbDxY2nK5kKH3K7S0KOSYv L1A9oHDlEA3Tyij/U6VAmRfUnKgRm2rW1Yg1hE+XC/xv5sUA47laFmfxAn0BKuRU6eLlOjfAOv96 epxbD3Ji8BVhIXjeTR5OS3w85NZGvpEHoTHI89ALSb4ZIEoun5IP8WYyy27Ii6ZnAK7hRU2fL0PU h6+gOYESLg0pZuF/PsyLlD87dUtxGQDOCtOwDL/hkBLeeExQ03KMuW7BoTiA01JfWUxIQP5LGaHF WDqlalLGGRNKjCJaZ+Uy/YiokaMwVGbWrwfcM3QjrQTkkgyrcaUqUtghAkKnuQliOOhEyF+I2Ohk oiqa9uvPrOleVZ986eS21jturXxxxneOzzX3elZ0dHcGg9WxDW9smd1x8jvvfcRuK1y8/IEJt5WF kzWT1k9pXp0uyUxc82B4evv0MWWFRX6tvPaO7va5L3/rdRqn5YO/Fytd26AA88sjgoY+WFZBuAci BSisg6gaAqgacwhBAxorGqZuh1s3EiC2e62khw3Kyl3qXQvkR6AW8ILsFLBy2i7vlU/Ip6FnSmAq OW4okGgkL/yeB/9xhfwxfuWPvKfhCkFzuTUZzf0occuFJ3KrSvmo2AnW2+h9wCi+hOEwB3ORULC6 L5KFR3wIaZyYekE4NE6R25rJJENUfxX1hICbY7iqFtcwEY3oN8f91ZKqDRsOHDzoz6SLf/SycfsD r4gLNzJ5SfZ7GwdeuqcK4mXw72HLLtAOOaz1iBBF3ajw3MW4P0i0+qt2rRWoy/hZueIPepg/6Eb8 wEQ1CbXBZDhE7kSU+yoh7qWELDLawJfhdlINhLiXwuFp7p+EAlQLOM+jniHucOL8GtGIpVmDIXYi xEJTICYDPIBck+jVqPhIdHt0b3Qw6owCeqVnOPRJupdx9bR6QQXHloe7Ob6anzjyqCs8lByqmgM9 Ve6bgPOEMa5OidwECWC6oPTFrzghmEGo3pvG5WYODnhGnYbPq3uJJ0jp4HBEnJ6Y4FXMGLJhEZWo XI+FEcZDPnoHnV+ACgiQ04qIp0A6mrrP3ruj1XD3uM2Hp03bNLbnhz0TH2qtXyFuHjjwvW80T5vx /NNiA2BBJqCJHJfROhq7ko+Lh1yKoCkSk4ZJqOXU/VzVmRu5qLQ8i/XWu5iQMBs0su9es0GFm1mn 0AHUzSsH8AiDzB/xil/aanFpnZDGAWeXbRVIjhDEAWfn7LXpkXVCHAfdM0JII6m0QajXJgrN2mxo fbQpc9RFbJHYoXSoqwTQ5MTVyir1Me0p9pT4Xccz8tPKs+rfCVvVF7XXhVe040KvvE87JbylnRPO ar8TPtGuC/1aFX6OFhaCWlqo0MZorQIgNJdtBetc6Ep1ebwNSqEC/XQB36nf1qkZNZJ3hTcCtJGu 8eUsUXP5VdHl8rhhAKvPZ8DTxb0v05cRqoepumM0YJBJVQuoqoZQGBBGzuEETIklCydkSrKmgjTq qoZ+SEKxbRuIswgh4thBG1AW8otZzFbjos0S7iv/RmMXCX4DoLRFw59fJF4+BmvDMK/N5KDil0xL gIUwnJx3M2Q+wWHjjFlOkAQzkv1jdsk/XUyCS/W7I9mHnRUDGx5cOnOl+HQOM5bAeOxF77CcRUOZ qRatTLn1yZGd+BHVdYZLRmJmBd+cxCPNOB3xBBhLMGN4AlMrlUybn2umg0G2UEZt66gNrwcGC7k7 EOzDjj0mkByOTuUMnYlZp6/P+KDPOMOTVPOsWv7r6IfRYIhhBAZYpXOEJk4255mboP2HKZH7OCRP yCf9XAF41lVbLSmtMwqRA4SxfdXuLSmvc0oe1S/F1IjlwtZqkhsZtYplCH5HQC5UYu4ieLBJuVLJ +CC+LjcqY30THM2SLd+jtLjv1JvNydY8fbq1GJpwD1qrpcflLuWIdFQ/ZP1Buq6m3WZaSHtTvrSe sqoDtwpjrMeU7ypbHVs8u9hr4mtuEEKEQ9JR39vAuz9SLzsv67+x+qU/qYVunvHj4UeDH338qPOj le+2Mc2nOy3BVGQA4nrSR26cT3Z4mSeJaPYH9hiyUl70vkoqYA+rgF/S3GaFljFnOqdr7eYSs9t8 1tRMzYm+SM2Raxha1lJfHiIwVyOtNpc2YVykf7nZH8eYjQAWEZtll4p0cPgomoEcqMODLeAzW1iz TLIXabov/lNTVuKyaVkZRLpcLtmHdk56fQHkxSoAdzKaAkl1hdjO+ZEC0UrZciq66fF5+dezYMdJ fwJcZslCzpRP0ALXDC9b4CVijcN7mO0CF7RVY0u1JzSkD4uzbBW6r0vNJyDIRGduw8UWcJwYCbRs 10F2zX8NkyIo/5F7ILweHpi/DP9pkM0Pfz3TOT/qsNbH2Pt/EJ1lMErpTlRnurfsLZkxpwfk17j4 E4hPMdx9g6d7hFF6HMzRC1yJj5PeW/bWzUC+rTJ4ep9MAn3YrbEUFOhaToFWBi/sk+O5qxaukijQ EfqgQ1gK4rNhrU7vl0fRJ+4XbhVJ5gp/afjD+afR+0L8fSZIyVrcGSfFWs6i5hED3+CZQ1aDUIU7 Bvg+P0H9bTTgyHnHkVZlPKe3FIxrzrT2hzjd2pFysJbssaO7m5y1u4+8XH/boT3ZnmO7R3wIA/OD i+Y74sMDW9/tExddPyd2H/zze5iHdMxD/w1LY7B/z89DBTpzS05RRVDeix6p8xW5Xo2kbuqTpCMT 69UtpoN0S1EMe2qkYa7+fef3FQjZ6CdcJ6QT8ru6qtvBhqjDrxZ4o0Y9a3SvZ5vcSrX1LWeb3Oae 49vCtmpb3b3iYc/b7nd8/2Kcc5xV/9X7K+OSZg0NLjCiLVMPe7GwwN8BI5pKOmdEQ/5dIvzwZkb0 IglirJwTLSHqBFa0jrxAkKJ13WsMM6INTYIanWacFE6qopEc5kSfRCwqeSMtWgLiAlq01moxa5J3 rSeh6fdJ6lobdOhYry1NldZxyao7bV/csVZMtKIuJ5nd3FGd35+bLDBXGJegV8w1CG5kQEMWPT9Z kDw6p0CDAM3Jzz/LHfFAXRdxKcwlFHjq8YWLGgD4gvBcBN3VENRZQ/wcoSWkSyIDpwCc5dIGFbxm 6ih0a+OgKcz0/DaiIGNdPnrMGIoOOVJMZxuy2/5jx8jCquSBD7MvsufOn2vMfiamWfaL5lHja69n PQO/YJPbsvPxu0rBpPhP9JEo+598HynSAjo2gSuM6Jbklvy2BV6B7Ynn+0qkOhM9Hw33ISxCD9xJ hy1DxzmgY/df+hEPFTakA7P1PRqkw200SDw9qs6gA+TDrKA3bKXcKU/KO9oz2lvv22a601baPzHY ZrX52wo6rA5/R8FqaaV3tfl44PGCJ73Pmhutjf5nAlu119w/MY6ZRwNXtN8E/uAdML4IDBYWD/Wo oN9dGHPqE/QNIEJEhr9+DkTIpdoRs34MckOQzmFh5RAJ+P1JSwvgBPLNpifp1uAGa0gc8XjcEv1+ odAoFKsL3ygUsYNw00EddWEHDoszbXeTZVvit603oDdwmI0/pLOEcFcMhnFmrrYgHDPK0+pxTPUM cr79+APV4BbiM3pi8W4YRlTeAGmXoRORtEDY6L8YgfT/ss+jSOvhJcgLwHGgfkUhTeXGkCZ1KZg8 ItS37PXB2oRhbY5BXeCy4B68TMYr362OCIHBX0M7QEtAPwCj7GAB0kNzqaDoPbA00DZD9/GnaI3L ecP5HA8sYbCGgIvyRGBs1biJIbPC5c4+9Ob5TKIk80lPdskd5aO6Z9dlH9xtpMtji/UiZ3pg26Pr u1eKi6+/vWd82wzyUNKwPWfQr3xsj+2F2O8pRbRYjRWi2PYvbBUFdjtWrTh7056MwggxrVYbYFpr k9jd4t3KJLXVaGczxZnKXHWqsYQtFBcCdlnDupQ16nPsSaRnfcH6xVhEqWAjlIzaoPy98iGTabT0 GgV1IswrFiFn7DI40mKjqomIbSeZiGQfkZGUnXifK4OfqN3nFTCb99sqn80zPg1JWHoPJkOXdExE KBVS6P02j40B5dsOoWKf7VvgW+e76nNxTjtgQLBFuwRtLWOQWm3FjhHYFVAI02UhohtdpWQ2KFaW j10PUOEitpKgxh0gEGCccQku4iVOIqTGhvUwfKR0TCswAO802mEkDiLvFAlQQ7WnUF3i7M1eqkWq Sv5CaGozyhKmGe7X+3WqhPzD5V7kSijB2G20ONsfomeQoBdsEBGFFqPBLw1LbT2inpSEyOTRtaUF aXHnijnZVsf9A/+8dHUn++1mhyJtfmzg3jXqDwjx5bfBFCm/fM1tPK45QLSlHX2+3M3n5h18aP+e ohv266H9eWh3ntzePLQzz8378kwQ7hLuFpqFidi9dLLQgr1SpyC6ORV7Y07HroIzsWvpbOxrOEdo w46v87AT4Hz+vaDFjl5JNwn6CULznFlzxk/J3LG8474l98z8X0V7UV8KZW5kc3RyZWFtCmVuZG9i ago2NCAwIG9iagoyMzg2NwplbmRvYmoKNjUgMCBvYmoKKHJhZGV4dCBjaGFydGVyLW1pbGVzdG9u ZXMpCmVuZG9iago2NiAwIG9iagooTWFjIE9TIFggMTAuNy4yIFF1YXJ0eiBQREZDb250ZXh0KQpl bmRvYmoKNjcgMCBvYmoKKE1hdXJpY2lvKQplbmRvYmoKNjggMCBvYmoKKCkKZW5kb2JqCjY5IDAg b2JqCihXb3JkKQplbmRvYmoKNzAgMCBvYmoKKEQ6MjAxMjAxMjMyMTUxMTFaMDAnMDAnKQplbmRv YmoKNzEgMCBvYmoKKCkKZW5kb2JqCjcyIDAgb2JqClsgKCkgXQplbmRvYmoKMSAwIG9iago8PCAv VGl0bGUgNjUgMCBSIC9BdXRob3IgNjcgMCBSIC9TdWJqZWN0IDY4IDAgUiAvUHJvZHVjZXIgNjYg MCBSIC9DcmVhdG9yCjY5IDAgUiAvQ3JlYXRpb25EYXRlIDcwIDAgUiAvTW9kRGF0ZSA3MCAwIFIg L0tleXdvcmRzIDcxIDAgUiAvQUFQTDpLZXl3b3Jkcwo3MiAwIFIgPj4KZW5kb2JqCnhyZWYKMCA3 MwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAxMDIwNzUgMDAwMDAgbiAKMDAwMDAxNjYwNiAwMDAw MCBuIAowMDAwMDQ0MDUyIDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAxNjU4NSAw MDAwMCBuIAowMDAwMDE2NzEwIDAwMDAwIG4gCjAwMDAwMjMwMTQgMDAwMDAgbiAKMDAwMDA2NTAx MiAwMDAwMCBuIAowMDAwMDc3MTA1IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA0 NDIxMyAwMDAwMCBuIAowMDAwMDUzODMyIDAwMDAwIG4gCjAwMDAwMTY5MDEgMDAwMDAgbiAKMDAw MDAxNzIyNSAwMDAwMCBuIAowMDAwMDIwMjQxIDAwMDAwIG4gCjAwMDAwMTcyNDQgMDAwMDAgbiAK MDAwMDAxNzQ4MyAwMDAwMCBuIAowMDAwMDE3NTAyIDAwMDAwIG4gCjAwMDAwMjAyMjAgMDAwMDAg biAKMDAwMDAyMDI3OCAwMDAwMCBuIAowMDAwMDIyOTkzIDAwMDAwIG4gCjAwMDAwMzQ5MDUgMDAw MDAgbiAKMDAwMDAyMzA1MCAwMDAwMCBuIAowMDAwMDM0ODgzIDAwMDAwIG4gCjAwMDAwMzUwMTIg MDAwMDAgbiAKMDAwMDAzNTE5NCAwMDAwMCBuIAowMDAwMDQ5ODEzIDAwMDAwIG4gCjAwMDAwMzUz MzggMDAwMDAgbiAKMDAwMDAzNjAxNSAwMDAwMCBuIAowMDAwMDQxMzU2IDAwMDAwIG4gCjAwMDAw MzYwMzUgMDAwMDAgbiAKMDAwMDA0MTMzNSAwMDAwMCBuIAowMDAwMDQxNDYzIDAwMDAwIG4gCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA1ODI1MiAwMDAwMCBuIAowMDAwMDQxNjU4IDAwMDAwIG4g CjAwMDAwNDE4MDAgMDAwMDAgbiAKMDAwMDA0MTk0MiAwMDAwMCBuIAowMDAwMDQyOTk3IDAwMDAw IG4gCjAwMDAwNDI5NzcgMDAwMDAgbiAKMDAwMDA0NDAzMiAwMDAwMCBuIAowMDAwMDQ0MTQ5IDAw MDAwIG4gCjAwMDAwNDQ2OTggMDAwMDAgbiAKMDAwMDA0NDM3OSAwMDAwMCBuIAowMDAwMDQ0Njc4 IDAwMDAwIG4gCjAwMDAwNDQ5NTMgMDAwMDAgbiAKMDAwMDA0OTc5MiAwMDAwMCBuIAowMDAwMDUw MTE5IDAwMDAwIG4gCjAwMDAwNTAzNjYgMDAwMDAgbiAKMDAwMDA1MzgxMSAwMDAwMCBuIAowMDAw MDU0MTkwIDAwMDAwIG4gCjAwMDAwNTQ0MzIgMDAwMDAgbiAKMDAwMDA1ODIzMSAwMDAwMCBuIAow MDAwMDU4NzQ0IDAwMDAwIG4gCjAwMDAwNTg0MTUgMDAwMDAgbiAKMDAwMDA1ODcyNCAwMDAwMCBu IAowMDAwMDU4OTc5IDAwMDAwIG4gCjAwMDAwNjQ5OTEgMDAwMDAgbiAKMDAwMDA2NTQwMCAwMDAw MCBuIAowMDAwMDY1NjY3IDAwMDAwIG4gCjAwMDAwNzcwODMgMDAwMDAgbiAKMDAwMDA3NzU4NiAw MDAwMCBuIAowMDAwMDc3ODQ2IDAwMDAwIG4gCjAwMDAxMDE4MDQgMDAwMDAgbiAKMDAwMDEwMTgy NiAwMDAwMCBuIAowMDAwMTAxODcwIDAwMDAwIG4gCjAwMDAxMDE5MjIgMDAwMDAgbiAKMDAwMDEw MTk0OSAwMDAwMCBuIAowMDAwMTAxOTY4IDAwMDAwIG4gCjAwMDAxMDE5OTEgMDAwMDAgbiAKMDAw MDEwMjAzMyAwMDAwMCBuIAowMDAwMTAyMDUyIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNzMg L1Jvb3QgNDIgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw0ZTBmYTllZWIwNWY0ZGY1MDg2NjNlOTdi ZmZiOWJmND4KPDRlMGZhOWVlYjA1ZjRkZjUwODY2M2U5N2JmZmI5YmY0PiBdID4+CnN0YXJ0eHJl ZgoxMDIyNTAKJSVFT0YK --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --_003_CB431B0A1C095mauriciosanchezhpcom_-- From mauricio.sanchez@hp.com Mon Jan 23 14:12:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2E121F8559 for ; Mon, 23 Jan 2012 14:12:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B95IKYDGm+2 for ; Mon, 23 Jan 2012 14:12:18 -0800 (PST) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 433A721F84E7 for ; Mon, 23 Jan 2012 14:12:18 -0800 (PST) Received: from G1W3635G.americas.hpqcorp.net (g1w3635g.austin.hp.com [16.193.48.86]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 97D443825F for ; Mon, 23 Jan 2012 22:12:17 +0000 (UTC) Received: from G5W0324.americas.hpqcorp.net (16.228.8.69) by G1W3635G.americas.hpqcorp.net (16.193.48.86) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 23 Jan 2012 22:11:43 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0324.americas.hpqcorp.net ([16.228.8.69]) with mapi; Mon, 23 Jan 2012 22:11:42 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Date: Mon, 23 Jan 2012 22:11:22 +0000 Thread-Topic: RADEXT recharter Thread-Index: AczaG/xDKiJT9gNoRwm22tOW8sfaJA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_003_CB431B0A1C095mauriciosanchezhpcom_" MIME-Version: 1.0 Subject: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:12:19 -0000 --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At IETF 82, the RADEXT WG discussed (see notes section 7 http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the charter to position the WG to be able to embrace several work items that the WG believes relevant, as well as recalibrating dates on several committed goals. =20 Below is the new proposed WG charter that your chairs and AD agreed upon. Attached are a PDF version of updated milestones and a marked version detailing changes introduced from existing charter. At this time the chairs would like to open up the list for discussion. Propose your changes and justify why. =20 Our aim is to have this re-chartering discussion completed by next IETF meeting. =20 - Mauricio and Jouni =09 --------- Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. In order to enable interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, be compatible with RFC 3539. - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. Work Items The immediate goals of the RADEXT working group are to address the following issues: -RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. -RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. -IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify egregious issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC=20 --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: application/pdf; name="radext charter-milestones.pdf" Content-Description: radext charter-milestones.pdf Content-Disposition: attachment; filename="radext charter-milestones.pdf"; size=63691; creation-date="Mon, 23 Jan 2012 22:11:41 GMT"; modification-date="Mon, 23 Jan 2012 22:11:41 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFnFtv3Mhyx9/nU/BRAqTZ4W0u501Z7y4UwEmOpM0eIMiD LMmXxCvZK/lskk+fX/W/2OwekRzaVhAIINm36rpX9WX0ufhr8bnYLet1UdfLbbNa1UW7q5fVttg0 2+W2+OOu+K24L3748bEsbh6LVfh7vGHQalk1KtvHplpW9W7LsFW13K0XN78X/3BVbNrQw19Xvxc/ XF2Vy1VRFldvi38rjl4dF6fAKY7uuo/H7uOm+/jjeKE+H45tzuLok7+fuooHr7j3d+Hvrv5tV/Fb AFUXR13LH90k/9l9dDA7WO/2YP7i5YhVB+qLN4DdvxdX/1j8dBVYm3OprnYwa9VxqRjg0mKPS0cg f/Ufw+Ai09ebdllWDm61XK122+LqZtGUgf3+EuAqYf/V+2NEYcznyTzr4ugCRsDjM17UmXwonR8v aPpVhUs1qftPKvxXgPB0XLQdNPjHeKTJcHjKcBhFzf3xItYLxG+AiM0IpCmOkEYcJkCIgWEMYAJE cIoMkQBdBRXm0wzrY6c/6RRhfAwI6CkYbxOU0LRqcSQQQlh9OoR7oGJUJBasVZMTa7xKx0aY1ItF ahX5qomCmNCd7WZZ79ZlIWG7hU2KeEp36t1qWW6aNgeH7pTlDt0pJgFjuheoCNx+dX5cbNENtEK8 3y5MDkE+LnW+IZJOkM037Jbc+EYk1MMInoheDKX+c+j55XjBN9qz13o7ZWLtql1uNrud0+U2kVHj JhYtYYpN7Wq7bNttlYMzE2vqOSb2BNGnKC00jou2t+N1jR27aIMdV3NkcSeV/HR9f5vPs8jdT7na LLf1alOswzypvzg4zwKZC77Z+L0MFdlQQqLI/n0+9V58KFu0d2V83Ccx8PGguj1hIcZHDC6wE6M6 RY2ernHpVGOB9kIz7HWtFziaE/PKwmufnrwe5Gl9o76Y/2m7OHrag48qJwAtJjEpfcZlWW3LZbXZ fhOdRyfwcMzZV9s1wmvWzyHvDgrPYu317a2EdgfvIFxPE9piPFwRVrY7XM6+vmyJ4KM+Ag+v8H7D hFjwf8M2JjRe8sIXyP6tgF+3l/qZgPp+JvByYeZP9xvw5OU9cBsUfKwZWASh3poiACiOfpe0FoMB uSEgl3XT5BRm3qLYi5uY8mJMRk1dLndl9bUGFhl2/U4WBYGosb4VIODhuM41GFez7YhI3Mc82zop gvYHlXD9NqWHzokpUfNd05nzQU+yIPGL/hZlfCAAhynseX9n0RpFmfQgvZNsy9xJTiojqi5lfDTT RlFujNioMKFyYTOjUdKbTBnNsdD50ZU3UzZ1f8xUk/zG+pvP4aWmG+mrK6/AS1HhAtO6fahzqsGA thzHEX50AK73Ts7e7GHabHYv3AkxzahJnLZ0Rn07ld6+DEgyT9SGxX72j2dHAcklgmiGYu6AFcnT LWwBkoepXtJVS8KvJDmG3PFQsZCgzw1vUy4PvTC8Ewm1xjZeXlnE+Oz1PtbDigcH5IcwvUcBjyh5 xy5gODyf0sNGnCvohImPmW3ZwnjvuYfr2yKPc8/Ah2hnGtCT4iB8MoebW3RxwQiyqDNeG6X15Gnn v6qW3M1qf3ilovBzbPGep+UqEp/gE7Wh+LyXZtSb3XK1W6EOifwO+dRRbajxNNs1K8sU2ozcyLXh 9u6TvOkDZgbfjSDj3b38qqLgSeKNrtVdT7SezhfYDu7JuMeawthE6SeV/qbXFS+gq78taWDoL7ye ebU9XvW6XrLq7nV9RhZuGdmfiJsp0D5yZ5ZNeAtQQNIIkSc08kQz6GOEgz0Ex06vVUXybosySKCd 4aCeJunoF8MFCq3gW8BVr/6qt6kXR6/UrCqfVSgAA9j6BuVEg/Y8QFWTqLYtiYdx5XuXOqy4l+u6 Jj4m0EyD5gWOGzMp1xy47JEA8iw9gSTYCcU8zVvQTwX0JzaoU+bmYzTqAPhi1gDA2HHW1DXrtqol DcwVRuuR3DnuL3RQmJPOK7qDeAJP4ayJzTYgoC+4r8EvBdfj7sUCNpr1Lb4wsM24x0zuXzVhismT Mcv01CdSD1sEjHOm2VbLpm7JSRIxz3M7A1s1hLNlVdY4sQQaSjPDMMPOFhjDoEEjWESblN1iNuNU 9Q5ixcJi30Ec3OL5U3jAWybV06w0sB5Lli3Kbt1UhbKGTZu+BpNfAGiZ0PAsPSjbZtmWKwwwoWGe ZKbSg5ZdLzYq+/wg7HrlJtDnHTHJ/hnVR7/hPQqG+WHT6BU10BPrjRk0o+6xSs0nDAj5IsM0WH3g ITXqA9sYhafFn6aTqVU9UX36kGfwxNvSU7tepvAUkEKcGA7zzTAsRl01peOIQ4qQwEgGDC6aAUHy jeR56lt9FA0F1OeMzRAojqhZaGuPQX1EmshXjUjGWURML0TImfJOC5qQdR7ws7yDwmWiM8+SwBrh blbrTZFKeVrdjUVjK7N6oww1QluwPW0xoLad0jGdgRrllB+M15YHeWb3EZ6YA1P1wuRuRbhgLxhj ftydnJc+uOv0PrDQFAx1sq5grhHByXqbV7oL9Ck+fox9w1x93xk+pGUdX22TBeL/YwT0aGlkwYCn sNIxUmGK1/nLGCYW0WRaxeuMF17HtIoSWsXTtIoXyYxnXRRMBIx1EBhSD8nHor59PxOnrLjHybHA XTAh4hpnc7VpUKhNU4jN7pgyP7cfkadUttqsl5ttu83Bmc7O3HrMlxLFW1dAfAEs0TNULY5cxeCF Mwsl7gI/hBszjA3Uurrle2i+L8bKxrzZoJ53u285NM8f9ozLkfKpfGKTHfN36YtbUeGtOCeTfbc8 6W3MpDWy9cN+etPu1s/ZO+kSYhgZtmeMc1xBYiwntf0eO3R1fpTuBq2WC4L70lNX2kzh3eCyNBTf BNtMUSTicXaVtrTfkl0J9yHl7mOt/CbKPbpTVrY1x4SkVxm4g/lV5H53/PBTUFkWYeB/1S1gSG9+ k0LYEoyWv0xJpSp9azqTSma2A5SNRppeyKx+42b+NLjT8cBFGGzXux2Mmg8OJRyLg4TBmkQZp5KC M75zKjkjEJ7hN1jD6ck8fKNkBPOH4wVPPAFekpyHb7NqCqgiBVSWJ+rGAAybegbjaomn1KO02DZ2 z7eBC8dxfAucIGgajXot0Obxke4lguelJgEXWBu4cCDYClOz/cUTEwC4+mdYEi5oEK4plsLsbTgG 1TCBi1QpaDA2paRHoqsXfLhAhiUIgiw4QAY588VQo2brGuxz3KmE3ZY1biwV6LS6MdGofnTn+C3L nqi98xOlLjHy6GHxF8mGALEIG53mw0XhBS8s9YwXZL9S6VxtJlnaLtXmAxyYbbECBX2w14kGeJcP CNi450XP1kJAibELwVqs+GD+kCOfDuMcUGiMUc/BeWVKVEjbDdyfYAXG3oYaWIYLjuOCqzY1Aagl ww2sHvKoX5suVGxyZNBMcCHHm86c2RiY2OUIdmscC8HijRJ6PABVWJizO7BAjA0taC5VHlngX9/Z YrUUvFkcPaqfQGMG1mK6IxkyyLSEl2kJTsO0hBJawjMmfDR1W/je/Wf6wf8f1f0R2dJfWGRT+dY8 DstmNJWKR04TyOxBB+64lPtwwNo3M6gZx3ZHHPq148a6a2zXnVVvm8Ketv2JULNj061cr3AlKThT oZmo7uDzmGMpq8ruFxHHUuDTuMLYcXDtcl2yK5yBm4kr6l6X6wps5Y141iwMu/JCZaMmad+u0nKz Xm+nxF617IFvLHmfT+6EaKo1e1urdpeDm09us97UQp+vSKiRxwWH1dRBX81WbLPhDFiEJLstw4eL +yd9JwUKbI56pdcuK3XLAjM2+rhP15DFUanajV5rvZZTbG/Katk23DfLsM207Gt8ajTeZss5cbL7 NveCFXEAx0NQwLtAI0+iD46JwMQ3cYmn9QkbyUR6NF5Jkdd3fQhr1OO6eH4MTzxvhKZRgsw+bYSM W+Nb/WEt31GFIzQgS8njvMLKoOGeA7aal+gXoWn2FJpaVS98CPpQKmi/EzRghMgWO5TajIEGBGhZ LgQMdWIAVaJPzebsaf7Z3DxvTVsHNFE6kNU3Ksf3pN7UGw6Z7HKFBP29Jw693tiGyyxoE8YflwDN bGiwYsxzxhVACg1P8u0LABMDDD57pczgPKSxv06ZaVnVy7qtqyLgMCvzuRynqORIZFXV5VdAm+BP WROoVmWTQTP+hHtxB/Oo0RO511JSvyl3FZZLoEHOiOlonaRVEckwpoO1YDrU/K5xmA4FTIcnlkAn rMIHk8SGb6xPIKj3jX91JQ1TA8PUqbthZ/UC9HefwO7cpeBwW9QIjvDFZQBHqAhTQdAofVv/sMYB Fc2IK1EOFlEH8njeVK83XKWpNxLDLBOaEGq94QiQLGZf5+fddZw60dw/zMHNQLIY5ZsQ4r64gLPH 0UZBwQsJ1mQd3C08Eqd68ebywOkyigl4SjaC9idVkZ3PjmB6j2RbT0kUP5zahZt/yBPnq6cFrKA1 1Lz5ojq/VAYOVEIA/uD9wxc0gqJdSrSud+wHWfFOMQcCKd3febMGPaivgL6/5h1penZEUFWoyKre FY3R9L0qUuFF1tuqzqBZhjWc59hV9vRG08gFRb9IYkacXKPo0p6Ju4gwG7laUlRgYxY8HRQyD7W+ GO06EeutGi5aX6/t8ilYjUBSe3umIHZAwkVXJ3/IJY9ugg2c0dmljbpet2LmfHXzSxtvHlwBpA0W YPBBZ7wI869UOg/qQ5ixpks1qXu4pmqa5j2laNcmAyrvXGGlxRpheQZQ1NGnfjDNNuUb3j5u6y2X CtaEicSgskRzgF+j26G9edb8QiDh16Tyxd3Qbjsen2wkuoq4LmCECN+bBm8fLQvuTIVNlW57fU+b 4VVYkUdNHNA1nw3VFqTvxElav7Ag+Jwk6bNrt+u64zhOZ3Cv496kLnEiXBMpmkQEIwIV480Jj2VZ dclZUFOSUCbQzJsMnLjtr0hYnj67HuL5gEnBpMuLyS1W+A6LsYlKrszbC5HTZvyJHc1dUDBmxTrY SDeHN7gV4t0zSNkoYYGlAMhRyaboLk769cMbDSYA0F/fNyYxUBIM1Tk1jtlyKgi05W65qVckf8bo 7w0CvR3arY/upHRECzArToentKAHxy5ABGfJJNt+M3bbf4MRhHlU24IHFwSUWpRsUp1TJ67ZC57T Dw+Hf8QQx7U8bMOs1mh5wAhPYwfh30+gHdfnu1uzjhOu0BmhzxNdistSXzCaz0ZTII92tJAnGkIv lIZvdEbZVBzN3iHfsI2n+nwMu/YwRStE3KNa0UHGMic1wOG5hws1F0zPsDNpqK1vKP2kEmdOVroS BF+pCjTyAunpXzG9C+t09dQoIjhIa4ksVogA9RELVC90NcpqFk6qGKRnOkrERxZAthgXCY768jwt 4BpU+AmABDw/LxiOmtEg6v1fFMwLdKNn2NorwDxQD7hongP5+SmEHzPDgFPbcraXblXTBb5aT6+c PCgsm3a5avmxo5B/MV9jW2zzPNfpeMCJmwTzoaE6Y+ErbhKk0OIieNpfEL6601mcFCLJfhyGdpJp wXWeMF1hgE6IihrkxhPEYg1WEbXz2QqATVz7sc2OH6/2LLQoO3mEj4L4rR6QMeG7Dnz84GpjwarX CcKPh0x7XVHCgCzW0eWD6w0YW6PDwzKtMWRL4SjTSubKkiWAT4UhJsDNi5gOx0s+eAMbizGfshvn cFmph7lz7B0FV3lfDnzI+ziF8b5Sjj0e0XDxWZhznPHhUnbD72ZSxr9AFOEMs7MEE+Phxandtbz1 xSemD6/e3cMJ3vzExNYAKlxAGopljhyf/UoltJMOgysIeVg9zZOGrQw67y13UY04haBpiCbNVhVa ChOM4gCYD7c/3aEmvIV8ujJWfXYdnYNrugr6jTZ67wVGw2/vDNmux/sHMJiQITazW3GEUidcfwEZ 5vdlhxLe/ZURMhw+frQ8Nt5s8XNDqIdC02tYQYS0F1ynzgvqoCoYZu1mRrw8CfVf7JhBYsk+yntq 8MFkWdfVYDZKZfYCcMfIDI/SjfmUvlZgERJomuXToqowe3d4mcFzHByen5NqUI65wwuvyCyBOgkT Dg3KUMnY17WEhURXCBjjWia0iZ8nsuLn/wiY/IfyhP1ljnFgNP501xDI7CO06BEObsK+uZbxkILB abfDa9nGrQyGybFENyJjKKVPtt/EG6p5vtFLhqtvNadWmNh4OMNh3HuB9h/laqDmTKHfv1O3C6Ye 8EzmJoY8k3f/WTr0owYLOsJmkKA6/UYxYUPtKd2ZV9EQIfcevZ0Q8ppbtHZCHMTyYglQxela6vYH 1shDLsO8Q7TfR1syO+YDG1LlarVstxzwhLmSDZYDc/mGlLsMN3W8NBPDtn56uEdBT7iORBE8NakV d78WcdfwSLIZwVxKkgLgLskNO3d1An6rdX5q3/8qCA48H+t4M3ZctlXDJf2WiJtKYzocnI4bcNVw mWC7qzNolkDOu2Z2iccmUEMMT2xZ/GSJS1DnCW95qh4x8A3L6AnVPGEYT9VfvpKl/PMU6XXFT6u5 4Jgh+82kh1/oNNyUTBn5f0L6cpIoO0AhTxMaL+aQqw2ZdmI/Yd120CHH32SaauOlTKf7F+LETYet yZjkmgLT48TXbk/5L4EwfUboWaDWFlBN8xlh2TFmpbvIXmdemrx66GeQXCYyP0urmSCaVDhujin/ YQCwROjuJ0mekjtknKrN1m3oO9YOoqv1TuEVCUR7hadR0k3mUBk/bqhE2eW2anZFEMXLOeH1t+Te 45F2cbQXaY3Oh2+LtBYN00AKJwH2xfP+STOo2NbdcOmlqIw+FPdl9rv4Z0f9ht43u4q4aP8KcPi1 0aypu9ybgTPXM++cc2LZ/hptxamip7hitJynvrVuR2+pMeHSSQV1IqCZ4XU+mjNOElq6Uo+tsYrm m+jEEysmG0fK9P+fLrTGnqpXT0FehkgAZPpfBY8vaOqJhii2MgvWFGfB6qgXDgm6C6dJaAnd4Z/O RXiiklSAGs0pvFhkMJvwEvXCi/4TNm33T2w9Lcm9nLfmiDT/iZz9r5CD7vqLDIwDW0sps3/WcIGM oe9MorYtUUrnod9QvqoF7QPClTgA908ZhEsBspkWQYHocX1//e7OPUX3Q21HBe9urh5448ys1qwZ KgKTHRDHXfdpIwX8mFVVa/tZT0XqmIKzxcjkniV4+v8j+BdIREmWkzjzY5+q4ppdNsk34xz3WasX uX7Y+6kU3Is4FnkRGYqeqSMgfUa9Upchs0NcmL2MnIBMH44decq8Yx+4rm/2DmiVdatGxioI+85l YbJiLLPwvEqcSwpZYwUz9YtyN6rhn5Th1FQjaImPBXayNdo5VAHkCYE5K4zAyApaQWbcCOxGGzfM UaggshfzKBwG5DchwwLqoEfpzgFhS7o9Ak/wC/Cfp6+x+P8sYesB2qFXTyi1UcjMXvCG7lr9TWzb GNTg122MbYvy0nzIwwoO1RI6SoLndZrCC6F70An5MJ5XjCHS2S4wQzP8Hbgvubr/NmPeDE0IECNS mkU4WYoKYIESLnqq2ZEUOxz238UoDelpmtCJxm458luiTIiZk/mmTZqSNUF+O3ZWlOE/UoE7/h4+ 8NT3w73vTUA3lRgZDGa7LYSF224PR42+XaPhsEb8o2fcpk2BfPJNkbuTZBPW92/ea3I4zmgPex6A rtXk/y+kK3klmziG2XgWHIx/QiKt/bdMfjIqFr5YMl+S7GbHsQe2OTxUDe/CBpvtNi8gHDb7toYK 0lN9S6Uzq8w029rDr8t7a3Qr8+1dgTn4sxD3I9qH1aSyjQw/vKXNo3af53E6DvMfvKoVvwrNOJiZ yP5WlDmVsdwhxuFy9u2E0wlo3W8BU2gvEoV/hHm4J+SGz1VAhWnEGGXcSvLVR4FNfWLGHTX82QFy ya+c6u2mLgLOycbBYY20i4f+j9/OECSYSdPcl7sXTMUuQbtXdpeLdNA4B+BDD+gtGoKO28Dnvz8K 99jPQ5Plu/S4FG7q7nO7enpIS/XTWzymCBG169up8lDnvUW3nsgocvvZgWhtG7Qb/olvqiEvoL2W +bpzssS3bebcXvnDLA4GgTexEvK0NrQzeCNfLMY8jWQKRnKse01hp5M69LJNm1hS9IP+wAFTMn/E WIcEP6kzUUR4Fj8pOEbozDgP+VXRkptbuICE6mkeTthsufP9hxSa8XDe2WYXtHSS4XcXUTUWSzCU 0ONx6e4dNEGgKmEATWgKbLDOtqTya7bXfmH3fbewYqOMdhJn+mbnHw9+kHqtGCw4Hi/vkCmjeI7z sWZJs11zPTelfJqPzHHYk5bfsk+VEbGXN9i/XhLf9vIGMeXhXotYdbnt+Rb4KkZ0bDdWiu34EL7F tF9QPryXOvkK1pkrSb33lEM97m3ehaW+prGOuTe903ypaCWeL0JWz+xffOoc3O5iT8iK26zNzsKe cXdosdBHvcOXH/uot+rPAkd0fj/hxOdn4slO8lJNfHPXsURMthtjcPzhS2cRncK/63I2jRbHNca8 DGNeST7J7+LiWZ4L5nrWYaBA+xV2F8unT2x+mIbROMF/O4Gw/Z8y4diIrXwF//E91cr+p3vyP5Ke /7PYIRFIzUSQXyq4z7yDq7H46Cn7OyN1nMiyIRXYbcpiAK2BCzsDaH0AIUvozLUjN4vwdqUGVrun D6uxvIgZ2d0Z8/wM4Xcv9rLEkNeH0KiwQNGiEi9M17NTe11RIgT5lFz4CRkAdFujuUNlSTbQoeGr U3QcZ0egwzkA6P/zysdp80QrmoaLnnucyzRkn1+z8lL+VeO+htTbxYyrqd1dKRyOEfvROeosdGIJ zsYlr7ToDJd8hA/o+OEjLAmgj/PM0p+uRMBzAN7HReCV+OhEaBeUkMsZL3ZZzL4pnavLryBF6VJt DsWRcgniXm1eSxq66UNyMa7bFf/ijP/90xYdQ2ct5U7H411l/zCbS5f7AEfcaO+eiePad5z6Z8KW M0E5xEGxRZnPX+RNvWhSobGLdfJlJ5MerLFTqd1mH99MRfexTFX0r/8Lou2lFgplbmRzdHJlYW0K ZW5kb2JqCjUgMCBvYmoKNjc1MQplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMi4wIDkgMCBSCi9UVDEuMCA4IDAg UiA+PiA+PgplbmRvYmoKMTAgMCBvYmoKPDwgL0xlbmd0aCAxMSAwIFIgL04gMyAvQWx0ZXJuYXRl IC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe9 0BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl 3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFm ZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK 9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1U SZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeY aeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09 yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIM JwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/j wDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfI bz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMEC EpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6C NnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD5 0CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db 4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMG h6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2Bb sJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e 348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYk F1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlD pVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJR wUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRN tDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP 2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80 /+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ 7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+t n6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3J TVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLess H1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEH PYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKR LmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS 92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUE w8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeL jRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz 7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE 0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMw Q7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341 ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz 7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fg dgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a 5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9H hUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarp J/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF 8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnp te9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9 Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16 sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/ 9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMTEgMCBv YmoKMjYxMgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCAxMCAwIFIgXQplbmRvYmoKMTMgMCBv YmoKPDwgL0xlbmd0aCAxNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB5Z3f c9w2ksff+VfwKTWqiifDH0NyHhXZvtJWzpWV5L2Hyz7I8tjxXWI5sb3eu7/+Po0vCIIckkONnDzc JlUkBQINNLr7240GOP4t/Wv6W7pbF1VaFOum3GyKdLsr1nmT1mWzbtLf9+l/pO/T7y4+Zundx3Tj /v94R6PNOi/1tz3U+Tovdg3NNrv1Lk/ufk2/v6HOZrPL05u7tMxcXX+7+TX97uYmX2/SLL15k/5n urr9eMbzKj1Lt+nqy1n6pEhX+1/4K1nZtX3Tq/Z6/w/XyNVLV/cffqUdVffvP0VN7t/4PxJe3b/f q4v738/SsqXq2/kyX+MZxPJ09U/XxYe96r9ztH49S+J+buMRXmnsz7nBz4X+ipn7IEr3Gvu7MxvW a9F9//Ys/Xt685f02Y2TS3+Ki7paN1tmUFOcaop7E5sMJtbm8+a/xskFiVW7Gol5ciaxBqHcJT3C 6YAwEvv4WSx+6N3u9Rc8IkDE4OY44YoUuPZeMziK3qvFXjdmwObN1xMBJod6t/Ym8TRV5Gt5CiLn y9SdilzL1PQIMiK5R4J0o2H69r5a3Ccysmp+bKJ2p0b/o1eO+3ZUvm/Pg+p5qn6WflYrDf9uZHhv NTBPSSRUW+PyBExjK2Qwqy9lsd5mZZFKwN4kZ8W6TF+abd/C6WKBhX8ynsyQbSq4w5sk7Wzpk80x pXfcTErpFQ9NujrnVqerp/rr8qXu1ypdz7Gfbet1XqHYVTzer8B+tVk0lU9mTG+73la73TatFtJC USbNuFkXZQNed7TMhpfJ5NJAjunt3+jt78kUCmWbYr3Lytr6izBjFuWTFuWbTQ5xxHyLNnPTFU1A 5Gg5Ja8+q2wvyETCFKrNC8ZaJKu99w4PI6TaP996j2F/JqtX+/17vWhB+cO9+t2/VrkGg+bOwHKx W2+A5EgAX0HJyiZyoQ6Qj7rQGUBOPNLBDjMNa1wv3dUkD1L3b6rQ8Arw2+iW65aeGZh/FCGPbR4/ X6uGL0So0PVlH0Vx4AMSKuiFiVQqwFUt96LmCajaaH/2KnEhwzgFwb4n99GP5AdRN3RhEKZZxhXa Bin1dUMZ7r8H2EfgtlmXzSZLq7KRYcy7UOtn0qjbaKoiMHN+PsGos2y3BGi/oK4wxTTiIf7bSZmu wFIsjOuns4Qr80EdcyMwqddf9J754r2uegHbzA7unhaAd7jen5kE1Q8KQSvqgyaIiXLVp5wSZpES 9Ym28Kxy9QjmM+1qFZeLD9X/1tHReAb06Vf0W74T+Bbl/3UjD5SpqfKYcjxm9YXOeXNPLDoeRGHZ dp1tS8y9Fc28YQYxj9DqQjAi6IdEzIlFzEwb5qnr/Wcf88IfgPn+LVxxXwKzgLON0Vrt969b4HtF fBNeXLrXz6Qs/ZtaelxPVm/RBnTl/vMH4ahe+0FpqGgWfX1eFvIW5boqa2wqLxc5Xfo7blNZvDx5 lKNstBAwiISnXLd1pvu36YR7NWCl+kErFwj5xilKa5XQSLt1KjmyMMg3JR4/r9Iq82H86ciTb6p1 3Zg3C7QeHU4Efh2Dg1mqxOA62NwYg9V2XWcZ8VIY1ONd7JawsDGzS1iozpNbEsqJ3KOVtI3meuSW Y/8LYewX7ACwuzp3RvwU+22S1cvr1qR5JZwVdgsfhX3CeqF8i6fmR6hPK71dOw9CFyC7etCzqGkE 8h8YPq1E/5XDfZWrjrVySyfqPGgk9CsGNU61lTcixOCt+h30RS96G/iaCeryzTrbVFnak8O8ljCk o9izrS3L0oV2C116LMg0FiSBT8yrONbcaL67mXYgErwwcXB4VivNn2ZUrQAd6nzrZGiyaiUpLVDJ l1jcXfetO4+rxqqlVub4W2EhGgQkZlQutSFcCQKN3XZMWW2XiDWrSFYVTdqTw1cQa5X1xbpplkRq 10wD4RfsMs/ESzyjy8A96QmFZbAeLJVypoRyLJUrE0Ar5MUzrHNVW+orMyDZVS6g1RRyVVv1iLgo Ub/IGgpMf6hDFoMSpAy1G4ccF8pN/PhdVPaDq3UtZfhp5UZ/BaQTO5w/1f362YUefjpzr0Xy1rGo 4ahz0Xipur6t78v/pWH4LteRx0gOojQ8RlXXZbp1kvHB1QJBJ6OptxCobQvLfSwi9+QsmYSDdv2/ mJwT4iS54DTi0U04jWGKkEjyqSxHVqew3S8MZKYICV1CrwKW65ncJSVqrDoSoUqEtSq5dvpDK7Sr NWuve1BGk2fyDU29bqp08Uylq5mJz3bZOtuxRuuRs5maNdiQv/AGK0MDQjEQmbBKxKwMSuYpg5Up Wc1khdoyCdTErM51k/oza5CLscCEwPSoByaY10zhzNKE1Pt215DBj/XgKyh9TsqnVXqLBpcle177 HA4sgQbMkLAeGHsFznBrVymfmStq3L61zHvkk1nzxlsM2XazrvKiTrcPGg+kb97YgilsBFjfTCTX n32uH/20dbAK/aLJRhUNZrAMdHEyMakfzKK4byaMzDOLN4huxVsUIMwqpuPNtk9mFNP2F6SYskip pPRMeC8/oGfZKIs/pkOtLDeDdOy124tBe9VAykuYQVV0dHquig2CQ2diuZ2+QumwOMuklhbAH1XL MFUHu0b719jktFVlOZhRb3ElbX+2s/V4qypBtZEtnOFOC3BGWDnhllo/spQWIpuk1TqRjtaEB+lG GHDxpcJGgAy8CgCPc0AvKKHb4DrkKFRT5eZ3nGaFOmAF6IjGUSKl1bPV7NNXed8FWbwYXBAU6IUS vzJCvymaTJGdOyRSP3cu1SkOwAJ61lWjvnRUxYfqiDMZ0HDspK3dTIizQGfGZrKavH5dpD1xbLZl smCr5afVFUbLFD7nxrgv9Fepv3LdLHfBO//XT2cYAWZ+o5eW9uQlbGDcs0BYNKQ9660b6CIUZPqm ApkC95zjvIzpCAIfnfa0MEWClxR8dCNBTi6gpAXSJMnt9zNLLYqG3kraIiS9H+g3mqeaYCajUB2j lnT6TTmAKzuZ1oiAeyVhbZwsXKIRe5+Y279FpDiEe+9zGTl/qezjmaUCETbXz953673fHfFl/e11 vxsjEkyHeVU2CbhdoUMwZToIRdNB/ipzskHTTLI4W+927GYFJi3xPR9wBGT3e0sait/Y0YjcIJPV vWfnZ3+MYGSTSTUuHR+eBAgU5gjJORywmRLpIck57oqaraKq6pjru5FhaG5L70lTaWzFWZaLaTHO aVpkWfO8jmhNQP9whEQeV8gXjLgonQbn7oqIEbWelYZAJmh5wD2eMTszS5mFrgwRcxnkLaZ1BXRc b8sGtKijjMqG1f0CiHzHWNyej27E7JZmxbSfsC8IqttfjMc0FznbDSDwhdND6my0snj5eGaRDqek UrPu2WTEGWWgZaawjL1f3hnGZRtsG0CycYM8dnPMOG8UcYiGG4d+EnwDPwm+XUvOzVBIS5OcsYa+ zi9+wtouAT6bYj9xLQVCheF4GOUrZdLf/fLOT/c735OXkydthozWtJXMTXWCMsDh5Tmk0KOn+gtT tiG+1F/Xs+ZJHn1bN9iBm/GDMG+o/aYgU9IrNvjvLTsXHa0JIBtSxaZuBTNs6tg29LS6FSX+si7a Tto4eNl28Z1NnhceN7rEZk2S/HGHYJGciSC8YiRdkemI1TPZcjdd4YaVU8W/86dgtGHs6fpXvvos byXHz7YVjiDIQpi0xNu9OHdODNGjDvTC1bt8eXP6h1cBELpvCuWu8tSMlbeoYShXKwZPecCwAFXm u11+ZlpQHS5sjx+aSAZH49qzCf90TDFSNH7cc00PIMvydZORzy637ekVU8eFm18mNjMzb4veMomP I/P2dUy0VtVbuTdQEz+l/fbftntcpgeT501yFo9uZczIo7BnduRhXfIGrTbF7GNJixr9l6RzfMjb NfgCi6ZCHsLepC+oRAH6ZRBzmSINanve2zNMnq4v9bx/Qt2o6in13+H+eCVabFnbMLpW9qrfKiUO jbj6jRZMrkdvUemz1kKvn4Z2uE4cRzS3tB1Y/jPFiaZ/PAM01Nxbh1+M7dW+PXkj9bWTltPKWu7y dbnD0XXKumC5PX7Ksdxtgch8oPgLt10mlwZ4K6CA6eQ6i2Kd4cNOHLQfxCgjbgD498dOASNm8ZbD HChDe2ZpPPK2c023jIn6wBnVUS6e996n6M3b+96Z1V5mzJTFOjNJJSt/rMD9haJLfG3iTh3c+xYf fOJMdXyOT72j+5AUF/HBgikWwuLBDI3o8ik3pvrSsfIS7eePa71az2lS0bAzbmezbM9nPNnS09lZ j95w/Ba1/Bq0OrUg5ODQtIZWb90Zad28PmTRGel/O7MkpEMDdzeMcA9MsrubQbsHpBzXQIy+AHju Vfh31wLZIDT3oiVlUOEKAk07v0lJRyuuMm3MuR3D3HFWplzMaiwFO4BTZ+ttnhZMWp37P8iUjp1M T+ZOphd1NNcKJg6scCS35XdHmEGZ/DSru2qdlVVWMNSopx50Da18yGpWlhwia3ktoMhfo8wmm3SE 2azcrsuSDY7eEJYzeySRhzLgm9AufKACJJRCGEiJWwomqwve4xxz94bjHbznUAvXIyv/nHNV2EIY +fHV05Pp+Du3iWianSfXZZOW5hIqfIaDmyssgcEHJHLg0yKRe+WRSNXNorAnVfieP5RAA4j1nink +fMrB5ouCRSQUfjYnsBS2qH3ncKHz69aPO3wPaCuQew9ajqtoCWTsuG0cDfHB2ucoQEMFdTbIkbN 2Rn9MaqeINmIegbcK8LB56O6yXTpE5FJQzzY/e0MMZxR7llhx6SIByY5o2eA01qhuJyzwnE2Oyvs sblwKwfVwXx+lBWZ9qEv2ktPTK14Z4tZCv2uO24AHSP844oKkaEkwOUZfOaKQoTyd641Xpv1ilqp vsox5VCfzqGDt6CEWA3NUn2UknK10gDJGmId6l17QabZFIkoVRmwGmhAIqoORBSToL6VtMPS2x/V s8YVH3RQgwE5urlWb0bVuSkGr97Uj8jF/fvZfe5s8mLWdGoUdcuqo9PcZSqFQkU+rBz6sORhX1cV +IcQL0yYztDHkFCYNJ2D462d6bieHprRj61HvAbrScYc9hhIdNZzGrNtRhIlmobCrGrWdc3nCGFG 2+zJ+NJm+L1azhaFD3GF6PSGlXTo7s46YgMT6N77kM3H6z/KW6CmONn7+FMEg/ZrvUXFzRrfv/YB vf9QwTQZI0KTDRlmVbloOIO2IzUl1k8RsfcC+dALPFSbi2hNObYm+0qq7Lo5Hk4gwjadF+uxuAx6 TOC5jM1Oj09gM1JiIqvCIeTWXWt3VVzFiHlrIQdQd8kfyYqQAwVADxWogYp6BqHRDyXXDaFpgHYq jhNCcwVSqQRCOjy2jVSQk+dAjvoqUTis/umYmirBQVBHUSGKjLNwnbXnAQXQ6liV1ExECW5oDFHI tRMwZ8SFnaasa/t2tc1qnQLKZJjCwoIDJ0vl2wUzG76UbRdxfywou55Osdg2pBGvXpk5VP9wUM5O 8kCTJ1jT1d+cxv7gFO3cPb+QCphSOD8e6aSpBjiJiku7YlWKS1A0VClsq9KKbQFaSQH1Nq4vw5CR 6K1sIWg+FGQX1qpVZ2m7aGrMS42NwbXG5j+DokRWELoMJSIdsy3bISZiavRsrdpTBq0B22Rdu8nS EEVfFqc6KtFEhFb0i/XZCVRbys340LDY3JBdjgyAQOlgZT0C5T+tfmcOLNtJ13Zj+u1GgGq+rP+O kSA+xK3QzuqpCMattm/EZNgrZsZunoQdPJ1mI88bPhTNCe0cG6dYl/xhri8KolXRMkcRgCSPJ/GP 84fq5lR/6Ll8hD88hc0Z/Lh0pu59mkxCjsQMLGl3fuyP1knF1qDnGEaCa8N6RFsWyUoHlRJEiJrK UcNgqbFtUQ4FIrLgatnBkV4zrNC2BywtBswAy7QiF8S0Rb5tUibYazHeaGHCQwkJZ2EjIasFoP2Q 1R+OYIJ49Z7xcvPJChOF1WdquTG19up9yDgbrSsZLZNzNFzdsnWFzjmuxnK4Q2AJi/neyotpGTj5 w9+1mM0e5hXp3wjjxsyzyyuEHagTVl69nnrxzDFWvZP3vAYnP5IqPZI9ZMfkFGZnjDQ2A1kn2oHZ yJBaT2wnQmRC7B5jKjKh88iFqVVb3yiMe+5HGBj9DsJkf34MS40HHfvLgeempkqEDZ3n5gySY2zo uduJCDShcB2xLWoxuvD9BAMd9dwGOD4Ja19kEIMLbGJsFOCJHbbo6U4DCxEQJRq8oEgdqY6HWl5P Y1FY/OTVBlXq4Gj+pL3ycWQs/kY8CBvnL4QQUoRv7JasfF4IFjRs6jE8QQ0lMAXLhH6U04BnZjXU YSZ5hilX087zHYkOOGNh31aKjzEAGlr9BABxsu1RKdO8fPiZyEn0mU6Z0s08kxJRYLKfMrXze3AZ BweHODub9DmFzXatiLQBhMJZ2NZda2clWizLqKX4wftSX89S/IHhGznUSUrF4lpoFYyUt1OGL1OV 2l46CiqR4sVfzntrEiEZpMYoY1MzvRVwisuOZzPehXbuDQbgCHYODyJoI3O/E4FJDO2cSjDBVXMV z9hhJPSNwy1AhfrPnbWJny76aemoY02nAEZ8MhTaai6cdU6eDtlmhDw1KrtcbcNXWV1aNuezwH4G YJnSdoF7boviCOSWHVk+xTxdT8stVB8OROksz+tccHBkUyMvBoi+jNmp4GD66E/GjvtmkyFc16Nn eiLBMkRhO5oam6t0UFqmclaMxPNTFme6mdiu31dKGpinGWg3dksvXGN7mkUghQnugKqiI8xEREVC 5FQi4+pCj9aq+6GHP+YHtRjVrlu2A33BkOqIvqaya5WElJ1GcTokAUOQWBJbYP1xTD52nm0YM6MX 7akwUM7WKQbAdlI2JRFlp7qIPKz4XH+94MYspN9w6sQExoTaHe5t5YJWcfWEemWfCEBckoIZMnL+ JXNnJ4zffDoSdVT4UVu55TGLvcXAUOGDR+6vezZ2TvwRO7X8uMSfgmub9qOGCSbnww5x+Ziw4wQ2 pxAN3Hgau0VBj1Y0siNZCOd5TIfkilVJ5qTG5u3br0TULCYqEkuRA43lm/LYyimRHQfkCLYu0t87 1Y67VCTEW4Z1oVELBHRVVY1UqCpCMQSpyz7yWpygElGwDpbl/8stJ24yEAAllXdY/llh5/3NzQTv Hw4zJMt/8pIR9GBoLDUwAkOT3n96U1Y9eXtcZigeDXxqwPMaDOXh+f8TmZ20lbB9JdWQ+ujZLKaN uX2UPKVj505ZQ1CLcnMGAnVXICv91HnvwU9CUVOWp5rBPNHAyzkfVPAx6KYh8HyASJ50+4sHv1fA rkppv6rXI3c01BEo2ga/jGYMDpLeVh98yTY1k537PoCDABAibVbcXx70AwmLpQ5pTgcSBkYSs6QT RkK/7dpmTgBbIL8uyv6EPcgkfJ6eW99BPjBpn8Wf4/2Bpu+6OTVpn4nLYPeLNzlDHucUNn0ArmWr zEwiV5Cr8hj0b3yipguWZZDS61jhpDSdR+rvCsqYbRnZOtBBXygZb7nGAOEdj7DE/WjS4Ld2jiAC XqDgoGs3U5PqmHCiTR92j59aL3IOQ1b81EFHawILxvzKNBb0t/0PsGByJ3IEC9rcoyYwFo0Jq4Xt YNX0NY0FhtQzWOB2IuexYMdhzyKarYmZV1p+PFLOCCYOw4AH/PI1p1f/pCSAenpEEsDzGsPBsoxH BwdDZhcebpTFImySsHrGafPM5trMgo9zHjVHltJljB+zroxPKwFqDlY7JqK8wggTIwY282MbloXG /LCXWazI2dPKOH7lR7AooJuJHnJ+k7Ksym2f3ARidOvGf+HooWSrv274KKRntBOoMVh69tbXfKD7 yPABLQgfBv2B4YPr5uTwQVzGeLEsSurw4gQ2Z9YMF/L/Ot8j5wOa4GRwR9MJRWcn2x0uOoxmXuQz PyVliRlhUqCFwc1vtodd4Vv/MwxEJQAGkRFXxs8VjkgJACE8X5EfwDPuf/usGvBsQbYthUghtT/D gLsNLfTsPy7oExb59uOCaC+fs0yn7+VHw+TE0NG9/JJN9GrHj+ceFcCsp84f66k58ROn6/UvHvR/ jGEEJv+C2zIWiUmnfRW5gKLigye+2ok6mVczxN0ePB0uDO0Hy8qMU4k9ckc1zUNWvuHLmynSGZ+o N3ZcpEd6fqT5DLmsWBcNv1jzAHIR49EWRSb5BrQ5IUnh5v7BuNoCjiLVZ86wbCMdXPHZ7LYG3h0f H35Rtds//4dLO2hNI4yi/bS25ASdm5yfEdOkMWKDaCfeRT9jcXOBShI+/SjN/M5td9/84EZ+LYO0 RDOwwTC0E44CC0jQZp5ZBlEudKAOsAOIQJGwjLcs1Ljav3cCCVAoVKUBz/DJa4J8rupAREVC5FSC zagOyMXEmhnpe3bAm2cR0rjUjaGcUgq8Vmv1KXogp37ZklFcaQ6eMxfTM13ygylZVgA9sW70tH0Y 6hlLrfFE6UIyP/2EwWHoPHuSKMsij78hDJ37uRKLZcnvPNcEIY5pDhsWQXVW5GnXwWL2DmCHM1fl riKi7A/28N/yOZi0I5jTrHdFuXyMeSeC4RgZGp+Jb1kVhDEu5jdGG8kzoM3DT0t1/ZvhLvtlgkuz WCAEvDA154SCbRKl5yolHW6l/obs7SVGZYX+ll7OrZjs5wmFK+NzM/BuyVwyIudnJQtO4UXzDJ9j oSpUe59Tzycm/58mI0yRqnoTm05PLbupn4txIFLz0xfFI3budhZ/QKLbvjsGNv5DyweBzaCXCVbB eEt5RYA6tGZ+80GIMyC4PNSZQQr+zRo+H6/TE2lnS1BoQHvxRERQFIQewOjhoU87jCj4cVmN+Z0x LPUZ/jgkZYAcnnG7XHHvXFViz253Hug6xx9z0xXXDUThuinBS9FAeR29VWOQi+WM4oRLebLx37XM C07k1524PC/zUzq3VmP5Wm344m1kcsYPr/zJMDbt1IsMr56zxGyH3lnzwpOUM1/RWr63k6sTDeKL vqLtqwCRF3KVpKUUyJIGVzgm9oaeu0huPggj9trlVcfNmGQPIooINbowzP3+3RGAHD/lHE5t2Y+D 8F/Rmco8QIbl+4MActBLT4nnWJ0EyAFBAeTRn8VaLYvLWuKLUpJLYPFBBAeS9pvWQdSPgMV2GJ2s FcAchcWnyjEBhWGTwpYmGAJgx8KQGI2gjIHbqQ8VgXMK3rhqe+RwVSiqsh+PheNbQXlRrbcNvwnT crBIMnPJYv69sl3GR5MDgtMx3fDb53+9zeaSb4ARxG44Zz1j7gK7w2jnr/8H9XeYBgplbmRzdHJl YW0KZW5kb2JqCjE0IDAgb2JqCjY5NTEKZW5kb2JqCjEyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMyAwIFIgL1Jlc291cmNlcyAxNSAwIFIgL0NvbnRlbnRzIDEzIDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMTUgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQyLjAgOSAwIFIKL1RU MS4wIDggMCBSID4+ID4+CmVuZG9iagoxNyAwIG9iago8PCAvTGVuZ3RoIDE4IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWE1v3DYQvfNXTG7SYRnxQyR1TOwUSNE2ia2ghyKH ZJsADWK3sd2i6K/P44yi1dfK2vqQwABFieSQnHnvzaw/0yv6TNHo2lKsgnZ48IuxdPOefqVrenx2 a2h/SxX/3e4xv9LWy3vuRKuta1KCgaR9UvsretpiTmU8tXvyhqd2j/aKHret1RUZaj/Qb1T8/Lak moqbkt5Q+yM9a/lI4y1So30Ivh5vsWq5oJLaj8vmGpzY+xjH5nDiqrH3HrmwlbHHbRvjtW+qZmx7 81FzOIyHiexOjodrQn4zVm0NiPG19r4y3RHoEBDTzK6n5hG5+KEkS8UZPJio8CU5KnBjtGnQf8f9 P3jObUme4HGF+dL/m0dlzlVJO9iTqXclRSrQYup7nvQ7t7IZsIBtsgmVA4iZ8kVGX5ZATUZKoOJP nvkXt9KXjec2L0uFVbKjWLvmVbKvfBGb/Umw78AJA1yqMS5dCjrEGhxg6Hee3hZs9WrAvdAY/RDq hcZpF/4/9ZocPTIVBxpsrEqF1qxx0uDKjW0cyd7rd0cEwPaMomOc7Hlzgjkc+au5AW/Elz1tNutY T5uZMxdoQwu0ecLwPH/O2H59yW8ZuKoD6z8MOwGoAE5gfd4y337i4X4ZMAhLA+xNZBeaq10dTOf/ Lvbr2NsdHDZVceutDinYsbms4ttufy53ERKO2a9G7Afv72c/w7Fnv/AVG0RVPGO3/su+EvYPHSoa 0wmODMjiIf0/cYBErb7SfM3Tvoo6Br+G9KmKDrPPIcOGeH+GVWsZNsScYQeCXqWZoB+QKaRDin0C R0GAgbnjcEpRp5yxR1uM0LR2xymamkrXsYlw2eTEkmHVyPDhxFIU5Ax7HKgG0bAcDTa9CferumN1 snXqTrrJHJC4pDsS3V54Ts/XM2cBc9MKahoFhPc5OLEDWcYPQrLesZTzAy7IbwSRynPv7m5KtUNe BGPQIlHnUfA2P+7AnPwEmXc5r9+jQwnxiBCO7fFY1SHUnwfkDFLat9chxL0jEJL3FPLOoEg1Ps4g j0Q5i+IB8j1JX4Ke8DlqGVBVCCt9RAE1EUKC76hQ0GYlpOISmiYSiU9QOau6YZQ0+CLmhgsuEE7E GtUd2rP+Lgv1trfI7SaEU2I6IYX8jAhhUteo035ShJDrmoHg2XrmywVGvNhzQSqij4Mh5wD/8GLF LdQFfXw5LofGZFlAGS8neIgssAseogpTHywQYcEHF8fKkXGJLjlU2lxHq66+FnAJ0sSDHxhuUmsD XKjBZfQX2QgiATTKVOlflwpuliAAvujLMsnIQGk/ChFCiMT0cFQydR5VxX8c0n4V9pqvkgNh9+OB dT5ph+ieEtgVuXK10cFPzX0fZRO8cVyuvIVc1QkUn8Lre5WrrF2HKy2oVu2Nji49hLMoqQM5p5Ov Kkc1flVZ/BAHZNLmbN7/OyRgWV+s4X8X+R8o8ujY6rTpCp5Hg4LiC4Ndim8KZW5kc3RyZWFtCmVu ZG9iagoxOCAwIG9iagoxMTAzCmVuZG9iagoxNiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50 IDMgMCBSIC9SZXNvdXJjZXMgMTkgMCBSIC9Db250ZW50cyAxNyAwIFIgL01lZGlhQm94ClswIDAg NjEyIDc5Ml0gPj4KZW5kb2JqCjE5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9D b2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL1RUMi4wIDkgMCBSCi9UVDMuMSAy MSAwIFIgPj4gPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAw IDYxMiA3OTJdIC9Db3VudCAzIC9LaWRzIFsgMiAwIFIgMTIgMCBSIDE2IDAgUgpdID4+CmVuZG9i agoyMiAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2JqCjkgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvU0NGS0xPK0Fy aWFsTVQgL0ZvbnREZXNjcmlwdG9yCjIzIDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rpbmcg L0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMTIyIC9XaWR0aHMgWyAyNzgKMCAwIDAgMCAwIDY2NyAw IDMzMyAzMzMgMCAwIDI3OCAzMzMgMjc4IDI3OCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYg NTU2CjU1NiA1NTYgMjc4IDAgMCAwIDAgMCAwIDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCAw IDI3OCA1MDAgMCA1NTYgODMzIDcyMgo3NzggNjY3IDAgNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQg NjY3IDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCA1NTYgNTU2CjI3OCA1NTYgNTU2IDIyMiAw IDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAK NTAwIDUwMCBdID4+CmVuZG9iagoyMyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0Zv bnROYW1lIC9TQ0ZLTE8rQXJpYWxNVCAvRmxhZ3MgMzIgL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAw MCAxMDA2XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBIZWln aHQgNzE2IC9TdGVtViA5NSAvTGVhZGluZwozMyAvWEhlaWdodCA1MTkgL1N0ZW1IIDg0IC9BdmdX aWR0aCA0NDEgL01heFdpZHRoIDIwMDAgL0ZvbnRGaWxlMiAyNCAwIFIgPj4KZW5kb2JqCjI0IDAg b2JqCjw8IC9MZW5ndGggMjUgMCBSIC9MZW5ndGgxIDMzNjgwIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4AYy9CWAURfY/XlXdPffRc09mJnNkkglhAoEkEAKRNEdARO7DBIkEuUHkCKDi QVA5RBR0V7wFbzyQEAIGZJeorO6qLKy67nqzLp4ryu6yrAqZ/D9VPQHc/f5/32+GqnpdXdNdVe+o 9169GpYtXT6L2EgTkYg2Y+H0xUT8hY6j+P2MFcvi+rU9SIhh4uzFcxbq156rcH31nKuum61fR6oI mb1x7qzpM/VrchZl37mo0K9pOcr8uQuXXatf53xECDVdtWhG9n64FfVrF06/Nvt+gvskfvX0hbP0 9rfw+vjiRY3L9Oubf4ty++Kls7LtaS0h1l/r97pyB14BeDD5B6kiDxMjYUQlJWQyIfLzci5RcM3v K86pv9j/dL9pzqp/mcIm8eXH/lrYnQO/efDKy37a2TFHJSYbLs2iPb+B7xkHZkaTISr5aedPK1X9 TfxO19/gfWSi1G13Khg7ekAqIseQmFTUks6N7ZMKpdyWATGtTUrudvtKnYN6SHE8sUTkceSLkHYi HUSSyTQpirsq8lVITUg7kQ4iHUUyEIKc340jLULainQMySDlSpGWeEwdVCjl4Ls5GK9TCpDvkTqR JBJDXoI0Bmka0iakrUgG0Y7XLEJahXQQ6SSSgWhSoOXuMvQ90HK7KHbPv6pUXE7XL6fWi8vdl9Xp 5ahxejl0hN6sv96sd7le3XOwXhYW66W7oLQJD99tsZe2D/JLfgzSj44vRk7ZIeKklMTINslHmpGY hK6KGk1y785PlW49KMmESkyiZCaJdbZLtMXuKh1kYZ3se+ImMfYdO6HfYSd2O1ylWwddwj4jO5EO IknsM3z+wv5CVrFjfM6RVyNtRTqIdATpeyQDO4bPp/h8wj4hTvYxKUGqRpqGtBXpINL3SEb2MXKV fcQpRuQcrkZi7CPkKvsQw/oQuZN9AOgD9kFnO3unpaKydJ8A0iVZIFaQBQLhLOD2l7axt1t+LAJF pYBpUNRLUh4ZSMqkvJaC3rE2KdhSNS/Wxv66O56ObRvUi71LmpEYevIu3vwuiSONRWpAWoxkAPQe oPdIE9JmpG1IzUigMuQqUpy9gfQW0nukF5KGNBbJxI624DVt7EhLanBskJ/9nr1OApjxw+y3onyL vSbKN9lvRPk7lFHcf4O91hKNkUFW3Cf4jopSRVmC+wp7eXe+O9Y5yMUOYgZjyEuQqpHGIE1D2oRk YAdZXsvMmBsPeYm8AR6OsRbytSifIo+ZiDY/pqWGgADjPEv1vwgQsq3xrSmmpbbcj0uepe68GxDP UrduBMSz1MrVgHiWumoFIJ6lZs4HxLPUlGmAeJYaMxEQsjb2yIv5hbGKMQtofJCTXYNZugazdA1m 6Rois2v4h/wo8z4+2NK9O2bsAS1d1D3WtJ82HaBN42nTY7RpFm26iTatpk1VtOkK2pSmTRHaFKVN Gm16ifbDVDRRrfVnl5VakDa9QZt20KZG2pSiTQW0KZ82xWmF1sYSLSPAdShqRLF7EGc6lth90UBI HydLYEYToPkEZMJB5EeQOsWVhkbxPL1xTpSXebu7V+vXPfuXLhp0MXsVX3wVaHiVfIokA0Gvgoxe xUNexeOcyKuRpiG1I32P1IlkQOs8jGOTyJ3IS5CqkaYhrUL6HskguvM9usLIIuS8iztFx0qQVyON 4VfsVXzy8EmwhJarRtS0erG0KUKdUTom2hllFcTvh1x2u0yuNmrf+2/7D/+2E/MgM7uTbSK5QMTm bLmp5cfcWBu9ryX1UmyQj95LojKojlaSFC1A2Y80ius+JGLi9eUkwp5DWdoSmYyvOVtSxbH91MG/ tTf2Y+R47OtIGwP4VeSl2J/ibTJtif0RNc/tjb0buS32u5I2E2oOpNooiv1x0XRfpF9sxxui6Wrc eKAldhMv9sZujAyPLYiIG7P0G1c04kpzxsanpsQuxvOGRq6MaY145t5YdeSKWJXeqg//zt5YL3Qh rYPd0dmiiHhpMioeOKmijc7Vio1bjLXGMca+xlJjsTFhjBlzjWGj1+Q2qSaHyWaymEwmg0k2MRMx eds6j2lpvup5DWLxM4CgKZEFrELCUC5mkBNGTYxcQpo90kg2csJgOrK5fQYZeWW8+fSEZBu1jJvS rCQH02b3SDJy4uDmfumRbcbO8c0V6ZHNxrGX1+6i9M461Daz9W2UTKxto528ak242T2kdh+h1LXm jjAvu625o66OBP0rqoPV7oGuymFD/4esQVQ2DE2f/wueB9PBdG7zlpETapufza1rLuVAZ27dyOZf TIhPrd1H/0FP1gzdR//Oi7rafdJA+o+a8bxeGji0rm5kG50s2pE4/TvagWJQoJ0JCzNvR+KmqN7u Ab1dAb6Pdvm8QDuzmRSIdgVms2gnU95uV2N+zdBd+cjQJhAnjaJNYyB+YZs3CtCmABna+JvIG6LN G/4m3qZ5oHhMJIImUWRoQkMkIppEaEg0ET3fJZqUZJvcdq7JbeJNkt4b0YZneIz9WFcb+zG0uWAi /9/grMHpNN09oG7G1JpZyZqGZM0spIbm21fMDTY3XRmP75pRx2/Em6VUw5Uz5vJy+qzmuuSsoc0z kkPjuwaI7/3H7an89oDk0F1kas3E2l1TtVlDWwZoA2qS04fW7R4+trziZ++67dy7ysf+D+8ayx9W zt81XHzvP95VwW8P5++q4O+q4O8arg0X7yKCxsfW7jKRwXVDgD9e7mZWC+i1IZyoG+xXFw8UxDsg EbwpvB/aynZiTdc125KDm+1InK57DOoxiN8CT/FbDlQ7s7eCNw1IhPfT7dlbKqpdycEkvWx543IS rJk3VP/XiD9ULVvOUaHnaV73P/6hSU2zNn0o161HNnefMLK5etyU2l1GI2obhtahrn9XndVa09bZ rlf2RGV/3lCSzjXkdVW8zmzONvxvWhB9QjVmZx8UjZd2Uy1Kl5HGOqk5OnIigyiYOAXTMHVK7X7o UnyRaKzDABtpmjZ2PY2PQ8BEryEYdmNXWrY8C2XnYlm2FE0b0yTd2DUlXY9L88kSmZirZWmINmU/ yUEKKU+THDlFYP90fon0FS8z8zq/4vd5yb6BoGvLJtgkZAedR3aQg+QVehLf2kn2kVbCVaCh5CFy A/klWYdlbQpqbiPj8VFQ/0ua09kKy+RRLJiPksNoexm5iewnfhrs/JqsImukd/CtNcRO8sggMpYs InfQSzuXk6nkU/kWUkEuJVeTxbSps7bzzs67O58gT5J90m87O4iVhMgMfA53fqf8ufMj0gPfuIfc Tz6ld5v3EA1vaULLh8lS8oBUL9POOZ0/oQcJcg36IJNR5DBtZ2k8fRb5kgbpDdIQPOXxzubOQ2gV IfVkLnmA7Kd96HCWUKZ2juo8TPx4x7V46v2khezFp438inxAbcrJzic6T5IcUkxGYDyt5Pe0Xcp0 rM5UY94UzFIRqcSdReTX5HVylCbpy2yRYlNKFU1Z2fku8ZLeZBJ6+zS++QX9N7sJn1XSa/KwzsHE gXm5i882+Q35Cw3REjqGTmZFbBF7RFpKTHhjb3xmknmY7/vw9E9ARnuZjR2RHpefk88YcjPHOh3A SIo8SB4mL1M7RhqnjfRm+h79KxvCprEH2WfSL+Vn5LeN0zHqK8hCcgd5jvybumk/Oo5eTufSG+g6 ehe9nx6mR+lXbBCbyBaw76W50hLpV/JgfCbIjfItylrldsNXmdrMocwfMv/uLO1cS8aBHlaj9/eQ RzCyfeQIeR+fT8lnVKFW6sAnThN0Er0en5voHfQxup0+Q1vxlqP0M/o1lqR/0TMMKy0zsDCUH64C JdlSaJi/ZA+xI/gcZd+yH6WAlCelpT5SlVQnLUKv1kmb8dkj/UUOyUfkTsxzqbJF2apsV55TXlFO GmzGm7HGv3X28Y7uHZ9kSGZ9ZkumJdPa+RfiAw6xesAEq0Lvp+MzH/jeAorbSd6hNsxdiHanA+ml mJlpdD5dQq/FTN5KH6BPir6/QA9glv5Ev0ef7Swi+tyT9WGD2Rh8rmCz2BIoY3ezVvYe+0kySlbJ Kfmk7tJwqV6aJS2TrpO2SM3SW9LH0mfSaeksPp2yRY7JeXJKTsvD5WnycvkR+Uv5S2Wq8qbyucFi WGhYa2gz/B1azUDjWOM4Y71xk3Gv8V1TA6jzVbKHvAgKPPdHj0mrpRppD7mTlck5MGF+D3qeRmZK oxgolW2n69mNtJXlK9caBrABdDQ5Kacw16+xrew0GyCNoiPpBDKf9dYfaPDKzwKqkl8lJ+QDGNvv 8eRrDTZ6E/veYCMt0JEqoSP9Ruolp6U3yQfSp9QoP0o+lC00QE+wp6WxoIJfyQOVWpKQHiIvSEvo jWQPqyHEcsa0EXQ8mj4LuTCRltIfpE6owaNBRRXSX8ktZAH7MzkBPl5P7qUz5TnkTlJGbyBfkqfA FUXK1YbuBh/9HZsnb2Ae2kqY/AxGV0nzqaR4ya20XnrA8D17nywnR2QL+UR6Hr0/wl6QRsknlfF0 LjjgRrKWLOlcTa5TauW36Rwi0cmkQD4G6XaDVConUK6CVJkKmbYX3L0fcmCQNAo1QVDOpaCLSZAQ D+BzH+SEDAqaBx6/DFLs96TVMJG1kTmKg0LqwFPzZmY8mdL5FLm/cw65uvNu0gPyYF3nDXjidvI5 2US20zWZ68limJLvg7cvVYaxI8qwzh5sA3ufTWBbfo5fzHYBDZJv8HkBmBmovEQ2yH8iE0h158bO P4K6u0HC3k+uhMJ6HKP8Dm+4WGonZZnRbFfnMGkxxvspGdf5dGeMWsjczqvIGHKAPGlUyHRjGjhu pm9jvNeTWWx85zJpVmYe5mETZkHDbC2H/LlNGzJp4iCteuBFVQP6V/ar6FNeVtq7V0nPHsXp7kXd ClMF+cm8RDwWzY2EQznBgN/n9bhdqtNht1ktZpPRoMgSo6S4JjmsId6camiWU8mLL+7Br5PTUTH9 goqG5jiqhv28TXOcf286bv2spYaWs/+jpaa31M61pGq8ilT1KI7XJOPNh4cm4210yrhawHcMTdbF m08IeJSANwvYDjiRwBfiNcG5Q+PNtCFe0zxsxdwNNQ1DexTTXVbLkOSQWZYexWSXxQrQCqg5kFy8 iwYGUgGwQE3/XYyY7Bhicyg5tKY5J4mv4jFSQc30mc1jx9XWDA0nEnU9ipvpkBnJK5sJ15TSogkZ Il7TbBjSbBSvic+DjtNMbo/vKm7fsLFNJVc2pG0zkzOnT61tlqbjGTXNrjTeO7Q5sPJ48PwlHg6d bN2Fd8PShprgvDhvvGHDunjztnG1F3w3nOBPqKvDM/BdVjCsYcMwvHojMDWS6+LNbE1dbTNdg1dC sSwQo9LHp2u9BQ3z483m5ODk3A3zG4Ca0IZmMv66REsopO3rPEZCNfENE2uTiebqcLJu+tDILi/Z MP663TlaPOfnd3oU71Jd+sTucjizgM1+ITALk67fE5BozqGR48/NLOV9TI6AJtgcnxFHT2qTGFM/ ns3qRzbM6AcE4K+O4lvNM4GRec3mIQ0b1P68HkOkzUqBmoxv+BcBBSRPfPvzmunZGkOB+i/Cb3I6 OUdqzXR6F9ycTjd3785JxDgEOEUfB4rrPj2KV7SxZHKxCvuZGw1kLOZ2el3/Ekx/IsERfHubRq7E RXPTuFr9Ok6uDLcQrQS6NWvgd9q77vgm8TtNXXfOfb0hCUpu5fYs8TWbUuf+OVW/p2Zu/2bq/3/c nqXfHzkhORKqcbxmQ0OWakdO/NmVfp9PKOYN97JQs2dIrRRmqOMQC0virq4hdzWBulxra5YL8M8g iHpmm9EEqhQ1ND6sWW24WM/rLIlElmf+ty+1dZ7k3xLF+a9lh9HcP53tqN7t5gE/u/5Z92wbpJET IXIYNPsNGyw/uwdS03s5IluA4mHoJ+JDmskkcGYB/sHk6MdTXbhZw5ThzkRwkaiuC2cvf9YwnP1S Hf44dfYoHgaZuWHDsGR82IaGDdPbOpuuTMbV5IZ97BX2yobFNZB2OuG0de6/Pdw8bGMdZmwu7Q/2 YGTwriRdP26XRtdPmFK7Dy6O+PqJtS2MsiENg+t25eNe7b44IZqoZbyWV/ImcX5BRlIMsoWZRPvw Po2QJnFXFhXiega8G6JOb4Q6Sma0Mb1O7WrHUCfrdZqo4+PjMmbIxNosWgRBcNYDDWGHBo/hOoYy mdSyZ8kNIlWSZ1EOQv1+fk9uJJOQPkWqQpqMFELidaOQpiNBfyWT0HafMrmzA8/aorxOZiM9Avgx +a9ku6GSLMT9g7BKK9B2i+FZch/uP4T6GWjzCOBHUU5F215Z2Gy8A/bVZGJG+0uQ1uK7Y1EOQxqJ Z3lQDkZaR18n63FvPcpb8Nx1vA5paLa8GGNZg/vV+E4+6m4BHMI7uEPKiZRA6kYIJoIzL8FOl4G0 o4yTy7M1vBbqD5LELW78KWhjhO1gJhbYUDbYXQ7ixN6Ri7iJR7ToyrzQGfyw14JCLyYkDN2YwKUI xzbekACcR5IknxTAvigU/ej6pl4Wke4kDRulB+kJXakXLBVCSkkZKSd9SF9Ydv1gF/UnA6BtXwTH fjU0iUHZB/iIj1roJfRh+j49y0JsvNRLekTerWwzjDX2MAVNV5vbLG9bifWPtkftA+2fOYY6tjrn ON9XR6l3uwvdZz1bvDm+Mf4n/GcCdwSH58wOfRuZlDs0Go3+AE/l6sR1eSPzfpPvyt9U8HRqQ+GC bqOKgkUPphcV0+KjPT7t5e2dKh1fNgw9gTrCp0vhc2fEZLsSrgJk8ASSs3Gp/aymkDMkLrfz+7Wd nyiFyjuYmWLSl16k/Xalb6l/aWBlz5Ula/1PlXxMTFtyH/ez20pu6ctuidyaYK1+2hCYnmB+n+af T6Rnox/4WWOkMZctDy0Ns+Xkej/bELglzJ7xveBnt0Q3xNkGyy0R9mb8tUJ22P9KmO0PveZl8/ru 97N5gVllbFYJnVw2tS8bVjYlxkb5B4dZr1BljKXC+XFGevSI9uhpsZCw35/ri/v98fh+Sw+vxdIj VaTS8qJof8kaXpubvKLBs9izzSOVeDQP83yUuylIg21sihbJGRhdGs+luf36FV2xzU7t23pfETdS 4/yKJfcF0+rp+hOn6k+op+qPnzpRjwLwcVJ9/ET1iXWOnmnHjeoho6NqnYMXapUAevei9f/9R7JV BQZDMq8w1ae8b0WK52WlUBYV2rciYDD6A8YU7du3T3kqmWfwef0BSg28LCvtKx2ue3vlX25dsPOF GYOPPLzlYOZv1Ngj56Ve42c1XbcwE11eM234iOnJJB2V2Xv37DtvHrdjx4wZ991w//oPJyy9c/Ct r7at/sMvM7tql3Vrv2Ht5ZuGSWtq5laPnHbF0LyR3Tv60Psvu2dEXfsscNUNmXGsAZhWyUWapdCJ jTS30aSqbbRsN9nqMKHUXMatjiuIpEpxSZKedz28UUxSx+kT6ukTpLqquoqPn6aYq7yib0WZwYiP T6X003t+P2rKgdXXFV6UTNN0ZtwB+gN1fPdBx5mjdRu2vPSrTCwT/9n7Z2m2bqybyswWlRK3mffA slWiKFux03mFA2tbq6qySQB+aHU6BXC81W4XwLea02Jhk5yOmIM5nndn+8h9Rv/RT0+SuMoLU/iU +aG1q6xjNU2n8y4qXLn6wJRRRzLj6DH6lwP7tmyY8vaZjg++y/wjY0Ivn818Qm+Bp8VCRu+xgH2e M7TRsVqKSlWMgbWriAXbmFIVMfQz9h8DK3QRbKptYLVt1kc5SZ2qP3VcPVGlVpFqnqsn1I4T1OWu 7N2rrE+Zz2swFvbtW7H38NjLSiuB98NLbk+NypnOZd4g2sbms4XgyGItZzFbLLFRdBRemSQspCxG gxx58R3B9Gj1eL36BSkZdaJ3L7KE1nv6JHyDWBFt27OHS9P9yNah9xIp0IKMd7ZK7+JOIm/D/W2y 6OVpkDo6qHdq/+HDh/l34UFjlaAPiUzYR6TOT1q8layt8xMt7q28V6JM2irtxBbuCkK9aA0RIxGL 9BVhXwFvz+Dl8u6VGH+VeuqEqtPKOqVnuh48xGkmnfbRMkqf2ZypzVG+/QlPYGRS55eyS2kHPebS SbuwQk+s1SyhqKx4o3Z7wNzW+ZXAPQe0HI58s4vYODUQv82G3MbrSAkQfxjZYYyHjyi8y/DfTzqF Jxkm4UlfgIoE8J2WY7UCchGV1xDVZuM5rzv3yPPPbDXEc9QIyBLKg/XXUPf9SG4kJzZcrpQN69h6 63rn7xyK2WgNshrPpb5LcoaEJ3qm+qbmjA8vMC6wzvBc5VuQ0xC+jl1jWGFd6VxnuM+4Rf1d8AP2 nuE964fO0LmBN5q1RLK8l5kSs2pm5s0xVyOBmqU5UBvHUsPI5ujrtwvGTIMv65ekOSr50Gn9Erj/ +vE/ilRX51HdXAb53SB+IZk8Kpc3LhUyyGiYtOCdbStalg2e/86j7153175nbrjhmWduuuGSevYO lelFz0/bnen8IJPJvLrjvhfpw5l7vz8Jn9r87+at5bTyKRB4BrizkJ1aXNLsrvIF8iq2id1vQhAH NRODwiSzQm2MvmERvbfwMREax3exSSW4G8A3mksgNCIQ6hAIxSxrORxdXTgR+AnZFM3uLFe6ZqKX QuPwQzIlx7qfVtE1RGeNJWlI9az/GDNTNaoDjFgdqKQucCCtJ/XpRNJlMBj7gAvL2JnWQe9MvPez kmXy9QNviL0w/I1pfGxVoGUjxhalr2dpyexS7UGPxzDJ3tZ5qtXlEsB3mllVAUW9SpSTaIA3iEb5 3WjEgTtRECjyNvaSZmOWQAAxHy7G4jFIg5J3D/P8MCk5wTtbzfNDcDqEs2zAX2hzu5l4oWZ2ugDp 7zmmWd0eNinq5XX82S14NGcVq5VNAvCtJmbxf3ob5xH+Pv428TKt7wBlgOEl5aDhJePrpt9FjCNs dbaJjgW2mY6V7pWe29wH3J+HPg+fDNkOWl/0sDC2cHPVqGr4NZzGRhC/CaUZ2ApFLarJYHgjEvJG IiFTJARpYQpFJHtUbWNP7B7jotjgDe7hIyBiOpyU2SyNgXcw25zW6UtsNYkTlfbTbK491XDuLmKr mMz2s3xs427apRM75MrpNBcvWIg6qqpPdNQfd7k5ZpF1Lde6pBUswDmgH6mn9Uvr6gp8iVQFMN61 /HIhLNZmUAL+ycazFSxQ8PgD32+///qbH6L7PD/84Z3TFz/9ymNTozt2DKqa0X7Toc9nL/jFQxs8 R97/ZkftsweeWD+9NyhlcucXsh+UkqZ1WcRZc4Iap+JghFBOqmkbLmhR0mJ32pxRi6XIF43I0aKI UmRP2m3BHCx/cYgeNiluTHEs8uapEi7QDpfwD3FXVldjETkBajnxmvqau1I9lC7lCcSidVPsfnuN fa1drnFd5loRlsb7r1Lne2f6l9uv8661b/DeFn7SblHiEt8XtlptdodspHgvlpondmsYwEtwuxUR O+3TarP55OB+9gTJYXO1QvRSQTft7sZp8UVxFg9ySo43GRtTQjalKEmpKYYen3qR30lt7hFso/1a ct6h+2k/LCTtmvW8tCpuo3dncZg+IbDIZdaptFiCgEegEYNTBT51dIJVIcLArXRJnafCz2WW0JuM FedAsZBy2cbXVJ6TZF5qcmvsngWrdj52Y9mlXre1sW3t/Hkbva2Jb1649o0Fs2fevDnz1Xsvd9Jb gveva775hke9j7Brb5xx8623xve8Pqdl5rSHekZ/dWd75l9fQMSGIANUZT/km52mtL7uWttc2wO2 Z2y/symXSpfafylLbtA4sRkko2KxSkZiA7O/IcleSZIlO2E2u2yUXkLYiwnK+DbNQmQZTcgbFrmN zX5RUSxabqzc0iUJAfCFiU0C8J1YoSxttEKzG7W8ZLmxKdHHuNmJpRizaveWE6bCgpVwfUx8B8Dx vRwLbI+jjW4UM/1tOl0vBOEpLl6q1C9UIQfVU1Wnq1yVfJIrK9f1TMtYnZ1OJ6Zb7PrZsea7KyHj 3tWsZZVSXo9KSc7NreKPqAMy0Ebz2jRrpa1pbKVNS1Xa8iIoe1TyBuk6GBh9aJmrzJd0SS7KtnTc yh7+xWuvtWb60GlPSnvPXvJk5lEw9T0dC0B4fO1PKE9Bxk7WOQfRAhifnU8CjTgsUZ8v4uaS0+qU 5WjE7qDEGMR6ITQCAQgu4+s+5xK+/oGIOg6BMzhjFLmF7HWKfGToutwNuVs8T3tetb1n+zBsMnuC ju4hydxL6WXdDzkmgTtUj8Xn9njecDi9Do/X4bSDRTQP74jm2AZF0+HUfDTbqRedMn2Hsw+kmhbn 3XNNUxepq9RNqqyCSYKCSYKUBNUgQ2d1JglujrsP0D6IjLsHRNWvxbHnf2IWBKxcyCzn2aWea5Tg ETHQeldlST3EwvF1pp5pBVgkwKjgGvDNEmhbP2Mb8Ion4UtIkHnE5zVCE0hN+pXv/qtubt2x8bKN 3Z65k73f8eKYW+9qp6Zld5z6bQdtUjfcfuixB1rGVPvZ35/PrJiaOf2H1+9qOca1tlHAnA8yL5d0 p2OyUi/mpDFsLEk03C2qwcqyY0kMK3lRr90SpaRAxRToGpwaDah8wQ8ImRcAegBnNbjD7x5Wf9OF SVhih+o5JnssyKFDjZpvaM7Q+BT3xPgCaaZxpmm+e2Z8mWl5ZI1pbeQ907t+lzHOOaBQ5wnDpKQQ eLwqIW4Y+Y3CeDKe4DdcvJdj7Qz9DNN3pnFEQuiZu/oMfbaf5iZ7ChpVgUjYKCqsEYzi5ItcS1Q3 F1u4mIvSSs1fHZgWWBRYFZADUEoNkwJ+/tJAG8vfndaVNHDiCb5yCZmna2q6pCup5yobX6U4+3Bp V0eNsFa4amYw8gXKDdkGZBGXWoErP/Wel4QG6czuYPGIBZMHTbqSDTowp7XjmqO3/iVz/OHbvtrx cUfFmDtHL33isetXPitPcMzvNarXwO8+mtGQ+ffbG07chM2wG+gzL29/5ezH9c/WtT1y386dmIDp kHd+7KnbyWLNcchOZfxjJtkMWca5sBejstlmb5QkxqdkjFiiJRZymhrNfyNjgPtpTKpGsYiugvKY A0EkqHg07KElVaNOnRitnubaGLcM+Opd6RIyCONfIiwYA5EMxmRft7tiurRnY+bEyL7OfdLN/7xN /mnHxnsy7syZtg930G/o6w9xj8UEUGAOKDAAH04vRnQabLWRcLQnl5HQw9iknj3diahB6RZ126Nm G19gofyfgpgEkHZy+5KTIQBdceKAuOkMYq3UjU8B8FYAsuQr5ftsXM/yiSf6BPn6suSrWyEXmCKQ R+kTleDKrEXyouiIMD54RwDwjhwXlgkHRF32/Vz9xWvPanm8IX8tJy7+Qp7zkZ4fXxfL4F1UyEO9 J8Im4hxU0cdPi/wj/CNSX9i+7qWYe2G78kZ6g7zMtMS61LbcvjJwO9lAN8prTautt9rW2u8IvOV6 zePOA6e0ROIhXsTjJbzoEceKf0yLFsVtJBokNnRjW096vifRxoNmam5jczQ13ejU4tD44WVwqk7m bKN37S0NNjbDdMb9lvxGX5ciH/dpPubb3PucSaN7ZLiGkFUQ3JX1JXxwfNHKcgznGmh2S8iSujp6 3tVyThMgcL54hG9F97dIF7IOnb/4qi8Otn+zYOG6OzKn338/c/quK9cumLvmttlz1vcfsXnC6u07 bl71tBQuum/+tg8+3Tb73qLiQ+sPdBJK2ze9TCfOvfWWaTPW3Xq2c9TmMU813fzs9i5bltNkFFLx Bd1qeNEawxJQ4MICcFogma8EYnEHcFLrxjEadAmUuoT16Qq6itPWblHu2RjjkBwOLxlLqVAj7Sqs CspXGghVRWD8ULq+FCRWf6JUTAwwzwlR5VL0499wohMG9QWdOL92at3F4ukSVPz/89afv+s/XoU3 nX+RVt4/dKlfS17uvyw5W7rKvzA0J7kydGN0Y+j26AP+Z0IHQt/4v4ifjnsu8j/i3+GX+hfNNLBC vu4mQUzBRNwQ7xYd45jGF9kIHx59Z6wuklt5JxC6WUmskMiuny+rm4u5nG7lYtp1jpZcmou5Nmcl b72ubXLBy+XuubWzS+ySevhPYCQLBXMg61NeyKUtSgJhix1ebjKnaJe/Djro4h3+G6ZPuHFsX9r3 pYV7z1Lja5tOXL/y7489/wF788ll17Y8c8ONj9IJ6sqrL13158W24OQF1PTnT6n6QOav8C19mdn9 wkGp/MG9hx7aCJGLlXQfzJ+1iGHiPtp+0CPg3zaamaFKlqqoQYbnBnoNYXHMxaOmrG9pCZefsAYE ygU7eOBVkpD2wYkj1R0+fPZpOHMYooyIUgf91UgcdM5e6nDCmwZF8R+tWeAHQYioOaXVcULkMtIw SRF5idpLnWOaa25Q10ub1d8prxna1ZOq1aTUIYRnrDrX2qz+0/ZP+z8dZtkm22WHhG1wRZZhXZgM RqMNsAmxKvAnwXunOYVlHzfavLjFJAi1HzRIM0jVuGzz4lvmqKKYogbJ0MYWa2ac6Phawx4O20+t YDir5rbFySyjNH4sQmI+laXNMpURI6tZx9rajZ/apM02auPXqtN4xMhWGZuMzPgL53t/Ep64JTlY ffAviBkL5aiggmB1VehE9XG45fCP+6fS0J3W9US4KUoxqdCO16mHDjkOHVqn6CVEzshmKyLootgm bJWdksm4H4Yv6fyBS6E6upTrW/wvCQ9XUkpInoSUKjQYJVb2B1b78XMdDz76Pv37/cPyImXK/p+G 0QOZoWwK3bLvmjtu56vZFqy8XwNTLqFRefYRGTgZzv1QsjwsOTk5O9lovtVsmBdariw2N1pvUW6x Ggr9ZilY2D3qzzWbPe5o9+5FRSSSG8W8xeCAIKZgymDj/lMD7AqtjK9hBjdneYOBz7zBxJ8OEBg3 ePmSYphYkLJF+DdsFt7OxunCx1vZQsW50bhw28T5feCUC7MswNui5idYj+cA+G24eMNzANWnB0zl nip9guqx8kMRwMUomH/6HwiaW/NIEGZVMFMqS1yVkPQUVj1mnntsylyJC+w8B0vSRKluyqeSMDpK KzjvpgBvYantbzbOnrNm02VNL2/M/IJetLrfJSOH3fxI5kO68IrUkCn9J96zMbND2V+3b9YVT5UV Hmias6uhtzTe5Z89asSiojPbjLZ+C4aNvw7bPZTM7vxSWQFvaC55Z88MNj+XQRBzZUGM7yttGofi pNQ+A1Euy3KbyK25m8kDynPSk/Z9Uqv9dftRcjz3n7kuhzvXlZsrdTd0c3WPxGPD7ZO9l/km58xV FuRe777d/YB0v+OByHb6BNvu+qPDg3ibkOpVQzI485OWbpVC+PfoVqk6CZXDnqhNCkdls5pyXkJS cawNoVggFTdRE7QSwyRTTnQGZhs6V7p+FNe4kHNvCWwjl5hMqKLcQwhlcykNGORkXj4mzp1fVipj bwJ6p4H5vG5uYcutr1yUefXzE5k/PbiTDnnlI1o84GDZK7945q9TF36x9vHPGOv9/ZmX6dVvfw6/ 7bE3e2y7+7HM93e9lPl6wwEu1x6B7JkCinZi7j7XSuIxOsSkU6dLjTqJCV0205hwk5gFUZktnKLM cDLoahoXEBBJoViu+n8mvX+DBgVqfugiveh/kl6WDLlWkSW53r2GXKf1lcJGRNAriKGXDTnBUJAZ rBbwgUUy+Pxev8cvGcJSIEHdDmRBUyRB/RZXAhGu2Ezojr/VtJ5TaAB7DFDYGeizIFGa9TUVgiof oT8+N+WmumWNo1fedXhNZhetvOvJ3jWj7r1q9I7MW8p+X+6lV2aOHHo6k3lmeumOvr1rvn7qi393 52fLHoNk4PGsVnKP5jMoUZPJaCSSzNncYo5aiQlWTTsOVrjLjROlS+KWuJ1ZQnbZ/H+eM863P2dX 24DLdQISzFnP3aeCjk4dT5+btCyfYu/ABaMymx6T888+IqXP/lG6Vdm/I1P9fMa+g3MRlCN5DcZg JndoaTGGTdh+6xoGhvBQHB51xkLW/0O/NauQM4LYIWQy/9V9C0c5p3/973z/sauXFTH1XMZc2Pft 0sdnP2fNHWN5v/vv6JiNXi8E7+8D7xdQjxYKe8M+1lBIrzB5qFvKzycJd4AVEKCBT3+cTyG28gJR hwSLw0xpqrAgH9tnGFdhg3DTcBU/u/pyCgdrfyAEplh9w/z7bGlTIS3MTcUt1CJUQUtOakYWE2Di UWq9kKAYDzoP4XjO4ZEGIeOay0sk7gIAQQ+Vk+FIKJITkQy2lFrgS8VSpgIEpRUE7bkJ4nd6Emjs 9cSNuMpTChI0YgVle13IouZEguRLyEQENygcGzrCASRmlNM6nHJ9Clw/kx7Y2uzJID74bqDXLUOA VLikS9nCTZmj2/6c2dq6m479cCuld6d2Jq7cu2jNK9ck+q2j7K6bTg5k1c/TjmNLG/fRK/78Hm1s ndP2y16Lm0aNu3XM+q2HMj80Ta+gLuDjIEhpNahIIm/toQg9Y3wbYHe/i8R2wO6ycr3s0UsvuxXp ZbJAL3OjehkMiRLar1oeVzYrOxVgCWrKJuzfNRO5BHsrY7GxcZIo7jgqNxNJ7DZYxSoXzK5+33at ftxPpy+DmnBmkLhYGx6T36u7YMWDz6ylCYpMfd2SpVUdWUUBHjnQIyfCMtfBV7hSgDFWdH4pTccY XeQZTZ3F5hiWseWG9fb1LoNZUFqrlRNaGw1pVjnqNJtTFospZeUuMd4zAfAOAeB8IQB9ueI1mnBO WOvjHhrHFvlYT4NH9tAUmAguZ33t/qaLmz7KCtCR7r1dIzmh1i/R13CuN2FFOZFG90l91jfbtw8G IlwVqQE7jYtnjJjf7ZW6l29++TDdFtx+w5DGm6R/nM1pe2P+J1wicH2nO8apkIWajTJZiirEFOdq HXtacxoZUBJHs/+DtnG6q8fnRL7hv0T+F/W63NInO+Hb8gp7GxP+zx14xX2IxHGiJyo73uWDNHWe 1oWMyWHH/go4FGgGAEL4TuvGIZubz5fitEk4dsxMZquDmMzMYjUILGAvUcz8T3sFClRM8Bdde136 TjZqzuqUw801bqTzXcbq9nb16NF2vpWRhgMTfJcmXRuZMaOgLIPIJZHLIldEboJWryU57TEhGMH0 XKI4eK5r9Rah6WGx0JV+fOEHLcbVsxQ26OIWd7lTZIpNItSBZcWE9YUPnD9TAPxRlpfYZMTZqGyy Zie6BBYvwnj0xxLufEifKoHwxZRXV0Eu8cHAicdHI/70UyFhbRVhTpOXhU3yCtta228xlbYRthFO qUgusBc7aqXL5RX2ax3r7CYrU0yV9r6OMWykBCegaZR9sMNyH7tf2mLcYtouPW00uJnT4eilMK+i MBNs6V6KCaDJNt45nmowI0wms8UKDnY4cFjczBrcTW7m3s+2wwPbu0WJI+iht2axmS1xzbbKSq37 MUgHteIOa4PxYYb7Iu5crFLsY01+Ma40KE0KhALbvts1ALyRw3f766uCHWAKbl8ADp27OF4PawPT wAVo1ycEG4RbHetuFEYHCnDReePiV8TWeQa7au/BgHtP2BYjm20wPLrB8NhH7J0/7HJYuMWRdda/ uzdR6ShOCIf93opKR2mFAPf0QG3WKZ+ug3VClmAXrK4OyzX1B/pW0IQr6cJhDtd9iCy/vJc/B/55 qryUmbwzU6vsP/OPuy4e+6B09qdh8ptn+sjHznBmhNtNiYFTzPTGXW7Ik3bN4vGVm4I2v/COfaUl OGSCeRc3mmDomZhRkkxmmTGz0SRLcYMBDKRLTgD/wDYG2ETROamt899aiJOaUh+30rh1rLXButja ZFWsJmgyIC/sCuBl/4tMyKoGspDBeOR/iQYLR1iXIYLNESycEGrZ7RG+OQKShUGNfeLKdbLAkO7F 4ZEQx160ucpNcWSg4LrevbjqBxy0mrRhlTBo2/cOqzRppTpYWmnMyxFxE3tzAJbqIK9N6tEU1mSl 0eFF8vDrU3s9AHN1MBegj4M/7PLpmypCyeS8I1gHKCyjELXA3UOvS2z/62czQNhqeRWQ1XSmieve M6C5fKy8i8i4MHlDGxtyUq/q9YYD4bAsq7LXGrCG5WcCex2vOaRAIBhm8VzNNcYzJqCFapVa82Xq JNc0z5TAtODk0GXh2wP3MzUnKknuqNXsS/G4Kb5ecEEHQF//AJwUKwiAb4TEAKB7uQD8BMKA7DCG mhCC5UxxHBoEhnTRkRPpsld0g0XXciAzRulWC7f/YK/AaPGoJFEqc/VaWC0VKlw0CO5hMFrIDLqe 9n2TDnuuNbP34JHM/u2/pbl/+pCGr/v6rt9n/sTeoAvpw69knvzo08y2Pb+lU36d+XfmCC2n4d3U +ovM57q9IneAuu0kSFq04lmuBV42Uh3pvVy93CtbbfDHOUggyNVuYnKnTLBsQesiUgSi9JQmNDhT KB6i+BcK2v/X9es/1Nj/1sJzLlzG0rrVvERMDp+YLluZq7FcHRPGRxSmG0skXDBE+FapsDtY0d2j rrq77rvM7zLr6fUHHqm/tPetmduU/Q73rL0LX8p0dDwv0Y2rpt7is3PKeRQ8DtMYc5BHz2oJt9VB 3X0jU2KzTQtjMDn5emESuVHk+aB7gXgREsFXO+40EDUQEDrgbuv8bLc7VI7y5O68wnL46T7bnVtY jp0UUcLrLUrc//Pu3JR+H+3FfZT8vjYCQIHjksgl8QnWqZGFkaXmax3XOddY1jvvtT/jbHN+5fjS qWK1i7ucXpfL6XLazG6cugr5LQb48Ow2JWg2+wOhnCiCI9r1oJ9AgCTyBD6DQafTYYqmHA/BVaKH GwE4LRZoAMe0PD4yg0E4Serj+Yvzm/Kl/Lzg/xXHOrX/T/IoOWD7f5kqWTU/53gQaBaLRhbXaQgr OEawoFJY8jzYge/5cfTrC2s250JC7NJaTJqz0qn2d7n7o6qOLhErhgOxXKGcShfkkxvJoUUq1Twv UgzpnMDh60SXuwU2rScp9WQgp6QgLbENn3iUbTj01so33hnVbdKlnademXT1ZT0SI/9CH12zZfS9 j2d6KfvH/Pa6h97LLcgfvTyzhPa+dWM/q7FjuVRWcd3wuSJ6aCp2cP4G+6oX82mFM6QZcqO0TJYL CvtIlZEh0gjjpbk1saH5wwonSHXGqbmXdbvN40hy5yUXPSA8HSjoAlJdQGEXgMbAod5YB9BYB9BY B9D4tDaMN+pmT+WzfKmwoK8Tp4sLakqmxCcnJxVcZZ1vX+CY7Z0VvM660r7SeaO6PL+xYK20wXqb fYPzDnVN/i0Fd9u3OLf4otkwoR6JlDucCplTRVCtSVHILZf2TuGYJiP2HteFbwuzcIHf3iNaWEAL FD8WwlOa7nWN9jBHo35JeGrSsOPqdZOOF/Uw1QKIjtA/2A4tyHfYrUoC/pQwjh7h5JGBFuTnoQ7G dbhHCE9kkzZBDp3AmU9hoIpVVqVxOpY20MV0MzXAiGjWPD34KxW8Gj2+xJwiRbSIi3CHg00CcEqz 8ycVhUoxJpoCh34rbgHA9EEAAsg6d7EpC7me0ztrsNaPOg6ag8dVePrOu6AQ35E+zrNTfEQgY4xO ePmwoMITnyVhFJD5nooogxWpS7L8QrHBw3dAeQwt91P5vAE/Nlx57Ad89PmpqS/ap/32xkXPThg7 dUDmqnHz5tz0j18+/uNaZb9zxzPNj1b2o+/XNq1ce+bh1zP/vJ/+Sb36jssGNw6tmZMMTE9XPD5r 0csz57212nH7nasvH1NWtqDbgD0rlh9pXPY1wbB6wVrZD6loxCkxu8KimHA4LXDkC9tcjbuF2ULp i4Y4ZSV8a4vSPVSYL5AmmpWTKzFlvaX/ELIR+sxnXYbjWdQI90sGNRzAE0177z+vpsBXAZVS7The /wXXIHXR37sXD7TgnhfmyeTKGzJhxb5jx0//5L19FKt/HnrrJe9rlpSzVq41/c4k+7ng80OHKpcH mIbJl5hWOJ9SvnIabYS5sLnbajB7U1A6dP0MQFY/Y8KsxfUxLcIXbVYf99O4f6yfNfgX+5vwI0B2 4bDgT+fqoEWYbDAYdAexADilAPhJX/IsQj3Dta6eAchabpZ6H1fPzntusGcOp0fW6NS1AbHapeF9 gKmpawHC6hRb4i654ZWZmTPv/j7z0+JXhu+48b29yv6zuz7OnH38Tmr/WhpztuXgnitfEXGr8EQR ZRjmyEIHZqMX3AqFS4Gv7haimE0KZUrJx9hFO+wqK8OcV4NQ+T5qfolCu5NuUoGlxNbL1mC7zXSb ebOt3XbSZo3bxtoQ2mI1sezWn5naYEjhkdXVYlcB37aYzXGT4jWZFLgD4kzxMqaY8aqv4xZYJrNM dBaDOoEQn26VY020ybQZv+jBdzbsTOtWOY3RTTjNymCVUM0VV8YqrBeskc1Ku3JSUWCRrN9tbcCC wi2SJcfBTTwFedwYFpJQzgnse3C7I7vZwfc6dKvDC8uihTiBib+3mN2QF39vgWEG5Q7WB/7q0Kwb DJC+wgBBWBdiSoVSxoMVEtjuEPZEGWWDOn77Nr2xZyyvB934WgdcGmf+1LT42mvlIrg2uHDA73Kt 4LoF/VBLFZGUq8idClaSvq5Kd9/gCDLcNcI9PFhLLnPVui8LqveZ7nNmJ1IrU2koJ+0rV8ptQ5Wh tpG+icpE2+W+mcpM2wLfMmWZ7XqfU/Fxy9WNs9FOnOYRky6wFhDSs7IyrEUlGfahwYjJt8CHaLY7 nE4bTnG6ff5AMIit6KrdOO4e56XN7eKlNsUH8wO/dMTi+DEVilAexWSK+oJeny/otpnNUZ8boNuF eOS46vKqqstttpmCPsWJvVzC0CVFCiLUxWw2mRDEzYJutwsbM6FAIKQOMtNxJE5syH1IGlHouL1x 7s7PyWmjt+/SFYP6UM6oDpiTHaGcjuDomllDvzinE3SZk1wfgBDlglQkmC6jLjQu+cbWeVMTopUf ZTiErIpnArowA7KdQLaL04TbwretdQooQGX38xSQNVgdqNlt0xQNjThRLK0HQXh0gvC4YWd6sBsG Z6jBSOkjmetf/zQ/1A8nqL95e0wy0uOLVzNXv5R5s9AY8GZ+B16tvveev+VLn3SEMt/+8/ZW6QUY NPUb47OGn3kc1MM5dgSox8P2aEVYjXKo38qK3EWefrRC6mfqZ+5n7+/o467wWNyeuDtR7uYZjg4c 240S6qkoEf4hSvDYMe0q3JB5K4ln19BrrCwlFxm7Wbs7Uu6+cn9Tfyt/4sWmiXK9aap1imOiew6d Jc83LbDOc8xyL5dXmrhOcI37Gs9aeYNxg+Ueuc30ovs1+XemP8l/Nr3veM/9pfyV6SvHF+5iqJGI crbBdaT6eW418Rys9sNuDmRVB6sNkVlq0IJtfnzhK83BIdWA4/iQSgxyBOYpxzGWR16EtXpQs9lM +eFjCQuNB8eR7VRV7S4EsVkxZ8xulWwei5UaVOYxWzyeODEj6t4sIeopbpO8NpsEiYR4HuaxY6kn phKEt4E64zYEK2NLddqLcctmS7tFQiRi255pWeHTplkMrZo6Vj2iSjg4Mk2zxEmO1/dKgguf9OhT nGbrg5/nnKg/UQ9AkC33wHGK1fN1ys9IlMet4c/p5FRZZRLE2VXoRHqoTli/uq1zzpUkFForFFpr TiXlymwwXAmV5JOWcKVHL2RM495wpSkvXAnct7dEuHOkXYtFKj1QfCUku8MfqPK4/YGLTLAQqiQZ EGyXT7SecKfnuSutttzERZTkJqqsFg4xDtk8AdR5AqjjEAN0XnXh0LkuAobmDW0G5x7OScouljCz ioztS2qZkOw9hBa+09HB0iczm2KJ3r7MZnaW/Tqzfnn12Mvomo5RZ39k1h59xkYzlFtpl3R+JUfk gTizVsF6aMVmu7l7jj3UvcjevTscZb6KcP/uI7rX2+u7z7fP697Qa4N9bdED/gdDz9h93biBw9dx KL44T8Ghp3Ke7bY356Vuh3KOdHvb93E301A/RSj7KZArFBM3NMeukIA+nGsm8etYIBZMF3cvr5Qr i0fIFxdPNtWlZ5vmpVfY1iE49kf7j2lXRbmDympJfnmgNOENTitaVMSKIiWOascmx1ZHp0PZ6tjp +B7xLeIsB/hU92ADwJ4zj6h3iJgYh4EHQSEkREI03bN7g/cgttwI9emUFhJqU02hpTQiWYumq9MJ 7DNoWgUJ2AbfdhkJ3+pepnyZ67G4cRyDF8ApMQuo+YhraIZJ+eJFuNb1sfw2drnmKNR4hHM81Su1 M6VUgnCE9gvj4b29XENO9eZ1mj2KEKfK9kq2rZJWwr48pQ3iTwwUBPNK8g8ajhhYzFBtYAYsN7Ai MSzkQWFRwoPKazgWDOBc5GLfx9C733kf1RLs3qbhpErD9Y6Dal1kVtWR/vxzbiscRyS/HjwtbtUv ObEE3MQZShgNXK3mN0Q8KFkizqbxQ2nYmuQfhLtwVdpYOBCqNjRrv48fSkumEIjngDOBbwOjkVQ1 c9/8nQeGN17cZ8EHc2hZzfpV1+U2B68+etv6Z8eq5kDegUjgykOLppYunDf3sVTuLZOGPbdm9OrR Xoc9lF9gubrHRXVLgktuH6lNv6TntSfPrLmoH/24W0TtNqrk4obLx1x0DSh6LSia+xb5KaAm7UGq 2Jz5Sh+lRlGqY80xFoshbiIyOLI4tjlm6O+p8lch2OjSUL2p3l7rrPdfEZpvuso+13m1/+pQe+x9 2weBD3I+83wb+Dbnr7nHYp2xnLhS4izx9lKqnZpyqXOsMlv5IPdf8k+qTfU5ZAMj4QgWKIsv4rAG 849aqWrV4H9sssr6/rRV0KhV7ExDNPAdB+HfPyloSDg6OJUCOCaUeV6jlXB8WpfBU0cE8RFZqPdl UgFj7RQW2DbaTE9SOUar8as4OPaGHRtuKgA4q+Vy8qKCVKhQwKmbkwr0SZAKXzXQVABnNT9/NQU9 IffyV9Cc6PCKn6nRIBzsO2HXENQD46uLhEAqnIDwT8RacEqBnFpKluBwTJkLlhbcSSoC6gslGFog BD2IjvZ4unXprit3LtEy//jVgQWsfNJdK55/cvmK55X9Hf/aNGbTG42Z7zPvPUy3HJx0++E3j752 GGv32M6vpBOQVyE6JattlztWOanTSvlm22Ls6MnuiNUYjMj4ZR2f0cRHbxSjN8I2Bgw/G3K+tZA+ /O5rwkRGZDBOQNSLExDDzTYaiwzxDAlM8EwINHgaAg+yB6UH7E+oT4RsJnuOZT6bJ81XltsW25vs T9n2mPda9thsfmw7/JVJjrxpzkXOVU7JiQMRz2rX9RI7gA3o1mZsCR7DTqCZOJ1WmIBdfYyg6/kO E59sR14Y48u3pmPQDqG7aQJBmsDOxQInIYGTERFf/hEjjRmrEZrk4I2MFt7IKMSrsXe4/FDW4gNW dOavX5o9Ni6C4vvVnVh6Kn1iqRg79n4R+q3WH8c/YTcDb3UI5oAZDH+oOO11zkbmmJOqduV+/8IH mX8v/fq2HR/FduasmrL+2SdunX8nXRN48QjNpZbnKVu989Hwgqtefee9V27ma8ww4OxTcCQikugk 7QkLk+0F9nL7ULvSx9snchmbaBnvnRCZw2Yqs8wzvA2R9ti7yh89H+d87vnc+33gbzmfC87zx2Lp EGfXkSHOu9ghzrf39PdnfewjWY19mHdE5DLLZPsc++eGL/0/0VMOlfokhxWBLmHQg4uAJSVrsIwH UDoLVPWoi6oI7mtwNbnAmpwmdAZ1uTnnwLGIRYsLWZeBU5BLMCxqYcryGXc5+Izj+jvBpQB+0AZz 7LiWufMPInLsU2OnUeYoGmOUjFFBckJOG3ESkROkQJtYloxi9THmRMvHXsBp9UtGnTjHXZzpsCOE rXqEHZyA5oZ0ns/4fkyiD/DFvRo6wsBziO0+x2dSv1mHVv1x+fx3b2nYUrK7I/788hVPbr/+2kfX PrLxzONbqbRh3CDm+GkYc7/1xsuvffDWIY6zkZCiUfCZDziboAViJOLD1ky9Um+eZJ0lLVAWmWdZ TTB0+ClaMRPHtfEcyo3wvND9vvKT93RI7u3un9M7Msg9KjQoMs6Ns4uR6e6FoemRaw3X+k6z00EV P37mtAcCY/3cByD5I87N6jaExqtyOGIx4pcLnuXHOLqkWTu4AfOOA8L0Hg84PKBBBftIuD8A6Add AOg7z0I7Mxd2L2/GAYJQDMvr7oJUOS+1QXyZjdGYv0zNN2r53cu7MIUNUGBHxxQGAlhnMBwnBIP5 +dA4pi6UifXpUR3HR6vwNyEgHX/CucA35rMHK6o6llQJFVucp+DhZ3wF5fFSgsX0jQevMSH8DjQh 4vUN0hX7i7/b93Xme+r96I/4fbCzX1la1szY2PEBG2frN/m2G56hkwOPt+KMhIQf4+qW+STzoxrf uX8uvWftkLlPQYp4gMIm+EMD1K5FvWbqzCnJ6ZWDY8A5D9oesj9jN4Xs3ezNOe05cg6fj26hWHmu yS7ZnBEL9bG01yPjF5ctW73U2+nR5ECBjF+duhtiiU9i737lvNTSkVj5ZkJzNM4mOZodbEK8wkPV TXio8jjjkGKhSQnG4eKXeDnl4/tcRxPAFyKUGTU/ibMQ5PFgzgG6nyTIafz2EmwAPUyAzyzYgB89 OgXVH36IEzADsBvKA69OIPpfBKp4EdVsNhpM0JBUOO2Jy+AM4/ez0t1X46A2+GQptrr6lPXBWXMs SRBr3PPn4+eLWrZu9YRuWXHp1HC/0vFDjxyRHti4ZEH5sMvcD1uGNVy58exscMTgzDjpG3AEj8he pDVYrYq32FrgvdRa4zWYc3Nyi60pb3Gy0trXe4l1mHeysdY61/qT5V8+R89kceHA5MDCSws3F28r NvZN9C2qLh5mHZaoKZqYmFg0zzgjMaOoobip+IPCrxLfJb8vdAX8Bl8b29XaLeIxipVEjcNxyNeR JtJOjsJ52MZu1EqVSMRpqcmL2Cx+X1lBmaUgGDwaoGpACzQEmgJyMZxkbFKxiIsLCLEmNEoh1gJC rPHDJeKQ5ze6WOOt+GGTrFgDcFa7hBN9YJmTFpC8WP5B5xHnp85OpxxzVjvHYKETHOOEDMPhB5wt QC58e/pBKV5vmOTMSRcvS3DxBoMui0iIN5xE+g8J13H8ND+TBMYRodXH9V8HwIbdkgAPhhMKZCG4 hgcZcgT26QoSuTAyf/ZOa+mQZTeuDzroiuYPT179hzsOrHxq1ofbfv3N/U/deMP2HSuv3V4bGldQ OnNKRfPttOrj+yjdeF/T2fk/HLn2Oan7H9oPvvXqa69yH9M6BNPyaDkvnb4Px7Pbd/sC5dicPcbP wxomFch98Aty++2yqOofyCkPmGCUeyX4/pwRxehFyF+BWSvrW95ppu1m6scMs0l+CDCEJHYTuZcz CEzJbzUXnzgEP2MSzdi6FrWIG+GsYgZLIecLDDa5ASG0UVyfRkQIgNHCGRso71ve7D/pZ4v92/zN /k6/7GfeAn2zW0UfTmI88BAdhQ4ic1YTApUDWkBwqa5WIowXHNq15f2Trg/i6CHeA78BXk5G+4YD jecsCn4GSd/3Tp+zJgSfiiPkfJ3CMsVdSoI7HQaHscBhsIWp3QS+xCHXdHo1AVNTROQKLREOeIQS iAB5g8+1rvWm9hUvjGxdvmDsHVVQCf9xd/0TD3VMY4+uu37CnTd2vASeXA9E4Ra0PiM5rF1h7stH MMa82bzN3GxuN39qPmk2EnPMvNjcZN6arTpm7jRbYjgNj1/hw5lyg3QTNpEVxMcbjAUKkbfK2+Rm uV0+Jhva5ZMyI3JcPoorWdZ1ZTYJQHbeEG0OlMkICEEuJBvu6ZINgO6FB3AWESGYQ3m06T9nDyFc wgtfrQfgc1OL+yWWLkmLMHzMyvrW1lb5b0eOnPHJqTMfcLrEmKUfMGYrm66FuQ2INckw2TDFLDnt /1ROGxD8wskLXh990xS+WB0AEekASPYrTWy6TpKusTC3Ie5JlMOPdXK3u7AcrU62onRjPwkVCVGh 3YoagywrsqHCPFxWCgw9LLWWa6Tllg+kvxqMTxlo0pAyFpgqDf3M1fYx9jq5zlBrrDPfKF+n3G9+ zfC2/J7huOFr478NP5p8bosFgXIyQ3gfvJm4gEuzwGhAmIdBwqadYkHAjcUCxMjc4S0r3M1qtRKc dKVOHKrDnMOLkAdftlNLxIUWLExdY2gzFnprAWEFsIkIrcav9jHQeEbrLWgcAwZ1CxOICIwRGEKg aaE249fnOH3n2Ox/SQyffYGk4qrXKO73xhKPM3c8zvz8XirUMOyewg/Oz72iDOo/8aKaqkxVksiz 3jj7SAQom2+VGGKSedAHdGzgGT4nzWIuzq00m3AqFgj7pCW3EsW7LXFR7EroQRs4K4uImyXYjRVe KgOcTwkRHNLi58UnLSpvzgtxZRPFLms24qOOO5D4q9wfy9Tk9eNtXm+VyPCt0y1B/uVvd4X15gjs 0a18vm0m+BK+JjiZjKBE+uzXmfn04CeZR1fBxXqANmdWdMxksZWZyzld3oKsQvDiX/cqghFBQe27 K/rpwZLlffSyV2+9zNODKbUCiFUngoG2Kp8q8hhkJxUppixGYFSngl9h57+Oogsy/iSgs13zYQXf Smg7zCl2oVTjliwwzLlTGL1ZY1nHta534NdpgOUu1gTQKfR3AFkeJaPln/MoULUUWodgU86a/Ir/ cYl1S6sItcTYsVYYUtANkvR1Hlelx6uAo3QALPVnbZTVXl4gH5ePm/8S+Dyu/FE5HWcBUzxpDobj cJsmoxGDjy+dRmpIIvbLcrSAbi7YVsAK4EN1FGzGTx7IfHguBBgI+wTuKE7WLi8XQTBA8HsRXAy5 GCdqF0QAcuGIwj09IoRbKVltndZrtmDB5jANi8eF+SIkHhcWj8P1d5qLPy4sVoOwMDBRm9EXoTC8 GIZJuNY9XOE2PA//e0dZsoAeJeC9bYTFcNRoDOQy/46OjQv5T3iriF/wH39KFi2nNC9/MBHikoh1 luTkF7TRa3cnOFrO6Q9AgPBDdBw/F5uNmvMuLVx0CF8xfBBcSYSmKJgY7Mp18a4FCVs2Ka/NFaZu u69rQeIRMDp+fVxLxP4DMn1ZEvrihQvUo6VPzV9xb+ymNx55dndy6sDFv2ytnXnp6v5y6p7R066s 3b9zb0che/iqaf3veaLjXtZy7bVjH7ir433OK1y3+AL04qc3ah5FMnjYdrVN/av0peekdNpjwJpx UqsCwVyn0vvUo8Fjwc6gHDd5HV6/G7oFNfjtFrvD5sgPCn0iKHQLq9AqrEKrgNsoq1VYxRJlzePI FM4koVVYhVaB6x91hFqFVoHr0zgfBfFqFYqLlXYihHE0Nm7atRDXMIIng2xxcFuwOdgelIM4j+Tz C948jZ8w0TnvPAteqFjoLHhesYAKCizrioXuy+KvcP+nojI6IH6NhrOb+AMXQvnn/kukC//4DyPx HQ2cSzmnbfgNLrPFZDHi1IWaghUfpk6LO4tkHnYOcQpPOn5dgOOXeysFYnUUr3ts+ccNj45VLa3d F1zc+LScundnzeJRpTd2NLK1Vy8cdPdbHeJcylDYyIXAop3k0AV7feI3LbBZ8JVgMsQafaU18lUl R9xwGy05tuGGi02TDXWmOYZ5JlO52t/d398nWKOOdI/01wSnKlPN49V6d71/fHChstA8U13oXuif GbyG+swGxX65hK1Ky+W2q6RZyizLVTZLICIbXRAZ3vyw0PHDggyM0EB014VROC2yDi++qnN2w+2T on8C4HgQAEc6gHbNk19Q3gtn7YyqMQ7XRe9PISN4/QhuMgN25BObAxKIiPNf+AkKSB+CTiAXpnKW a4X84T+rBDxreCQXB4z0DnHTGUg9h7wTMJzr8eNR5yrO//YQ92vwZcs8QZlgvlK50izztYk39Ijj 69jfEib0hcr/0Cdu+82H1H/9327/NHNiX8u6tS2716xrwY8fF965IvOXjsN/u5lGqf2tN9/6w2/e fAMdWpeZJyeAQTfO3l+p3Wn7/xq7EuimrjP97pP09BZJb5Gs1Yssy5awHEy9QGxI/AKEzQlmC8Vg UjIkZGxICOAQCC6BM6TZKEnImQKn7QkNNITTzLAZzFImTNrQkIwbZgJJQ4eGOYGU0GaG6XGZptTy fP+V7ECaOWcEerrvabF0l//e//u//7vGLcZtRrPhbIrvjYsl8WGesqKagpqisUWPxF+Iy42hxtiU 0JRYqzzP0xZqi3XIiz3txkOhxbET8fcD58Pno+8XXwxcLL4QH4gHy5wZI1NQ72w0wJAw5hqXtN8V ZQ3N9AHkIIhYCgIiFnyR5GmVGaqtLlDXqc44b8I4b06s2z6FWgXqWuUNiXOy43lND2pLvrKjJkTh sl1Gla12Mn+tWGuVC8LXI8ODgDC3xnlAmEOiQ4DwNW6NOXacA4Q5pwgmEl2ZRUoACLMbiRU5QwxA +KtwMFb/NB7J1g6iwX4abny8gVwIR64iZSKReginempn4+a/ffp0x6Mfr5n7/HDz1ZWrfrKrc8W+ bLvr+LPTp28c2Loje/25uxr7rzt29v783bPvvvMhIVWTsu2OC2hDQyhkI+1NmpgRK8OjxWZxtUdq KmiKNEdeKN5e7Krz18Waisf7x8cA7MYW+hfGFhSvKz4jnbU+lT7zXAkbw8SEJwO2bL1nsjjBM1ds Fz/y/Dr8SfCzyKexv4g6FAwCUSCJPikA5EnwhXy1EKIwTuvM0G19gb5OdxZzhxtSEOQGc4cbRiCP I+rc4da5w42rmEipKfUgzXxkKvg6hL+8iSpa7zT/GkdM0jAjvBBH7mu7+QBzc1zYHSkqvtnL/hoM sb+P3I2vNAxU36BgxfFejovArb4JPayq3HLP8ex/LX1/7VvLXukvfX3Vilf3rHx0R7ZdlEdPZcOZ e3v2717d9Odxjn/o7f3ZL8588Aua4Z5E05xEq5jCKXt0tZ8ZTlbmrHOOg0j+ImenU1JMWZEVr99U vIJDZhofEoKqpF9A9mEi7md+MWH+3x7s0FrvT7Z5gwcLeiSfh25YUfA+LOT4wblF/lRr4iBCzs0O JpMxWEjM71tOWV3UZ+G08nVCg2CcesrHSfXzl1NWXq775pAj5CaZT75ye3vTvHtvHzt29L2BYmfF j5ZNatyVmti0YHn/GaqFJiDf+1ALIxwhe40zEUg0KlOU8cnZiQcSXcomZUPyVf9Pqt50eJVQNBwa 0Vz1QcgVQ5aIaNQwNdwmtyltapvW5mnzdsgdSofaoXV4OrzdFd0pPVWRTCWHjUzOVVu1+yvuT3eW dYJK+pL6A8/m9Jaqvx+xU93t2ZHaiZ3p3qoIIlSbW4kmBgtlg4XkYIG/hkwIfw0V+GuowF9DhSIK ZlvFDXPlVLlHdUbjFQVObXhRlIIdiUgVVX5JpCnSEvlWZE/kvYikR0oiSyMfR5wlkecjYuQ42qYA /YJjujZW5KAwMCRVGNjnQBSYAQ1ATDUHAsE6erQNn1nH2PC2oiVFYlFhgRurIgq1cgeckmDgUZOJ 9JMFdBYO10rAUkxGbH+4robeXs1xSb6+pRkYGCVGC45xemckTu+KcMcxwnHdCMK0+93JSrz1YGHD 6UqG0qfc3qKQY/LyAtUDClcO0TCtjPI/VQqUeUHNiRqxqWZdjVhD+HRS4H8zLwYYz9WyeA8v0Beg Qk6VLp7UuQHW+dfT49x6kBODrwgLwfNu8nBa4uNBtzbyjTwIjUGeh15I8s0AUXL51HyIN5NZdkNe ND0DcA0vavp8GaI+fAXNCZRwaUgxC//zYV6k/NmpW4rLAHBWmIZl+A2HlPDGY4KSdseY6xYcigM4 LfWVxYQE5L/kYWqMpVOKKmWcMaHEKKJ1Vi7Tj4gaOQpDZWb9esA9gzfSSkAuyZAaV6oihR0iIHSa myCGgk6E/IWIjU4mqqJpv/7Mmq5V9eUvndzWcsetlS/O/PbxueZez4r2ro5gsDq24Y0ts9tPfvu9 j9hthYuXPzD+trJwec3k9VMnrk6XZCateTA8o23GqLLCIr+arL2jq23uy998ncZpcuAPYqVrGxRg fnVEUNEHyyoI90CkAIV1EFVDAFVlDiFoQGNFxdTt0HQjAWK71yr3sAG3fKdy5wL3I1ALeMHtFLBy 2u7e6z7hPg09UwJTyXFDgUQjeeEPPPiPK+SP8St/4j0NVwiay63JaO5HiVsuPJFbVbqPih1gvY3c B4ziSxgOczAXCQWr+yJZeMSHkMaJqReEQ+MUua2ZTHmI6q+inhBwcxRX1eIaJqIRvWvM3yyp2rDh wMGD/ky6+EcvG7c/8Iq4cCNzL8l+d2P/S3dXQbwM/j1s2QXaIYe1HBGiqBsFnrsY9weJVn/VrrUC dRk/S8r+oIf5gxriByaqSagNlodD5E5Eua8S4l5KyCKjDXwZbifVQIh7KRye5v5JKEC1gPM86hni DifOrxGNWLpnIMROhFhoKsRkgAeQaxK9GhUfiW6P7o0ORJ1RQK/0DIc+SfcyrpxWLijg2PJwN8dX 8xNHHnWFh5JDVXOgp8J9E3CeMMaVqZGbIAFMF5S++BUnBDMI1XvTmNzMwQHPqNPweXUv8QQpHRyO iNMTE7yyGUM2LKISleuxMMJ4yEfvoPMLUAEBcloR8RRIR1PX2Xt3tBhat2Y+PH36ptHdP+ie9FBL /Qpxc/+B735j4vSZzz8tNgAWZAKayHEZraOyK/m4eMglC6osMWmIhJqk7ueqztzIRaXlWayn3sWE hNmgkn33mg0K3Mw6mQ6gbl45gEcYZP6IV/zKVopL64Q0Dji7bCtAcoQgDjg7Z69ND68T4jjonmFC GkmlDUK9OkmYqM6G1kerPEdZxBaJ7XK7skoATU5cLa9SHlOfYk+J33E8435aflb5obBVeVF9XXhF PS70uPepp4S31HPCWfX3wifqdaFPrcLPUcNCUE0LFeootUUAhOayrWCdC12pLo+3QSlUoJ8u4Dv1 2To1o0ryrvBGgDbSNb6cJWouvyq6XB4NBrD6fAY8Xdx7M70ZoXqIqjtKBQZZrqgBRVERCgPCyDmc gCmxZOGETMmtKiCNuqqhH5KQbdsG4ixCiDh20AaUhfxiFrOVuGizhHbl32jsIsGvH5S2aPjzi8TL x2BtGOK1mRxU/JJpCbAQhpPzbgbNJzhsnDHLCZJgRrJ/zC75p4vl4FL9/kj2YWdF/4YHl85aKT6d w4wlMB570DssZ9FgZqpFK1NufXJkJ35EdZ3hkpGYWcE3J/FIM05HPAHGEswYnsDUSiXT5ueq6WCQ LXSjtnXUhtcDg4XcHQj2YcceE0gOR6dyhs7ErNPba3zQa5zhSap5Vi3/dfTDaDDEMAIDrNI5TBWn mPPMTdD+w5TIfRySJ+STfq4APOuqrZSU1hmFyAHC2L5q95Qk65ySR/FLMSViubC1mqQho1a2DMHv CLgL5ZhWBA+23F0pZ3wQX3c3yqN94x0TJdt9t9ysjdMnmlOsefoMazE04R60VkuPuzvlI9JR/ZD1 R+m6ktbMtJD2pnxpPWVVB24VRlmPyd+Rtzq2eHax18TXNBBChEPSUd/bwLs/Ui47L+u/tfqkPyuF Gs/48fCjwY8+ftT50cp325jq052WYMpuAOJ6uY/cOJ/b4WWeckSzP7BHkZXyovdVUgF7WAX8kqqZ FWrGnOWcobaZS8wu81lTNVUn+iI1R65haFlLfXmQwFyNtNpc2oRxkf7lZn8cYzYCWERsdrsUpIPD R1EN5EAdHmgGn9nCmmWyvUjVffGfmW457jYtK4NIl8vl9qGdy72+APJiZYA7GVWGpLpMbOf8SIFo pdtyyrrp8Xn517Ngx0l/AlxmyULOlE9QA9cML1vgJWKNw3uY7QIXtEVlS9UnVKQPi/fYCnRfl5pP QJCJzjTDxRZwnBgJtGzXQXbNfw2TIij/kbshvB7un78M/2mQzQ9/PdM5P+qw1sfY+38Qnd1glNKd qM50b95bMnNON8ivcfGnEJ9iuPsGTncLI/Q4mKMXuBIfJ703762biXxbeeD0PjcJ9GG3xlJQoGs5 BVoeuLDPHc9dtXCVRIGO0AcdwlIQnw1rdXq/ewR94n7hVpFkrvCXhj6cfxq9L8TfZ4KUrMadcVKs 5SxqHjHwDZw5ZDUIVbhjgO/zE9TfSgOOnHccaVXGc3pLwbjmTGt/iNOtHSkHa84eO7q7yVm7+8jL 9bcd2pPtPrZ72IcwMN+/aL4jPty/9d1ecdH1c2LXwb+8h3lIxzz037A0Bvv3/DxUoDNNcooKgvJe 9Eidr8j1aiR1U58kHZlYj24xHaRbimLY0yINc/XvOb8nQ8hGP+E6IZ1wv6sruh1siDr8SoE3atSz Rm0926TJ1dY3na3uVm2Obwvbqm7VesTDnre1d3z/YpxznFX+1ftr45JqDQ4uMKItUw97sbDA3wEj mko6Z0RD/l0i/PBmRvQiCWKsnBMtIeoEVrSOvECQonXdawwxog1VghqdapwUTiqiUT7EiT6JWFT5 jbRoCYgLaNFqi8Wsyd61noSq3ycpa23QoWM9tjRNWsclq8bZvrhjrZhoQV1ONru4ozq/LzdZYK4w LkGvmGsQ3MiAhix6frIgeXROgQYBmpOff5474oG6LuJSmEso8NTtCxc1APAF4bkIuqshqLOG+DlC S0iXRAZOATjLpQ0KeM3UUejWykFTmOn5rURBxrp85KhRFB1ypJjONmS3/ceO4YVV5Qc+zL7Injt/ rjH7mZhm2S8mjhhbez3r6f8lm9KanY/fVQomxX+ij0TZ/+T7SJEa0LEJXGFEtyRN8tsWeAW2J57v K5HqTPR8NNyLsAg9cCcdtgwd54CO3X/pRzxU2JAOzNb3qJAOt9Eg8fSIOoMOkA+zgt6wldJSnpR3 pGekt963zdTSVto/KdhqtfpbC9qtdn97wWpppXe1+Xjg8YInvc+aG62N/mcCW9XXtJ8ax8yjgSvq bwN/9PYbXwQGCosHe1TQrxXGnPp4fQOIEJGhr58DEXKpdsSsH4XcEKRzWFg5RAJ+f7mlBnAC+WbT U66pcINVJI54PJpEv18oNArF6sI3CkXsINx0UEdd2IHD4ixba7JsS/yW9Qb0Bg6zsYd0lhDujMEw zsrVFoRjRnhaPI5pngHOtx97oBrcQnxGdyzeBcOIyusn7TJ0IpIWCBt9FyOQ/l/2eRRpPbwEeQE4 DtSvKKQp3xjSpC4Fk0eE+ua9PlibMKzNMagLXBa0gctkvPLd6ogQGPgNtAPUBPQDMMoOFiA9NJcK it4DSwNtM3Qff4rWuJw3nM/xwBIGawi4KE8ERleNmRQyK1xa9qE3z2cSJZlPurNL7kiO6Jpdl31w t5FOxhbrRc50/7ZH13etFBdff3vP2NaZ5KGkYXvOoF/52B7bC7HfU7JosRorRLHtX9oKCux2rFpx 9qY9BYVhYlqpNsC0ViezCeIEebLSYrSxWeIsea4yzVjCFooLAbusYZ3yGuU59iTSs75gfWIsIlew YXJGaZB/LH/I3DRaeoyCOhHmFYuQM3YZHGmxUVFFxLbLmYhkH5GRlJ14nyuDn6je5xUwm/fZCp/N Mz4VSVh6NyZDl3RMRCgVUuh9No+NAeXbDqFin+1b4Fvnu+pzcU47YECwRTsFdS1jkFptwY4R2BVQ CNNlIaIbnaVkNihWlo9d91PhIraSoMbtJxBgjHEJLuIlTiKkxob1MHykdEwrMADvNNphJA4i7xQJ UIO1J1Nd4uzNHqpFqkr+QmhqM8oSphnuN/t1qoT8w+Ue5ErIwdhttDjbH6JnkKAXbBARhRajwS8N S209op6UhMjcI2tLC9LizhVzsi2O+/v/eenqDva7zQ5Z2vxY/71rlO8T4stvAylSfvma21hcc4Bo Szv6fLmbz807+ND+PUU37NdD+/PQ7jy5vXloZ56b9+UZL9wpTBAmCpOwe+kUoRl7pU5FdHMa9sac gV0FZ2HX0tnY13CO0IodX+dhJ8D5/HtBix29km4S9BOEmeMmNN/Vkrljeft9S+6e9b+GiE81CmVu ZHN0cmVhbQplbmRvYmoKMjUgMCBvYmoKMjM4NjkKZW5kb2JqCjggMCBvYmoKPDwgL1R5cGUgL0Zv bnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTVJDU1lDK0FyaWFsLUJvbGRNVCAvRm9u dERlc2NyaXB0b3IKMjYgMCBSIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFy IDMyIC9MYXN0Q2hhciAxMTcgL1dpZHRocyBbIDI3OAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzIyCjAgMCA3Nzgg MCAwIDAgMCAwIDgzMyAwIDAgMCAwIDAgMCAwIDAgMCA5NDQgMCAwIDAgMCAwIDAgMCAwIDAgNTU2 IDAgNTU2IDYxMQo1NTYgMzMzIDYxMSAwIDI3OCAwIDU1NiAyNzggMCA2MTEgNjExIDYxMSAwIDM4 OSA1NTYgMzMzIDYxMSBdID4+CmVuZG9iagoyNiAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0 b3IgL0ZvbnROYW1lIC9NUkNTWUMrQXJpYWwtQm9sZE1UIC9GbGFncyAzMiAvRm9udEJCb3gKWy02 MjggLTM3NiAyMDAwIDEwMThdIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTA1IC9EZXNjZW50IC0y MTIgL0NhcEhlaWdodAo3MTYgL1N0ZW1WIDE0NSAvTGVhZGluZyAzMyAvWEhlaWdodCA1MTkgL1N0 ZW1IIDEyMSAvQXZnV2lkdGggNDc5IC9NYXhXaWR0aAoyMDAwIC9Gb250RmlsZTIgMjcgMCBSID4+ CmVuZG9iagoyNyAwIG9iago8PCAvTGVuZ3RoIDI4IDAgUiAvTGVuZ3RoMSAxNTgwNCAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGlewl8VNXZ9znnbnNnn8lktiwzk0kmIZOQkEwIgUhu IIlgRMJqBk0JSxDcSATEHVyR4BL3jZZoXSjYMpkAJiw1al26WKm2Vn1r5W2xqJVP2iJaJTPf/9wJ qG1/7/f7vm/Cuc/Z/md5znOe85znXtZesa6LmMlGIhBt2WVLuon+Cw6B/GzZlWuDmXRWGSHKohXd F12WSftvJ0T6/UWXXr0ikw49S0jOgyu7lizPpMkp0IkrkZFJ0xho4crL1l6VSQc7QdsvXb1srDx0 HdLjL1ty1Vj/5A9IBy9fclkXKH5n3Y9HSffqNWv1JDmrCbSt+4qusfq0nRDHm5my008rIRRxN/k7 qSd3E5kwYicVZAFmUs9eJBLSvFyyXfiTWZteXmyr/9zgM+jgJ/5cn8cjLz+2dMFXX50atRNDIeqq en1eAJwyNXUemW4nX3311TX2TE+85PTPPTB/Y6NFeJbsQkDHeAYR+hHAaOHZQcVSpQ2BOl06Tbqj VcPpEeHZ5ORqPb/8/qqNB4SdZDGpRvbO5AKevXNQa+LVdw5WT8nQigk6TRoyxYqrKtDoB6wCgRHb WGw26N0I2xCeR5AxoJ3kA4Q0giBsF55ItgTQ8FNoyNboEp7CFDU830BIIwgY/VOYy1Pks7EcEaP6 4aBq5t3/UEflCD8EyoanHWEjwi6ENxAkshrPbQhpBAGxJ1D2BGHCE8LjSXvA3mgUfkA2IDDhUWKj lATQ+sODdp03jwzasqq0RrvwAGlDYCQhzCIjCAzN3gPYPYShemuyfILOwtZBo7XKjvpbMOgtGMgW dNmPJ9XTGmK8/pbBLDcf/M1Jm0PHXZusjGUig3ZvVRu4cBWhQpdwOQmTgHADaD7oMtA80KXCcmLR x6kN2uxVG9FfA6o3CNlkHIobBTepAm0S/CRHr7Yuac30sy5ZUlqFGU8XvHoVm2AhMVQ1CEqyKhDc L2g6828fVE18fLcn7dlVB4VbBYW4UGsjankCtoOCEWts1Gcyf1C1VPU1moX5mOZ8sCWAMVJwmT81 4fIkGmp0CM1CLjZDQLhEyCPZoC1Cvk6fER4nLUh/fzCSGxjZL9yno+7ljaL7qRnRmjposVaNNKrC VJQmhLuwAHfpnfcNRiZVkcaIUEIqERh4vAGxDYjZhV7EerFqvVipXqxULwbVC+kjwmaUbEadCuEa 0i2sJ30I2xDnYpWdBEP5ZshOFpZUDQs+wQvG2PeDlRS5/kHVykfmTTqz9GreQbO1quGgsIbMRmCY 8tpBj7dq9X6hVJ9K2aA3hwO6kxDXg4InszRoyc2X5KCQC0ZwxuQJ+cnsQKIxgDQX5ACh7BfsEGcS e4v9ji83ewNpTn85Rl8fo7/O0PQIO5TZFOxNTg835rIP0dhi9j7Zhhhj+9lLpBINvMeG+Oqzd9kw aQB9B+nloMOg1aD7kqHXAkNsaBAEY38saXHzybKXktGKsUigaCziyRmLON1VjUXsRfYCyUUTvwct BH2BjZAC0OdBvaAjbC15DXQPqyFTQHeP0Z+xA1zE2XNsL5kEOpi08iEkkgonu5IyJz9JkkyqrSJw gP2E7SR+VP1xMuJH4fbBSGHAth/tUfYUW5vMCzgbjexx2k5PoFI/eYdT4mRPJGt5I33JA8HAMOtj fZq3VivSyrWnhcqiyvLKp4VgUbA8WBt8OthoZ3dBgWxj2L9sC561JMggPQgaQh/bnBRrE42jmBOf FyMb8ezXY514dusxgqddj/HS43qsgd1KZiMwtHEDwgaEjQg3EhHPaxCuRbgO4Xo9Zy1i6xDWQ5t0 A9ENRDcQ3TqiG4huILqB6NYRvOduILp1RCcQnUB0AtGpIzqB6ASiE4hOHcHH2wlEp45oA6INiDYg 2nREGxBtQLQB0aYj2oBoA6JNR2hAaEBoQGg6QgNCA0IDQtMRGhAaEJqOqASiEohKICp1RCUQlUBU AlGpIyqBqASiUkcEgQgCEQQiqCOCQASBCAIR1BFBIIJABHWEHQg7EHYg7DrCDoQdCDsQdh1hB8IO hF1HHAbiMBCHgTisIw4DcRiIw0Ac1hGHgTgMxGG2fkA41PgyIIcAOQTIIR1yCJBDgBwC5JAOOQTI IUAOjU2dM4ILzAiwI8COADuiY0eAHQF2BNgRHTuCmiPAjujYBBAJIBJAJHREAogEEAkgEjoiAUQC iISO6AeiH4h+IPp1RD8Q/UD0A9GvI/qB6AeiX0f0AdEHRB8QfTqiD4g+IPqA6NMRfUD0AdGnI/6v l4bdSNsNOGvZRjpOpxvIpzq9gbyj0+vJgE6vI0/r9Fpyk06vIbU6XU8iOsVS63QtCRhoMlBra3RD BcxGWIywGmEbwi6E5xEUPfYGYh8gpFmNViDalNnKNmWX8rwi7VIOK8wmz5a3ybvk52Vpl3xYZsHG HGbR9ShUC7kbOEo24PkZAg4RPBv0WAOLod8Y9GwN/mIspjmOBT8rpW+U0udL6a5SencpbVTZ2VTU NV2Q1DIwgLZr5sjUwDsItZHiqdBMd+391BNIRiYGhuiBDBmnRZH8FGEA4WmEmxBqEaoQyhGKEAII tZFSwNq1grEmD4AWI4QQggi1xO2Gmeh0GLRhZqFPD75sISrvp7gEuP3J4kqQoWTxbJDnksVLA40q 3UuKuVVE92BT7QTdlQwcQfGPM+TZZGA/UtuTgRhIR7J4PMgFyeLXA40WuoAERA6dP0bnYcF5em4y sBDV5iQD40CiyeIIr12KjopQOg4W9RFQxHV0YaancDIwBbULkoE6XttAivnCU5mU68OTEOdpYRAD +myYtotUMwWOBe4LfIrx/hWMhXi8GxwSQd4oGqILNWPgQPkPULkxkGw08vo4HwbGaILTPYGnizYH HkNbtGhv4JHA+MBd5UMGZN+JcW/Wu0gGbgoOsZ1aVmBjoDKwtvxIYE3gnMCSwNxARxHyk4ELAwf4 MEmctrOdewNtaHAmZlGUDJxdhLFgiC2BqwNaoDhQFzzA+Usm8a4hyeUHOAdIVab3MvC3tAi9JwML aoeoQytVjit9ygXKNGWKElYKlHwlT3EZnAa7wWowG4wGg0E2iAZmIAbXUPqwFuX3BJesXxdkkSdE PW5nPI4HnoRRAyPnkESW0Mpa502jrYmRZaR1aTBxcl54iBrnLEpI4Wk04WwlrfOnJSZFW4eU9NxE bbQ1obRd0D5A6V1x5CbY7UOUzG8fommedWtOwjkdheTWO3OGCaW+W++Mx4nXfWWDt8E51VHX0vQf Hp16ZmdT9Juf99vRvMSDrfPaEzvy4okqHknnxVsTN84LXtg+zGzM0tw0zKycxNuHxW5ma57L88Xu pjiqHdGrQZqtqEaKOUE1wzQS5NWgT6bxalijTL0I4KgX4gT1jBYS0etFjBa9nkh5vYF3gs1NA0E8 UKeIkHf0Ou8UkW/VgcQA2zQQwQO1wkHazmvR9nBQH9g4vaFAAFXK8UAVCntPbyhA9c4SFd9UKRqr UnOmSo3el5AZj94Mf6AZV8npOq4S1PmGkf9vsa5pUTo4Yd0NLzV3hZs7w81dCJ2JLVeu9CY2Lg0G B25YxwuCCSHSuXTZSk6XdCXWhbuaEjeEm4IDE3TcvxS/xIsnhJsGyEvN89sHXtK6mpITtAnN4SVN 8cGG+vbG7/S1+Uxf7fX/oa963lg776tBx/1LX428uIH31cj7auR9NWgNel/Nq7jct7UPGMi0+HSs K6eDzGSEDHfmhOLT3PbuqVygh6eEvDfk7BMJ3U5M0XjCHJ6WsCDwovLG8kZehH3Gi6zIto0VeW+Y EsrZR7ePFdmR7QhPI6cXgnB8a6JmTmsiNG9ROxeVhAYW/Kc1W8N/erGXNK9qwj+k1+ph7Zq1p1vk lPCa//5b+59+69atW7MWj3XRNYS0JkrntSYmzsFIFAVddTbFkTf+dJ4g6HkDqto8lB5BYRSDoGt5 dzwWpVFwUDMSmSisX+5XGL9FrB3051WtPgi7YQMCrsNsfRKuBF60frCgCLclVKmoyVBcV3k66Q9V oYfBWkA5LcpQzVGOSF9RX3lfbX9Rf3l/rYzSvU8jM/A0P0qTFU8LZG10zWlmILo2DmZjWLy/x5O5 eXrH/TwSjcaja6jOr9P1v6F6PpLfMBZz1H9r9OY5v3UO48mjYDovxXpkel/HU/yXiehY8FkHIRe1 Mik9iz+++SEFV9E+kquHZ0iuGMEdi6SPnA6pVekjvIxT9gk0OTxIPIz9kuRZ8ntaQoNkkH5FPORL 6qMTyExI5xe4T+wio+QBXO/nkwepkxTiNrqAzKQi6kTJHfSx9JXpj8lZ5F7yRPo5elN6B8rvJq+Q LzGCP+LErCXnof4C0kU+Fj4k8fSjxEA2EROZQuZSN1lC3sbf5xjHfeR+8lN6XfpL9OoiN6G9etJI GtMvpE+RUnKH2Ce9o+4h95D9VE4vS6+ChVRAelk0/Xb6AxIhcfJD8izGFKUj4gwSIpeQW8nD1Ce8 gtgD5EmSombWIUyXnkdPM8lCcjlZT3rJDvIL6qRt0jvS8fS16aOQwixSgjGtIh/TGjqLPSWa01PT 75ELyDB5DfPlfyPiBeIz0gWphvT30y/i9v0cNdID9AWpSrpr9Mb04+mfwF8ZIRPAkfPQz1JyM3mB /Jz8jfydbUhvIDPIPPT8Ms2jQRoBx99mPnYDu0F4i4zHbDsw2nVkG0mQJNlH9pOD4M1/kcPkQ+qi OfQcupTeQ//OzGw5e0N4TNgt/Fak4o/A7zApAo/WkqfIXvIr8jp5g0pov5K20YvpavoQ/T49zBLs U/aFaBBvFr8WR6VI6nDq6/R56c9x5/aTc8k1ZAN4+0MySHaTX5PfwSv5D3KS2ukkupI+ThP0MP2U qayAzWbd7EHcnn8snCfcI7wg1ojTxEvE18X3pNukLcoSJXXq6dR9qR+nfpN+Lv0byI4V7UfgwFlF boRUPEWeJ2+h9XfJ++RPXH7Q/hS6iH4Pvayht9P76Y/py/Q39BPMEhYH/grYFNaEXlezK8Cnm9h9 7H70/gb3dMBJ8T77K/tckIQCYaLQIzwuJIQh4ZDwF9EuRsTx4gRxtrhITGNlqqSzpXnSdmmn9KJ0 XK6Xl8vd8kfKTcothl+Nlo7+MUVSK1OJ1CBk1wBJugac+AGBExC82E9+AY7+GiM+TE5gFfw0RIsx 7jraQlvpLHo+vZB20ZvoJnovfZg+Rp+gP8EMMAemYOxR1sjmsSWsi93CNrE74cvYzfaxn7O34VA5 hpF7hLAQFSYIM4VFwgXC5ZjDWrjybgFn7xF2CG8IbwlHhY+EY1g1j5gvrhOvER8RnxF3i7+RzpUu w98T0vPSiPQb6ZR0SmayX86VK+SL5e3ynxRZmai0KZuV3yr/MHTTXFqKkQch+2d+zIc9mM92MJe4 gR5Ddh5uHTbMPIp1mIdd8Q/SIKSwLlZejrFlM5+YxeGyJiZgCK6l+0kNfZlskJkAw1A8TJL0D+yw +BI7i/yOdlKf+IxwufQLFiI7oY362AG2n04ju1k9W8i2CoR+iFPxQ8j7VeR+egldQ3bSY3QyvZ7W 0g3kt8wtzKO3kPr0E0ykKp1JjxOMgNwoLiffOzOF/xihdfDOf5z6gWgRr4N+GiIPYkWfJR/QH5Gv qJT+FNpNgDZaAi1zB+T9VsK1Xgf22QbsRx80yKXyG2Q3leFDr5WniteQ4+Sf5GNpHyRqGrTp0dQq 8Qfin9O16XLsMOwysh37biU5GzvmQ0jJQaR56kLsdCN0CZyPpI0sgvPsemi9e9KJ9Nb0zemr06vJ L4H9ipbRr2g/dsQQEPXwe72GXfIu3YJ9ePZ/nN7/MTO1nIyQT6iXFtEq7Idj0pVSn7RD2i39VHpd ngBu30Ieg0T/CdJsxAyWkd+QT8gX1IC18ZEyEsN4J2Hs7eRSFhcOkunUT7qxZ0ugx6eNzWQNWrkJ 3NuK/XwQe+M49MSF5KfwnzHqwYyWoX8D2mkFnxeTNeRprODNdBA5y6G1S8lfMW8rnQT3QBnR0NKD 0FojGNMfyF/A7bQ+rjLohSa6EG19Qc4ny9HDRNJGB7ACe0kdNGuT8Cvwu5DayTRaQJ8ErhM71Arn d530Z8pIWeq89CS2SjiIMyaN/H6cXjnkLNqDUdgwj1GSTWeTmtRcjOEtKogJ+qY+ikdYV3qTsD51 Kfkl+RHWRBOvVJoI0Rrnaw1Tz6qfMrluUm1NrLpqQmXF+PKyaOm4kuJIUWG4IBQM5Ofl5vh9Xo87 25XldNhtVovZZFQNiiyJAqOkrDnc0hlMRDoTYiQ8Y0Y5T4eXIGPJtzI6E0FktXy3TiLIcUtQ9J2a Gmqu+JeaWqamdqYmtQfrSX15WbA5HEy83hQODtFFc3CbSNzZFI4HE8f0+Cw93qfHLYiHQgAEm70r m4IJ2hlsTrRcubK3ubOpvIwOmIzTw9O7jOVlZMBoQtSEWMIT7h6gnqlUjzBP8+QBRgwWTDHhDzc1 J3xhQNGMUNS8ZHmibU57c1NOKBQvL0vQ6cvCSxOEW79RvQqZrneTkKcnFL2b4CpYtwmyJThQNtJ7 x5CdLO2MmpeHly+5sD0hLEEbzQlHFP02JTzXHPF+k0TjsJM3fbs0R+ht9q4K8sq9vZuCiZE57d/C 5oR4C/E42gCWFbV09rag6zuwUq38SpVgt8bbE/RWdInLQpE+q8z8MjeZos6Lgwk1PC28svfiTiyN vzdB5l4dSvr92nD6MPE3B3vnt4dDiYaccHxJU+6Ai/TOvXrQpwV93y0pLxuwOzKMHbDaxiJmy7cj XWB6pkyP6dV5rHXuGc5SPsbwTNjjieCyIEbSHsacJvFH1yTSu2wSFgC/OAUqsRwrsiqhTu/stU/m +ZgiTUhF9nCw93MCCQgf+/S7OUvGcuQi++eEF3I5OSNqCbrkdDwRjSZKS7mIKNOxphjjVD1dU152 5RCbGO62wzcyERdB0gbeLolPrgD7QyG+wFuGNLIUicTGOe2ZdJAszUkSrQL3JdbJS7CAmZLsBbxk 4+mSM/DOMCR5N/dbkOyEIXLmn83uzmpeOTlB3f9DcVemvHVeuBW3m2Bzb+eY1LbO/04qU84ZCr6h bCyWyJreLuQw5PEYyxH0UgjlhYvOVEGi3ZwQi/BP5oPG7hAglHoGDbYk7J0zMs+4MRQa2zL/jhlS DN8CDaWPc5ROvoGNzSIxOTo2zsyoE1O+k/7O6My9Qut8aBzWOn9Rb6/xO2Ut0GW9vS3hYEtvZ++S ofTGpeGgPdw7zJ5hz/R2N0MLZRZ0KL1vS06i5Y44prKSTobYMjJtIExvnzOg0dtxfR2Giyl4+/z2 JKNseue0+EAhytqHg1C5ei47k8vrBHmKtFIIepIZ9KKcYY2QjXpdUc/Q08vgXtLzMpWQR8myIZbJ s+v14vF4OQx+eLbqcHd6ldwv15Gl8g5yj3InUcQ1ZCbCAvHPZD5oI9tBvDyOuvchvVmnfyb3IG8u wha8tNyE/ErUCyB9JyFomIsdwW1AxslCSBC3gUyOnv3/9eDOOLym/FYbcBb820/6txwYb8hTYOWq sE5MiJsRLDgfCU5FO3GAOnEHcuFew38T8beTnseuEh4R+6Wp0l75gFJvKDVcqzrUs9UDxpgxaSo0 v2o53/JL1MYhB07iDyNTyLTdjKZkZYg1aFlEElMCMSpiihKfQZZSTDhAI0TFxcJLvFH7yfrR+vPs J+pnjdaTBsTtp/CYUBlyhBxFeMATSU4FhZFTmkS+JkFxBH3htkikJbjT2uEB3aBVl0glxrM9XWKX WSr11HlmuOPulW6pzjMxZ1POI9KDJingKMJaZzmLbHaDr3iXQhXuJlBNMQzxDi1rY4gGQ5UhFnI4 gyRor7Qz+xDbMhicMM8bxdA6+Nhm2Tt6TkZ7Zh3TB8kHOqGSdPTQjqxQlcftdma7YHfjLxyijuqq 2qmsJhaJFEfC97O85zpvHOosr10x6+alT46+RUvev652xuL6+kvnTd0j7cuNvJg6+us9N/cvay0N iC+eqrE6F768Y8feFU79K5Gl6aPSQektSNA7Wsuk/Nb8hcqVhivNtxpuMd/quSVHlT1yjtPjzClx lHhL/CX5hhmmC8T56iLTxeK14jXetf691r32Vy2v2H9vP2q3CrlykGDqWsBfh3fIpIhR6s4tl1Wn ZnXGnK2zs2iWlu2NZQ3REq3UXW6DrU6DvsXILnYuZIFgUGD+YEFlASvwFfcbqc0YMFYaBSO4OBi6 YVuGW+DRefaOk5xp9hPHehzOugqs7OiJaMeRaMMxB1KjPdF6ZHMG0o4OWhNyyGK4oBAsc9ZOrA6K HikSCRfI2XZnddXE2hqhgd3Qkdq25y+pHc+ODN/5JnXQ6rLUe4GdG1/88KMDHfuns5wvRocWbX6B XvTWh3T54pkf/qL20utP/j31derrmbF9mOc9EH4f5MXMvJrJJEQMEZMgClSA8tLU3MkxY3DylJgK R/jgGNWezB2PXDxk1WD8s/qpURRVozGL5Yp2NWAMszIxqFYYL2IrxS71YuN6dpX4pLrDuEfdZzyp fmV0bxP71G3GV9SfG3/P3hHfVt81HmUfiR+qnxgt69WrjDezO8Sb1TuMfUxpN3Wxi8WL1JXGK9nV otLEWsUmtdV4vuF8td2oeI0V1hibLMbUKcYGqyIwsyirqjGb+UWPqgzIbPr8di3ARMGoSmZFqZKt 5ipsQbvADG0GS8zEH/osrSZLzKBZi2Mm/kDWVs3OIyaDgB1GmWKEYmior2/AwnjqMt6lDlpxzP7b YzwjZyg9RStHL0HRoKpVgugSBBFuT2OVwBBlaEYwi4yZjUZVVQwBK7UOUcsgt3/3sUlEwm67oCMm cdHzzJsfk6oUTdlgoIaDG7AKB01Bk5kNsUmaE1pEQ0WioRKpCpipmTdjmbAOiuJEz7Fo1F7/v+z1 fp99tGe0p97vtY9Go8iwH+nB4EExfox2kzQ+uun6n20a7+UkGp9QiXcVWfPgvTekDw+YgpMmxSF3 /NdzBZ8qifZ0VEPVUK50cMl33EP34yai0AOpY6n3U39O/VHad8orfPRVi3jT1zfwAJlSoEy3cJmi ac0ZFaJy0FRtEolMTZp/cgyexo2DoJz5p2nSVwMZO6qp/ryY0YeH+XSK8BS4c1iLu/NiYhAPBcss m/0kWx1HilTlY+NR8xfqP41fmKVXpZ8bXzW/R34LqXrb/An5UFV3ij+UdhqfMu8XB6X9xj3m10R1 vFggVRiD5sfE+6THjA+YDRlh2W2gVgt3gw5aQ3xwI5qKCIQixIe8dTAjL1u1bC49y3nKJEMJKBAR VZcQyMg3EkKxi+tydr9oEqXgULpyUIaADKWrtAsFYg4SgbEg3irhvZtRlqQqk9FlwqVIVpSgQXUZ DKpoMpvHRAmdCGYcIqJZkIwmRcXbKUWRJBEiRTNCRQxWj8dfAZkZopWaMSgfNB3UKvgeRtIc5B4v Rn2W7y3LKCG/b9Zoh987Our3jXZ4z2vuavrLGQnhcsL/9NFjAo66OjyJgwvOrG9LzpgAnZYjeIAh SbrYZDaI7sPt6QjRUBakJguUUtqVeoJWvE/NMIrpf9PS1NbUK6k/pN6HBDmEz07hNIMUzfh6CKfY zPRH8FRNhQevivZoKxW/IVfKc/vPyZmRO7Pov+wfONSJvhbf+ZEVvosit0Xu9d3nf9o/nPOq/7Uc syxbst2yz10sj8uO+9az29jT8h75Fdn8fOxdO8srrJrgKLMUatHxsUKtoAQPX15sdeGpQlbYkscX vdJqi52VR0mePS+R9888MS+vjFYTDbk2HKmMLAhpuY6GkJZjx8Prj4XgZd8jKmaLsYzLDsp0imKd okYZamiay5Q/IWIYp5ZY4gHzNjPDDk5jE2tWd8zsnx2jsU7snLsqwabqcaHFHvqBh872LPas9gge X/WqxrED5IpZx7DZO/gpEsUWReoINw6w/aMN9Q3Y8tETHdEjOFc6eqIZsU5W5NGe+LFMYpgUpkee y8mLzS9cXsg6ovEOICCpgtVeX49jm/Z08JO7eOLE6iq3O1twuT0hHNXFshwuiNTEJk6sxaET4ycQ lXGiZ7vcONCRWUO70tE33zgw1CrkFKU+MdkVYcaTHU8eXPjYvS+f27a6dT793sRPCmvbm85trrab 2J/GP3p/fPNzqaE7bj03t9ZnaGlJ3r7oztbcomDunOYpqTedVd7i+ikLqyK1hV3gygJIQwOkwUf+ W5vTbos7YcTYVjlXua/3Xu17iD1kfsX+ivf39re9H8sfGz7O+jj7SzlrUtak7HOc57hbvHHzKrMy 2VnrrvUK66X1tk3SbbbNvu3OZ9zDzr1u1cpXzZsT43SP0xWzVlt4ji8/plObI2bZBx+gEWvodJiI hqpEQz1S3Ye12octLKIo6FEoz6UhUmHhEUtoNjS9P0cJuXz+9szy8dP/ZMesY9ETx6L82MepH+Wn fxQ0YzL1dNCxA55zdmKtxBlPHHaC5RAnpP5qXTZ71fUbLmlbkU1d0ROvf5z6K3Ufe/FD9mnVvPn3 7Di49YLVFT99ER47ERq66BluD84H77g9aMN7hz6t3BmX48a4c6F7oTee+7DyiPqlqnbnb8xnk4WY eXJ2zHeO0GQ+J7vJ94iquvj7I8nk5+JrNSlWG5bC6BlntUToEB2n2WzEf3c+zbeHDL689npdQPkM e2DfHBut50oFf8cajunGTE/H9HbNskpeZVzlXOFe4V2VK3fAo1IzNkGYMx4cMy4Pn3ZGwsQlqa8b BxY9B1vlxeRN1DfqrGi6Zsntt1y0fNPWC+JwN0NfU9/9zH6qe8e5lz/15HOPb8N8GzHfYsiKi+TS Hw4Te/pLrcVU94j6qOVB+3bpGeN+db9lyG8wuOgMdrbcYpydv92yV97rf9X4mvlt4zvmL5UvLJZc W262hl2SrVkdMVv289lvZAvZXCps+Q06tXpA2Z2a2WZ1tlk7rczqdVJU2OvLidFqJzckB/OCMZ0W jMvQaHmGenN1qtmgUvrBUpjqjCx2OsHmQdHk9HJ2F5oUEqIV2RkhqshfnL86f1u+mG8LGTSLLQaG j2mEaMaihFCdgPl9jL81dHm1EleDV8u34QE15OX6imvleMMof31HnBgcajj5IFFJp6jHafJ01RPQ H/ynAwgKnHV8MkkPJ4lB1ThVTzaGGvTXdfEjXIt06N1bNXDJyju18u6tGpilHwdxmLfRKMwKHC/V /LjoIR1RykU8WByp4TJOhJCbC0AWN3IV2cO+ot6JH+9K/fXWVdT11jHqlEc14aYl0xYVC1ctvLC+ ntK5FY8+vuee9yEL0dSrqYPXb5lBL71mw/TpeAVL8Y6FsL/ghuAmQ1rVRJGWikF70BEXN3olg/i8 l2W7HczldDusWbjlWbMoPmVzqQabiS42pU3MxBfCKFOHzU3TburmyXz+6cdxNC1nuYxqdYNhNoxJ wVBir3AsdjDHEBU1izUrwlyLSb97xM3c4Nle1Rxz+zxXDbNVuNTh0hTtqZ/Fb3KnOupPdPiOEC+2 SUdP/ShCAx51VTb8xnRxVjXXutgcCle62dnV2WEYYmHv1rpH1l21JjJ96lk1b76ZOrpVjLTddsu8 wp/Z6+a0vn/qOWGmvvdTc8RO/RStoOdpS9fnbcpjTrOle8Jtlo0TxCANs7BQSatZtaDR6Wy6cIEt 7ooXLRy3MBqvuMT2pePLLOcUS7V7Skl1Waulyd1a0lR23DzqMd6Fc8tktphKzZZiq9uTXW4xe9yi t5DvgD36DtAF3+rQhWTQZM7QktLMBggXZeiEWGYjqNk5+uG3WAKLkwFbMSdWYzlnuClb8frk0nGm iN/LlY7q8/n9d0+gE6CChvCCvLow5PRVntE+J8b0j/2YffQIV0BQP9CwuikbHTsQh+Eth43n0DvH 18Ux7IwjUVg8kG1utPGgGOz8Egt13NGj6y3bKteqoovGrYiuqoDeIh0eyc1VlX721UBHjwmwBxc2 l5WFgzgss3QVntFlV9NGQ17Jwstri7IsN4y8ff1SSp9/eSNVpnbvvzv19z+durnzortuX9l1c0vx pOz8kHtC+HuPPbvn7t9RE/X/+IFTZx/Yd3H98F1WdvOPvv/4D57q/z4Uxn0QxGeh17lPYf0wUWG5 NDiMDZraprKNakIdUQ+pn6lSQO1UN6j9yJAEWYHDQYAW18ghvBUQSAdcE7IkK6KRKTgzsHqaGiqM iT5DQ0adR8dcD1yTc/EUJJgJ+KcL5xXRLH4nQLiP+lJH8WZrLxVTp74+R4x8/R62yGa8/VqMEZrI P4aJkH5/0OJo0M3q633lMQUXsSy5WF0h7zI+b3xN/aXxPaNxntApMIviVVvk8w1XytJe9QPxmHhK /FyWzlPOM6yQrxfvEB8Tt0qPyo8qjxqMAdEpR8WoVCqXKqWGCkur2CoZYZeoeL9glIyqIIsmSZS5 A8ZkMii4jRtN4hC7TPNLFYa6AHwdXRZmitCNhPIrv8/ccO2YmcXn7bOf7PFCrXJ7GKKEJ2cDv0MZ rrf/zFB/2qIS0q8l1VCMnDaBe8gVsKpwaeL3JfxTHJvxBm0mXZR6gN6a+k3q85th8J6kV6auG/0e fX9z6ll0/c1qzhvmV0JtHF9LqU1iG6UE3mUekj6TpIDUKW2Q+pEhYUpwHDEhQvlO01eN+MR/W7Wx deJjwRpJ+75qQV+48YtxaAU32aZ5lSxP1iLDSoOIT+pihpi9ydBk+9guyXzv5TkUXIjMJhOOfUYj bqIFC2O78Dk/GsFuRL/ugsJYn7ffy7q9x73sMy/1Gk0RM+6345IWC65wI5oNkH4zPQ6N4fOMjQ83 S/iMsEPh3OLXzJN6hu7jyjD5tMUQCjngKYLek7Mxg1A29GA+yxbjqaOFc+pmro1C6KQtb3U8OjvA 8p/tmtR2SzIVECNbd09fecu1XP/NhS3wKGZqgeX4kDbjI3rU8EXWF9niq+wjiTl9kk9lcfvCrIXu uPch9rD8sOEh85D6O/Zf0h/U35mPSkfljyz2Zwy/ZL+SXzK8YpbWGTbLtxgEB1dPRpOHs8glKq46 xd+Z053DcqwhXFa/Zer1nOQusYwBdFqTqKvsK2D/rPKKtANqBD6ymBPTItkuAjdPpOhbOmNu7+jW v9FY6uef3pv6opcGH7z88gceuPzyB1nBHVTuTb362d9SL92S3v6D7dv7t27fzue7JXWp+BDma4et 96g2flLWjCzmjAl1lrqsWE6TMNMyM6sp55856kJ54Rkb8KTyzxx8ZylzKy8pKdzm09wmE97TeUIG fzfsO8c4q9UWsdt1o8/UTTaiJ19eQ8akhUerHgtpP8LtPt0DqKtcriFwk6Bcd66QV3zb5iNwC2bz I42btbhVFHOzD6p0zOrbQuXqn1w8TFnq1HD73bOxxO67Viy96bZlF92OpW1bnvpjajR1MvVuy4LR j4XhwZ3fH3zmiW0QyE2ECLX63LdrJQ9JVLXSedIKaZ0kVDjbrSut3U7RqNrMATO725w2swbzbDMz D7H12jhFgXwLTDaWENWuVqrdqqj6Nzi3Odli5wbnLuchp+i0kwi/To/TTAwfXvfz+7SjYZjmZg50 nOdnxPlkh29W5kjH4QPprsM7Uc6KHnz+5cHnXzX8kzBj1SQsPsQ7w4nM4S47aD+X6OmXNHXGzz/7 rClzK8TIQ5c01Xw+vnFH6m+YYyXk2Y45lrIXtRHZIYcNxR6HJ/yw82HXQ8UPlKqKq8XFnPstw9ZX Qx+Gv7ScLJDHWRZYuiwPmB5yPlMwbFYaw1phU+SiguWRTc5NrtsKbi5UayPNcovpHMtsW0toWoFS UFgcqTXXhGoKasI1hYpslBxqyGspNhcUFISVwgKtbI35KtfV2VeOW1d6e/YtpY9mP1C6u2B32LKR 3u25w/tI6Y9KE2WyJ+TWQuGYW8vF17du+gHMp2pDqK3o7iJWpHnzYkV+fjnWPNBybWW0soxWlNGy /FClndqraUi3Hmxqg05RJaPjVEuM+KJXDXEVfQqmqX4THtMg3Pt8gnusjpGMWtZqZEpl6qaRgomh ltB8Gvcsp6s8J+G78jDRHypgJVkWMyvxL8a3Qi0lpjY/9bdkKbC/8I+bAqdDR0/OMClI/3IQ1kto KEMLuDs0v5CnDw8GCmN62sddAXBT5SByiYVOLGgpeNhyf8HPCn5bIIcKzBZR9PN5cPuIVHNLadBT 3gCqG9N6uqAoxqmW58cNAU4bDR8qiZ10Iz1O4WeyI9WJix1HZrlRk1JtFvyTi8XjIuNTcGto2l3t 0dCuR4OF7tFqamMe7unwaEXj8EC7Nk9AdyqIngV+Ddrb5qdt/rSfjU2+h7sP9B8c0jjx4ZnmXOU3 VM6QsUuBftLBU9CDXwc3+rlb4eeaanI22ErwCA2lP91rqTO7zHU8mjTXgUOfDJjq9GsAPgiMw7LK KuKmPlwHMfgXIHSwc3HJzfi3uWcBFiX/ZgC2VaSS+p2XL7ustsiVPTP17AU3vPfhe78tSX3hWNy+ ujKYG6EvxNtPfPbuKK2Izl1QklsRzHY5WqcufKT3wF1bJkydFnCH87NzV5zTetu9byawiwLpj9g9 0vdxJryujQsSmMHGcbbJ1nOscZviyyZewZ1NPM4sF/U4mYt6BVUxKmYYn1SzEU+/J+EROkFG4JeB uZ/ERRwqc5Bk83c6uCebTXB+VxBSQRdDS/ALQYlXiHicC7IbXNtcu1xCp2ujq891yHXcJRGX3RV0 VbpEuAiu6h8zPa5oTdRCT0yBnhgmrvTIpHjmtoB3LfYT+m3hmP4uCDe0IzBVHdVjt4UOiquBS+ep hzMNbpsaR7imuqbIwa4ZMRXnFp/jXXrdudfUmdQbb6R+MXI4Nf+maG7Oe6XVc5onPEDfOPzWk6nN 4M+d0DLz8G2Sm2zVPOc7LnI8KAmq7JPrWb0DX7c7jjLFxqfqEE1uYsx24SKE21AkO5twBWl161ZC 5sr0P1gJqoGLum4eGOhx+C6/ax582zbIHDFnTLCMddCRcR1EMEmY3PqtcSKPCudNPrjqkh3nUl9g bsOMK0qpb9uCpd/b8SDrT3kPd02Zve4IHYF5yt/L8QfuAsXk95nYvzz5//cQSDG+zKkkk0kTvtY7 G18AzcRn/ufiS5vZZA6Zi68WF+D95fn4Loj/KHEi8B//YpLMmjt9Xnx6tPGKVUsuLZ+2+tLls+aj 6H8DOrO2dQplbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjExMzI2CmVuZG9iagoyMSAwIG9iago8 PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9XRlhKRVorQ2FsaWJy aSAvRm9udERlc2NyaXB0b3IKMjkgMCBSIC9Ub1VuaWNvZGUgMzAgMCBSIC9GaXJzdENoYXIgMzMg L0xhc3RDaGFyIDMzIC9XaWR0aHMgWyAyMjYgXSA+PgplbmRvYmoKMzAgMCBvYmoKPDwgL0xlbmd0 aCAzMSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDPasQgEMbvPsUct4dF k1shCGXLQg79Q9M+gNFJVmhUJuaQt+9owxZ68AO/md/4OfLSP/fBZ5DvFO2AGSYfHOEaN7III84+ iKYF520+btWzi0lCMjzsa8alD1OErhMA8oORNdMOpycXR3wo3hs5JB9mOH1dhuoMW0rfuGDIoITW 4HDicS8mvZoFQVb03Duu+7yfmfrr+NwTAidiovmNZKPDNRmLZMKMolNKd9erFhjcv9IBjJO9GRJd 22huVo/A4lhaxWJUJY+eMqP89Z7NbkQcqy6kJi5JfMD7zlJM5eV6fgDV7nFlCmVuZHN0cmVhbQpl bmRvYmoKMzEgMCBvYmoKMjMzCmVuZG9iagoyOSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0 b3IgL0ZvbnROYW1lIC9XRlhKRVorQ2FsaWJyaSAvRmxhZ3MgNCAvRm9udEJCb3ggWy01MDMgLTMw NyAxMjQwIDk2NF0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5NTIgL0Rlc2NlbnQgLTI2OSAvQ2Fw SGVpZ2h0IDYzMiAvU3RlbVYgMCAvWEhlaWdodAo0NjQgL0F2Z1dpZHRoIDUyMSAvTWF4V2lkdGgg MTMyOCAvRm9udEZpbGUyIDMyIDAgUiA+PgplbmRvYmoKMzIgMCBvYmoKPDwgL0xlbmd0aCAzMyAw IFIgL0xlbmd0aDEgMTM2MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Zt3QFNn 28afk7BDIEFANGKCEaoFRIsDRyUCiSAOEKIJKBKWoKLIcKO4qsXa2trarXZpWzoOx1bRLtvaPWzt rq3V7mX3erXId51zc1v1e/t+f3z/9A38cv2e+xk55zlJwJQ21jdVCoNoEXoxuLzWVye0W+rdiN7l ixpt1I6vFsK/T1Xd7FpqX7xOiODes+ctraJ26stCSBnVlb4Kaos/kcOrUaC2NBTZv7q2cQm1U3ci g+YtKO/uTz2EdkCtb0n344sP0LbN99VWInEbZsKdra6+srtf8mA50/lt8xFt6Nm7MBwSGjrJJkzi aREodMgUgRXNW6Q1wg+9ar//9o7Nv79knhU+5lfRK0ib/cg3K3A+Qjy34e5Np091bgr+NnAvmsFY gW6YF7i9830hQnaePnVqZ/C32krdnVrolGC9rUO37qHgGGkCZC3LGpbVLC0sq1hWsjSzrGBZzrKM ZSnLEpbFLItYmlgaWRpYFrLUsSxgmc9SyzKPZS7LHJYalmqW2SxVLJUsFSzlLGUsPpZSllksJSwz WWawFLMUsXhZPCzTWaaxuFkKWQpYprLks+SxTGGZzDKJZSJLLssElhyWbJbxLC4WJ0sWSyZLBss4 FgdLOstYlktZxrCMZhnFMpIljWUEy3CWYSxDWVJZLmEZwjKYJYVlEEsySxJLIsvFLANZBrBcxJLA Es/Sn8XO0o8ljsXGYmXpyxLL0ofFwtKbpRdLDEtPlmiWKJZIlh4sESxmFhNLOEsYi5EllMXAEsIS zBLEEsgSwOLP4seiZ9GxSCyiW6QuljMsnSx/spxmOcXyL5Y/WH5n+Y3lV5ZfWH5m+YnlR5YfWL5n +Y7lJMu3LN+wfM3yFcuXLF+wfM7yGcunLJ+wfMxyguU4y0csx1g+ZPmA5SjL+yzvsbzL8g7L2yxv sbzJ8gbLEZbXWV5jOczyKssrLC+zvMTyIssLLM+zPMfyLMszLIdYnmZ5iuVJloMsT7A8zvIYy6Ms j7AcYNnP0sGyj2Uvy8MsD7HsYVFY2llklgdZHmC5n+U+ljaWe1nuYbmbZTfLLpa7WO5kuYPldpbb WHay7GDZznIryy0sN7PcxHIjyw0s17NsY7mO5VqWrSzXsFzNsoXlKpYrWTazXMGyiaWV5XKWjSwb WC5jWc+yjmUtyxqW1SwtLKtYVrI0s6xgWc6yjGUpyxKWxSyLWJpYGlkaWOpZFrLUsSxgmc9SyzKP ZS7LHJYalmqW2SxVLJUsFSzlLGUsPpZSllksJSwzWWawFLMUsXhZPCzTWaaxuFkKWQpYprLksUxh mcwykSWXZQJLDks2y3gWF4uTJYslc4/62zJ+a1b6jrXid2albxRiDbVWK31HodVCrVUUK5W+oSg2 U2sFxXKKZRRLldhxGLJEic1ELKZYRNFEfY3UaqCop+JCJTYDE+ooFlDMpyG1FPMo5ip9nBg5h6KG oppiNkWV0icLQyqpVUFRTlFG4aMopZhFUULzZlJrBkUxRRGFl8JDMZ1iGoWbopCigGIqRT5FHsUU iskUkygmUuRSTFAsOTiHHIpsxTIBrfEULsWSi5ZTsUxEZFFkUmRQ3zia56BIp3ljKS6lGEMjR1OM oukjKdIoRlAMpxhGiw2lSKVVLqEYQjGYFkuhGETzkimSKBIpLqYYSDGA4iJaOoEintbsT2Gn6EdL x1HYaJ6Voi9FLEUfCgtFb6X3ZGxWL4oYpfcUtHpSRFMxiiKSij0oIijM1GeiCKdiGIWRIpT6DBQh FMHUF0QRSBGg9MrDo/srvfIRfhR6KuqoJVEILaQuijPaEKmTWn9SnKY4RX3/otYfFL9T/EbxqxJT aO2QflFiChA/U+snih8pfqC+76n1HcVJim+p7xuKr6n4FcWXFF9QfE5DPqPWp9T6hFofU5ygOE59 H1Eco+KHFB9QHKV4n4a8R613Kd5Rek7Hqbyt9JyGeIviTSq+QXGE4nWK12jIYYpXqfgKxcsUL1G8 SENeoHieis9RPEvxDMUhiqdp5FPUepLiIMUT1Pc4xWNUfJTiEYoDFPspOmjkPmrtpXiY4iGKPUp0 Ok5aUaKLEe0UMsWDFA9Q3E9xH0Ubxb1KNN71pXtolbspdlPfLoq7KO6kuIPidorbKHZS7KDFttMq t1LcQn03U9xEcSPFDTThempto7iO4lrq20qrXENxNfVtobiK4kqKzRRX0MhN1GqluJxiI8UGisuU KB/Ofb0SVYZYR7FWiapCaw3FaiXKjVaLEoUfNtIqJWo4YiVFM01fQfOWUyxToiowZClNX0KxmGIR RRNFI0UDLV1P0xdS1ClR5VhlAS02n0bWUsyjmEsxh6KG5lVTzKYjq6LplRQVNLKcoozCR1FKMYui hE56Jh3ZDIpiOukiWtpLD+ShmE6HO40eyE2rFFIUUEylyFciHTixPCVS3dYpSqT6gp2sRK5FTFIi kxETaUguxQQlEr9ISDnUyqYYT0WXErkSfU4lcgMiS4lchchUIlsQGUqECzGOwkGRTjFWicDvBdKl 1BqjmL1ojaYYpZjV19FIijTFPB6tEYrZgxiumIsQw6hvKEWqYk5C8RIaOUQxqyc2WDGrb0gpFINo ejI9QhJFIi12McVAWmwAxUUUCRTxilndpf4UdlqzH60ZR4vZaBUrRV+aF0vRh8JC0Zuil2KaiTVj FFMJoqdimoWIpoiiiKToQRFBE8w0wUTFcIowCiNFKI000MgQKgZTBFEEUgTQSH8a6UdFPYWOQqIQ jq7wMqvKmfBya2d4hfVP+GlwCvwLtT9Q+x38Bn4Fv6D+M/gJfT+i/QP4HnwHTqL+LfgGfV+j/RX4 EnwBPg+bbf0srNr6KfgEfAxOoHYc+RE4Bj5E+wPkUfA+eA+8a5xrfcc4xPo28i3jPOubxgTrG+AI /HVjovU1cBi8iv5XUHvZWGt9Cf4i/AX488Y51ueMNdZnjdXWZ4yzrYcw92ms9xR4Eji6DuL+CfA4 eCx0ofXR0HrrI6EN1gOhjdb9oAPsQ30veBh9D6FvD2oKaAcyeNCw1PqAYZn1fsMK632GZmubYaX1 XnAPuBvsBrvAXYZk653IO8DtmHMbcqdhrnUHfDv8VnAL/GasdRPWuhFr3YDa9WAbuA5cC7aCazDv aqy3JWSy9aqQKdYrQ2ZbN4fcZb0iZLd1vT7euk6fZl0rpVnXuFvcq9ta3Kvcze6Vbc1uQ7NkaLY0 5zYvb25rPtrsiAgIWeFe5l7etsy91L3YvaRtsfuA7jJRpVvvGONe1Nbk9muKbGps0v/SJLU1SVlN 0uAmSSeaTE22Jn1oo7ve3dBW7xb1efUt9XK932i5/ni9TtRLIR1dB/fUW/q6kI4V9UaTa6F7gbuu bYF7flWtew4OsCZttru6bba7Kq3CXdlW4S5PK3P70krds9JmukvaZrpnpBW5i9uK3N40j3s6xk9L K3S72wrdBWn57qlt+e4paZPdk1GflJbrntiW656Qlu3Oact2j09zuZ04edHH1MfWR29SD2ByHxyJ sEgZgy0Oy3HLDxY/YZEtBy36iPDe1t66geG9pMwpvaQFvVb1uqqXPjzmcIzOETMwyRXe83DPj3p+ 39Ovh6PnwEEuEW2KtkXro9Rzi55UqJ7bnuj0LMohw7RznRRtT3CFR0nhUdYondMaJQnzcfMPZn3U E6bDJl14uBQe3hWuc4RjeHiYNUyn3nWF6R1hQ0a4wo1Wo0696zLqox1GVNSDvyg0r9AVbrAadO50 wxSDzmFIz3Q5DMmDXUIv2ST8lx8TQh+kHo0UZXV1SGJPtOQvdUhb2gsLEhNzO4LE1Fw5KK9YljbK 8QXqvSO/SA7YKAt3UbGnXZKu9LZLusxCOTI3v4ja6zdvFhmxuXJsgUfeGevNlVsgDlW6ICK2PVpk eBNLGpoaEhMbS3BX0tCYqH2jJTWpLdzQge+GRrTVLwTaQu35+xsNw7hZDbhpy9Dqfz/lv6BH+i84 xn/4IbYLPEU947p060SFbi1YA1aDFrAKrATNYAVYDpaBpWAJWAwWgSbQCBrAQlAHFoD5oBbMA3PB HFADqsFsUAUqQQUoB2XAB0rBLFACZoIZoBgUAS/wgOlgGnCDQlAApoJ8kAemgMlgEpgIcsEEkAOy wXjgAk6QBTJBBhgHHCAdjAWXgjFgNBgFRoI0MAIMB8PAUJAKLgFDwGCQAgaBZJAEEsHFYCAYAC4C CSAe9Ad20A/EARuwgr4gFvQBFtAb9AIxoCeIBlEgEvQAEcAMTCAchAEjCAUGEAKCQRAIBAHAH/iN 68K9HuiABISokFCTzoBO8Cc4DU6Bf4E/wO/gN/Ar+AX8DH4CP4IfwPfgO3ASfAu+AV+Dr8CX4Avw OfgMfAo+AR+DE+A4+AgcAx+CD8BR8D54D7wL3gFvg7fAm+ANcAS8Dl4Dh8Gr4BXwMngJvAheAM+D 58Cz4BlwCDwNngJPgoPgCfA4eAw8Ch4BB8B+0AH2gb3gYfAQ2AMU0A5k8CB4ANwP7gNt4F5wD7gb 7Aa7wF3gTnAHuB3cBnaCHWA7uBXcAm4GN4EbwQ3gerANXAeuBVvBNeBqsAVcBa4Em8EVYBNoBZeD jWADuAysFxXjWqR1sLVgDVgNWsAqsBI0gxVgOVgGloIlYDFYBJpAI2gA9WAhqAMLwHxQC+aBuWAO qAHVYDaoApWgApSDMuADpWAWKAEzwQxQDIqAF3jAdDANuEEhKABTQR6YAiaDiSAXTAA5IBuMBy7g BFkgU1T8w9+m/+mH5/2nH+A//PhiZpWofzEkxJmt5/6RkMgTc0SDaMHXZWKz2CqeEEdFmVgLu1Hs FLvEPUIWT4oXxDvnzfp/Ns4s9a8Vofp9IkD0EKLrVNfJM7tAh3/YOZWtaPXws/1V6TJ1fXdB7bsz W7tMZzoCIkSINteoO4LVfpY6u07h52uAMHYNV9u6DfBw7ZF+DNx+5sEzu887gTyRL4pEsZghZopS 4cP5V4hqUYOdmSvmiVoxX2vNR99seBVaszAK7yWa/zVqgagTC0S9aBRNYhG+6uAN3S21b6HWbhKL 8bVELBXLxHKxQjR33y/WKivQs0yrLkHPSrEKV2a1WKMZJ1XWinViPa7aBrFRXI4r9vety8+OahWb xBW4zleKq8Tf+ebzeraILeJqcQ2eD9eK68Q2cQOeFzeLWy6oXq/VbxLbxQ48Z9QZ16GyQ7Nt4nrx qHhWPCweEA+KvdpelmNvaUd4X6q0na7DHqzAOa8954hpNxef3a2V2A31vFu7z3sJ9m/NOTMWde+j untrMVLdndbu66Cu0txd4Z3YgjMj/+s81T1Sz+Gq886TZ/xfVfWM1X26BfvFO6Pu2TbUbvpf1XNH nOvbxK14Bd6Ge3VXVbsdTrZD83Pr28+O3an13SHuFHfhWuwWqnFSZRdqu8XdeG3fK9rEffj6y881 6n1A3K9dOVm0C0XsEQ/hSu4V+0SHVv9PfQ/ivePCOXu611LOrrJfHBCP4BnyuDiId5qn8MWVx1B7 ort6SBtF7afwt5SHtFFq71N4bj2Hd6gXxUviZXFYPIPWq9r982i9Jo6IN8Q7khH2uvgK953iNf9P RZgYhz+8PICrcYsoESWO8RWzSmbOKC7yetyFBVPz86ZMnjQxd0JO9niXMyszY5wjfeylY0aPGpk2 YviwlEHJSQMS4vvb+1ljIs2mcKMhJDgoMMDfT4/fbJOcdlepTU4olf0S7NnZyWrb7kPBd06hVLah 5Dp/jGxT5/nQdd5IB0ZWXTDSQSMdZ0dKJtsYMSY5yea02+RXsuy2Dqko3wPfnGX32uSTmk/S3C9B axjRiIvDDJszpjrLJkulNqfsWlTd6izNSk6S2g0hmfbMypDkJNEeYoAaYPIAe127NGCspIlugHNU u04EGdWHlfXxTl+FnJfvcWZZ4uK8Wk1kamvJAZlyoLaWrUbGMYtNtvakg61XdJhEWWliaIW9wjfD I+t9mNSqd7a2bpDNifJAe5Y8cNmnMdjASjnJnuWUE+04sNypZx9Akv3jTXZb668CB28/+S2O+pyK r7sSEG/6Vaid6ime3SZZ8rELHBuOEOcXF6cey6YOhyhDQ27J91DbJsosinCkJHplXanac5B7otxq Twv3nJ1easfOOu3O0u7vRdUxckuZLTkJV1b7jpf94tFvk/UJpWXl1Wr6KlvtWThD7KUoxIc2WRCH r3szne2DUzDeV4qTqFG3Id8jp9jr5Eh7Bu02Clgk3llT4NGmUNUpR2bKorS8e5ac4sRcPEWcreqF UQ9QXcue79kvUruOtw+1WfakiqHCqx6HHJ2Ji5LgbPVUVMnWUksFnp9VNo8lTnZ4sX1eu6fSq14l u0keeBwPhxsuoDYL53bBaB6M05YD44NsHp1F71WvFgo2F+7sGWPQYZIDqKle0YwxNo9kETwMj9I9 QrXz1kFDH5+ZjclITM3MtsThya3d/sMhWegEcBhy0Nlj8sNB+P91TPQ4f3toNFo9oIE2Z2XWOQd4 3qJoaAfYvdq/P06duhfdm4FDCFIvZ7Z6DslJOrgN3UGyDuepldSrGGOTRZ7NY6+0e+14DjnyPOrF Ufdau765BXb1g0Htanc/SwrPa1F/GvXJIi630MMN9TMb2ZWoXVf1smrt8Vr7bDP7gu4c7ra1Btlz C1rVB7d3LyhseAXh4gQk5Pg2pUUMxYvVhTdKu8tnt5lsrlZfR1dLWWu7w9Fa5yytHoWXQas9p6LV XuAZg2upve6bLcvUh44QuVJuYUZyEt57Mtrt0sb8doe0saDIsx9/oG/bWOhRdPhQtDTD294ffZ79 NiEcWlWnVtWiOsSmNtSVpqIRpI237HcI0aL1+mkFrV2Oz2W1Gg1CTRLlHTqqmXicDjU/qjm0mhc3 vMJiqnEJ8D7stFWol2eFt7q11Ku+uEQ0LiW+JVmyjxWyzj4WH+UGhMoh9soM2WDPUOvpaj2d6gFq PdCeIUvREjanA+9JraV2vE/hKefBR+RePDtM6rNfF2/r6Ooq9MS9YjnpjcNLYgYo8sjBifg54B8/ AePGq5SiPF5uKfepxyHceKmrr8ycci9eC7wghuTIwVghuHsFjHBpc9SnIyaV49rgAmrzW9CQW7yy N1F9UE+NekQ2m0kW2fZRuOy0pn+C+kAp3tYI+yXqExtD5ZD4DWoE49gEPqTWKhY08WB4w1XPKDAU R15uR1d5qQ1XwE+UF+CpTu+lIep1Q6USb4l+CZUaIZbuTqGelj7eYAyRgwdhQXyrbhiEBfEd6MWm qCevtTZ0D8Bjm2QDjijhnK3snoDdQVeOeiz43oCDV4c+qS6T3yGm2pfgrVE9aO2hAtEtG+NzfHjz p/kGVOxpPBlrBcWrJXWNQ1QNVM88FPuujy/s6NptX6q+A/AtOcmu/nBQn5jCsh9PbOFtvbAgFycm JwVdWDVq5dbWIOO/n0D7FWQ8m+oqNid+1gjhp/5vLIfxkAh8qbdQ/HsqFBl3tiLw++ltqPjjX5gN +iP415ge/7/LSDFJTBbFjwojPjaJFqOkhx+OysoKSg58HB+J6IQNH6oECUnKdIT76Yz7evdOt+8b FrBZb87pkJIfSg/cjI8L0zuPdb6a0nnsZMTIlJNSyocnjp0w/fiqeWRK6ok3TwwZLJnjzBqRYbrA wMgAe79BumEXJQxPTb1krG7Y0AR7vzCdVhs6fMRYfeolfXV6jKTKWJ3alvRH/izST+kM0K20p09L 9e/bOzzSGOCv6xMTkTwm3lRQHD9mUGygPjBA7x8UOGBERr/cec5+7weaY6OiYyOCgiJio6NizYGd R/3DTv3kH3Y602/e6Wv1AaNnpPfX3xASpPMLCOjoG9Pr4tFxOdPCe5j8DD1M5uigwAhz6ICsGZ2X RfVR1+gTFUVrdU5Stxe7GtG90wH4TVVMd3kmOIsSM33zasrqa/4HYwZ03QplbmRzdHJlYW0KZW5k b2JqCjMzIDAgb2JqCjU5MjIKZW5kb2JqCjM0IDAgb2JqCihyYWRleHQgY2hhcnRlci1taWxlc3Rv bmVzKQplbmRvYmoKMzUgMCBvYmoKKE1hYyBPUyBYIDEwLjcuMiBRdWFydHogUERGQ29udGV4dCkK ZW5kb2JqCjM2IDAgb2JqCihNYXVyaWNpbykKZW5kb2JqCjM3IDAgb2JqCigpCmVuZG9iagozOCAw IG9iagooV29yZCkKZW5kb2JqCjM5IDAgb2JqCihEOjIwMTIwMTIzMjE0OTU1WjAwJzAwJykKZW5k b2JqCjQwIDAgb2JqCigpCmVuZG9iago0MSAwIG9iagpbICgpIF0KZW5kb2JqCjEgMCBvYmoKPDwg L1RpdGxlIDM0IDAgUiAvQXV0aG9yIDM2IDAgUiAvU3ViamVjdCAzNyAwIFIgL1Byb2R1Y2VyIDM1 IDAgUiAvQ3JlYXRvcgozOCAwIFIgL0NyZWF0aW9uRGF0ZSAzOSAwIFIgL01vZERhdGUgMzkgMCBS IC9LZXl3b3JkcyA0MCAwIFIgL0FBUEw6S2V5d29yZHMKNDEgMCBSID4+CmVuZG9iagp4cmVmCjAg NDIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDYyNTE4IDAwMDAwIG4gCjAwMDAwMDY4NjcgMDAw MDAgbiAKMDAwMDAxODU0NCAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDY4NDcg MDAwMDAgbiAKMDAwMDAwNjk3MSAwMDAwMCBuIAowMDAwMDA5ODE5IDAwMDAwIG4gCjAwMDAwNDM0 MTQgMDAwMDAgbiAKMDAwMDAxODY5MSAwMDAwMCBuIAowMDAwMDA3MDgzIDAwMDAwIG4gCjAwMDAw MDk3OTggMDAwMDAgbiAKMDAwMDAxNjkwMyAwMDAwMCBuIAowMDAwMDA5ODU1IDAwMDAwIG4gCjAw MDAwMTY4ODIgMDAwMDAgbiAKMDAwMDAxNzAxMCAwMDAwMCBuIAowMDAwMDE4MzIzIDAwMDAwIG4g CjAwMDAwMTcxMjMgMDAwMDAgbiAKMDAwMDAxODMwMiAwMDAwMCBuIAowMDAwMDE4NDMwIDAwMDAw IG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA1NTUwOCAwMDAwMCBuIAowMDAwMDE4NjQxIDAw MDAwIG4gCjAwMDAwMTkxNzIgMDAwMDAgbiAKMDAwMDAxOTQzMiAwMDAwMCBuIAowMDAwMDQzMzky IDAwMDAwIG4gCjAwMDAwNDM4MDIgMDAwMDAgbiAKMDAwMDA0NDA2OSAwMDAwMCBuIAowMDAwMDU1 NDg2IDAwMDAwIG4gCjAwMDAwNTYwMDAgMDAwMDAgbiAKMDAwMDA1NTY3MSAwMDAwMCBuIAowMDAw MDU1OTgwIDAwMDAwIG4gCjAwMDAwNTYyMzUgMDAwMDAgbiAKMDAwMDA2MjI0OCAwMDAwMCBuIAow MDAwMDYyMjY5IDAwMDAwIG4gCjAwMDAwNjIzMTMgMDAwMDAgbiAKMDAwMDA2MjM2NSAwMDAwMCBu IAowMDAwMDYyMzkyIDAwMDAwIG4gCjAwMDAwNjI0MTEgMDAwMDAgbiAKMDAwMDA2MjQzNCAwMDAw MCBuIAowMDAwMDYyNDc2IDAwMDAwIG4gCjAwMDAwNjI0OTUgMDAwMDAgbiAKdHJhaWxlcgo8PCAv U2l6ZSA0MiAvUm9vdCAyMiAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPDRlMWJmZmRkMmM4Nzk0MGVm ODI1ZmE1OTY5ZDE0YWQ5Pgo8NGUxYmZmZGQyYzg3OTQwZWY4MjVmYTU5NjlkMTRhZDk+IF0gPj4K c3RhcnR4cmVmCjYyNjkzCiUlRU9GCg== --_003_CB431B0A1C095mauriciosanchezhpcom_ Content-Type: application/pdf; name="radext charter-milestones (marked).pdf" Content-Description: radext charter-milestones (marked).pdf Content-Disposition: attachment; filename="radext charter-milestones (marked).pdf"; size=103869; creation-date="Mon, 23 Jan 2012 22:11:41 GMT"; modification-date="Mon, 23 Jan 2012 22:11:41 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVnduSHDeSpu/jKXLvSDMplXHKw9xpRXUbx7bnQLK3x2xm L9hUSeIsRapFqjWzT7/fD3ecIiOzIpNVYlE0VUYgEB4OwOH+w+EA/rb619XfVod1v131/Xo/bDb9 ajz0626/2g379X71y83qL6u3q6++ed+uXr1fbdaH4bBpD9u5q+b9q9XQD+t2u2q32/VuNwxcdOvd MG5X265fbwbR+z5/sx0P6+1q2LdrsuYcf2mKL642/IPy3/hku9/vdcs/vx5hshvHdrVrD+vDuB9W r35a/c8Xq90YstlP8+Kn1VcvXrTrzapdvfh+9e+rR08er77crLvVo5t48T5evIoXv8SL14/5Hnl/ ftyE3w8x4Z0/eOu/K/+N6d/HhL8EUv3qUXzyy+PGvv9/px+JtH6Y0Pyj3yeuIqlfnaufH6/+z+rF P66+fUEFp2Y9VcVlo4aqOlnF3ZZWP9DksYqbmSpeTar4ESV/8Z+389JMBew8L6m5t4f9ejPutt7c m/Vmc9g3LxDANlDwH+OqKxr+xY+PEQI1O39hcrt69IwmoHW/5oc0SUbXPHoaHv3ZHj23R5b9W7v5 r0Dhw+PVGKnRcryPHEEMCYEyTdQ2j8p0IyFx8MerRzTosHqEHKTX7AUEwFjkAzT+l33jWUV19ejX 8JdGT5l+I1Oi8SYwYH/5KDS+TyytHr163JDTSBjDlsdI2/ctxSoqFRauLSUXqikKu5oprFWRUbbi W0pqiCS1zUVSi57Z7PZDT9/s9/uuH3V1OHTtuD1IFc0rjH6DZhrQExMJOik3DQpjqTQfqcvz0txv 9utDz5cjL96zkOa2PawWSPMzhJb2f4K07leP/oycmjTsG5TVCn2DcJmgcU21k4mG4Bolh9DZNUJC Ok3DX8tPE5Pnb+Ev6oVr5Hny9Ltr1E0TbMiZhjut6fvDYb3f7aZ1dbLdpOiXttuFWmjYoFG2HUbt WAsN/RIt9IGa/5I+SaUn6c86e9YUH/F4Tv5VjUHSO3hE4LHv3brbYofdcIra9yvV6e4QOsNcJrPW ZnAhOLbr7dgaxV6mdrMet1swQwuCGPjdtEb2d+jG2RDs9+ttWxuCbq7rNCCA0hDcmE77+eXb7+Zb 4bTlbDIcukqU91tAS7+lJp353O83h1nmBV9K5o1pWZ63Zj7on9yh1un/P15angLeHZUHxOM69XTX bLtRIO+QylNYZfTzVI85HCvL8wFjoP6A4gndApv0Jfrpw0u7x9goGZWjH0+k4F9iXT1x5akfPoT0 oLGoi7/aK1g6vflhQh8dmQg20on6KHlm+uRpaTiuPersyCKdrr0OZNwhCfO1d6s2efQFzX0PUKvr dustZnKuf93KFAj75XffmWje0Ji0hP2dimYTxh5LKve8Ke3G3XrfdrNdag/ovx0YvoJbDN1/IwRw K8ngB5M5NDKTugGQ6cfySdxyPokvd/RCBOgVheTHc2BduQnvJkpGwnLrE/RZI/DTUtm72BqcQEP9 YT3uZclqTfQprCpAaL3b7nMTFlrk0C0SuR9MDVLldHa7NqxJq6Y+/bugzG273u+H2bLMaERGT1Pz 9MXKdZarwqi5ioJkwDDTf+5KQBibt90wTgUkDLgWmap3jDtoDfoEf9/eaJBCN5MeaI4Gq7PA5whU HwOf2kgZNpBM79Yd49Z2u1/v9rsuYh+DNb1Efyc449lmAZLacYBGzDR062FfEzrGR9j3Q/tQ8NHu sG53FT6a14dTAXwviUOnvZIcJrXniabhTHVV+lCWGqP83vWna07LYtnfV9ox5DfLzjfs0StTmUF/ hjGvjT/QkogSf11FW+ZSiTppZ/i9K2BX2zd4XNIn/NHc14UnyOcFtS/aRzy3bppgGaLC91L683Vg Eu6Sxrmso95i6IZhvd21jIPqhq009hRhqWKPIMJlne0UpkmdbYcBZnzR7vv1btNpcGDeujDQOO4j OAhHvIx5CNEBmg6b4YoRxPkKyyMFrqQGCrA9r4qnYPupGlYqzAdtSLMk5DsEilRXzJ64SiM7T/d3 JXBkdjiKgLuIiSwCZV4i5YgQ1en5Jx2o1t9ymvJGQs1zvjWuIq/fr2pkPU9eXSQXxVlWhyHR6dbW aPWMN3AIfM3Pznxm3D39s6U+t9Svntitlc+5BeF82W5StRX8LOsuKO+m9kgfDVkQqluHLP0GT247 oNhrqai6kTs100Blthstsb3nJbTHnRA875GXi4HPdzc/G+Z5h25EFlTJas+3hn4Men/xuCENTcDf l5bd/lqSWhRFqxbFNaim4+5bu/s3+3nBD9SVv3kkHyZN/0d+3J4fO5+XqBgUyy0tqLbifwZIgPxB TozaVCc3RRMmCpKbgtwbhlVZxUQvhb1wzktxhJ7Ot2DWMQPjmQGoYS5yc+Qtga6/0c2oRno97jp8 wZg5qpk+RefhL+3IX3okedS4tBCNmjL9yZLc/0cz8ZzXaZ7Sz0e/5nUj9bLw6lm65aeXWmvyuSf2 bUvyr6KBjAa07ZqZjMU9dzKXdNTuNY6bH7K0ewDN5gAiret62nMrPKPaODKAMz1XklFpF7X7aWdy e2hBmMw+TXgROl6Gsl5JvXqPpeUdNklXkkhT0cS0An9lOUiyG/otEMSuLVOFiRJ0Kwn4h2jsZc11 YRfoQMrbgyb66mZRVSzziX4RbZabmg+U0krMX7dJr4ODy2/cakUL54ZKAwyEN1jV9F5hZlSLIWtw kRdmzy2u6h4N6ZaaOiZ/yckHVbV6nn9IOYCDmNll9XokYsfqb0k36BmY4Yx9EN2gB/PhCp/rBifm MarOqelYapFGm1c1QfNl7UhXLmq6uWz6+kjlZLCgbi7lsjkwWtoy+73pTpga1T1TSBik+VyGYY8x 7yCP2u9skBjlHjbXGCRrESSf6re/VDzXdAwsgOn+1eOGFDcN1nj2mpmUaGr0QpluLzPQIn2dWhO/ zDmTfNRvzpvkFq/qKL+FV4Cj/qmVqLD+UitxoWrM6IAYhRFvREYHCyet/4BKRA2hoVA81CqWAn1D CjWZ0n8Cr/MY3ZaS7PEX4QVaj9fsZctjKZaHBuMtMIVPC8e5ZntqOWl58tDM/AVXkNMmraUIubEH xiNtSyZeQ5PaXLN9UqICj5i5RAmOyIR4wJ19wa6ROVLs2vII2zZO1L+ZHqcasW8a2zbDY3msaFZ8 S2GkBBMYkcTpMyvI1/yQJghMsZ4G/jSy4eZ5klZk9Zy0HonIsZbPmufM3MBhtx7HjtG+i84nFONO k4Wo+sRLIcb9otiL12p+Df58OPuGZpKtjcl+60NY2krNgFgpj9+9DqY72XVaVfKEhCsrbV+8EZ4F eVGiW2v/xJs3M3kDgcK0nI2MuriBO5pyCNM87X7dHsZuMoo5ZTRaTWxgkX7XYUwLbMMXX7Twvl0y jFkIZ5tjOBuhLe1Mg1ZwVlCMFlTT8WMZ1Jzkc6eePxIuNDHgkTozP+rMmBl1Zu7ozPxVZ+aHzuxD V24YEOldJ4H+ypT8XbRGyBeeSGTRORVPfsOAiA8ikjOitGTIcawpluDBDjkZh4N6Z9V2U4NXIa+l Bm/W9p4eFnUoq12P7a1ZsaHA3FxcxRRwcDod/L33emwCbWR/Pcn7NY0TWi+4rOLAAFukVlS7oEFc V9Tzwz7nO/Wh8QJObN6jxePMck3NxxdRdblGc6b8Tf+wOwrj8EYiBjsrf4qR0lfiCMWfQmGZ+Bzp ofOwqN+PcqHMNc1CHT6rgNGmFbs2rbvE/YNeO4PJsYyNJHu70VQ04VI7rOFEcUo4vw+lrt0/5O41 8XGsOE3VnjPfswJ/2kxnhIerattv94WPed4PUOFOJD4qTtc/703ZBDXURC2DAKJYXMtUGso1ZKU1 TU/6vDIvqX2ay2NDz7XOaQ3Q4s0/dMSybL1C3JJMtVGqhnuMstNIoG01WjtqnBOj08SVBwvHKLtv g5LBGYpSeeFONg2A/mJdWK5QnvzDpC9YePXtmh/vpf6djFxsdx3R1wxNF1Up2PZUANy13bI2Q6GJ B7yyI7iwb5d2y5HZ1hBylrslsjLumOEP/fg+euW4x/QQLLwIPH+5zFN4od7FOzYMI9N2kZe5DrFo 2u52QZIYmSt83oO6xVvTEzo75YVKamnPaazMlCu01deYYBzA9hfdzzX6iPERxoG/GFUUFWNWrmUg TWtxA7LnL5qJF7BwpPMyMArrSTr6DbtoJIyckTByqDDyWLreah79yUgLzdHtntMj+TGCRtzI2otG BLXKp5nU5S/aEoJGquKSEQcP0MT8Lbk0zngZju0zRs5yUqoACFXCsiQlE5Zu9C2/UTDKRgfKMCdY w2DXHlvW6z2M58VB0yuMR4apOJzQ1WcUyzLRPKfjkiEddxhShj2FIe2PRXM6QYdoxjGlY0AfPQaY 14RhhaCXScwzftDeGiFQ40/s7qk9k1Dx7Lk98xecmI9PEUXhuC/sBc/yGvHwkYN+ZmEhMiXE91pW G5gZOa4JhYcJuzp1TywLFZwwIvcbAxg49mdImvwV8FjhsuW26JzdP22jhNXalkj82H6ouYblOCdk iQ57ykjNy1I99XveXmoUgmwfSl60NEjDkPsZzaIPaQj0jUtAaBVr6/CEfkySQzKaNGfWIABxYXqD tPeWj77PjQNCibNpN9IkuPxIcFGhElzuEFz+Sm75kdyyXsS+4dn/QBoi8Y3leI+4kdFyVJ/y8Bt0 r74oKTdFRO4zzEyoQ3dG8GaRx5ElvU30JGQsJWOZRwjvqieDDUUkKBUng0diwE7EZNn44RzuOOLw vOBlJYbVn8ReLQhkfNTtt+O9gJDddt0TKIvhrxmreufU3D9aCIhmhkznQMiO9hhGAnAmvKh3zsTA H3FFJR0Q4SsmdYGx50ecJ1YOsdZj27cVw59KtbWY7H27RbXVDWmVt8RR17Mwk+ozY8jfftyNk3uq NweMsN5jUz4fttv9bBef19urC5Z0dptxvd/07bRwn0JKO5wIQ0ec2mxFL4HKw3bXW8VxVVXxuNlv llbhhRqo2+Jr3gcdeaSBlk7Go4IEb2BRP4fqLrrEaiS08lday7uzn639rO+pqH1HIGFPpPWkhc5L C+bpSHPMGqcjrRZ1B1pkdo2HtMSW8MeRpc2Kh6ytk9maY+tE5oG1jL+rr4pV03hpK4h9WASxXwAu AQMgTfABkIC/QFqgBeujuWYww1/LYyMXatsGeSnd8thQCvDB0zc+fIrUAngh3SjbbKe9BTCBjuUH nXCdFBP5jRqUTbWF72aujJr9tZxA6kQN5DahZk8tXaUIi4QoqXGiUSMVAcjnNasOK/Ap0pCALY3t WGFsmXiBJCufPRZc4xN/EFDj1yqvD9+gg/Elu6ZHcq1udRxHf0oJX7Do+zCsx80Wf0UtJVW3mg6/ xOtRt5rh5UJtlvFU35bRdRUvRwDhfmBL9uOc4SXXy70OlrMfx3nJg+U5P07mCsFh2DXvx5H0IVdf P7H5sKfBG/Hnpcr7YnU576HCo7jpBxZIjmdq+ajFny+TviMez7tH2s3AdhjsaXGOl1y399riLYvX gRG5XooWX7Zg/GSc6Z9ob7TNNIQUjwI60Bx45q7DVYI3BbWHDiRFOpD30IHcoAP5++FxQybUW3oZ Zc01atRIcP2bPUb7kRXtZw+4tkxx6fmKQazl/HvxgZIc9id8UnRQP5BG93NtrBinRuFNCFYqv2vX 9kVsAmWCAu9aOpRnhrBL1FnECJjzWYwwL/QdwaRgzaPGrdRcFjTrxPekcjv2gGF3BQYYdQeUi7g9 LBlgLI3oa7DQGDHazVrP51JMJKxpgBJkStJDA5m0mQBaw+lvFBUT2FJIAAgmHvw1gTFqv/HNmTae RYJHRuu2VpYSAwf21JkCCUe0CJOYDD61iY2ofb+yJg/92XMtg4sd2+bMBhIa2XO+jBntt8wh27Uh kDBrnLlh+lQ8sTEvDeHYX0OF9C8wz19/RVHw6+uDaQpuaEesz4/vfqX5uNXSfGW9sd/vbgzYGYG3 N/5YL7G21vI4oNJnZ5p2pvse1Uhs2FMQf777tgSFYifovl5Tn3CGR4uwGKHTfWte5B+YWfM0taS0 2jQCgyoW1EWrajQopV8s4onDQa29D1E0tA+tSD9UZvC6fmKAwwqdXJCiO+rpyjPTL8NteCmFYHiq fJHKa+QX62ca+CK/seLcWPI5qbtKDU9rbKkaPpK189ij39DpAvY4bscFTjLa8a/vvD9Y5xC6w1x+ zQ9GW55j7p6GPgbG081ze0RkLzWdtpnwnNbvXqr5eXpjpG+sU9sHNLaBimX0T79TR7+yL573tA7a eKKjZWJbuXaq2mqqk2bb6m5UvnRAj6sZfpjTPh7+m3o+Hv6TG0/TzOhf8nJ+v7Qjs3S+xvJYqmXR maBkWqm0cJlGjJ9yVeD91/UDWpuOHx6xJsL6KWZa0uIZ16vpcsqJqkGawkxHqSamisC/FvXOailP aCFbQVLzFFVSneofsUK46nFF5DwqZpCSzZaTty8S+Y/dU6Yb2FRm3OGe9oa9uivMmMgLhaxjCdBm 6DA/x0K2bObtlhVMcSoMuQAo6k5Nx4/MBj+IIcZKbcYNiokb2Rdu1IApjabliQQT+DAz7ZWyV5SK tyJxFB2EnJVqoXlcCO/ffWUvg2LIb9ev1FtgyWhYmpdG7lWerC8UpbwhzXldMBCeudeGTrGZrhaZ u9GeQYR3wswtXmttGlmj4RPac8BeTyKk0adaS35/2nM4sCg4B0hX9uZ3wgZJkw/7LsQcZk3ejrsl UxN/QcwYEKHMhOVYy2GDsBaRe0qayaR+EF7yYfXBDO/vyZTLb74Z8OPH4lwtjB+vv3LVsnvpXe0y Sc9mFCvoRNf3H1QF1Yt24a89RxlYvduIl2vUF9fM/3NNg/HX8qDjSMfM0CjCXmFzIZ6iW0g3NOYA LLxFIxo1LNYzuOC1r03zPLG7b+3u38wR9MIoBF91/DCSAu/nd6o0Ri3nu1A8dDIfNie5FcYKYHkS WzBt7Fohy5yqoLDRF3TKt6zwqQqMAn9RxOSE8jILfKF165mf3GirKRyUpXR8WiUwogTqbfCWDfSW h9YHFOdhVQzBJLlUvaTZf8KYzWwmMuaJi6NhL2yFtt2yDHzYrYa65J+2FXosVpdAdcVLHoa4i/jL q93V5xw2aYJicF4+oR5NExSRl8JELfMixshr7BHGqdjfNGhNBpp0cv5ilAxPkQkJJQVQx1+USEpB Ou9FHbRyxo3MVRwXcrNwSYXgJT2GsujnzWsfKvm9d6S1gUGKJEz4gh/TdHrltefxh05PKJKHPpDy 3inL025sTQEP/VNoXofF+pHSp95ep1VyKG9RQvfKbDhdPPLh2/U+OM6C6wn/6OtFJQyvNjJgYsK/ wjeXNduRayXE05+MptemK6zjnrba+S4Lh0vmN49YOY/DM9zo2Cy93qFoxsuTFQlWzubxvnMfKhiC ZvrhLXzyy85rOYDnGbVKj5DJpwmf2B3dinx/tpvn9sjePfLaBuc6meW11Uv+RcYm3Ng7Rs0eW0rl DTKPLrMw6QWklob++QYJ5deYLx28ll7tVUPQNlmNuu12+u6tkbHXv6u8UT++g4Nl4nOh+VGEzV57 vDFjY5vLmR+lkp/ffSTQ9uX8uLy9M6uPplzhJYyrj6Qc0Crq7tSyjaKlhbjxCFVqHk2r7kyar5mk xUkD1CnNMlgSjaUkJ+eEfJM2/5S/9d9JuUHplqF6HCqjGRBoqQm+4RxJ32gs79/yVOMJAYG4FF5i s+K5ouc8sPm1cntErtGpOXd6/uPfNVJfhA8WLzWxkipWquqrnlQ3aNRCkuO2FzODnQu1j+DsoR0O xGib9HxCwJA14aafbFvBbNOSace/vjSlwSCFdnP985L2kNSaoqBBGCxZtndqTPTRz67vqHHu/mo/ prDs2rRaqX2SbpM+s8c/ijSqkb7Cx+1F+6Y9t5S3P1i2Z3x6opGbE754UfXsfzD5/cZeNuoIGhmM qpefiRhK/M6e53LTTa1U9tdeceaR3ULA4uL3GQG7VFUyr70f2almqBv1k6rKnvimift7oaqk5qhZ 1xzv5ai8l1pjJoGFizqXZY7TJV3BFa0rSOwqbNPgmXnanRvmZvhrGgsB5TrpvqApLZcrtvcM58hh ZJ6bDFqGUCHhrItCHXstGXFXxghrovC/jYITdx0a8pVbJS+r31NqD03pc+4BhcXrlmplM4thWr+V VE6gVvMRsfDnxmwtW0Nw8k6beHEVjAFfGMj1HBsLrKMi+YtqQ6/QljjtgID8tWtLp+1IoWXISY3z lwrnr6U/f2L65Z/vSaw7Il03B6LoJ2JdVfsUoXxEtZ9bgqAty3b4NyesnKj1KVPApjO1rjoua31d 1OdlG1CfHzuECJKhHVMhHoL11iYDm+wGsaiDJSorTQ1KcWDSpAryD/WJWZ2dwfvCYwI+lLuyBQTL G2hs/q7QQlJNUjbQ1OgVPWR+LE+TSWfcu2hz05Xz5pzaSQUELcft4XzI7JSxwPpanLCUpsvliqme KfyY/iMPndb4VBnix5wqLCzTjZdabDbnPbDZ5mrSkOc7KQrkysHxuU6aIGG/G5lST741CdXM4Him ly6EhKGqqeMSEgraIXX8XQQJLSvtBxn7+2saJt9PAIS2Nmep5WEVa+dBdP9xZEFx2j3ovNR8eS9S k7yg/RlesnW/16Dd5AWNvBTWfVnQ7kkvqK2Bx3ijGDD5qBX+2rW5QVEUpGiQQya7sUyANmm6iAUI s2XoTFbSsVwWfQlyJAW1iUsA0Sb//wvYzT5gOS3dchpl/JRQgDL5XwRkYdQsJ93C0B95UF/Qt3dR c6QbDwW7AVAmtoxdDx1Gq/MF+2sPjJ6VErhrFpg8xpdtnmt8WemNL/IvU6IlwAznWN1mmVlB0XKu YWz2uXhARLDa+0j1dqUSJZLspLMzK9GBgCkFKOWonxklOuUKqPOr6TOPw6zOdHiGdNFEX5uQPbG7 p0FrBs9ik2PKpEnNwfcOsTJBIOmfKgrPjRA1wSMfn798+/KHG21wSFLc1doyvMOQy6pD76JmzPE2 tzTjhqV0h75b9XXVnddq1zfjOVvYbZhq2LGl9YQXA1hLpvyf/guVS8dY31dtseaeje7A1J++trLQ EyVYLMOuWu7IBlxvj86N8LI9cl7u0gYkfYyuM81W6mxG8/TOUrubhkREyW/6GLBKHtsT3DRxyoOw 2DVOraSILcX0qlGY2oFGIsa7fIW/pR0oKdu78EweK4XRNE1uKXiysD+WYtQKc8h71aRgqgoezFWF duZLVUHxYeYirZFDq87PLnV4FzZss8Zy++Wid73SOCd6uRu06P56veeMyyt3CNSqzS7FGDYqVwOo 6FwnRBgNTsPz131N9VkxSCHVTRXrLRpWPzQK2bHa/PXpAYrN0o3a6W9U/R3NJfKq8tmQkBunqlEW d0YvpMWTWTwDcqMMCCPvGgWEUWgI668nFf+eG0iiR5QmeP9lgxDBuYIYRY0bIW+kjBf7a48Dk/Eg G6et4Wf6un+WDywTxkuHc+ylc2g3SKNLwBwSmQ6cPgKJnDNhWRpZyoalqA7wPT5PasoVSIRz5aho cACixF+7fvfW/drUOInoFSrXMhDDHvz/BBDZw6OpzUgkTW2WRH52h/rNF4GyHjVxXuFH+zhtLVhi b0XAYo/8AI6Xfuc/PgGggamiaGbnKpbKwqWolFODOLMTWajrf2oUf1dUyiFdil0uZWFeM1VcnZy3 dD1lqoYqp2u6drEb9c0wnc0Dy1RoIps0Sr3ZnruuoIV54HrAJ0QXbtlT8WRETT1W/LnCsef+nffo rmVqoRQFDmsPFurcfoIsEtoTOMsqtKr6p6LguyHe6xg5qYWOPWo0L7PIj7EQq12oLhNWi7zkwdLC tY8FQAFjVADlG4NmCBxDboNdtDa5bBhso3bLY1jG8qQh9DJJuLDEbc9WqQemgI9LvHSnLOsaX2PV MPlm/Nxsu8GTtNedzjuVW9eKgL+au2s0rtYzPFqgNOrPzAQ7A0/s7mnorxqE0m2fG2/2Hf926JUs IrDEsluGJwltGCP23K69VI5QPDexLXzISk8LL2urSa8No1H12hPzVnL477ccuTxpqxO9NoC4sJfG 1W6F07u95V5LNIwc/nlUs2E/welGkjPQ8hcpOaszIBlVa26qL9HPAkU8oWkwkapublTdKe1P3Bws lAl0NpaP8DHkl34BqHInE8C7Tom2JE1ikOgJpnHjHCGvy9rv0r426uAxVlYrgqiYJKnabwp77mkC jE1b13tGBFNelvvWIzoyCOMLAmmyBMwcAN38QH1SubQwj2zdLz2EJrDMaaHhSw8v+zF6eewNBqXk rYI03nmU20uCPxMdD8q4MUjG32VtWPbBRa49doViL7BpvVVtOHWifQSgXuTa0wnIt8+PTLkSoDa0 7A1BxwgtpL9lm03AsTXIu7cWYmiN9F3dZo7IY5OLoDU5eptr+94f6XRYDMv099CSN96wxsmPjqst x1v7rjF245z7ox+s0aNYae7GSvarvWR/fULGnpgvUmvNl8nJhX2dU71ZEo7vcNI2lZwc9XUq5kpd vWjg1XFmUVsdUbdwHq0aN1VhVqUA/fUmNoc1sDtt3/0aNUEchf0QB0X2trW2vSPNTuvJiiMbxaZp YXDPkygULxdNyxlp3x7AReLnn/FAy1rzcFnblzoCdJ3s9IndAhXowK7jwyrW9yJEu7DtL5TDbKcB ervqNKiFYXXel60mPcT2baWO5YYnqtwa0LP/IC//VbV769ilHdgjkJiy7rhEM/sET/sYWu81ZZEH RhAAiRIK1So4xMMRQXDP1LeURht3CSHwCnvU6Ad3on5eh4cGH7gVeuEHVSc61Ip+XvADVPFPErQf Dmzyhx58IHzCi04Nu1qy4zw7A5HnQMCcEgwkiNq/stKTSJ+CnsMG6aF6J5VeqbMJyLt/6MnyC6BU CT1nBGDClfa+iqssMAuq4jfejrOrGbw1vW38DX8htoI3iiAq7RdayuJ94x2fdAKexxveE7FFhag8 447G1HgGV7Y24+LuqWX5sz17bs+cijPlcoMRFBeCtPnzfEid8YpDIIJknJxd7NilQptUdHVTnBOL 1VJEe6Gm69isa2Av08RLHrsv1XQ/mP0yMGHXNCa1GIGFISPZjpu//WoZqHXdShTIGGGQmZovlvbG S4u6QwX2rDuK1X61V3d29XY0d/8O8G6Rm03znU1+fPNc8ZRsDrVngeHcBlfPv5mYxC9jzCX7cW9X Oy1XHmQNu37gjL4VG1+y1SAjWlI6tpsiBYMVUt6snodT1iIB7Zxxkhrv8qZmaw8HaLEIepvvjdJX 37xvg+0+VwBNo3M8AtsTE2zEsZbECLLO46eZtDfBi7qXld/iQ+vY3klJ43qr7hBfbZQ2Jfdm9SMb e/w79br6bkF1qW3bkZjgsRk4AJ7K6UIRlbJKKW9UaKKkymK32iZ7kqd6C/Z+DNWsdm412B85BLMf aSoVio1/VfjjtDcc/MHXh54jpzxfM7JtWK/a2jL/Ne55VKSw3uoAUeinXDDCLNmWWstpSMN+Nx6g FalzsjwbHuu4ishXTHlFSVXbQOxtTHtDGrsfHXT+lKc1nLxhrcjseaBOnpgSeRCtmMbq/sCraKU0 KxG0IvVYO5mHmPIqtG63+m1B06onIB+sH9R51dYP6nvJD77akd1ZU55+w1FfbPHEweGEJoSbHacO 2eWIBdRLZOFIsPBiojDSt+ggRIzpm+nuFb0R8Y33CEXX4x0Q9ZgW+msiqM7L5mZEklg6vZhvhtTI VqRAlXnJwjfSnWpJ/fu8OkEgcyPsCUxEvpqfirQzjUWuWxuLSsuCFRtwRrgLET0p3KKVhdt4pVaO +CfNdvWR6KAw6GqI6lbb8bQ9Fkz7xemUQMYO4Vic8kjq1E0V1745DINtJxSvM0X1lh1bV1uoz24M Rtx+ZvDwn+TDxDVlgDZc/IJxsyRtW2JXAivhIbAj/D7XIrBwJVQTLl4J4IYrYaJwQeBYHgcsZNwH TJnxkdZp231HQV78pFkJznVCY+kEif+Rx8x3Rp3F/UYdsBhLq62tQ4HSxVeP2SaOWksJY8zylddQ epIuIrWUlVUVgcgQ63IXicSs//Knsga1wZ9E245FQ6eFlSJy47MxwX4VzgzFRFyIKFx0pDdRGjpo zURH7sBwvif6XMLmP9YGxDmkWnpCe1MVBp3sGugkZBTSQdEMgv4hDLspVxaIr/7l5pdXNz9/+PXl m9Uvrylb3PeFj7EMpqdIAz0fE1By9tXTn9rmybvyINZlSAaLG4DAPJKhOQ+HTmZztQjJqJIcyehs K0cfhmTQfBcimUBtgmTYGqwNOjTQvgDJyJhr0RVzBhnJSHdO06SjWA8NwiiRzACuD1tXRiQTsk3J XYFkKBCbtmfcQgWGlIxtsCTsjl8jmW4D4i3eCnkqOgWSwSVcIRlg0Y4zxiokE9NKZR/Tshrno2ya 2BbYZqfhDpivVPZb+q+iGUokQ9u3YQ/VhGRG8BTS3GSD4ynQyigippVIJqZlU+LUEYyIUCIPpcGM vJZGyEtUGEcvNbQSmvL6ugTJSHYNVWxZUsp/iFp1T+1kHOJ5SBFMgQMk0KGM+lFAQo5nwjHrIKOA pHXEKb41oaFEjMMoClCT7hzUpPsMapqUFhBLJGg3OtRdOMyRTeLG4U3iNeGbMZbFMFS8uwLfAOj6 npWuJb65qAkLMYqNWuKbKN5LRB7kl7CM8TBW+MZ5lVLIImj8kzbFNwjwHr1a4RtOU9lObdRieEOT 78J44icd6pRRAhbqYcMbZ/ye4M1i6p8NvGHwsB1Rt3cHbzQEqqONtDjtvtCNAGnY8zmAp3g9hOgb DljYVtxUTEzleHYKcRnmuTfvjcb+tfeGc22u9N6MIdbevDfawy7dX4B55L3hwJ61kAwjoE6nqsix VKegyjvOIdUQeAsW2XNgi5Ioyk7OHH9Ro+CjFy/323DUkvw2GjW63yakrFIKfhvwJtimKDApAf/E t5RHdNJb5/w2mPEa6oSEUumHhKjfm62GyezaWWh8VLrsWwVy2FFKHbHEOOxu3odTvBzjNFsqTKe5 FoPqmFJinJhWYpyYFs1JwymlRj2mrLbOQglxIqelHYrlieN/Sqgqyfgm3F4DbhpOcUKgAq7RZQFp dBvQzHbPGH7D2i67OxgaoirD/Y574YuIZvZEYlZoZk+YbnbRpDtHM+lecMRcNE1KCwAmEgw38WsR zWwjN3odF07iNRFTMQKQ0cUVGEYrP7ZUUWw06t5l6VwLoQdnW6iAyjynzrJfsJJh3l8kw8Zd5qQh GFb8HiMWZjPCJqTJI0Ms/7Dn7OLoGo/e5AhZwrTZOY8MwLILA4djyDKZoGrwOXyER8adFO6RYbOT j/TIZMZ14h1iITcAP3fjkXHqtwOiTwlZtpd4ZBCdHUPuhFiYrT4QbHW9QyYEaFbL9u7VIXMbZDlm Zwwnh51FL4h0OL/Bwn34+1bRAvze/BdeIv3mnby4i/t6KU+I+1CavWDZQxAIiTbNZmke7I8TCmfT rIOpOeFg4lhM9vGSi6konFxMq+Bi+urZzZuXH17//eabd2/e/fL6p5sPv7x+ZbQiogt+WEd62ZXG hNZG27hkV9pMVdH7p6HtCq6gcPaX+UWKhBOWlBCIxa9XnpU+xuGFRKadLdVqS4EFvK2YOF6zv/ak ymZfUg3nevtXVFqYtFsGMu/NscZUI8gnzQ9GhIk1WDY/mLxqCWAxnbbT+VKOOJ1S1Oi3zkho5nLD fElEikIEltSkJJDBwPENvXxvCWP2iqE4lOBU2SbEokuNKJjFk4M7wkkzOIQfylemUEJSNF0Yy4zJ a3fY0OKtkKd8izwnJgcBejg7B+qgnByMaaWZjmkRba62GNLtTiepun8BWthuzZmWLjU2AT/olJsS brIAdrcbOe8hudSqeUHc1CXI5FmJL7mNmGS1jZRySvxexpaZr4wXMvcRW5LiNZHhZUxJCHMSUsMk gg0JQ++yKfHkPtvjB3OEqcsCYepWGLLZo1YywtwPnQFGR5hsfS6Eaa/iL8P2CGGyKjfOIx5oguDj Eo5t0p1DzHSfIeYqpQXUmCjaXfzeqybcJ34cYyZuI8ZcqSABY+riDMYsnPHVPCCTYxv1v4wyaQWX oXNtlaV2rq0y1oztd06OoTWR48xDJcfOa8lX5N9RZ3C82jygBs8s0Dryk50CnWGG+RzoZC/8YauO cSvoVFTUItBpm9OEGSvMRfhlGrAGnSyf/EjQeYrxuwGdi6l/StB50TQgGi1MlSXU+dHTgJwPwRHd THQE0XlI04AFZw9vGvDASLRyiTUKoQgplwOWIqCpG3ZQ8inGC1ximgnrGOVamAyHZfTyiTVHSWhr You28tIrHEG5lERhpJA09RreVFpNDGxxuVesw3cBGOGLMWArpDQpBTCiE0HIk8tMirxiVZ6aTgFY pnOA+FmI/6kBS0wrFX1Mi/AEsMD4DRRfzAEyWwqCqQDLKNYE7QrAQoAMdnqPKzMCFuKqOK2DeY9k bGIKdjAZpZRW4JeUliBLpJ7nABMPGcTAvfNaGiAvEV/EaoZYKS91MQcY6yGBmAXRTAnEsGVKnP7T 7ikFiAmbqWjS7wA8TuFLB5oxOL0cwxDHkPALW6yH8Kcm4Ze237CFoNy34cpxS7gW5jC3mD0LiCRS MJ+XaAMUDbvE7+o9/GGRqURE7AaooovLocrI3o7ES9dQZUmLNAR3mLwmqUgp5ZRezHVOgqFlEpwg d5aKAqokXgtJKdLClF6GKmNPyTJO0RQs62MP1wKVkWN8tgcmxz83oHKS8TsBKsupf0qgso/oL+LB M/FKkpudQVyPV8I6Muvd7qZzwcGjIut1wh/F4BXQjDlgvoaY0d8tXukEO3FGb8LOWadYOaV3iiyj DM3ETMgKjo0nvYClMNjiSnw/xSZe3L37uxby4BkyZ9Dbm9+IPku3pePppTvmtGZKL9gz8zGtg1fJ SDwN11q+l8+kP1Go3HQYJwX3Zow54x+bToQyULFtQCiGMWO+sXdvibYnzdh5Zo4vraEg7uyJ3X1L Ibn7N0vUKUfkdxeZEUl+suwHWxCgNrLzlY5SI7pd5ZEWu8V7aKFu0REw6z1UqElfb9mD1/3EXHXZ 5Drmm4aiuYi+YxGRNStrEziSiWsmBlJKsVkBz/NmBdx4PB8NTW4qhyRW5hfva43lH1kHkx7jdeW6 DAO01+yDlm7kqHheZtTo5MKCb64tvaRjizSP6ZAzt9BtYoZ1apk8dONifWdJRapXBPepCUrhlQ0b +ljBkaDklS09r3DOo3oR3BJR0o78OgavYPoOZInwsANHT19cBT9r+xwKWnY0W0vLwlltqOXPvYZ+ /tk6kHUmy+jVZkmlY5/asUpijf5tjTl2mkU5qF6sJJfrDC0uh2FbXM7FGR6TIhFbtmTqNhkDSuMS usXVP6fKIluuXo0rQqbRU5Oa8zp+q9mN5sU/rr59QfjrJSJV8HiLSC2Y3BgZnjEYKe3ujPKem9ww sbC/tjQ4tUY4HoE760i+dvtHL3ha60+Gf7KO6er9uSl0y6eFWOTwXSPDdViURVqqQSSOW5PVdy6m dkeW22RRkNygR68Yk+3lvco7zc1LY+it9k6AH7fBLgm2rYLl+I9HoRf+Ly+vl/4/HodUy+L2na0y 11aEyVK/TzyL0/bEc+RpHGIwNbq/2CWyJb7S3SvtyIGR8f7iORzCm0dCyxX8OTDPIJd7lQLBfqOT RAFfrFJieMqAn2EiA5VuS8RQfFHZqhfJdJE/RCqZomjiZStvhi0CmqbgDxkZMZMnVoBSek3gpLfe NMdvnZjAYfFOqEcVvPBFeFoeTTYpX/KHjAjSjj0N8mhy1Lq9iTsEDysxMBrExxebseXUpO4AYk/u EI7xY68YlLqWq4jEGFNKd0hMy+4QaPmb2R0SqeeUyEPhDoms5jEuJfTyJG9IKnMae6eUS7whatjo pdCaxHxd+EPwWnikUMvauewRUXfB4RBihlqGR0EccZu0CtWvAobaAR1stHUVvSG6Lr0hujdviFOw 2RrRDu/g/QjfdE9I4ia5QgKnwRcSro6cIczW9Ps92bUwNC6iKOdtRiLsNkxGlPM2x+2BZFp74Gtw 71Sq/bn2yKITJTpLb5Ly7LuL1JNYkmdGep3TLCYc6m5pNMQkulmyuGXFQvaG0JCKbr7aGaJYOCJG HKzliBsNE2zhTQn3H86sDQp1nvG7cYYspl7WDsYxzFGl9Vfp4n4Wb13kDEFntTrVoJi12Q1aXH21 MwTR2/6O4c0L0Kcv3hoLzh7erE07AOUKdLKjT183Z7PTdLvZcKaCVvH2UnzSHlCnrADFuoepN5Rm TCKk0pJAANhNWdmt4IPsp5Lwq41Ky7mmtCJCuSDE5KBJrNVOxicWrkygePLhh8mcWGSYOYQpnPSW MpVvkeMEPsHAM97rCAop8UlMKzV8TIswAwjBytCB7ZdjCrQwSGHf+5RGILVwHwzEXKTg0R6ZWUjw ZCBadpBnMdoYwrg9pYAnKS3DE2h5vgRGEvWYAq3AQQlOIp+l2YmlydYwljhaw1xXl6CTNFcDfjD4 SyxIuC7RiZ4ZBhkUFRGXm6u7JHSCQFCPlmskjqZEJyDSTpEn0nG6iuhE1yU60b2hk0jB76BtczXw xjcjOoncZHQiTg2d6OoInWAEjtCJVgvE5iAwSgG+QeBy2kUNkifPkvAWUzUpbZHwFoAl8lBO1URe S0HJaRN8MrBIgzWMLCovVpcLn/RTKxNjmW8LK1EQ2ee4+sr5PsJVdwNPrFJuJ/65oBPJjeB6DU5Y /DoVm6UzNQPbqbCE/wGGlJScPUBwMhIkf9fghGMHu6Yw1YqlXR4Bq4kOBpQRY/zU9JMUDII2mtFa oAKc9CzrDmGj8UVlq0m9aS7ynsiMURR5TxLMiClNSgEWcS6J8kR0phR5UvJbIU9Fp0Ank2gSLd7q WTNVopOUVij4lFagDBDUdldEkwxCZzutSCywiHaqUd8r8QmbYxM4W4S/DtoE6lAEk3gClCI2YH+l kAdCCUDEpGTmhkg5pjTalSl8vzCQic/C6Axsv6LSFMRjzUQOwtK3UFfXoZOx21HLQhDCEjsKkuNA dO+4g8CajE7oL9SBPSHWN7wj3wmj9Ak6YZFZoM2z4G8xBKHrEp3o3vBIpOB30I7oRN+M6ETBOuIm oxNxarR1dTk6GVhUdtgEgYuNBMh0wVnUIBmdJKEs0ElKuwvhjbyWfOW0KTrR4n85VKfoZGplloIT VmnhS0zLZSrvycz8yyLviaZOPcI1+hPufuubyPjtCOKarW+WU/9s8Alqa9NxIFYBUNi35iO2vhkU +Dgy+YpRYalbGGXf5+Lw5d6TkrMHCFC0jL0AKHuMTnAFXDy9s9+l6Flp+ybdXxrxCtRkcTox+YRY yLgS8TpNQlsz5B8JDFhtccTtuhCpqPMwhh4ZSK8qX00Nb8flIGXU6uUVVjXUFHM36RZyFFbTYUVx SVFOy68MOT925pTbZFD9aRV74TZJaaVuj/kyMAEf7ZjkSiCkGdg7EOtZAxMautMouQQmzI5xqrPW jwOxtCUgceM4wFHB2XESU0poEtNKbBLTspWL1GMKhsx5KMFJ5LW0ObFEBfLx2sngJNbDdeBk22dw ousSnOjeIYhmypPrhL6SwAmbS4Z3BE52rButXSc7HB7mOtFVdJ3ougQnujc4Ein4XXCD6Lpp9c0I TrbOTQYn4jQCn6vAyXZg8UEQuthI7E7owrOoQQpwkhskCg8Y1pttkQBn10nioUTWkdeSr5w2BSeI 416R8yU4IQx9d7ganWjam0AcNzGfETpxxu8JnSym/inRyWEKAs8EukrFDLhQ7hCdoAl3GnU/PHRS cPYA0YmthY0LiFnweC06ObDK0Kc/2nYzQMnvL0UnzIWxPy7wBOduOJUR5qZpUtiCJYqPxRVgZ0ko DQWCaY2vhmxTctfgk5YlZCOrRR2fFLfCJy27BvI0F5jncpZY/pAhv34Gn4QFF0yplPgkppXqPaZl fKJ9RNhsvMAn7G67EVIr1Tvh5UwA1fiEwIC+w0pmfEKIAeP1Ep/ElBKfxLQSn8S0bOgi9ZjSDJGH Ep9EXkuzE0uU8UksdcYnMeU6fLIbNIFmzhNdl/hE94ZPtA484xN6S8IneyKk9I7wyV4zpMW+ew2e 3IhPdBXxia5LfKJ7QySRgt9BOzpP9M2ITyI3GZ+IU8MnurrCeaJVbNrRtFgwjGo24VnUIAU+yQ2S 8UlMWyTABT6JPJQCHHkt+cppU3zCjA57RdX45GM21sM5y8oCYf7jBcMP23nijN8TPFlM/bOBJ0jO fofyvDvnCU5PxSI8PHSSGXuA4GSPF6twnRyudp0cNEqy2AyFf8RbjPdFUzttx1bAwhdEtYZNbZlN sSTWEXoS5r7TzjYKjcA1wgYtijVk/Z/5qKt8E2oBmTQXHX2gRYgADXeclHeub5tYVpgY95rUscx6 nF89CUpWsL/W/HjGJNhwSyo1uidlREJA83ZgCiCnEKEGDFAQZkxrIMxc+STUhBAOnDTFwmCiM9nv BL2bjUpMyYgEWp6rRCQxLeKP1RCpFynOQ0YkzRB5LQ1NLFFGJF7oCEhSXRV4hMDPvMPl2b1N2j3r 9WIgrK5LPMI9S3wD0mA8nvEIHYT6tCcH97Eo10GTogUeIQUvh/lLuApLfLWVhlJLPKJ7QyCRgt9B 2/AIWCfsCec4xbghXBYzL7ZCKQyPqAyL8EjYjBu8p9NEqHqaUT5JHGW+ffN1rZHEFHmLEdQfJ7nl Hr+RzVJAnPOjGNiBMCXFn5V+ko/CIdpuL2D7zw2HOOP3hEMWU/9scAjKqtXEZoFDCIH9mCgTpvi3 Ogjh4QGRgrMHiEQOwXQmN0nLcgBM6cVTOLynmQ1gQ8to3e4uBSFyhuhcN7aGB3L4Lr6e1qQ0OUMI oJZx1WpJ38cXewsKwpLGV5VtSu4KGEJxhNRawRwvXr43F4lcJ1584BD7MuX8wUOS81OtJ6dwCKHk aK9qZc4Q00o8EtMi1MDwM2PJVFYBPohJU3x5xiOrnvmtXoNhkfIDmzj+G8yntfRxBodt6Fn6xPAg 2pUmpWQ8Ai3PVeCRlJZsW6IeU6DlPGQ8whEUxmppbWJ5MhyJZY54BEjktVUAEiZulwIS9phzQNIQ D6R44BxdonuHHUDrDEjoJxGQcOKcOVUAJN2GnWpKQNJ0G9waAZCEK3eQhOsCkIT7ADUSBb8Lzg5d wxvf1DtapSO0K24yIBGnBkh0tQiQVLGvUKO1g8jFNrqsPQr/SG6PKDrIpbfRIukt/CPH0ps4LcUk cn+ESiSLIfD7zmAJO6ns85rXz2j2xhm/J1iymPrnAks4AI7loWHiz7cpwRP/UbCEhaTTvWBP7t/x +x6rVHL28GBJZ2a0gCU6DQ9leOHmrzo7LNhtwh8x0rq5FJWwYGNPvCVgQ/os7OrkSU1KYokLWwkD R5ioYGmxbaOGF0IRbmWmKakASDgS8oIlOcxCB3wRjnhkLFneoh7lDmq81NyG/WA5RUDv6Gnx7kks goEHfukozZ/yjmUprdDmKS1DCsajnF+XV+EQ6Mv6mrDFUwE8wpE01WxNL77322IZTg+Q27d4VZJB iSnlfq8xTYWLC0dTWrJqiXqRosOOtoGUD8Yjp4FUSvPyZOKxbiIWSbUFLYUHLTsBUsMUxwjE0ZbX GYuAJHgWsAjrTM0L4XfsiOHOEU4tU8taeqv59NI5AlLWdA9RtOEqYhGlllhE94Y+IgW/C44Ou6ZD hnfAJYmbhEUCpwGLhKtFWATnCAAiVbRaWyKXvSOXNUgGI0ksC/9ISlskvhmMJB5KLE2Ie+BVMjfl /xiN7EBZikW7KzSCcmFwFD3unw8Ycb7vB4ssJv7ZQBHEhoM+785B0muKQbsuPDgHScnZA0QiXYiB yEhEO7xfg0S0Dbw8CKy7kC7g5lIkwonI7h/B16IAEbwtnsR+FpYEEtGewHKOKLLQVgcDTsw5kjLF 99gHIb4XY1s5Nqre9eiUc591k0IiPUtEQ7nKW2ENpmQaK6hMaoAgnpnbOvMJr8iq3zHZEhxBBRKJ aaUqj2kZiWhvSvZvLVAHxlH7t5bOblwizF4yBBat6BYBR2w2u2LFTY+W16ggIxFLqICI55FN8A0s 4mvZSETKRYp9v8IhzqcqLZmXWJpMPJY44xBPuRKH6JDdiEN0XeIQ3TvCAP4knwiBOX3CIfEkdPlE OrV9hUM6PBmGQ3QVcYiuSxyie0MbkYLfBf+GX/NN84mAaZybjEPEqeEQXV2BQwD5061b+4sapMAh sYlKHBLTFglvgUMiDyUOibxWguL8H+MQyZK2Kr4zHLJl7zOQvRuUzwiIOOP3hEQWU/9soAgzoBwU f4crbtgtaM35KL8bFqntWfQTp+MYJ+yc37yVTede/KdtwqcjuS84KufezmPk7Gg5RyJEUQ+/BKKo H+jsakclQhXsZBHvLgskYb1NZ0d3RmAB7WkS6hvFzeYPOFUySOm0sFEx8v4m6GjmzYhSlp+SQ3RM ACIOUzhjMUzYGGxhgkaLIIvStkSIZljD80n+Hxu5oNKyxIwJCOsjLLZag9PHtFLbx7QIOJqekIZW G2jFFE4HYjfQQdtKFmmEbjHLU3tNAG/siZFjXBttt8fOcDnGlSNOPaWcwYlpJVqJaRF0QMupxxRo OQ/FDE7itbRCsUQRrlBGr50MV2LKhW4TokUY/HaIRoIrus5wxZ4ZXNEmfRmu0E0SXMElhIB5LkbU NVxh8irAFbBEcLUYpNB1CVd0b6BEw08o2OZqHbQDxGHaRl3T4QrXzk2GK+LcaOvqCK7curmahhGD 4vlKt0kUnpkGAZxEcBqrf65BjoV6RoALcBKb+7wAR14rvox/mmIS49qzPxv4ro5xDWtwrt1fjdXo 7C00xG07K7zyoPdXO8n4nWxgspz6Z4NXEJ3dHu1ZBJd83ArhnpiIVmrn4flOCs4eoO9EwWQZmOAN kN1HH146i0NQQqBzYD4AItf4TjT1w+iHEznDQhpATp2CCmpxSmDrGOhr/bCtJ2nZu4QtOvOLylaT ipM4bNO4xHUiuMXBB7ZUusU17CWrU/DjMH8ellNbgam1A5s9CamEV5TBXqFaPeWkGwWUhUKt1t/0 Ma1U7Z5WqHahJmawChxCMBojYk1AZHUP/mTBR41NYJ/dcg/Qos21Phhjy0wa44hsXmJKiU1iWolN PK2YL3DqhYsk8lBik8hraXK8RIUpjDWRTWFMuQSbqF0Nm3BKX8Imui6xie4NdShuJ2MTekrCJgxM EjYJ6LRypWinAvtO2LPA8YOuS2yie8MmTsGxCbQTNtE39Y5wSuQmYxNxathEV1dgEyKm9uqwJTb5 +AbJwhMb6U4E2HktBcX5n8Emajnpiakr5WpoglICR+OaPI57fdjQ5BTjdwNNFlP/bKAJaovIr2pa 5yOhCQsBNN57eMgkM/YAgUnY/hnNJL+HvAPDRR4T1bZ5TAaf1Gm78YAr4ZpZHYYkbKTBwD5sYUpT QtuT2OMT4EkSWpq1aIT5YTxRPuy9FSbw/Uy+MteEVsQmFwSYtHjyBTO02aawW33PbvNd2PbFCgtn 3COCMb/uy/fPRJmwupltVjkxLqt0S4JoARpCrgJrEI9LbRXrb1gwAN4nxqFAJDo9rtPAWKR8YkdO p81+U6y/6bR8YsNIIXEQU8qpnZgGrTR8TmnJN5KoFynGQzW547wGWjF2IJYoUScaVVXD5whq10YU nnDl1A4iQzs6ZuA645Gm0zPDIzrNKOMROkjCI1pYFn0lW82GVnhki4dDtJtOV3FqR9clHtG9IY1I we5EW+8Ig+ibhkfEl3GT8Yg4NTyiqyM8MrfVaxViojMcDAOnFoqSw1eLNJevaWsUEzvePMhbXH8T W+wiycWVZZJLaQopNTYLliLnR04SSaFtJM7cvo6hIeL9Y9bfyEEVjmmbwSEPeh1wZPwIQN0NDvFq uZ3654JD5GvnCHMh2BTo+nE4ROqPlXUPEIiUnBVI5P8DpaUpgQplbmRzdHJlYW0KZW5kb2JqCjUg MCBvYmoKMTY0ODkKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAv UmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQo+ PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VD IC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCj4+IC9Gb250IDw8IC9UVDMuMSAx MSAwIFIgL1RUMi4wIDkgMCBSIC9UVDEuMCA4IDAgUiAvVFQ0LjAgMTIgMCBSID4+IC9YT2JqZWN0 Cjw8IC9JbTEgMTMgMCBSID4+ID4+CmVuZG9iagoxMyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDEyIC9IZWlnaHQgOSAvSW50ZXJw b2xhdGUKdHJ1ZSAvQ29sb3JTcGFjZSAxNSAwIFIgL0ludGVudCAvUmVsYXRpdmVDb2xvcmltZXRy aWMgL1NNYXNrIDE2IDAgUiAvQml0c1BlckNvbXBvbmVudAo4IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Afv/n1KgUPKSoBGqVa+Q1QC1oIkAZTVqEWqACrQaXpn1vUHWterUd616qBqI AsuJb5znvrWb/ka/7TVQOxABFcw48hWuy7DztcOst64L3sJFsDIg5mCVIkYQAEyTIikKZW5kc3Ry ZWFtCmVuZG9iagoxNCAwIG9iago5NgplbmRvYmoKMTYgMCBvYmoKPDwgL0xlbmd0aCAxNyAwIFIg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxMiAvSGVpZ2h0IDkgL0NvbG9y U3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQZXJDb21wb25lbnQgOCAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFVjMENADAIAtmim7MuFWJr5HVcCECH4kNI AqgYc6GNfdB1h+N5/j6H/VN8AbxeO+sKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iago1MAplbmRv YmoKMTggMCBvYmoKPDwgL0xlbmd0aCAxOSAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0Ig L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VBTXF8ffzGwvtF2WImXpvbcFpC69 SJUmCsvuAktZ1mUXsDdEBSKKiAhWJChiwGgoEiuiWAgIFuwBCSJKDEYRFZXMxhz19zsn+f1O3h93 PvN995535977zhkAKAEhAmEOrABAtlAijvT3ZsbFJzDxvQAGRIADNgBwuLmi0Ci/aICuQF82Mxd1 kvFfCwLg9S2AWgCuWwSEM5l/6f/vQ5ErEksAgMLRADseP5eLciHKWfkSkUyfRJmekiljGCNjMZog yqoyTvvE5n/6fGJPGfOyhTzUR5aziJfNk3EXyhvzpHyUkRCUi/IE/HyUb6CsnyXNFqD8BmV6Np+T CwCGItMlfG46ytYoU8TRkWyU5wJAoKR9xSlfsYRfgOYJADtHtEQsSEuXMI25JkwbZ2cWM4Cfn8WX SCzCOdxMjpjHZOdkizjCJQB8+mZZFFCS1ZaJFtnRxtnR0cLWEi3/5/WPm5+9/hlkvf3k8TLiz55B jJ4v2pfYL1pOLQCsKbQ2W75oKTsBaFsPgOrdL5r+PgDkCwFo7fvqexiyeUmXSEQuVlb5+fmWAj7X UlbQz+t/Onz2/Hv46jxL2Xmfa8f04adypFkSpqyo3JysHKmYmSvicPlMi/8e4n8d+FVaX+VhHslP 5Yv5QvSoGHTKBMI0tN1CnkAiyBEyBcK/6/C/DPsqBxl+mmsUaHUfAT3JEij00QHyaw/A0MgASdyD 7kCf+xZCjAGymxerPfZp7lFG9/+0/2HgMvQVzhWkMWUyOzKayZWK82SM3gmZwQISkAd0oAa0gB4w BhbAFjgBV+AJfEEQCAPRIB4sAlyQDrKBGOSD5WANKAIlYAvYDqrBXlAHGkATOAbawElwDlwEV8E1 cBPcA0NgFDwDk+A1mIEgCA9RIRqkBmlDBpAZZAuxIHfIFwqBIqF4KBlKg4SQFFoOrYNKoHKoGtoP NUDfQyegc9BlqB+6Aw1D49Dv0DsYgSkwHdaEDWErmAV7wcFwNLwQToMXw0vhQngzXAXXwkfgVvgc fBW+CQ/Bz+ApBCBkhIHoIBYIC2EjYUgCkoqIkZVIMVKJ1CJNSAfSjVxHhpAJ5C0Gh6FhmBgLjCsm ADMfw8UsxqzElGKqMYcwrZguzHXMMGYS8xFLxWpgzbAu2EBsHDYNm48twlZi67Et2AvYm9hR7Gsc DsfAGeGccAG4eFwGbhmuFLcb14w7i+vHjeCm8Hi8Gt4M74YPw3PwEnwRfif+CP4MfgA/in9DIBO0 CbYEP0ICQUhYS6gkHCacJgwQxggzRAWiAdGFGEbkEZcQy4h1xA5iH3GUOENSJBmR3EjRpAzSGlIV qYl0gXSf9JJMJuuSnckRZAF5NbmKfJR8iTxMfktRophS2JREipSymXKQcpZyh/KSSqUaUj2pCVQJ dTO1gXqe+pD6Ro4mZykXKMeTWyVXI9cqNyD3XJ4obyDvJb9Ifql8pfxx+T75CQWigqECW4GjsFKh RuGEwqDClCJN0UYxTDFbsVTxsOJlxSdKeCVDJV8lnlKh0gGl80ojNISmR2PTuLR1tDraBdooHUc3 ogfSM+gl9O/ovfRJZSVle+UY5QLlGuVTykMMhGHICGRkMcoYxxi3GO9UNFW8VPgqm1SaVAZUplXn qHqq8lWLVZtVb6q+U2Oq+aplqm1Va1N7oI5RN1WPUM9X36N+QX1iDn2O6xzunOI5x+bc1YA1TDUi NZZpHNDo0ZjS1NL01xRp7tQ8rzmhxdDy1MrQqtA6rTWuTdN21xZoV2if0X7KVGZ6MbOYVcwu5qSO hk6AjlRnv06vzoyuke583bW6zboP9Eh6LL1UvQq9Tr1JfW39UP3l+o36dw2IBiyDdIMdBt0G04ZG hrGGGwzbDJ8YqRoFGi01ajS6b0w19jBebFxrfMMEZ8IyyTTZbXLNFDZ1ME03rTHtM4PNHM0EZrvN +s2x5s7mQvNa80ELioWXRZ5Fo8WwJcMyxHKtZZvlcyt9qwSrrVbdVh+tHayzrOus79ko2QTZrLXp sPnd1tSWa1tje8OOaudnt8qu3e6FvZk9336P/W0HmkOowwaHTocPjk6OYscmx3Enfadkp11Ogyw6 K5xVyrrkjHX2dl7lfNL5rYuji8TlmMtvrhauma6HXZ/MNZrLn1s3d8RN143jtt9tyJ3pnuy+z33I Q8eD41Hr8chTz5PnWe855mXileF1xOu5t7W32LvFe5rtwl7BPuuD+Pj7FPv0+ir5zvet9n3op+uX 5tfoN+nv4L/M/2wANiA4YGvAYKBmIDewIXAyyCloRVBXMCU4Krg6+FGIaYg4pCMUDg0K3RZ6f57B POG8tjAQFhi2LexBuFH44vAfI3AR4RE1EY8jbSKXR3ZH0aKSog5HvY72ji6LvjffeL50fmeMfExi TEPMdKxPbHnsUJxV3Iq4q/Hq8YL49gR8QkxCfcLUAt8F2xeMJjokFiXeWmi0sGDh5UXqi7IWnUqS T+IkHU/GJscmH05+zwnj1HKmUgJTdqVMctncHdxnPE9eBW+c78Yv54+luqWWpz5Jc0vbljae7pFe mT4hYAuqBS8yAjL2ZkxnhmUezJzNis1qziZkJ2efECoJM4VdOVo5BTn9IjNRkWhoscvi7YsnxcHi +lwod2Fuu4SO/kz1SI2l66XDee55NXlv8mPyjxcoFggLepaYLtm0ZGyp39Jvl2GWcZd1LtdZvmb5 8AqvFftXQitTVnau0ltVuGp0tf/qQ2tIazLX/LTWem352lfrYtd1FGoWri4cWe+/vrFIrkhcNLjB dcPejZiNgo29m+w27dz0sZhXfKXEuqSy5H0pt/TKNzbfVH0zuzl1c2+ZY9meLbgtwi23tnpsPVSu WL60fGRb6LbWCmZFccWr7UnbL1faV+7dQdoh3TFUFVLVvlN/55ad76vTq2/WeNc079LYtWnX9G7e 7oE9nnua9mruLdn7bp9g3+39/vtbaw1rKw/gDuQdeFwXU9f9Levbhnr1+pL6DweFB4cORR7qanBq aDiscbisEW6UNo4fSTxy7Tuf79qbLJr2NzOaS46Co9KjT79P/v7WseBjncdZx5t+MPhhVwutpbgV al3SOtmW3jbUHt/efyLoRGeHa0fLj5Y/Hjypc7LmlPKpstOk04WnZ88sPTN1VnR24lzauZHOpM57 5+PO3+iK6Oq9EHzh0kW/i+e7vbrPXHK7dPKyy+UTV1hX2q46Xm3tcehp+cnhp5Zex97WPqe+9mvO 1zr65/afHvAYOHfd5/rFG4E3rt6cd7P/1vxbtwcTB4du824/uZN158XdvLsz91bfx94vfqDwoPKh xsPan01+bh5yHDo17DPc8yjq0b0R7sizX3J/eT9a+Jj6uHJMe6zhie2Tk+N+49eeLng6+kz0bGai 6FfFX3c9N37+w2+ev/VMxk2OvhC/mP299KXay4Ov7F91ToVPPXyd/XpmuviN2ptDb1lvu9/Fvhub yX+Pf1/1weRDx8fgj/dns2dn/wADmPP8CmVuZHN0cmVhbQplbmRvYmoKMTkgMCBvYmoKMjYxNQpl bmRvYmoKMTUgMCBvYmoKWyAvSUNDQmFzZWQgMTggMCBSIF0KZW5kb2JqCjIwIDAgb2JqCjw8IC9M ZW5ndGggMjEgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4AZ2Wd1RT2RaHz703vdASIiAl9Bp6CSDSO0gVBFGJSYBQAoaEJnZEBUYU ESlWZFTAAUeHImNFFAuDgmLXCfIQUMbBUURF5d2MawnvrTXz3pr9x1nf2ee319ln733XugBQ/IIE wnRYAYA0oVgU7uvBXBITy8T3AhgQAQ5YAcDhZmYER/hEAtT8vT2ZmahIxrP27i6AZLvbLL9QJnPW /3+RIjdDJAYACkXVNjx+JhflApRTs8UZMv8EyvSVKTKGMTIWoQmirCLjxK9s9qfmK7vJmJcm5KEa Wc4ZvDSejLtQ3pol4aOMBKFcmCXgZ6N8B2W9VEmaAOX3KNPT+JxMADAUmV/M5yahbIkyRRQZ7ony AgAIlMQ5vHIOi/k5aJ4AeKZn5IoEiUliphHXmGnl6Mhm+vGzU/liMSuUw03hiHhMz/S0DI4wF4Cv b5ZFASVZbZloke2tHO3tWdbmaPm/2d8eflP9Pch6+1XxJuzPnkGMnlnfbOysL70WAPYkWpsds76V VQC0bQZA5eGsT+8gAPIFALTenPMehmxeksTiDCcLi+zsbHMBn2suK+g3+5+Cb8q/hjn3mcvu+1Y7 phc/gSNJFTNlReWmp6ZLRMzMDA6Xz2T99xD/48A5ac3Jwyycn8AX8YXoVVHolAmEiWi7hTyBWJAu ZAqEf9Xhfxg2JwcZfp1rFGh1XwB9hTlQuEkHyG89AEMjAyRuP3oCfetbEDEKyL68aK2Rr3OPMnr+ 5/ofC1yKbuFMQSJT5vYMj2RyJaIsGaPfhGzBAhKQB3SgCjSBLjACLGANHIAzcAPeIACEgEgQA5YD LkgCaUAEskE+2AAKQTHYAXaDanAA1IF60AROgjZwBlwEV8ANcAsMgEdACobBSzAB3oFpCILwEBWi QaqQFqQPmULWEBtaCHlDQVA4FAPFQ4mQEJJA+dAmqBgqg6qhQ1A99CN0GroIXYP6oAfQIDQG/QF9 hBGYAtNhDdgAtoDZsDscCEfCy+BEeBWcBxfA2+FKuBY+DrfCF+Eb8AAshV/CkwhAyAgD0UZYCBvx REKQWCQBESFrkSKkAqlFmpAOpBu5jUiRceQDBoehYZgYFsYZ44dZjOFiVmHWYkow1ZhjmFZMF+Y2 ZhAzgfmCpWLVsaZYJ6w/dgk2EZuNLcRWYI9gW7CXsQPYYew7HA7HwBniHHB+uBhcMm41rgS3D9eM u4Drww3hJvF4vCreFO+CD8Fz8GJ8Ib4Kfxx/Ht+PH8a/J5AJWgRrgg8hliAkbCRUEBoI5wj9hBHC NFGBqE90IoYQecRcYimxjthBvEkcJk6TFEmGJBdSJCmZtIFUSWoiXSY9Jr0hk8k6ZEdyGFlAXk+u JJ8gXyUPkj9QlCgmFE9KHEVC2U45SrlAeUB5Q6VSDahu1FiqmLqdWk+9RH1KfS9HkzOX85fjya2T q5FrleuXeyVPlNeXd5dfLp8nXyF/Sv6m/LgCUcFAwVOBo7BWoUbhtMI9hUlFmqKVYohimmKJYoPi NcVRJbySgZK3Ek+pQOmw0iWlIRpC06V50ri0TbQ62mXaMB1HN6T705PpxfQf6L30CWUlZVvlKOUc 5Rrls8pSBsIwYPgzUhmljJOMu4yP8zTmuc/jz9s2r2le/7wplfkqbip8lSKVZpUBlY+qTFVv1RTV naptqk/UMGomamFq2Wr71S6rjc+nz3eez51fNP/k/IfqsLqJerj6avXD6j3qkxqaGr4aGRpVGpc0 xjUZmm6ayZrlmuc0x7RoWgu1BFrlWue1XjCVme7MVGYls4s5oa2u7act0T6k3as9rWOos1hno06z zhNdki5bN0G3XLdTd0JPSy9YL1+vUe+hPlGfrZ+kv0e/W3/KwNAg2mCLQZvBqKGKob9hnmGj4WMj qpGr0SqjWqM7xjhjtnGK8T7jWyawiZ1JkkmNyU1T2NTeVGC6z7TPDGvmaCY0qzW7x6Kw3FlZrEbW oDnDPMh8o3mb+SsLPYtYi50W3RZfLO0sUy3rLB9ZKVkFWG206rD6w9rEmmtdY33HhmrjY7POpt3m ta2pLd92v+19O5pdsN0Wu067z/YO9iL7JvsxBz2HeIe9DvfYdHYou4R91RHr6OG4zvGM4wcneyex 00mn351ZzinODc6jCwwX8BfULRhy0XHhuBxykS5kLoxfeHCh1FXbleNa6/rMTdeN53bEbcTd2D3Z /bj7Kw9LD5FHi8eUp5PnGs8LXoiXr1eRV6+3kvdi72rvpz46Pok+jT4Tvna+q30v+GH9Av12+t3z 1/Dn+tf7TwQ4BKwJ6AqkBEYEVgc+CzIJEgV1BMPBAcG7gh8v0l8kXNQWAkL8Q3aFPAk1DF0V+nMY Liw0rCbsebhVeH54dwQtYkVEQ8S7SI/I0shHi40WSxZ3RslHxUXVR01Fe0WXRUuXWCxZs+RGjFqM IKY9Fh8bFXskdnKp99LdS4fj7OIK4+4uM1yWs+zacrXlqcvPrpBfwVlxKh4bHx3fEP+JE8Kp5Uyu 9F+5d+UE15O7h/uS58Yr543xXfhl/JEEl4SyhNFEl8RdiWNJrkkVSeMCT0G14HWyX/KB5KmUkJSj KTOp0anNaYS0+LTTQiVhirArXTM9J70vwzSjMEO6ymnV7lUTokDRkUwoc1lmu5iO/kz1SIwkmyWD WQuzarLeZ0dln8pRzBHm9OSa5G7LHcnzyft+NWY1d3Vnvnb+hvzBNe5rDq2F1q5c27lOd13BuuH1 vuuPbSBtSNnwy0bLjWUb326K3tRRoFGwvmBos+/mxkK5QlHhvS3OWw5sxWwVbO3dZrOtatuXIl7R 9WLL4oriTyXckuvfWX1X+d3M9oTtvaX2pft34HYId9zd6brzWJliWV7Z0K7gXa3lzPKi8re7V+y+ VmFbcWAPaY9kj7QyqLK9Sq9qR9Wn6qTqgRqPmua96nu37Z3ax9vXv99tf9MBjQPFBz4eFBy8f8j3 UGutQW3FYdzhrMPP66Lqur9nf19/RO1I8ZHPR4VHpcfCj3XVO9TXN6g3lDbCjZLGseNxx2/94PVD exOr6VAzo7n4BDghOfHix/gf754MPNl5in2q6Sf9n/a20FqKWqHW3NaJtqQ2aXtMe9/pgNOdHc4d LT+b/3z0jPaZmrPKZ0vPkc4VnJs5n3d+8kLGhfGLiReHOld0Prq05NKdrrCu3suBl69e8blyqdu9 +/xVl6tnrjldO32dfb3thv2N1h67npZf7H5p6bXvbb3pcLP9luOtjr4Ffef6Xfsv3va6feWO/50b A4sG+u4uvnv/Xtw96X3e/dEHqQ9eP8x6OP1o/WPs46InCk8qnqo/rf3V+Ndmqb307KDXYM+ziGeP hrhDL/+V+a9PwwXPqc8rRrRG6ketR8+M+YzderH0xfDLjJfT44W/Kf6295XRq59+d/u9Z2LJxPBr 0euZP0reqL45+tb2bedk6OTTd2nvpqeK3qu+P/aB/aH7Y/THkensT/hPlZ+NP3d8CfzyeCZtZubf 94Tz+wplbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjI2MTIKZW5kb2JqCjcgMCBvYmoKWyAvSUND QmFzZWQgMjAgMCBSIF0KZW5kb2JqCjIzIDAgb2JqCjw8IC9MZW5ndGggMjQgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ae2dW5MUR3bH3/tTlF8cELFq6trd5TcWSQ42dhUyM1o/ aPcBhpGQjQAJYdn+9P6d/Oetbt3VPQOSw4aI6aqsrJO3c/nnyZNZPxX/UvxU9NtmVzTN9tCWZVN0 fbOtD8W+PWwPxc+3xb8Wb4pHT95Xxc37otz2bV9W/W7uavP+pmibdlvtimq32+73bctFvd233a7Y 1c22bI3ed6nMquu3u6I9VFuyphz/uslKLEr+Q/kniqwOh4Pd8t9fd1Sy7rqq2Nfdtm1ox82PxR+v eV6WfV1c32zayr3gf65/LB5dX9fbsqiK6++Kb4sHz98/5PpB8bDoige/Piw+a4oHt6/dnf7qCdk2 MdvL2/9wL/l8b9/9yHu8fvvmF/eiXnn7XX7z5tan/vywaDe+PP/eW0vjdeX4AmJ18eA/XRHvbvXs B0drVM7z1w83FKvXnqnuX/JDRZ/oLm/cO1F6q7qL4Ev9vPn+YfH3zfWfii+uGZ3IE0vjk3OE693F 8an7w7btujaOz0bjc3RUrEHX/3a6Lpsxdx6vS+KVqtv2/YBXDtXmGu49wSvvP6hz3w1+3uqO3oV1 YACNLuPJ+PN38JiWkfRGb9zqh763EfP5jEDxgGHh7/OHG3uSJ/lcnoLI+TQVp6TnogkHQ0bv34qY qunf99nyAuAOK9PXTdRu9NJ/6ZFr/cZT9WX7Niifp+p76ZXeUotuZqr3vSrmKYmEcqtenoDx/q54 AEf/vVjDqWdyR72vt3V9QJMMuWPAE5uR/ljLqRM9WpSbVVqt3G27bsCpbYNWG3LquFZotV+sN001 2CDwS68GHuPuFxtdfm/4Mf4onnFxKB48ZiT2xYPPdff0G/1e8UPqdm3H+8ZuotE4LpYVmps+r4v9 sLG/acfvDjvsWFN7czKoSxGZAIuAEXnw2Tp1NcME9Myi6tyZVeyqfRHq8huqzl2z3TXl/hDrkpnZ tlmjOp+aVYOLhj9og4EwbxwUubvZOTSgjqasY31930VYMBSgNKIRFhx42Znc5yghExn3FzFCu8tm vvigtFvZWMSDbHrnK9pqMMLDiQVCpuXNfI8IKfer5x5i6PbF7e0bXQUr/u6tyr19qfRfHC3EftCh wnZ379B6d9jumxoc5wXjN2TGaMd3e1BmHYXUBvej2PGnzooa5zKowx/6HgV64BE2s9RPrR89ei8b 5i25N7svlcPbSZgKuj7tvV5bhA7GUmJBytWbt6LmCeh9T3pYnh45CgFh/PxwY4wqCkIL/ua9r8mf 9ewxP+Q0zqbg91vXbhG8Jg28+kpmXJZ7tZVeUoqbebxfM+RV03bFaOwXFLQTZwe21+DJpbqcmnvs dntmTE2dlExV9RMrPaNkfkVc6VSGEWDz76FLMcQoBv7COvxlPMhj6IdOpsdJ+pVO5ofxin/1gG5n dECpvIHld39tgPNyRJX8aGPYhKfKTzopgC1SVCbcw7XSrcSNAQbo662UHugr/x8cHdVnRJ/aiv5b x3Zqt9ry30PK5FS6ai7KeZ2VAs9/nGlL22/76oDtHQ7tMTZzg7OGzc4EpknddXum6AN119drbO9z hg31pL9vP/hJKv2L8XnzPb3KL2bObBGDyl8GhmFWhlnr9Ob29mUwPC+YFkBdZJ66979AFcCsX4hn /Y8yRLv6vQp5++Gd7Jge+0qpqvA3lfnAHNWq5uaoq5D/mXJc77pt3dXoFN/BvwvbhvulLQeDfSeg ZSaKTjQTxU/NAPGzrXT7h2IBno3fci+Ht/zLhdk2Gx/RMpG8fJTMhzSv+c2T1O4PQNBhzyyK5Mag OVy1RiTP5Jhq1253O/NZ+bokzV/OzM9mNP9if7uujKM06O+dOni7toPP1DN1VW1LQ1OhUXNzn/FU 8w4dvGoCvKvReXU7V5XUq59oGqaq/IbKIc3CBr0C7gVvrDEEX8mu/4pUYGCfgelQ3J+js7n75iqo cey8bLvss2y47K3whZDFFFPoKfwJOYoATeBQkGngWtRUAyEXlD05Rf+FwxpKVx5RoCbksXc3PufJ mlCWGqh6qlzVFljNU6GrUVmUoqexXevU2LlS1uFnr/DoHOHsTy5k1WHbHIKQiZ0m8HVcKZxMiwx0 BKHaOG88vtQIYzAi4mTOG681PhoNjaT4Qvn/4Llsw3iKg8R9ovlrzmYiJJaYZk0sHaolkCvmhCVg DF0rXRSWwG+ohFVL757JThNLhJo84iSqu5KFlq4pdoMxXDCKXlHSFR/BKCacWh5YJmqTTazKw4Sd kvZ2czRbibli0ECNdDM8wJyEa2QXZIHnWlMfOjVqJtIZCtLRB/yl43kLPuGaLuev3iW/nMY8hWfQ IuIQhhRqelclwiakqFx4DAp5HhzcpPAu1K6dpnyi+e7Xj7K0P7tcVyribw9c7Z9htlGCjz/X79UX T3Txt4fusUiCoSCv6qhw0fhGef27vix/p2r4IrcZKtjc5wLOgSW6Hfw1GNQF/tJQWi+t4a8zNWfk r+5wyJ3ig7qMtdQdfLPH8En0zR6rS2Lxjyp3ERWEumSCt84N8bl0lPSbnAHe3YDkITewJX+RpGit dS21qJeVR0yrFFlTpVwhMQFV5ApUhSG762ytV46rVxaYxeOzDv0yByI/Eb+wvLFt+n4/rovZ2hnl OK5VUo5SaphJtIXUpVLUzVJeUoVSjqytxZyoCBQcOVFhj/UjVcN4kSnXuzb8DLlKYGh5jH/grEFK MQPHl3/qttt27b6LXfMbAuykYvb9tjKUlkcTrEHYL/1qAJ2Jzmdskh8FabFZsvO3bB58YJTI8fx7 W/S/Q8cemTDX5bY97Nuim2vMnEHejEIjBgEMiDzVf+VjFBBo8/Ao0S+RWJN8S7BA92iD3HS72yHJ viWrWGTlqtyZVqgyh+B+N9erSPIaFvEw57gkf/fQA9somAIjAim6pvORZ7xv5JH8m2sfpsqz2gsO 8yD0YG+yItQX89sxm1g3mOW2quMozenbT2QTkyDvgC/7ZpdsosKCTq7/TUJ8bl+iP63jNufHyLCU zOIpnqGSedahbsDrRFL1ddXt+mUB7vfbpq5a2N434niHYmGXPF7rYruCnu6q7a6zccQdWuJ7Kbcd zq6yrAo0StOXrYnMiiiuPErosh5Iw4gltxWWVT2wUvAnM61pHTdxlFYs03fH6zhQrmsh8mIdqdmE k47UMSzfj+q43nP0jWbg4AVgQURw4EG0CSmoH4cNE1pUTqULWKKJIn5E+aGP0FOkCCfqWjmNvkOL PFX6EYxJHik/79wSNM1W1jaDlbXHzuyqHP1VC7BdmGr9Va2fOvWqdijPG4eGpXandVcetSzSWadp JzZoyopJYSwPc22SSxBkEYY503qE4I3DhpIujlPwvz14hglhaL7kh/54oruWqS53tRJtUSDd/e0h ehGjc61UC9biId2DqUmA4ERU4T11ACEq2643yONlcRVQYLgvmq5eNkhNaZOSuh/XccHtNjNIGW/f z6qx5EAyJv4lLAAmEEfrqbhekiH5Z1qA5Ec5B4oo51jOXbyM5Jy/wBXpixnJOGmmNi4E+YgxNdmQ 0djRv/ttvyMYuWG23tcuZlkBxGa+nFvNOdaiuSN/hxc0mbueAKzS7N5Je3dP/JvsXdO7pd5MgF00 80nYcuuXVW+/RwLB62/9PKNwS6hKQyqRV/394OcrDCy5fWyRTxtGM/tYJiPhdLNNBvSWqQzG1FQG dE1lcNfWqImZMZ4JRbqnzquIW+8bm+9f2nk+4ku95MOt4Hta+isKkEa99d30ygeNz4R+KcdT95Yn gYGDhKgiXkTvqO9Fekxyba85aJAHyl+qjgil77EOo14beNXGSsg8qZ9UZeI9ITL3rCrSr5+0iq2h ZBw8E+ZbGQv0DPnBZD5pnYLE1MJviBB/WaznrxbI4CKUKPyDjaWFXM/HAqGN9YJ0OFm9LJ47Mz/G VctTl2ZPd9To3tAdmSOlmV0MGMBj/F0/0EYDEv4Hz5bFGNAa+8Ho2A+tMo2DHNkP9kuJc36qk6ZF u1smpmU4A4imxaa61rwGm1FblEbYj+IshbaomCkKMynyV4QLTE2L6b5PPJVqcAulwJJFOXeTSfp7 jRAtTlNosZ+mDDtyPsQDT3Zdlp1p8EEdgUblDNfMeElf/2Cey6qEf4Anxg5gFfvxPOL5xzMOitkY 58M4fiV7L5DzL3qinpqn/dqTU5EuSM441/NjoMAEKqPrKfyAkFrqD69/CCm+JMf3znFjVTTji6yH TAayE/+b/eUhM5s8eJ87XvxGz64udt5O5X/NSNZtBRAnWGc0kmNuG0i9yfOduO28SXHdEiR+QCpH dTRuWxlXZ9bcMNYbi8H+pGCn3iMhO5zmXlIyoIihXDHTuzEegkGMh/mhJdgYdwMDw4u0yzgxPqKB KcnEgCc3xuL8mjrmB9tEFv/MbQhy/EuaL8Q/8tlXd9l9IZ2u3R72tsFx0mcrTfRXiBjtBNwhblSf vybdWG3Fs2ouJBONbjGBdX81L6IT6GK6NqZrxkWvkB5NOt5aWe47zZQG5mxJLqI5q/stkfM2U9rb 3NQMVZopObfgcKZUsxmAzZy/C3OGT7JPG3UkvHMCMFA1AIywj+I/3ZgyUCjUeTz/SQW7J56j7XAV d75hmWSvDC00MTPr4KGTNyg38uF4q+TzBCDljZO3KyauEBi+/wfiPIPVuTDmempLYKGTbnCbMbZl jy2ZDvV8j4yH+ju0mymo3LS6SHTXTcOHLK16/5V7wYVjeutb+L77rviKTEgx6sAs7tMC7iG379Ow uc7T9ak+SPYXZR2Ogu9YHCdQUQbC4a0a/sn4LVerYljxn3iDQfNAWVSGOQIS8d3gKsZU3g/zeep4 zre/pGbmwV6D+e2blinCdFhXml9ndmnzi9uwW4pmc2/bqaPQnhcMcxmLNgTJtDWrOqO2jOFO3Hu+ uFIz4x65J3Dd9ExGqhK/46S/58zfDLien2kiB/MzzdzlOzv9OtvvE+1VxaJea/YKk25rU8FeaTY1 nX6Rv3a5wkLWb+jZI8q6I8o6U+vrPHuATH8UABACJn/OfiFTUTiZbHdE5p4Ly/KvEGnLqB9ACNnR MSTdPkdCUC968v1bzhGwZFEarPqbzjAaEiy/cyTc+US/g0QFvPVvvPMbSpTnhX5UjK7VinzvyHIT nsn9ZvoWsPU5PyCmp67ONsHh5kqPtpngH41AOJv3FpRYyXEXti2yGw7rouC7/cJ0+5p5zqSOYYF2 qS67bVMdWLf1dZlbLB2LtbHApC6z0rqohpbUfpLWkmk90mqRPixRnXKWtBwZsTuw7J3gJRqL0I9a 4n2PgSWqIqeHtAdOD9kdDl4qiUYyJeJ/tN2bzREIkM4M+eeHVM7Bfv2amXYJMLj75bAQJdC9LiHm wOq6BJCX+w0Z/uJIIGpIh3sQSNmxDS7B7LS7sL397iLQMoMeskS7dx77H2etGjZv2WQQ+8mz1qCf PGvFfhqzFp1dd+i6dsfsYsdyTLdDK+MpYI+yW2epcxZzSz3Ha5VGjwWeA6OXnIwrLZoPfKQfUSH0 Yuq8eRHb79kGX+05ssaX6PnlLHGvOF9i1+F3iB3RILCHHrKhI86U/KraGULex2oNOmJNTNKJ5X1Y z1mLtCkVFqTLYF7Mf/Bccwcart0T9irxnB1i/B0sBM13bNWzuas3QTynYz9LumuJbEcYX5s65myr C4NWtAu5fIaQ0Zhog9yC0JwNUnaTZ95Shj9yg7qgGzHBeq7rDy+cuQxHCsgm6m/YXqnVI39CkN59 9+FFbklleH0QnvZKvoWlTzFzQ0xq2QMIQ59fYi+iUNtGOIuKuzeZZmNDdgDHwur42Jwxr79cpn2J d5Np3w/3J9LTflgZZgjrIY5fwzL8GPfCe2ETgp4ZdiIs229XwETBo8wf+QsLsv6PO4Br9CJ/YaiY /oMjCdshD3pL+eE9ikI1xPwUDh1sHSlATkOS7hqmJl1vqYLIA9RUOvOJeuNcaySpMLJCWi+oQiKq AkRUJPIUXX9NNAMlq175DhG9MCJHMVcqTVTVcJVmKRvfkLx837tfOvl+skL09hW7dogBae/Ac1H0 Gs4ImrWnZ5qRZE9ZruLAj6E9XWNGLpc9X+LdZC90xP0J36UdkZnEU2qY0yy2ezYDcnSeev18G9Ue dn6CJasC28PvOrDOWxgnRyTC2fFvsDCDE/D8bPFrWSxkFsP/1s6asY2c4Y0rPRWx529e+umkP4nG pAHBRRpM5awRhxJXUN8hDsMuOAtWRXGocfPPWaKLpaE2+Yqxp7JEH1cafIl3kwbfD/cnDJf2QyYM oMXGKfrO/d27v8KKOB94arAJW4F94gbYBAPB03JVoJl1jZWAv+R1MvzEC1gJXpDeZqcKWVHrZEJL 8xeBIAXtzXUkR36lCP6ThxQKJqdSMFJshRbSRRAwWL4wvabCVLAy6TU9BaBBTgW7DtiskQSi1Gzf yaFoh509kIQx6LFS8jl8lATEqrO4twjK2COKVifkIJzpedYsi8DFvh1ZhclKy7hyd0JkvsS7yUHo hSgIrhfO1AZpilXZ0Q+jXlijDY5slv6r4/M/O/bUjvmvco4VW+WcjHZGMMSTOQPmKbAn3BsXEeHq x+6tICPGnnl+iZNEy94NEhTkxWRKddBbYnOTkSB3qvMKEQ2x3SMRhZCIhiKNtFJEOm+2JO6dC43S td4a0aTSV1mzRS3vUKVYkzZJWVBuprROWvA4/S5xcNXRi2RrkWvDrn+m3rbgQw/bD8NgP7Zmh8oa PqMvGHyGXSjb8imJDrDc4HL7oVPsEXjXfsyLxI/tOT7ZHI7jdfau9c25y7zQVh1sQTmqoODiuFQL NUR5mv984OL4qFoolHgnLRT6ISqh0A+X6qFQq0E/3FEPPXXC7Izcxh8fJjMmofLWTzeSISkTyZCu c3WkPBh2pFC0JaP6K1UjakqBjaPE5zIq6QdPMvkSfRbtJRf8je+eqaCyMMF571EN7+4tyGba13Ob yGYsn7w767G3Dxh+qvOu0K02bUU3IbnW+dxFL4979CYu3NjtMwk+/ZThbu1Wm29gi1sX3D1u3wBs pNDf+U3sAWw0FpB0OAo2XEyKuXSX40bjFLThnL++HJnZiZhTufFa/8VT0FDi3cQ89EKU8zuBDYKe tzsMyn0KuYlRwMscH47A5dZetl1CJhEkkAshkwg+zkyp3kr5Q9jSMoIwZL0OQWxgeNE5AvITRInQ KGqPpBPCqUHSLXMIwpq3DkGYHjuGIELzVFaGIHjPDgNhBqGKCbZIt6qv1ZvqZVUm9iMviyD6gAaq x5XHq2oenzTqAaM0HHNtsV0ZS607gOCv4FMY5/FXUi+q6j/qBw+bKSCaQmWpGvlCivUZjaPpQFHS eYFrRizmoUe5pnEx5yqUYuEMZdMXoUGXyG1UXlwQCjpFKWda56S+WONq037VT+AzaHyJl3RDXJFq fD9E7XVnlHJpP2TCA883Tgd17m/uM3jh4L8kKIo8+XV9pgZxwaozGmQo82L4p0M3gbgePSLh/BGw DUtHWARR1VFSK72qp9IBECVP1mYIRoVhyhAUD/WVCgNSIiiZSgpDPnUJIZloBH/VV3mPTSHZPzq9 L6JfOnHVEWqzMAyaR7Q8T9eIN8uZJpGI9x34Oop3s2eFeYJNLhZuItcmy81roPfl2MSXeDfhDr0Q pftu2ISVLk7WyQ3JukMIlxwhJ00YBRLfUrHpRiX73lhYGkzAlemywjaeibPFnZJICYeOOWLijKjJ Ek/lVdz/+AgCkkuSo12csIrOSJaQ6yOywVNK4W+QxrTvy8+9VC1IkykvQERVRSkWkRA5Swna7QIE hMhehWZzTSQruiifn6lEdWVekwWFZr0cFJrhz9gorlXhWQR0kj8ixGELHsdmhGAec8PMxwnHcEzP HyFOmOJtrmV9bluJir+iz+lwAJAlwwJ2ZzjIKoxutNuCjrVfesFmX7SJv57QIO2X/5IrpqCnjJx/ SB/a3Xe/rNGONdqxq9lt2AybujBzkwBY3865iRv7/oZtgxkv3V+sHzmdtB2cU004zsfVj77Eu+lH 3w9RPd4Z/FzaD0saEnb7PCmU4AvRBE3yKPEhPM14UHpI0iWx1Ms5jNBr0n+5yggayGDHsTkYHJ8r VSs/zLgiOaotDaHa/dGJRmqH02QmQQ6OPFGtpUzyYwhUUyk9EcpVmQqYanClWGFBAQaldHrOZNDj ULFhqBkO5EDKxl6fRSmr7PtqOQYJ7HWxJ5Q4su6Trsc0vsS7iVnoiPuTs7mOWKNvjsjZXxAhD+E3 3taJxSRt4l5vlHUz5c/HjtEjGoDF+UQG8iTrJg6XdI4+fkBOpStnFG0E6WlkW7evIezTciHvfs9W 3fJVFI4pK8Jw+an+gG1zdOQ2I3yWjMO8s7DmSBW+r4c0zHX3xDU3lgtbB5SEn1YttHMIbqzX9LIG IaoWekopepprBPWdcIau7a1wxm8OU64G4MY0nnpceURfoxXfolz0iB2t+CQOiAu4nRuQhkXdXd/W 454bDMi4vxb1SIn/Zs5aX6xGWB8dflXiYwfPNr7Eu6kR3w/3p0Xm+mGVFpH851ZVPCO7qXRZWHHp dXB+4QhTTvGbuDrnWHEdsgC/JQ53EWi8K65mko+8SF+EsoyHyc9bPOWvcoqa6CTVZwg8O/s9VzGL HM3XMrCMbHsIQykVc/xbm/lRvAsqprNveNaomCGHrJ/hHVExziWjbpJyGaoY32V0hobkmIoZDkA+ YHpLDBGVBTSXVYyptiMqxlyjK1RMizTs+TDruOcGKibX+XP7UIK7pGYPKto+ixsJUOXSGYGtpE1C R9bI1sUek1DinXRM7Ih7UzKhWgPv+5qOGISkSiEALGAOOC6bGLMXZ/qNXOKJAARVW4xKP84cnz3c hNnivLRWnPHQNBwKOR3cdSsKqw5CTYBnURtVfJvusCd8MNRk1aCfBDwVQbrsSejGZP9fG2UMx0ak KcPhpdseuiYx3KoBwTAFhrMtXlEb7e1Y2TXuiWN7d5cPTaQcfUG6Ppjay3dmzgGhsRI9Ft+28A27 uIsolHgKoKOs3ew1dI+qzIY6uoZDZPnctovrC0MxPFJodjPfoiIPJxYZaev1tAfP24DsMLy4bBQy n1aTlw1RDL4LHeb5ab0kJrhjYCmDO0RlChYpUE62XMgA0HSK0aUi+ETrqGKnNGtk9AXNyulZlVPY E5acCzyZYcnn/vg/ACFORVAPf2kVf/E+4hpC1rh+xiQX+HH70wfloCdwzd7atJan4fg/LEx8Q9dZ THn6ZpzIhwjxYUx5jGuxUt+ASfmZxLUYKdXj7Yq4Fn0dfL7/Gs5Lruzrr2cNS6Z/PMNlEuYQb3bQ lwlQdm7XrJDlM7IY++JOqPTHggW5mQpZIh/V4I5J5CwomxRD290/hHfHWSIcnQEsOLBWbqpi8ftq SQ9iTlliyRZ2OBtmzfz+T+BY8zsymzklOJjWrjxwpod9V9YKO9dCzA/8nnOO+5YDxEZkbQlgxS77 B2xTTkZovgg+f3uoek6ZHBVxXOTrU2TBUBUIGbBxYYdEm8ARPiXfMsdpyYnZbhe1M9CJo9wnli9k 2MCExzg2mYWQe2IX7ollk12YsOyc6R67WDDdwS5ofvaF03RPNEP26+8hBziUiXS0HBbWolk1B8aY DnV/ZUp4/xT/c2YgO3btRPXhcDtGnT0fcbxWdc2s0DyUX0vmHrmwmus/0wI29CnNVpLQ51RHETeI pjQ8cso1aph0qW3yoH3R7lBkXsFTnBdQMlMACdRyzMoLXNNeMjHF5a8KEFGREDmloA1cHlPvdLAp CB25hK3lWoRULxXjy9QDva0yRY+YNcpXmc+gR42/XDFDbjCl7d6mKwNeOeGyoJgAupJNCBLGkSKo 2nSewacTsWgUOP+EL21Nl+7uScCSTWBxkJPFs6hrO5BpfMzcjIB9qWGEm06JBHFpjFHPAPmyzjUJ 8diXecVtJ5LudpzRM6J/kW0Aal9iYw+cH9BXKOdQhwXkPwhqtR31gQlPtJFd9CWH0DITTuO1+eP1 8VOjTZYi/Wm7QBEeO1jYbjQzuOr4OAVTDw4z0Flwmgc6XEQ79xXGlHr4bC1WPp0rdz+S4pl/nS3y mU+bouNnTiSTM+RS46J1QQZPTWNjPbAbplrZ/GZgu2Dfj6XeKNX/IDz2EKVqWf1PgSk6JUz2xRw4 AZQyrOZxlHLaJWIW3TZXjsjS+jmDOzMx+b/qoG3YNlYSFDHuueMDkknmwCVCOFg5OxcwwQp7+/wR kGM9leR5zVygZXNygufr4cmc3kdp6jM4SycGLSjuaBh8ZeaU5tj05EptgWy0B0OysgcnfbLMFc5Q m/NVODQEtGGTOBlJ3ZzcwgvTlaFhqHLLEDqX8T3jyzDJYgxHejVfzljCxGEDiwHTtjYxYf2/6/m0 2sBdFXljofob4EHLKTF0VSDD0ZGdO4Q0MzxHa2P8bl3OWQlYpkAnHjZ1j9OkIJ/rTFPIfdo2TccY UfIHaC5Lc7JZEzZb+fHBL0Ds4GxgOCYKo8Q1wJy/TAD4qxRdo7LI81hZtRMbcI8RA9zzACDIC1q6 yMlh27RmCbZfY9/swMXWljTOYdvT9s2JgzHHWO39PsybN/vLoR98XLre8/2b0ICkUOZGGvs8UChM iP1ODqa2DBMzNP7qWgM0Hem4MDX+fi2zNV7W2Oes8Qwww7zvSzf7WzNxI8SxrQ5g2uGgrNZQaeIW RL6u622/r+2EuU8s9HHi1rB29kkmbjh6AKb3M3E7paRZtfE96kB0uE4zO1+Zc2d2C2SjAR+SlQGf TE7HYHSVsy/O14ZFHOe9zCrP1zwZ3XPIZmCQnl2GdQOjC5/t3TTtbkY3kuHgVc4Ni8O81guef6cm TLDiUpOXhamxNC+GnOzJp+gzT2zlDPJd/ubiGls5HJozZjhaScI+xsgO82ihC7VnhqmdnHIsRH2O UeQH3UqSHiw5FfODHMxAbq7/dGwJBL3GEhKhNLVvxxxoTiLh9/auMJAcT442GVFd6J0xKP+/HANI DAYLHlixI+Mx7q98EpOsWJDFuvbLSEHPRmlZ9vBPpORcYfwWn22F+6HcvNQHnp9cmTJY1kbF1ZOR WeCoUiF2V00+N4Bn0SxCbSeCMxdq7NshBfc1LeV+36Poi9fF1SQAZJESb9p7xEcbHWJW/Y2IHK8v kwTivsuuPmxqPoDaMMX4MaQwe1fKa3OE2WwEt5KL6ibBPp3gXHshiycTXtq8Ll6hzr6l84qXK/rE JNac1dYFdJKakm4hx+GU7qlrKLf4emJme5oy032vXAfa6FWm/joQNN+htU8YcaBN3W5+nCTxUse6 FB8jICJPuUiwOStbZXHn0XJgWZbCeiMHvG4gHnPxZQlihGpHKrxJND2xQ3y7JBJn50Vjx3inSvkU aLW4EHe2ldb2qbhcr0ljEtg3nFwQ0lqsyd7VK1DPUlQHRyvkalVX6pXyhRYl6r7RqQq+r27cSNbF ryuHke9Sms6sS1gpXb/mmvko38nZuGd8GdL0NV1GOB/P3B1Q48ZfcwIv9VU631m2FyMF0HFt7+zr jbu6gZD56SwVVrCzPo2ouzdB48pT8HfQtnfsCQLo3mkbq5dqkyhYK0TbrqwnTDBPydQmdXPDmaww 0I95z58xGlAKDOGHZ8rMVD8x10nO3TSBG3LO9dXMGSQmCZRYRZqyQ4Tgwr5hPmFn+fEdABeQU9Xt wZ1YnfvjovgZMCxZupFDP1wniuzV3DX0kr4/P3fOMq5+JFkbG//CZEsnQDOz1sXPQAtd3cQrsIWS gJLuvGiOZnG/V/F9YIt/y74F4h6aE9pdsEth6Hde0QAP9VMD+CAnfhu6qPToo9lap9iXq/8hOdRW ds9p6nkvhVazxq8GPfLdAGC3hI3tMx8+iVl9Frfw6DojPvknTyQmmEffUQvlff2XvOPMkWsaZlci nxwdjyLDkFiMZlnBQnyDlA80IKqZJ3fFKW2ec0wj7olnIwBTnANnKRgTHW68ph8PNHBJRxayjWVg VAUM6Rr/DLA0TvmZtNNWYdfIBwshbpx9wElztgdlWh14gYXDQX3GQNSAosoFFFMrejKW6FCAgw4g qQOL6Hx1A3NjXce+4Hi63bdAWgdUsLWPnryvivsHKnZ4630ClZbTLAZAxdVbn7w9ArDe32xc++2E /QhYximvCyadtik2hyzYX87ld8t0HrNMKF2AWVoUboAhoIr8Fr1sR3w6UGfgzG4FYRzA4TZ7l6cZ ZtGsNmAWzrZkNeWAEckgg0/LdX/IlwESwmJ2/X6TpSAjiEsGWkqqaAd+GqUAWko+rrAHcSS7wuFJ WOB2k2rgU6CVbFRIMzsSQEtISzbRU8+sZKiD0Qqghc8gUFOjFFPUmoy2b3FmJUMfXAZa2rpnEAVa uKb0AFoMTHA+g4MpNqoJtCAY9IGe8DEK946BmQ6/m6GdRKEzXOfAkV0F0GLXOWixe0ETTyHcVRWg zgMYyrR3HLTxtUmgxWoaAFFPOYugZRgplzraTn0sHcOltNPDsWlC5yeGCCk5aglpx1gXWn6wE1Oq BjnrhnrmTJLSxriFA/5YKR7ilqZqduNp4mrYUhF8Zt94+F8LW3wDTgOLi2DLauq/d9gC45wCLSw/ p2+sz/tBE2gp+YyufdDpdwJahtVZgCoOOm3sGxcheiZ+meY4MuHFGWRyZGl8lQvF+s7Un1nXjk/m dajty1wojlLuQtkcQybHvawjHEKdRiko7VXIZPzeJd6UAboYIhPIXYpMht4UC+zcdTsamuECpdHU DD34tKTMS9x5fWkIw2OOumcUge+5Q6UmtArQ4UiFbHy7CB+ZwWDvrCHuF2CHgMYqhJTcnxLSoBWh SUyLVq4O1LMUV4XcnRJq6kgFbBLaE4nbrk7rG4oLM/jQW5dhk46DsgM2seuETXDdce8RCN/oTtgE 0YjYZIcDIzhU+K7PyKHCF+YcNtkQ5ynniDlU7DrHJnYv1BEo+DvnHNG1lSlsQr18bRI2sZoKm9hV hk2OSlaCijX+0dKcDplH5bwBycBiGKIcnYS0VeybgHWsQ4ZPYl0zfJKljfCJcWN3MHdK5le5Cz6x 49WBOx8XneBM8V/sui9niqo9wSSdOyyeD77dxZWylvZRRBJ9H4+8QykmdIselZgluEli1uBR6UI/ TpwvRzwqpq8qVigzh8q+ZQNLO8a0J0JpIzap2fGxw0GeYxOLDptDBQiiQwVFcmCccqjY6X4D98YC VAoOlVF1BrWYrB9lIWpnYpOPt7xDVCoQJWGTQ2lelPOXdw7Yl7i8oxsRWe01SeszfHSBeGUqNUlC 5/mFHj4Wz0ZjKpoWevxrrzczr1221LNhqcd3T1i9sVuMh5Z6QjvjUk94ar/+Xe82cf6v4VJPjZcF r5z53jNk4NMy7R7zBSiyqTmImB2JcrW59R/bu+Y2lOXanZ0RnCntOimCmB1n4ld82S2gE8wpMCBb 6/H3mdPEp+S4RO8kDOKpZlYwlJ05TGIdc2sTWhJhSWhtsoIhxRnj73BAnrfOs2v30WXCNaOXHB52 L1gCEMpgicVqB5eJfRgqwBJ018hlssfRIZeJXQWXiV3nsMTuBT48hXCHOye4TKxMwRLYy9cmwRKr qWCJXWWwZOyKXHCZ1GzGa+2TcDksCUxzbEBgNs+SESfGlAyWxLT7YNxQ17xeKc3BEscebrnH9v2U 5r0fw5LcZ2/R12vdJvWe6bQD+j8W7NZIiyVmo/T10dz8rlrtcR+u0WJGMLDh99zVHh9ueGS1JzRg gqzmVnt8rMn61Z4V1MeWD/sbWhtxxmi1x50qPLvas7EdN8Oui0QCNokJfrUnlTfAJq7rTNO41R5j nM7iDifgZMw5q8EJGzJYQ86/Ju22ZQ1ggWehleDE4ji1r2+62jNa7g6BHHG1p/bVER+gGMry6GrP GCyx2pPWeRaAEMEO5f6AN3nY9LkWR6HJA2mWyLKvl4iJMVlrAvuJF/BeKoDNTrBE7gjibNwtRyQx ZeSbAF3tHAJMnPnMgE9B9zor3Fu8rsuDjSTrAR8/SxR22BpH8KQU1vX2ZiWYYcVcrBKzpGMaMCZx iieqMSONqXRrJZ25DlzxIQVSxGbSmzav9bmgRV121QHtH9L4uiDnMgGqrc9FPaWoCpDKk1xNIZXS Qnsicd/iWAHdY2c2tmB+eoHv0de3P9/cvvvlw/PXxc8/jDgT6Z2NMXp09QpI9Io1xHV4+MjKYWb2 VvvnmpIuNaBmsRcYRu7RCIA+d282n+4g5iLk4F7AjgM+bOzjvX0dzOEF/5xVVkOJeg49IhWMTEbP BVWpPKi7O3BAz65Yq4+7BwsQFe0K8ilMDiko0dM9+V159r49t3v7sff9va9vRs+1UOWF9gZMEQG7 W6EmNmleRI1Xe5RnEHyUjO1tZKhLWwRGRGt9ttv/yHDC1tIyD7bbbfFt9fckpTGWzcKxGE5xjKne OfYxnWaIyrWXI1wGcxjmBHEOs46S868emFw4PrDVMd2MQtQg5s9wIGIjO8PBPCO9qSu+qc5Z6eb8 mSS9tt0uhsBYqLOYixonJ9DKxWPF90gakzpzzdf8Eg3fbIcPDtRG7cluYUs8vPbUtZZbZtQxsz1N mZ1X1+KJInRKExVmQMbPg8lLSDMNGJyfPi1zRDE9YwnRpiDBZUpN3H7UfPLCsZkcBLRz2jTks9ih puuhFahbkNgODZ3qFVLyCUxIy6cwPi2bsnjqaT3Xju50dcgnMaGuOTb1LYIWI2yBcDY/dL2TMHNI MTFbO4lxY+nWY/fOoehIgr+sV9Ikxu41idmjz5Jvdb+3iYKeHJoDg+mvOTp0GKx2wCMq2nZlExJj U7vOJzF2r0kMMZZuGuTvnJ/UT28oM0xiQm3SJMZqKtp2FRRODFZbkq40z7SDDneO6bI0zzyXD0hi njBI98HAoa55vXwaQzH2rYbNMONJjDvg6ZKYtbDXe+Kn/F8zi7F4PtssMfYP388s5jT1324Ww0dV hhOeY7MYOKe3DZzDWcye4PYsZm1w4NG8QU8uVjMbpQsCx6CbPV9E3J9iEqPaeC4YzCvGA5Qv/i60 EdCNvZOhtu2q4q3VVNfB1IhkPp7bFr+hM+1hSbmv0Mho3nOj8ntiVhx0sqh83VzqtmWV3U6eyLy2 PgVlKqcta3ruIFMSQnR+zOJ9toQ4i8yZqMfBQfloe8IFaBKOTQdkdItNQrdjmEMbvcs2PR1kziLd WE9OMWVERbCBaxDoFpJyk+FzJYDDpsmeb/9GyEMz6QH3FeuYRngA0zkDiEYqQB6LReqI3EyQx+KO DqjFYLU2tn/SpeSQJ6TlkCekJdsZqIcUaPk65JAn1DW3ZKFFCfL4RgfEQ+C7+uocwGPD6IEI+/Cz awdeFJ0PMLGPQLpAtwPHyCTAg1BEwNN7T69B+d6Qbhadv2Fi5GZvzOzsKgAeu84Bj0P0LoQtUBDI Mdr2jkXkW5kB8ITaJMBjNfVgiqsJ4EG5TqYTFlkZhoN3bWiN37IkzzlrRiNzosfRCHxjew4cM98D 5/pqDqqkmk+RDlxoB6GNgc54QTBOOUyTH3N2shi9t8NsxjABnDM2EPghV3lr3S7roQX+eLH58JFr wASozeEcP3k+w1u7mnr0nq3w1t5TbL7HOe40VRfGP8A5zimUvLU1cys7aj/DOXeLza/RfnuAkxhn Hud4DlqJcyw4fslZeyo0f1obVumWHZ1y2zNUs8c8/sv/AEI/n+QKZW5kc3RyZWFtCmVuZG9iagoy NCAwIG9iagoxMTc1NwplbmRvYmoKMjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAg UiAvUmVzb3VyY2VzIDI1IDAgUiAvQ29udGVudHMgMjMgMCBSIC9NZWRpYUJveApbMCAwIDYxMiA3 OTJdID4+CmVuZG9iagoyNSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JT cGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDMuMSAxMSAwIFIKL1RUNS4wIDI3IDAg UiAvVFQyLjAgOSAwIFIgL1RUMS4wIDggMCBSIC9UVDQuMCAxMiAwIFIgPj4gL1NoYWRpbmcgPDwg L1NoMQoyNiAwIFIgPj4gPj4KZW5kb2JqCjI2IDAgb2JqCjw8IC9Db2xvclNwYWNlIDcgMCBSIC9T aGFkaW5nVHlwZSAyIC9Db29yZHMgWyAyOTY2IDI3MTIgMjk2NiAyNzQyIF0gL0RvbWFpbgpbIDAg MSBdIC9FeHRlbmQgWyBmYWxzZSBmYWxzZSBdIC9GdW5jdGlvbiAyOCAwIFIgPj4KZW5kb2JqCjI4 IDAgb2JqCjw8IC9MZW5ndGggMjkgMCBSIC9GdW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4 IC9TaXplIFsgMTM2NSBdIC9Eb21haW4KWyAwIDEgXSAvUmFuZ2UgWyAwLjMyOTQxMTggMC42NzA1 ODgzIDAuNzkyMTU2OSAwLjkzMzMzMzMgMC44NTQ5MDIgMC45MDk4MDM5Cl0gL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBZcFT2BAGAEDRbNu1tGwbW8aWbdvGn7lsa9m2bdu27Zd6uN89 58ePX77LN/pKX+QzfaKP8oHe0zt5S2/otbyil/RCntMzeipP6LE8oof0QO7TPbord+g23ZKbdIOu yzW6SlfkMl2ii3KBztM5OUtn5DSdopNygo7TMTlKR+iwHKKDdED20z7aK3toN+2SnbRDttM22ipb aDNtko20gdbLOlpLa2Q1raKVsoKW0zJZSktosSyihbKA5tP/Mo/m0hyZTbNopsyg6TRNptIUmiyT aCJNkPE0TsbSGBoto2gkjZD/aDgNk6E0hAbLIBpIA6Q/9aO+0ocCqHdAQG/qRT2lB3WnbtKVulBn 6UQdqYO0p3bUVtpQa2olLakFNZdm1FSaUGNqJA2pAdWXelSX6khtqkU1pQZVp2pSlapQZalEFaUC lady8i/9Q2WlDJWmUlKSSlBxKUZFqYj8TX9RYSlEBamA5Kd8kpfyUG7JRTkph2SnbJRVslBmyiQZ KQOll3SUltJIakolKSkF/SnJKRkllSSUmP6QRJSQEkh8ikdxJQ7FplgSk2JQdIlGUSUKRaZIEpEi UHgJR2EpjISmUBRSQlBwCiZBKQgFlkC//QSUfffrCmVuZHN0cmVhbQplbmRvYmoKMjkgMCBvYmoK NDY3CmVuZG9iagozMSAwIG9iago8PCAvTGVuZ3RoIDMyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHVnN+THMdtx9/nr5i83T1wOT97ZvzmUE6VXHEiiZfKg8oP9kkqOnWULZJO Uvnr/QHQ6O7Z2R+zRzKSxNLuDLYHje5GA18APfdT/XX9U70c+lD3/WEemqavx6U/dHM9DfNhrt99 X/9n/WP98tX7tn58XzeHZViadgmnrqr3j/XQD4c21G0Ih2kaBi66wzSMoQ5df2gG4feD9jnOh25c unrqukNoeGQMhy50Q4s0A3I0XbXpu+31P/oO8GyWmau56ZeOx+n7J27beZ6bWv/Fazqau3Fs6Wk4 9E0zV49v639+oG3TDvUDIrfaPn49vK1fPjx0h6Zu64cf6m/ruz/86b4e67t39/Uf64ff1797QH46 Cs00D33VHPp57vqxh7YgyRiW87JM3aGfpobJjbLUJstKhOpIhLv6vn74L+v39BCn4TCGjo6P2DLE Zumqa2O865q2u9bHwpSEbhlSH3EaV6LXF0Rnys4vn6iOLVSgg+6wTKhG2x/QRVE1W1XVnTTzkE/N fMUcD21ULGOzHEI/dms2O9S+KtReNURkbA9hbAutbZj5gLomtW2zirftSGs2QdLxvm0P8zKFSzpu enVmdGd0vG3DYWiW6XhxRMfbZY+Sf/Mv93VX371C1+b6briv+/oOneBzvq/S9Z+V8hdt8/6+HmrR Tdrb9d/1V2vz9r5+AT9r+uG+nuo7Pufq7ntt9J1+2sNsLzpI7GhpFPv1q3s2omy+UN/9VVv+TT// qmLZU1uer/Up6dG5/ahPWb/G33gKpZJh0G8xCXmrn95yfRPQynZMM247udq9HeKSleo+T4cQpqSo Yv/MVt5gn29Q1Mw/2eK2OUwNEmxs8cYPeD+nZyfb3Jbd2ITh+TZ3UR1rG1VHzHBzX/HZnjTGt20a me55mjHGayEvL2FhKM3PnHU82WLewh9NdGN/0dSJxWQEyI7tmbArzTzMNR5u6IYbTV218vC+ssnU uVLsM3Xe+rqp845Oq1A2aXH2oqs0k3bVp+G3v/mtGoEvvlQr8B9mEsyomCH5bzUJ36shMWNgv37x oLbwX/Xn9Bj2AU7X7EK7NIduAUXdpFQv8qKfmQ2UaWkWPPxal/Yb+C9sbGYw15a6WllqLKbZza1V PWepzbbSwVTd/U4n/X917sxSGx+bYPMH0TnYD/ZwaaqfdMHq+wpR3CRfn/ke2DBNQDqfoluxlUAC t4RhWcBOp1BpaQkrRcQXYM15JJgtZCM2d4VKwYfXIBvq/VtmFw/LvGadVIskluG0Fk1YCRwMUxQ7 PTVFJYarQMA74CfxwtjN+MI1W4Ofm7Fs8C0WLOv/RaN3fj7nALKemyzDLnh6gzFnlcZekN96vS47 C7ZEYcz3wV9RvV7hb3foMhowWHl1dmQeFuKsxGXtEbLP/whMkTbH1iNk/gn8ptYbj1BuJQ0u93qE 9RKImg39Rs1KPY6R3JcYpxfY8fVXDcJ9ociili90Qr5qvIe0/fCBHfYCCIrp4hN0K79iQOXrAyZM vrGqLwQMf3lf5c14eg+2M/Ft3wPV15vljCJVGoXe7XIQzdhvtvYZB3G8B7EnFxzEGspvHITEB+Zd zjkIfr02L92IFQkSwmxWt91nEL9ioVgLfDtm0YyjXb9XD89SQQfu8ymuqr57jdPhC6Eh4YbSz0Yx duUD37DMbXVHqIQmvLo+pr5nrdsWMHBhrY+XorS3K5cE2muvgvPokp4TRCaXFGZSJmvQ3o179te/ P2pMaL7cNKJTIABoR0ew8hZJXtMFMNQ0LN1UuySn/NSlebOhkHRizgbBxX0LfDo2ppdzAGLKLgJj Ya4LsjWDZqyFfzaD3npjBjcdeW7ptnAmAWaftCLm2pkDwOSh2FvAXK0CfEN19mlAmp1CdG67ybaW Lf4Pur/KNoA6dty/WUfAaW6sqV2XWJD9irYYa6OzLaGYdgmQrGJCoPzVsKP8Wt/9n2pjeoq+jG4C 2VMm7g673U3BEKFP7ymdzD5nr93upvkQOnDFEdtfjd0WGzf3pLR8AIXa/VLttrhzFv6aGRq6ma04 PN8MpRxPtkONJCNTiifbifNwbGMeHCV5gL7LDin/dqT3ephbMuwxIX+W+2n0kn3EJMaPBY4J7FGl GvQrWmYSZJgTiSD+KcPgyzbXEeG3PNiyPk31nZUeXr2WnMZ5AF2/fnUU87ygvdYCdOTTTJVBs1Bd P5BWptqx8Pm27jpcA7et3D7Vr7U24Y9KOHWKD4Ou5EEemw+jJH9hFPp8a4xy0eSS5O8fq8BuJ4DS XOISiDrf1hvSk8SmMa09iiuDQPpn5kqy/vrY05bTU/2GJOK3TGX93Y4ZkuXsAoOq+mbMQ4NQJ8IT LTqdszh4CCQMj1qUj1QihUytrGorQdwICqZmYtlPLf+8PUFjiAurA1xmjFYmqqQ6xbRLUp3iTxdG rVcZhdUIfUAnC1qDnupkpecaZqtvejg576Y/tCMVgiyVU6gOjSTxZ7bs5LQnaP1hWHoJNu3JamAz TipV5E6bRFEJhJNTXE7h5LQ4Gjg5by+MZQmc8qiL2tX/s2NFxRz3oi9MEXqVLp+4nKXAIuCI/5sF /e2AS1T34l2PwvEf06m/UuXAAzYtq2n3JB15nF3gjIZObuhLLh7rrg+DXqIgFGBgbb/IFqTqZk9X dhd561P82nvf8qjcu2SJkQitHciFTMjr6usrNgK9y/NNcam1rVbQov48FevpWrZvXbIGub6e0OFC O5171mrXjVKHo6xMfCFrlP8p1ghES9ii7Ch0cpKKaEspdmBn1rDsW/ZaAWglTEibUUx9s1B0VRvu 15mhlLHgZ5Z+Mksfvx7eVieqpdhMYimJkfXiHbDLrh7TFRjMSPhhbQQy1O/X4DX7BYAWn3rjVxJu ayug3dp7X5c/4pIsP2M6LCPz00TYxowyKUcOa9/kXGdeVpR9zARENpyXcRKIloRQ3fXHv6SmsYkC GJ2K9MtvIpNEmJ2b9/fVH8ppE1csWh0I9dCagaL/jNLM1AzFFx2wiFThj7XmStEjao2YRrSm4aCA qY2YDk1rYsuFhX1FpDAU1fYvLE4HxxPL2zWIn+SKXROOA94YqtUekxJUp/HKgImb5yBZhY04HAkg zbqS5xi/kxb5vegjXaKNqTMFCecRm09ZRDGVuF7FAoZiLsTmt6KYgTMajj8ikAHo7AcyorYGZMCE kdHQY//9dgNkzgsvaWc9OYKpmLBYkmnG4WxITzW1jHbQuhsHOUTXIJGZ5kSFVLLsSWzdiSdvxjLD wNGICkyQRieEOhGwqCg8hDzgoVdw44/QYvXIJSzTsMk70usllnFa6QcircAyuL9umOzsDQ5N8rfs w5GwqvADgeTuOLCNhFdEQWEmwTu2bUYzQTSAB5MrckKBZZwkDiXCDSe5h6mcc/Y5qf/CjyY5S9/k o3Hm1eSzkLGMU27BMoK7I76YFIo4oBmABwJNmJkCjESagZVeTkiAggTnsG3qRzhxOTYR5ERQg80D 1EwCgSI6GnuDPYZs0l2EN36PWiRo4jSDLomjApnUnzwvMAhRIsYZTEQAUcJKcQQRSMU7BTvlGSQc 6KmTMGnhqsCOG2dVTF/erGCXFg6zGVXaFy4vZQnivdUJJc+qKknQlZIj1wkld1kLuZL8G7ADMseW MLJjsHMc1+4FO2EZD43GEHpILKMFnNZxxhHvIGfDzIXfhnZAOZU996lQjgu+QSLjQiDezuQcPgLm 7Od+EeckaPIyor1EGH0eHQqlX9KFo5jU1AHP6HM5ORNvegHwiOZwEu8E4jlWnb2IJ8yiOtTeCsQj 5xROIYxnIJ7qCPEcxX6es0iI50iclRTHmiypeS9UflSG5jw8uDlDM5LvOMY2kbI3T1PAGwJbCWVj nkbKAnJ7I7xJSRli16Unh1bkaZyECbQ8DZk+te0pS5Na5CxNIj07SyNHPwWlx7RN3TsBp2JZmjzW mKUpWyj2iYQLyCYAjzo5yVggm0QrjL7TMrIJE9MwiaNNiIXMYTdLYFDQwhgzWCWNDTq1S4FsAtO+ kN/J0MYpJbZxWgluIi3H9SEY9+Qk6+AylOjGZS2dURxRztT4qOEVc0WJcgu6EW1VdDP20dMf3xfo JrUxFDMU6IaNU8WUTSD0T7iIReAAr2V8HNwEz7Nox+kughu/L8GN0wy+OEPFMqm3iG0QxLHNGAV0 bFMl+RXbpLubsU0dONQyt8NQvS2W8sKy0Soh3qjUm2Vj+rKKueqfUPNCWc+qufDKqm+yMisZh0X5 odlhT5FGEzlB9q8UC0ps03bDvDkZvxvcsNPJ7nrS/lcEbqLgnwnc7Ob+c4Kb4RZwg3VrO2zsJp3z bHATSCbKyfdfCLg5IY6ec78IcyJgt7Iy6SVgInVrMmpQGv0EB3HN5zrXM3Iiou0oIAXSAlSV1A9O YACpe0aSOH5yQstE8B5JIwcZxpmAnWPdgM2BoDxTeN2F4E/NQ2pFiZl8pFiaRMK/LyGWJow35kuS JiOOPQpgFGHFyw/yWgodxlbwmiTLMlPFdBqvqHAEiXoHby5E7pmiIgirkiSSiliZ5uPJzG1iCgmU AKc3eozierrs5Vffv3v8/m8f/v6np/rdX47gLcHSyXLey9dvuvr9G8Lhfbj1Qh6O/LO/wLMrDydb gdcAKJNRrcNUWx0QCpMKxIsU8dmsSocdTzQoArwCuYcJqCAt9J6E9AgsSreGUvG+TulGYWRFFmMp 1UvBf9ZtHfweF7zMKFGmAAgXBKHDKrXCREiXwfn6fRvxsXCxFiqasLDbKHnlLPPYvFsfv3v0VAzV 9O/ZI6qiPwvaLaop9iZafJYfHKOH/DiKJBFZ/LIXjgi8Yub+cDjU33Z/zOFMWUpGhz62hCyLLmBH lphN7UGFJV81UyirsTdAUW48Ww1wdF4UktOtMbosN3OZApOm5VW+NgCGjkmyfTUwkaSLnoUS0xAL yPEx2hw/pkHBcwrIJFabPCTUu0oED02KUVposmohO6IgFAVke1ksFpADEocJY1aGJk5jiF7kTe0y GpP5kHpmQeGtxVYi+AKzDeOhlbfQhJcnXVkttHEpuA9gSeonVcaNkQKvjC+dVoYmTsuIMHIvghWX oQxNKLmrrCWWjCMqMG6cCXh5aOJzc0toYqaOfH5AEqkJo2DYpHzP7KSEqbeBIiEHHZN4jZlX2TMa kMQAZeKIjdyrjaP1JMcypCTtAYq8hSodWnfpLgYo6R6VilnTKtE0JnGGdhN7Y00sYHFp5HGSsUnW xCyNRcOUdOdG7erGzItKoV+4rsKUm5awUCNfVNTUz1Ek9d6l8oUqRxkUh7h6R1lZ1I380I7DFBR4 WtiAZZgi9eZjqLk7SpGapCYIPmsK9vMVnEMcwCZa+SQV5/3cL0Yrnmf9JCXnFJvEC32hUqvTlzKw AxBpxNpughQvoApm0APNlzFDjJjBMVhOORBVxCibEu//X8l5K83OirOUEo4rzmfK2wuJ5J6DSKu+ ALJNM02boefqtoElwiE5sW1natcBz3m07rs64arPVtyeOHG7TgDfjK9kB2p9O0ENskQg8XR7YwIY MEFQPTlcorq9JlC0lkNp4hgzysJEB07X5Meeqs1jtxe2yRFmfCReZUUQ060HG4uRchaoeERblDwg 2CGqZKezcxnQKAZeQqxIKt1NJDlMIszg4FHXCExyz0KJs5W3qEqAxenFQAKP/nM7Tk9R1ZsSwKoC ddkwIEMWyiklwHJaCbCc5r4MXpG7UwiAogwlwHJZSy/oI/IkYsW7/zo1GV9FwnPgVTWNciZVkZVc FqBKbhVPTRIYeSF7mgyOMZ/6IwexBU4RgFh1m1cfgFNTgadmIKICMO0k3UU8le4znqqdZgf1EkcF TKm/CKiSPBFQubCOp2oZhkApHWmBoi7UjcpTe4GYIpAhKXO9cZlAkHk5j5cJ+3h2mbJCxTZPRcUh krJiOueCckKlo5jFOUKXfAufOoDhldN6vBzH+wTyL8bNF067Bf6OS6sxzBY9ZQdgryd8XAE7Fr5/ 9Orr48cd03PBN6jp0xSw47Rc534RNaVi9OcpYKfS9p4CNorDsfYVfJoGyf65i96ZcsnwiT/R00ny pcBPP2cBey3OxczuL7GAPXMewGuzlh8aYxZt31sGCbyMHMB1IERyKN3eCF6IGvUtA3lfhCwgRvSY gge2FBGS64lhCDFF5A/lVwwS5Zm1a45eWYoU8KKvHCQCfs9q18VILUHkj2gLSRAVhLPgRV7taHW8 2dQ7rYQvTnPTXgXSoNPQCgpx/CIrQahbwhcOzjaSTC/hCwBxZlsV8EXOt1MBKOCLU0r44rQSvjjN vRup5cjdKaxjlKGEL1HU0i36eDJ68TFn+OKUG/GLncubASeKLiKISfcFkkk0QywTic9GU9qkf2TL aDoo4pklppsUCfH7gjqu0kOSjs7poXQX4Yzfgw0SAnGaZXycoaKZ1FtEMy6NaJukh+Yoaz6hl8ai 6aF0dzOwQdVEP1RJ86ruWME6+Hr5CsIq6nuZHXLaJX2H15G+w2ur7y7pSrGi9Ft0g/bqKzmfLDnE 3z/Rv8NgPupXVMKOgl8HIM95DYFj1Dot17n/nPAm3FLCxsp1jZ5+IGKxNxI+Et7gbzhevnoj4eeE N1txTuRsjk/qrXI2VsLmkyQeL9xQwuYTiGqf64xOLmHLG3GSdpNo3kvITsM+pCK203IxmncoFt6l cAKeSE6fScIt0dQX6Ql2MTVexWaohJExeNcqNqurVRsXQb2aUuCVqtjeCl6p0Oy0XIxO3GN5WuVS GeCVStYuK7wyLQ4oM49z4yLAKlLEpsufAzifGUtZy2fWsfufv469yPmwVR07UbQIbXXsRItlad6E FEApJR6tYy+kYZVLKmWT/tJaoJZ5rA1n3Cll6zORK9hTS6CxlL34Pd7YStmJgj/2Unaixco0hQjj 6/exZ1Q0UaJ0wkWr2S5/rmanEXrPPi/u2XeGVqmaHfd6NM+3VbP7opr99T8A8mw6BQplbmRzdHJl YW0KZW5kb2JqCjMyIDAgb2JqCjUyMjQKZW5kb2JqCjMwIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9Q YXJlbnQgMyAwIFIgL1Jlc291cmNlcyAzMyAwIFIgL0NvbnRlbnRzIDMxIDAgUiAvTWVkaWFCb3gK WzAgMCA2MTIgNzkyXSA+PgplbmRvYmoKMzMgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQzLjEgMTEgMCBSCi9U VDUuMCAyNyAwIFIgL1RUMi4wIDkgMCBSIC9UVDQuMCAxMiAwIFIgL1RUNi4xIDM1IDAgUiA+PiAv U2hhZGluZyA8PCAvU2gyCjM2IDAgUiAvU2gzIDM3IDAgUiA+PiA+PgplbmRvYmoKMzYgMCBvYmoK PDwgL0NvbG9yU3BhY2UgNyAwIFIgL1NoYWRpbmdUeXBlIDIgL0Nvb3JkcyBbIDI5NjYgNjAyIDI5 NjYgNjMyIF0gL0RvbWFpbgpbIDAgMSBdIC9FeHRlbmQgWyBmYWxzZSBmYWxzZSBdIC9GdW5jdGlv biAzOCAwIFIgPj4KZW5kb2JqCjM3IDAgb2JqCjw8IC9Db2xvclNwYWNlIDcgMCBSIC9TaGFkaW5n VHlwZSAyIC9Db29yZHMgWyAyOTY2IDkyOSAyOTY2IDk1OSBdIC9Eb21haW4KWyAwIDEgXSAvRXh0 ZW5kIFsgZmFsc2UgZmFsc2UgXSAvRnVuY3Rpb24gMzkgMCBSID4+CmVuZG9iagozOCAwIG9iago8 PCAvTGVuZ3RoIDQwIDAgUiAvRnVuY3Rpb25UeXBlIDAgL0JpdHNQZXJTYW1wbGUgOCAvU2l6ZSBb IDEzNjUgXSAvRG9tYWluClsgMCAxIF0gL1JhbmdlIFsgMC4zOTIxNTY5IDAuNjk4MDM5MiAwLjYz MTM3MjYgMC44NDcwNTg4IDEgMSBdIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCj4+CnN0cmVhbQp4AV3C QxAgBgAEwbmcbdu2bdu2bdu2bdu2bdu2nUfy2Nquhv8FCID95x90wIDoQIGwgQOjgwRBBw2KDRYM HTw4OkQIbMiQ6FCh0KFDY8OEQYcNiw4XDhs+PDpCBHTEiNhIkdCRI2OjREFHjYqOFg0bPTo6Rgx0 zJjYWLHQsWOj48TBxo2LjhcPHT8+NkECdMKE6ESJsIkTo5MkQSdNik2WDJ08OTpFCmzKlOhUqbCp U6PTpEGnTYtNlw6dPj06QwZsxozoTJnQmTNjs2RBZ82KzpYNmz07OkcOdM6c2Fy50Llzo/PkwebN i86XD5s/P7pAAXTBgthChdCFC6OLFMEWLYouVgxdvDi2RAl0yZLoUqWwpUujy5RBly2LLVcOXb48 ukIFbMWK6EqV0JUrY6tUQVetiq1WDV29OrpGDWzNmuhatdC1a2Pr1EHXrYuuVw9bvz66QQN0w4bY Ro3QjRujmzTBNm2KbtYM3bw5tkULdMuW2Fat0K1bo9u0wbZti27XDt2+PbZDB3THjuhOnbCdO6O7 dEF37Yrt1g3dvTu6Rw9sz57oXr3QvXtj+/RB9+2L7tcP278/esAA7MCB6EGD0IMHY4cMQQ8dih42 DDt8OHrECPTIkdhRo9CjR6PHjMGOHYseNw49fjx2wgT0xInoSZOwkyejp0zBTp2KnjYNPX06dsYM 9MyZ6FmzsLNno+fMQc+di503Dz1/PnrBAuzChehFi9CLF2OXLEEvXYpetgy7fDl6xQrsypXoVavQ q1dj16xBr12LXrcOu349esMG9MaN2E2b0Js3o7dswW7dit62Db19O3bHDvTOnehdu7C7d6P37EHv 3Yvdtw+9fz/2wAH0wYPoQ4ewhw+jjxxBHz2KPXYMffw4+sQJ7MmT6FOn0KdPY8+cQZ89iz53Dnv+ PPrCBfTFi9hLl9CXL2OvXEFfvYq+dg17/Tr6xg30zZvYW7fQt2+j79zB3r2LvncPff8+9sED9MOH 6EePsI8fo588QT99in32DP38OfrFC+zLl+hXr7CvX6PfvEG/fYt99w79/j36wwfsx4/oT5/Qnz9j v3xBf/2K/vYN+/07+scP9M+f2F+/0L9/o//8wf79y3//BRVJT/gKZW5kc3RyZWFtCmVuZG9iago0 MCAwIG9iago4NDAKZW5kb2JqCjM5IDAgb2JqCjw8IC9MZW5ndGggNDEgMCBSIC9GdW5jdGlvblR5 cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsgMTM2NSBdIC9Eb21haW4KWyAwIDEgXSAvUmFu Z2UgWyAwLjM5MjE1NjkgMC42OTgwMzkyIDAuNjMxMzcyNiAwLjg0NzA1ODggMSAxIF0gL0ZpbHRl ciAvRmxhdGVEZWNvZGUKPj4Kc3RyZWFtCngBXcJDECAGAATBuZxt27Zt27Zt27Zt27Zt27adR/LY 2q6G/wUIgP3nH3TAgOhAgbCBA6ODBEEHDYoNFgwdPDg6RAhsyJDoUKHQoUNjw4RBhw2LDhcOGz48 OkIEdMSI2EiR0JEjY6NEQUeNio4WDRs9OjpGDHTMmNhYsdCxY6PjxMHGjYuOFw8dPz42QQJ0woTo RImwiROjkyRBJ02KTZYMnTw5OkUKbMqU6FSpsKlTo9OkQadNi02XDp0+PTpDBmzGjOhMmdCZM2Oz ZEFnzYrOlg2bPTs6Rw50zpzYXLnQuXOj8+TB5s2LzpcPmz8/ukABdMGC2EKF0IULo4sUwRYtii5W DF28OLZECXTJkuhSpbClS6PLlEGXLYstVw5dvjy6QgVsxYroSpXQlStjq1RBV62KrVYNXb06ukYN bM2a6Fq10LVrY+vUQdeti65XD1u/PrpBA3TDhthGjdCNG6ObNME2bYpu1gzdvDm2RQt0y5bYVq3Q rVuj27TBtm2LbtcO3b49tkMHdMeO6E6dsJ07o7t0QXftiu3WDd29O7pHD2zPnuhevdC9e2P79EH3 7Yvu1w/bvz96wADswIHoQYPQgwdjhwxBDx2KHjYMO3w4esQI9MiR2FGj0KNHo8eMwY4dix43Dj1+ PHbCBPTEiehJk7CTJ6OnTMFOnYqeNg09fTp2xgz0zJnoWbOws2ej58xBz52LnTcPPX8+esEC7MKF 6EWL0IsXY5csQS9dil62DLt8OXrFCuzKlehVq9CrV2PXrEGvXYtetw67fj16wwb0xo3YTZvQmzej t2zBbt2K3rYNvX07dscO9M6d6F27sLt3o/fsQe/di923D71/P/bAAfTBg+hDh7CHD6OPHEEfPYo9 dgx9/Dj6xAnsyZPoU6fQp09jz5xBnz2LPncOe/48+sIF9MWL2EuX0JcvY69cQV+9ir52DXv9OvrG DfTNm9hbt9C3b6Pv3MHevYu+dw99/z72wQP0w4foR4+wjx+jnzxBP32KffYM/fw5+sUL7MuX6Fev sK9fo9+8Qb99i333Dv3+PfrDB+zHj+hPn9CfP2O/fEF//Yr+9g37/Tv6xw/0z5/YX7/Qv3+j//zB /v3Lf/8FFUlP+AplbmRzdHJlYW0KZW5kb2JqCjQxIDAgb2JqCjg0MAplbmRvYmoKMyAwIG9iago8 PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNjEyIDc5Ml0gL0NvdW50IDMgL0tpZHMgWyAy IDAgUiAyMiAwIFIgMzAgMCBSCl0gPj4KZW5kb2JqCjQyIDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9n IC9QYWdlcyAzIDAgUiAvVmVyc2lvbiAvMS40ID4+CmVuZG9iagoxMSAwIG9iago8PCAvVHlwZSAv Rm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9BV1lSUVkrTHVjaWRhR3JhbmRlIC9G b250RGVzY3JpcHRvcgo0MyAwIFIgL1RvVW5pY29kZSA0NCAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFz dENoYXIgMzMgL1dpZHRocyBbIDAgXSA+PgplbmRvYmoKNDQgMCBvYmoKPDwgL0xlbmd0aCA0NSAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZDBbsMgDIbvPIWP3aEi6RkhTZ0q 5bB2WtYHIOBESAsghxzy9jMs7aQh+cD/+zM/lufurQs+g/ygaHvMMPrgCJe4kkUYcPJBtCdw3ub9 VjU7myQkw/22ZJy7MEZQSgDIT0aWTBscXl0c8KVoN3JIPkxwuJ/7qvRrSt84Y8jQCK3B4cjj3k26 mhlBVvTYOfZ93o5M/XV8bQmBEzHR/kay0eGSjEUyYUKhmkary0ULDO6ftQPDuHeeWq1KNXxq/8Mp aPniM5JdiThN3UMNWgL4gM9VpZjKg7V+AG2acBAKZW5kc3RyZWFtCmVuZG9iago0NSAwIG9iagoy MjMKZW5kb2JqCjQzIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0FX WVJRWStMdWNpZGFHcmFuZGUgL0ZsYWdzIDQgL0ZvbnRCQm94ClstMTA2NyAtNzM3IDE2NDEgMTE2 Ml0gL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5NjcgL0Rlc2NlbnQgLTIxMSAvQ2FwSGVpZ2h0Cjcy MyAvU3RlbVYgMTAzIC9YSGVpZ2h0IDUzMCAvU3RlbUggNzcgL0F2Z1dpZHRoIC00OTAgL01heFdp ZHRoIDE2NDAgL0ZvbnRGaWxlMgo0NiAwIFIgPj4KZW5kb2JqCjQ2IDAgb2JqCjw8IC9MZW5ndGgg NDcgMCBSIC9MZW5ndGgxIDg5MjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvVoL eFRFlj5Vt/PuTnceHZI0JLdpAsgNhIePBFvoPDojRDAJQbtBoRs6EFAgkvBG0qKB2OADfDCfOoo7 s/PtY5SbThw7q5isLn6yO+4g62tWF1DHx7crO4zriN/o0vvXvbcbksn4sZ/u3s6pv+qcOqdOnTpV 997udG7c1EoWCpNEjUuC7atIu8argPKV64Ltetv5LbB45eZOWW9npxOl/nJV++p1ejt/iMgya/Xt 2xL6op+nrTUY0uUk9K9uA0NvsyuBE9rWdW7V284vgem3b1hpyMcXop26LrjVGJ/eR1teH1zXqvcf 3wOc3L6ho9NoB7T2xlajP/MRmY8QA5fTFrLSjZSGlo2m0w6ilDOWWZgv0+SpLPWRmOWL5Vb3H5gD 08LV3/XKiwKPn7KfO7/5jw6LM2MBmhlafyGA3bQXLzRiziXnN5+vtTiTEiEVF4/RHUqMVoNuBS1S qrPBrCcbiFMXryPG53I39BQ+h7ujTPndC/w6MK9DI7+UjkJmA3G2l/VEi0s9MXZvn62giqqzWQ/Z QJzdzbphS2H3GLiHdUe5En6BdcHsabbTs4qdPlMwZuybb6HYsbPAYd1RuqNih7RjZ9EbJ8HavAXF unYUt29Acdv6Asfy9V238dvWd20s7tyUbx+7ei2KVWtQtLblOx5oPdx6olVqbeu+o7ioo2B7bZFz G4gPSM3SfIxsOyrVUyOIk0eqimZlVw3Eh6TKaLZR6cswVzVWZ0lTiUnTpRlYAYV/yf+L0oEfRV/i Soy/3/dSCHPl7/XNmF0lMOqaJKygkp+vVX4TnVVlVKZMMypOl1EZU2RUsnO0yoloDio8zLcK96oV 3kmNII7Q3orarahl8RvIAboNJKHVgFYDcT6bm6iASnklMBc4k88QwebTDawAloA/jc+IlpTKMUBu QdUAO88+ikpKZrXMviTGfsf+U2ixswZ+buB/GPgZ+1SEgX0CNAE/BqJ//B/ZR31ZcL16HBiMNqPc I0TsYXZQM/iQgQfZg5QKxQPANOADQDHg/exBTHlwEE1G7SjDQsBujh40KTG2KHpAwI3RQwKu7uuS FCRYVTS3sKo6g01gZZpTNpajoclz7bcI39eNX3PPJ8XFVY89LilPPG5SHj+UqTwEewcOpioHYekR 0I8PceXRQ5Jy+BB76tCRQ4OHpBel66V5YnLSvGg3V0RK1PbZcqpKX5KwCeiMKKWrpCsRNbk6V5pF 00EeUCPIJM2S8oUT0kwDK6R89KwYRBO7ENkjgzg/Fz2aivz5MDqYLobgH0THTNZS4IMociHGz0T3 ZkJ+um/QhKnyd/pcZSK/3onasWjofzIKl6ot/FV+TMSTv8yHNPx7A/cL31/km/kWMRW+xZgKv0Of Ct8opqKVHh5IGA1EM7M068ujYwq1yrLohCu0yhJNrzqfL9UURWnl81EW8Hk0EcQpg0+lIhCHe0o0 x67pXdFnyalCtrlEth3l47kslps7uRw1KcdhT8YZUoJSbK5SXcq+Yr/WFvIMe45kcrLT7LnoRKcc Y6ejJc6q6mL2b+x9LWveM/BfDfyNge+ydzQD77C3tX5vszeRXeogmoy9xd7UmP+iMddUZ7GTmMeA KNlJQ/aGJsOIJ6I4BAaQ378W+a0Msp/Sz0D9ICl+hv08mmfHMrD72H5twH0GRoAirW+K7sExwRZH wxKgJbonBdAc3SugKdojoDHaI2QLo90CbhALFWOV0b0CZkQHBXO8zsz2ZEH4x29MyjeiU3zIk/kH kZhfsTNfMdHM6LWPrfJ8jJQXrWlHLNYqeOrpb+wP9Lf3h/uH+k/0n+k/15/RfyRU+tmnJuXeSJoS 2Zeq7AdB5fn7p8+suv8+DAn1/PtKXFX37ePKvu50ZfddJuUuMYf4UF94/gJhvy88t1bHK6t0nDxN G9ccHueqCu/iStcuzarHfKd3XtWdaOyCJWFa7oHpHsxwLxh7ulOVu+/JVO4BtneHu/lgN6vOlBZJ LZQtNUpNKBdKN4oyKoVKqxdLN0gLyCo5pLHSODJLVskm5QDNkkXKBk4CXkEWyQm5C1gCuQycRG7J CSoBOUBWkJnc/Bn+LD9CZv40/wv+U+CT/Cl+GDgAfIEsvA/y54Aq5FHgAHT6QKrQBT0NehJ0F99N 2XwX70K5k98pSs3fTXw734G9YuM5PBd2LTybW4GMcy6RmV1gcY57P07yHHocxEVfnPU2ego0CDoN SsHJbaG5oC6QRKXsAvZNEXQd8CkPNu3AIviRB7KBLKBUECM3+rrZUfYSG8R4vSzK+oDPsiNMBR4H /hNZ2CuQHwMOQf4y8Dh0XgENCV1QL+hZ0Dq2nm2AXpCtYCuBy9hyFtDaq6JjSkura9gqmgvqAkls G6Q7YK0DWpuA7dDaCNwGSx2gdmERtAoUBC0DlbOpZGUT2SSUk9kVlM2mMAVlISsCJ5flocxndnAK 2BiUKSwVJWcSSmxhUXr+CqlyIW51XGMvvNpuv8qee6XdOstunmnPmGFPnW6XKuw0zT5xUvbkSdYp Sna5Yh3vyp7gspaUZsulVqstx5yRmWVOTUs3S6YUMyJtJsmTV+wiKa80VRpbWmqda+2ySrLESqUb pUEpLpkcbJylMK3YYreNseSa8i0POli5e4p7snuie4J7vFt2l7gd7kK33Z3rtroz3KluyU3uxllM zW2ghpYaNY8BF9Wos5SGmCQ3qzOVBjWjcamvl7H7/eCqvCfGqEU19cQ4ILd2yVJfjBUJcbdjQMxb bQh03+fv5VSjsh7VtcgnwNPkU+WemI1afL2c1fj9fvWahkbUqcavjFNDDegWHudXZ4rKg+P81KDO blIdrhpl5NUhGB2dGlyU9U6e6FWneINquTdQd5GtKIQGHPaqF7zBGOOuYcJExxHGEmxgBy6jGeM7 vTG+HWb4rtHNJPVi0kJvTLoBXaVG0bWzgyVlo1Q6OsFkWjlSqg3euQmODJOAgasDYRCqIh4aXFJo bnfoArpUTElLCW4CLxnkkmkbNoVWh8JqfQ6/oqiFqgtJklAwLApgMbZT9q6ti7E7ddilQ5cOYR3u 0mG3DnfrcI8O3Trs0WGvDj063CvAmBmeSq7VuNytw3U6zNFhrg4eHap1qNGhVoc6Hbw61OvwIwGI G+bW0Zshsr+xuaZBTW8GNS5Vi11ovIbG1WiYXTWUqlAR3oxeo7JEqb/I6KVpDok3Moq/p5WfJeoX NsW1OtGFdwXv+1zi3UuQ6fsYEbrHCAdq/Nr4gfiXNEhtlB+vjv84/vmoZnfHd9FpOknHqZ+eocfp FOrH6CUaoL+lj1B/FbVn6BFaAe2f0U+oG/g39DQ9TBvBFyg4x/7UNps8jHeeztMhVk3zgSOvh2Hl 4ZHMP9v+JF48iuxUfDztpJ18E/8tbcLnMVj8BR2+pOca1P+SOvD+e4ydpRXsRVqF+fRQiB7gjfF/ TzlOBdJWvPJsMB0WmTDsepR8tI1C0hPx3yNPrGmNuKkeif9evEsPu76r3waMnbgGaD/LpF2I2wy8 mT9GNQnBcEQMz2MOKzGX3fgcwmr04bMT4x64tGdqnWgl/E4nPVsTeZQivmvAFf8UtFWrHhPxNjL2 A9qMEdw0Fa9z1ngp8ub6eGt8W/wn8aPIBrH6PzeyYhCtv6YD7BA8WEG30E38V3ixE60NaN9E89k4 ZqEnYfsqbZRkYewqSWeIHBdXwj+TEUVjb8FL/Ypfm6ixg7gxn6fX6BWKaf48QQcpQmHEoRP5vYQa 4ftsfC2h9/tYy2Hh+cU+y6gFuYcLOTgH8zmVsC0w5S1t7xvf3fyJf2LvH5Ne1nVEFPXrQqJC9DpW Ut8NPYjGJsRjJVb2vLZ7xPodw6o9jVxLyG5KSl/V1lb0n0MzhRfx2fFdiP0/0820gffhgeVu6PVc HCpZ+wW4iUwupFNsTlIyvPJ98n4n9tAxenSYwW66lVqHcUY0RsZvhHiUZspZPDo+jFX7Jcbbgc/O UToNIL+PIU7bqYmqaS/W8RT2Rxv2cAgRP8lkrM8bOMVGu4KwewKrskFaJRmrPFo3ZIj4jHKlnNWZ 6cRMyPxk7ia66rmbaA3DOSkSvctykR8P0bvIiWfoeZwlqwUXWaxf/7s12k3raYrxIY+ned717mtn V1Vec/VVV86aOWN6xbSp5cqUKyZPmlg2wTXeKZeWjBvrKC4qHFNgz8/LzbFZsy3mrMyM9LTUFJOE 5/lyVqgW1vq8a9Wi2gDuhXUum6yaF55bUKFSrsPpypFnVfinGr3UFEWlvAY1H8985Kn0q6nKyC4L VanM9oUTygscslc1leHPNT8YUic3+5wu29uOpNwPs2pxrc/pdKi8DH/zIMLf/KAcUm2N4EOgceap 1OgTFIt/WAkmVTr9KJt9akmiiUfRUZwcwI4aGuHmQhax9ZqLautUyu8l84cq2UW3c5WElzB1Mh6N y2yoadaoQmX5X6gsT2X2BZjS8CGE2pnKUWLgDa11eUNrENFQ4GJMz+kRdcoROdLsy5nlcDo1p/Ek 0uTrzcqsddW2ZmIWeGgGg3ozs8DJEgwsS3svM89hWoWbvbPxxJ1uQfhyhbteQWtVz74AKq46xA2S vIsSvCTvv1REUNM7EbppNaaNqabWqmm6E/Ia1RNUaZ/cWz4U2Y8n/hUBxRxyhYK3+FQpCKd6SSrz trWoYxsal4AFJ0CBNlksd51WiMWTvW1yBG3RN4DSVQfV4fxQW2tApAkLuOogy6j17XUOOfBK4tvr VXMU1QJ1y/bfOqSIt3CNLJqRyF5ZPYxXkUukTtEHSVA4tVyOeF0YDca8a2vEilUkl03LxnkhbXE8 +4KyGl6xFjHDX3B/Iv+dEZtq/sqJ1cH6QFPsDhFgQaHAWjGVtdA0AeTIvlZtqvu1qSFfxWOnIKGI 7KfF0F7i87a5vIinMSACAn2pbKSu06kWKUIxEvEKF4MheC8ig78iPKzDDb2BPeFQGPypVT0tGlCL tgYY0ROs8xssowMkJqyD6gnU+f1iUvoCqGlle1OmueSIMJpWpuYrNuc/QDY0tbyh2eetE9mJnrzW d93ZQsdZ1PGil2CzQvSJVJwVQRKSRa6GJj0L2kR8RBFo0TcwomasPLoa/TWrrxc6Xoduvas+EInU u+T6SCASjMXDK1yyzRXpNZsj7d6ArO18Bv7f7XOo9fv9qi3QxmZjkUW+1eMJPq9pqVieerktCA7+ 5rqclQ5nDkzrfXByjC429hkyHnkv9lnE9jlmbMaJ5JDrxfESw6ngUG2VYpvCk8U+7IOVGMIb0grs D7zmcofYKZK/zLtmkREghxNDagkjzr0mgwsjTqfYQ/tiHlqBhhpu8ultmVY4ouSpULB2ASEZSkjs i4UknJAk1QMurFWheM3WcuLP5TTO82Q+R3JcuXKVOMzhHf7mhdShFszx60o1HRHTljuv1ic5uOiC GndIopap4JbgVscomqKICU7JiM0ln3CpNkVNqfUNOdx+2ZaDA5Ilk8GwKNLUdsJ1nIlDlPJtKnOr rEBsK8KhijDi0B9TCWFSUfZGAkb2XTo/dBW9Q23JfaTPAhtXTBJhsLmwbx16PHJyXWKqvxLZrt/g 1JSyerGpsDZaxOb71Wxxs1OzP9cKTM5R65NxDGHbNmkV2Su3iVVX5UCddh74HUKeYMfiZwJ14vzz IdHQxWHkN7IcYTP2hBGGhhZfotbsu9Ox3T8Vv4qVN8QoA3dS8Z1MjMW7Y1Q3bgC/s0nLl0HcUi7L 3jV1GBCNxeVgTHGidlM5clOkvs/lF3eSeaGILJI/hGlpCEFrxF+BfF3kw3mJr2qcqsfvSFZb/f7Z sHOzsAMVdI/4YWGtYQGosSr+G5185Q04qSY2+nDYhuuQ6HViC2O6Q9hVQ2LGYiL+pKfw+M41hYbP S+CzfwrkS3UryNUwTPgjEWFzkc+FNI9EHBHMw2jjG56RDI/BiJFQwcS9MRZuhC7ApT0feF1Ol4i8 vw5D3YK4J04p/Pb43RFelvQbmsvh7TItwoEfKMLBy4nwisuK8Mqkp8MiHILPK0WEW0ePsMonfkeM Lw2pRw+pZ5SQrhoW0tXfHdK2pKPwag3ca9NCuvYHCultlxPS2y8rpOuSng4L6Xr4vE6EdMPoIf2/ SNr2YRG+47sjvDHpN5zsgLcbtQh3/kAR3nQ5Ed58WRHekvR0WIS3wuctIsLb/v8ivP2SCOOHTWa8 eKGiV81gmsEU/8mQEMokg4M3JHxDgA9+Jkmj/OdTuYkEVbz+5utaMWO6M8eZU4aC4b3wW48U/jac Qt+QxxSGJn6A0a54Jd5TR7uEXB+R4Yd2vZZKeUTVN/ubm/zKDZtWrgkFf7QxuD6kvXbrPYQlG2hs 3LgEI1k3+vwPaEuB3wplbmRzdHJlYW0KZW5kb2JqCjQ3IDAgb2JqCjQ3NDkKZW5kb2JqCjI3IDAg b2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1pKWERUTitU YWhvbWEgL0ZvbnREZXNjcmlwdG9yCjQ4IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2Rpbmcg L0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgOTMgL1dpZHRocyBbIDMxMwowIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDMwMyAwIDAgNTQ2IDU0NiA1NDYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzgzIDAg MzgzIF0gPj4KZW5kb2JqCjQ4IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5h bWUgL1pKWERUTitUYWhvbWEgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTQ0IC0yMDcgMTMzOCAxMDAw XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDEwMDAgL0Rlc2NlbnQgLTIwNyAvQ2FwSGVpZ2h0IDc0 MiAvU3RlbVYgOTcgL1hIZWlnaHQKNTYxIC9TdGVtSCA4NiAvQXZnV2lkdGggNDQ0IC9NYXhXaWR0 aCAxMzkxIC9Gb250RmlsZTIgNDkgMCBSID4+CmVuZG9iago0OSAwIG9iago8PCAvTGVuZ3RoIDUw IDAgUiAvTGVuZ3RoMSA1MTI0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AcU4a3Bb 5ZXnu1eS9Yj1svySbN8rX9uxLTtyJFu2HMe6tiUDNZunk0pOHCRbchSXYAU7bSCUuLvbhlVSEqZs gaUDmc5uKLSQ6+uQym4e3tJhWrY0AVqYoaEESgvtNE2GGTpAi9XzXckmYdJ2pn/2k8497/Od73zn Pqfu3JuAFTANLIiju2MpUIZpENGDo1+c4nO85gIA885YaufuHK87CaC+d+ftd43leNNfANiTyUQs nuMBefAlUZDjSSvimuTuqX053kR5/vaJ0bze9B7y1t2xffn54SLV3xHbncjZF71D+dTE5FSelxC3 pu5M5O1JGPP50vW8EYCglRaiUAAbQQUMmEGENZhpm/pe5IiiJ17vnSf+vfs2U9cH4NAq4Z9ZmK+g xMnQ+29njy9G9M9qaSQd+uQGclqyGAEw8Nnj2VP6Z5VIeaWCtHMgkonZ+mafmCETcqnDlyF7ZtlO 59EeO9mD5i143ICQQngc4RzCmwgaMOExgHAbwgEEVXaBbJYrKn1zSIzK1iKFWCd7W/NETR0GXzfb VcKZzpBtcAWBwdmHZsvtdPah2eJiBctms+IRmdXpqSCVTy9F06PBh+XiHDEi24oVycjSvJuWiJ2y 26eodsrGOoUYk3WFChFbIhKyN2eTkOsbFVVCruQxyYRsL+foTDF5/ca8T3cgT5TnVhibLVLSjc0a CmmWt8n1HsVivbx1KEfM+tf4WnpKyHpc5Xqs4nps3hQepxFwi0gczAgMXMDjJUqRuJyKKxP3y0U2 JUi/XFKSJ7AaNKde2UJL+yMk9EZF0i2XlinEWtmABGkhbtHg4d59L86993ILx58mftxHP8b3y2wZ 16Mna4gHm4wj7YgLEbcRj2zj3D0rkCfER7xgRGkrYhvi1cQrmzlxnnTAUdIhuhnTr92/ZsTXq2t8 L70W4F59zc5N/4L8AhH3Gkm9Rl74SSP3wk/8HS8Qw4+DP2Yy2YVTF3UW3/qXCZJildzg8ZllXhbl DXJKnpaPyZJ8Qb4k6xfkqzK1Fvc/iwvigsS0ldvKrN9y2xam41wjN3GOPH7uxDmmfa6Yc/+AnD5b yp05W8KdPVPMzc9t4k7NNXDfn/NwGYS5Nj/XFfBwawNrue6Ak+sLVHK9gU1cD4KIEGjzcB5vnPO2 tXJtrYNca1sVd6H1UuvVVjaT/ePsydqbfZnspdmTZgHxH0XjSZ3Jd9J+M3fhDnJpj7IK3cO0Offg sjLZ/xV1KSs2wwR2BE3ffofO6ks9QsSd6JYamx47NiaNqU4kziWU1f0qjl4T3zjwDWbiKEndTw4c fvwwM32MwMiGkYURVoylYox5G7/t6DY2abuZm0Votlm4Jlst57L5uUZbEfdm/ZV65nw9RWy9zcw9 xvdxnK2KcyLmbV3c4/ZNnN1xE+ewd3F2m4crRr8iWw9ntdk5C0LKRkRbT58PNMRE8O8mATJBDpAT 5Bw5T66QLNGbgJjADQGYgANwAs7BebgCWdDrde2ciTGxzHnmPJtlsqxqRaFfrfKzjJ+Af4OaZNBb sg7AwGCvVEQQb+6d0XlcA1J8U+9Xv/71SumbA5vC0nRlJKNFm7BEJHJ/RNIObM6T4MIxOYX/ySmJ DUmaUDImaYTgJGWMlDEKQSQkE6VNQpBItlBSsglB1yR1XR4YQxmT+eGanMxb5DSwd9n0GoJOjJYK IlMuQCdFgiaUzEW4dqLJqakbBsrFnFSW48KraiiJB1yGYg2aKo1NfVX9kuoe1TD7Mp6MkH03+9bi vsX4YoR9FFbi1fmb8BTMwfPws+UL9mn4oUJ/EWRYgP9bllPiK/AgHIefwuu4TUvjYXgMvgv0HvQQ Ul8mY+QeOApU+t/wJDwDszAPzy0Z/038CqnM655jbCSXwe9gBfMSmST3Y+SHoBd/z1/jfx/ep/34 +ycGyTK3sAFmiPkp8x/MBNOeC8HcjatbYF9mn4Bb8bcAr8LZGwT/CvmIfART8Bus2wvkP5nn4Xvw BHwV7oMHcNX/g9wEHIQj8Cgc+6y3Jq22qN6/TpqBp+FrsB1+iZX+EXp8DTaj/iGMBfBl0IMdOHU0 7/EUfDtP/b8j1Q7mWazWg8yLbC9zmpFYN6NiT5MHsN8+ZlX4lBGFCOZ/K9ZhDAawHsfhO3AaJXQc xs6S4X7sDzr24O+/4EP4N+YptN8Le9lvsatRdxrWwgjZT7To7YdT5DF4G4bwl8ILxdvkOaw+eqpO i2s6/R3tvrZWr2d1i3tVc5OrsaF+ZV1tjVDt5LmqygqHvbystKTYVmS1mE3GwhUGvU5boFGrWIZA E5HK+sIz5QUuh9PpjDTnefv1vMTWmt93SmC9zshxvdFMxWf4ys/wVcv8OglsUr/QF6SBZ6D/txIU ScQmAZ2FFP0LzpTPJBQfF0K7pPK+eDSKHkHBzEv9V935VJSEZwz6PqEvoW9ughm9AUkDUmibmiH9 3UQhmP5Q5wwD2sLmJsnqkpjaEIVxSTwURUII4tJRU/SpBu8vh69VAbrljADNFIpImj6pQJmX3yWJ MQkO8TNNC+nDGTOMRF0r4kI8tj0ssTEs6gywtaEkXoURUYgmeUmF8yoHB0r4UJJPI0/NongUguh1 QzmKdX3hg84Fh2RFHJIsLukm9Lzp7nccbDpUtounbDp9kJeObQxfq3VSm0gkUtbcxKdDAk4UbG4K jfdipcvczU20BGSpNPHoOM1lPEbzDI3z6UMJJdfDSm6KaSiJGxP7R1bpdCguhOKxOJ0Go/dJ4qCC YHCIloMPYemCkbwob4AalaKJBiNYa5oY3sz6UBsSYkHsQdqny5JoXoKC0JKSp3neIolRiR/lJdgU FtC5gx4SHZAe7aB9jGFIc9PAhk+9JHWtWeDTH4BEosLlP9CMP5XE8hJNrfkDoMp+oT+aTvcLfH86 mo5lstMjAm8W0jMDA+lUKIqzbsBbLcrnDzmk/sMRyRxNkk6sPe2A/k3hgMNpwXXk2A1LLGBLYWNh C9Pbt6oW/7fkEe4FDIbx2UOCLeGIAwsZpvQg0jlMGwkbtwP3OF82WqMEXSxOROk86XTS7jyUEWEE 912a3hjO8TyMOGQQ3S7cjyjVLCxpirdQzfSSZtk9KuDmnFTed4olbd3y32QuKQolOyVS8nfUiZxe KuoLsw6GNjxSjIOllN6FZ3qXVOpCut6Vxm25IEhml6QOLzi6IrzZglcAunubhYGNQ2E+lF7ugpwk v1LaB9jqQiyZzp9itOlvLKWPRrmC047FU/oQVnx6ZBybBv+xw/Ty40ybpf4/OR3OtEWw8n53pJm+ UhJgpvGN+HY4q9oBbyPsRoixZjiOMIJX+Ny7JeCbtQbvbwA8dCs1Q/KGg1GkLL6lqm+o/+eFGnQt UNw54KAD79S/IUfIKfI6yvB2QJVowiKyfV/DqICC+8U3XlQOq1ucFqelFg8ErT6eVsOfKQYk6Brx WYE8jU8xLNhFE7OVaN1qAs30gZch7uHLwxC4jBEEi5c8feUK2hG8nwGbUb+KdekSq9WnNBoda2Az 6AjkBKrRXWfgCc9OswzLGgstVr972HvZ73F73cP4WvxJV8DrxpgNpA1zavP42r0WJ5v5pJEYF99/ 5AHdo0T7MPvb+z5/18c/pPnh1wqVSn0V6mBS9Nqra0tdnMvZpfaV+oVb1f2ltwiDpUPObdWJ0qhj qvRLjv38geoim804X84wtfNES88tsdxgbq+r0zoDFesrmIqS2pIKvPGTBYbQd45ZfWE743YN7yn1 unHBXrcLc/QEkFjdMoxJdpP2btLWWrdyFRGqNQVGUiCgzOvBe7PCocCpUv1l16g0+NQ9K6uF7e1t uz2N68oM3W+MXvhDQ01tsnPHuyHm4ks7vjf8g7f2de/gqqocNkuL5efcmjfOfP7BQM9099hFka41 ln2L/T2uVYRHxC+UGOt0DcUNgk/nsXYKrc1tnSFd0Po5Idgc7NyiGyoZErY0bV+9uXNUFzWOmuLl u4S9upRxj+kuobLY5mubi3aQjg6noaAA5g1MbW3DvFPvW+O0+GwWtsbtDDimHYxD69BGa0gNrYKh sL0Gq+BVimAt9bsv4wsOFoGCsoWXrX4/VoRcV4PSKkLLUFxF8pQRi1S3ss1bhRXyLRfORdqQzRWR ZH23t7bcVLGi581E4qG1vX3f3uP+wqpVnaFAT2Zv6uKAMfDz8bX7G+ob3Y2Nk31beg8+2VRdt13d Zy+2NRW9IvgbXC33bds/X27UNblcB2OJJ3uC/b66V1YNrmxqGt+4MVlVVXp8+u6OjWV2G63p8cV9 zDMaG54bdWKp+gxDNGeIgQXQcEDMhCcbiIr2udfdhculvU6wK4sRmGc++ZDRLj5BIov7Cr515KN/ pdFGMNq4Eq1aLFKdKSAsjcbhlysaiZ4xXdjcy5GUDncy4598iFGewGj7jmjuPbL0DSq7FTDoDQb9 hMWCBT8wFEMJXnVExYaAFTOgQ4MfJmDoc+Hg4DrXYCw5sTsGfwUKL9WmCmVuZHN0cmVhbQplbmRv YmoKNTAgMCBvYmoKMzM1NQplbmRvYmoKMTIgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUg L1RydWVUeXBlIC9CYXNlRm9udCAvQ0VBWlhDK1RhaG9tYS1Cb2xkIC9Gb250RGVzY3JpcHRvcgo1 MSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFy IDExNiAvV2lkdGhzIFsgMjkzCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMzYzIDAgMCAwIDAgMCAwIDAgMCAwIDc1NwowIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYyOSA1OTQgMCAwCjAg MCAwIDAgMzAyIDAgMCAwIDAgMCAwIDAgNDE2IF0gPj4KZW5kb2JqCjUxIDAgb2JqCjw8IC9UeXBl IC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0NFQVpYQytUYWhvbWEtQm9sZCAvRmxhZ3MgMzIg L0ZvbnRCQm94ClstNjk4IC0yMTYgMTYyNSAxMDY1XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDEw MDAgL0Rlc2NlbnQgLTIwNyAvQ2FwSGVpZ2h0Cjc0MiAvU3RlbVYgMCAvWEhlaWdodCA1NjUgL0F2 Z1dpZHRoIDUwNiAvTWF4V2lkdGggMTY3NiAvRm9udEZpbGUyIDUyIDAgUiA+PgplbmRvYmoKNTIg MCBvYmoKPDwgL0xlbmd0aCA1MyAwIFIgL0xlbmd0aDEgNjAyNCAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PgpzdHJlYW0KeAHtWH10FFWWv7equtMf6fRXpZN0k1R3Op1AOiHfCQnRVOh0AIMYIGgHCHZD EpIgJpio6NmR7Doy2sTFI87+wY7KeDyze5hVKhUHwd1ZAqzHj9UVnFVnPDo4s46zIiysg9mzIJ29 r7qC0TPOnpl/9p+t7vvu73689+6771b16xq76+4+yIRx4EHeuiMxAtrl+i6xk1vvGfOnZVMbgGDq H9m2Iy1nrgIwerbdcV9/WnZvAuD/daAv0ZuW4Uvi9QOkSMtYS7xoYMfYrrTsYn7+O4a36nb3CpJd OxK79PnhA2a/M7GjL+2fw/yLRoZHx3S5knjtyF19uj/GKJ5zX5ezAJC8TPC3kAv9xDlwgAzraSWD 3CkwkMzsBm7fgt5fXbrd3vwF+Eza8M+//ZEW58lTPz50ZXuq3QamPeRrph7pi/qZMNUNYBu4sv3K Olt6Jt2oMdNk1+2tORyyKfAatQ5qZaLHiHhowS/gdo1m4DTOgDA7jWE101Z/jECZGlqkAzGQBlNm R718FBeqXq+mWDhlszFFaKq9XeOq5NcMIdW3QAfZHh3YnTqwZGqgUC0p0UFBQRpMWSxsmMKpzEzG A1M5eYzzak6O5sCreWzik5itFkg6sIgacKvU99jsCfSo69brYPUtOohGdRCJ6GARWxo5TxUVsxk8 al4eKaYJeNLxelRnOl6Pak7nI0+tqtJ88qbKylinPFVK5yVPzU8vIG8uUNcUDUMuLjU3Pa5LXb1a 6+xSo8t1ECrWgT6Tay7zkmq1aiZJpfyysKS5aCTV7dY1eqCSlkYsQVSrJZrSqLpcmgenLkzvH06V LGLBcFOURuI4F2WRmpuruRapdkf9TzELDeAEifJimLJpOy1MUWzURVDNLLvTBPRECWrzDbrmppvS YOq2buZboZpZ9CfQpJrZbp1Asyqn825Od2KaxZW6qaRUB4VFOtCKi/mI2ZpGVIvSJlEtZhVzAsWp THe9vTULa6iEa6iEa6iYJXQCogPtUEvYrgqdEosYZMmaWz/7qSSd+8wrVX6Gn4pe6eJ5h/QfRDAj z3BHZ8fl3BlrZv0MeqUL562S49K+S5x8fuT88fP80dnpqSsOsZ643PTfLrH+t594pU/qvJL8PgXc 8nM8816L9O57Xmn8HXyHWPy9kfe4118rlV5/rXHJ62h9te1VTvkAqfuRD+juGXmbQfmhty3u+qKJ romxie9OPDuhTPzTRIZ8ChuOOaVBohNEx4n+keinRP9A9Pe3OqWXjvmknxA+cswrvUh0lOgYxdLc 4pRuILqRqI0oQrSsJVtqJZIJt9Q5peoaUaqpE6W6WlGqJX6wToskUGelnd7Z1FR/difKO83u+n0j ygh3dhjlYVrt6Ts1L8+dLPb+x/qVfl7eZrbXP92HSq9mWtrLHgoH0f995ftcy+N4+77d+zj/o9OP cv7t8nYOBlD7dg7EB/jdCazcKG/cvXF8o7DkB06JpeJ3P8ik/i+jPIWTtDOKmC0dFp3S80TPEf2d aJV+LGZJh4jCpU5ppBTLyrOkctEmPeWPSJJYIAWI+8Vm6QVvkfS0t0/yeaul3d59Xs4rFkqvuFdI 2WKF5Bb9UqVLdnW6HnMJI65x12kX7xJzJScRiNgpxsURka/MQjCiHelbgS04jLvxMB7Ht/AizqLF DlRcFdACw7AbDsNxeAsuwixYLOYGyc7Zee4t7i1+lpvlBaYxm0olwVAqcXyxlGlrNAiNPNeI0Nhp wKM0muLqgI6uZYobia9bNmmuDncovWuXPfToo/nKX3WsjSnj+d1HTeQTU1DBv+xWTB3rdAhh/Rod C4+OjY4pfFQxRgcSijHYNsqELCZkMSErqtiZYA+2oSJGBxSRtGPh8NjdbAit0cYa1UcMh0cJjtI1 xhoS2Jcc72YNEPz2a3QUyT4K2gjMczSMzFtTaD3Tvcf+0CDfPvy3WlisYfrlLTCKhkuGM8IeYSv/ Iv3KwuyvZz9M7Ur1prr5v6ZfX8BbMY5DeA/+xdyPJG7GbRp+FhO4He+d02t8FfyENvl9+Df4z+v6 WRToGZNH8m/QDd/Rev8Mfgln4TJcRQM60YvB697fBg7A87rpXTzKZWjYAhPc0/AKpuAAfSIQoWjO cX/GP8Qz+x74Dj3X2Pnlj754G7cPN3H3wkH8IRfhYtyH3KH5g6AJVtHa78LH52vTGD0o0a3QhO24 FrdgEi9yNdgKn8Lv4Bplwo0SvESnpI/hPHJoQhFvwke4m7mrmMIhY9LgFD6fPyYO4gpaySYcxQEc gBnC68h+AJ6g9k46/3lBuj5vGE7QXlVhJr+FU/lV/P385wYLr9JR6Qx4jQ7uMtdPN+Fu2E+fbujG cojDg/Dn8Cbl/xJ+CYu0PD5JHtvpc1bYKtzHv4IqncFuhX7iP4MN+BhshUdofTdjHvfPIMIU9xv4 IfwCN/GtsJ+/D0/SCu04TJXzBPX6AKZgn3Bm/or+H/9fZEB4P2NBxnl4Dh4mOoQvCkcM78Bn8CP4 BeyAl2W5a0VT89KmxiUN9XW1NdVVlRWLy8vCpYsWlhSHioKFAb9UkL/A583LzfFki26X02HPsmVa LWZThtEg8HRaLkMlNxKbzMsI+wKBQHe5Lnu/Lit8yPF5QAHX15x8X3eaXPANOf8bcsF1ebUCotIe jLSxgSeh/RMF3AqKCrBZ0H0zzaRHEu0dCkYHlbxIbzxOPdqCDr/SfqlCD0ULeNJqiQQjfZbyMpi0 WAlaCZHvyCS234ga4NqjTZMcmGzlZYorrHChKKMhRd4bJxBso6WTxf2VhX6uJ+abgLqlnYDcNISK MaJkaPP6BxU5ocBe/2TZdHLiqAO2xMOZvcHexKaYwicoqZPAh6ID9PNGjFF8wK8INK/W+Ejjjw74 kyQztzi1wTbq9Xv1pDZHYt8LTPsUF/Go4gwry6nn8vs/9vHJaO6gn4nJ5Pf8ysE1sfnWAPPp7u7O LS/zJ6NBmqitvCw6tIwynVtRXsZSgHOp6Y0PsViGEizO6JA/ubdPi3VCi01zjQ7QxiT+N69kMtob jPYmetk0NHpEkbs0Bl0bWDr8UUpdW7eu0h3IImiWeFs35ZoFRqeECFmjwUQb1SCr0+uauK4hRXTO 6GdxrlTkuOLf6ldgbSxInZewpm8JJLcuYXVMw2B5WUfnV70UQ8gR9Ce/AAXjwQvnWcRfaRK6xhhy fAHM2B5sjyeT7UF/ezKeTNDRekvQ7wgmJzs6kiPROM3aSWcY0r+016e0T3QrjvgANlHuWQW0r421 +AJOWkda7JwTgUqKCotKmJ2LhBB9V+qM9gK6YnQEVGB9rNtHiYwx3EU4zVkhUeEuoT3W08Zy1McW SxMxrMNAgFXn3qMybKF9V8bXxNKyH7b4VJArwrQfcWaZnrNkr2eW8TnL9e7xIG3OC+w/N2QrpuLr X7vD444ONCno+QPmvrRdcUdivI9jBU+I8/EMWcJ0pzcrOWHCC8NJ2pbTQcURVgyxaV9zt9/hpCcA 2711wY41G2L+aPJ6FaQ1+kpZHVCpBxMDSf0WY0X/+7XszJlOOKtYuqX3UsbHtwxR0dA3McEeP4Gk Q2mfCfgCSWfQ5W+soFBZVTtOB1+jk6ubHmsOBZu1ZaP2TKP5Vyp8zhIysmj/pBn0RepLoufYsskg PrxmUsaH122IHaPTn//hrpjKIReJL+vuLmevYBA4ekPD/TucMtrhgMEM9cI01HJDsIdfB9m0XdqL EuKZYIQXiPvpPQ3bxj/2mntDM78fP1/4E7BA74rmX8b5AuH0KRIgSJ9VcJBOozvxcTxHFvpFY2bq wBPLl+1GTgCiSpChk3QVPW9++CZUUFNVGXAGnCFq6H8QXBk3wFXGgQC9dTpFTUjYqo2yUM7DU5zB eMpgcpj9ZjrDKkagk7EfeazoqblW3QMtF1ouVFUiG5E+XCj1FG5hxL2Pj1x9Eh+hEQ/Qae4NOs9l QT60yOFu162+fm7QJhh5WybnqTPxOXUZJpMd7dn30j5sk2SpU+JyxIzeAsfMhR7H5Z4L6Wl6qip7 UOQyjEKQpqoWcjwuQ21xSXFxMOisqa5vqK83vHFk71jq4oHUYvyXJ9G1a/+h1Hjf4Kq/GcvIeOC5 1Zvi3G9Pp16MdYQNZxbevDl14p39Z5aWmr7cZK5qeoPirJ/9lfCgUQQP5TYily+1Lc1fZVuVP+I2 BEszHQ08a7LB1+oU0BRYZrKIOeiF4VCBzzpSRJE6rl2rrmb5oG9VZTjcEwjUGY0ZRmOwkHPWsvBq qj05lHQnRVxozBY9FLTwYOqZwtsCpWsbpz9aFbnh+URsZwduTj3j7Sp4YHffzsWb714gO0QRb0TL /p93rlwfKsFfXi3kSmxO5akfPVFEUdfO/lp4XNgDBRCCbXIwZKu1tXK3CK22dUWj3P3ZJi8LO9Rs tULhjUbhYC7m0oNyKsvRwLicZ7Y25OY6ZTDn5Uley84SewmGrF5+pNgxQ9vruHyhhv4LU0Prabng aqygzQ73GPzgdECA2uyAx5PjYSuh9TXUOLUFu7UFZnAvp06mnsNmXEB/G4RraFiyuHzX8hvuqQqv zAmFl9/YeF8+n+jtHzUWYCXm0SF8Repc6toDqwclyefzuMucqbPOfLvdyX00PHb/ILtv91DzMe0Q DyVHOKS/NF7t7USWOasB0SBUGmRDp4HvcVKc4QvQQtsQoErBj1PP4GbqRiNkz57jbzI8Cz6IydlW FpnJZBNaLBmG3FyxBcy5VpYVv9nRYLXmt+Tfks8ZLTZvht0oGf08bwTewR/meZ6Kn5V/RY+TMkPv pwi2kFxTQSVqKCyucwbratj9kB1winP5qck2Grnad0/t2UP/R9ekDnP2rOVtCza6ChrHPcqrnO0y tqaOX07dtTQWDC7KtfyX3Um7q12zI/BaGn2jZa+QebqrSmA5rIBb4DbNjuDSn2dGQhCJtm6IRcJd iYHhHYnyZcN39P4PqqKNYgplbmRzdHJlYW0KZW5kb2JqCjUzIDAgb2JqCjM3MDkKZW5kb2JqCjM1 IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1BNSkxD UytDYWxpYnJpIC9Gb250RGVzY3JpcHRvcgo1NCAwIFIgL1RvVW5pY29kZSA1NSAwIFIgL0ZpcnN0 Q2hhciAzMyAvTGFzdENoYXIgMzMgL1dpZHRocyBbIDIyNiBdID4+CmVuZG9iago1NSAwIG9iago8 PCAvTGVuZ3RoIDU2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkM9qxCAQ xu8+xRy3h0WTWyEIZctCDv1D0z6A0UlWaFQm5pC372jDFnrwA7+Z3/g58tI/98FnkO8U7YAZJh8c 4Ro3sggjzj6IpgXnbT5u1bOLSUIyPOxrxqUPU4SuEwDyg5E10w6nJxdHfCjeGzkkH2Y4fV2G6gxb St+4YMighNbgcOJxLya9mgVBVvTcO677vJ+Z+uv43BMCJ2Ki+Y1ko8M1GYtkwoyiU0p316sWGNy/ 0gGMk70ZEl3baG5Wj8DiWFrFYlQlj54yo/z1ns1uRByrLqQmLkl8wPvOUkzl5Xp+ANXucWUKZW5k c3RyZWFtCmVuZG9iago1NiAwIG9iagoyMzMKZW5kb2JqCjU0IDAgb2JqCjw8IC9UeXBlIC9Gb250 RGVzY3JpcHRvciAvRm9udE5hbWUgL1BNSkxDUytDYWxpYnJpIC9GbGFncyA0IC9Gb250QkJveCBb LTUwMyAtMzA3IDEyNDAgOTY0XQovSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAt MjY5IC9DYXBIZWlnaHQgNjMyIC9TdGVtViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9N YXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgNTcgMCBSID4+CmVuZG9iago1NyAwIG9iago8PCAvTGVu Z3RoIDU4IDAgUiAvTGVuZ3RoMSAxMzYxNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAHVm3dAU2fbxp+TsEMgICAaMcEjVAuIFgeOSgSCIA4QogkoEpagoshwo7iqxdra2tqtdqktbT0c 24pdWmv3sLV7a/eye71a5LvOubmt+r19vz++f/oGfrl+z/2MnPOcJGBKG+ubKoVJtAijGFxe660T +i1lD6J3+aJGO7XjqoXw7VNVN7uW2hevEyKw9+x5S6uonfKiEFJ6daW3gtriT+TwahSoLQ1F9q+u bVxC7ZSdyIB5C8q7+1OOoO1X613S/fjifbTt8721lUjchllwZ6+rr+zul9xYznJ+2+/r89shOCTM Mkh2YRFPCn9hQCYLrBi2RVojfNCr9ftu79j8+wths0LH/Cp6BaAgxCPfrMD5CPHMhj2bTp/q3BT4 rf9DaAZiBbphnv/2zneFCNp5+tSpnYHf6it1d+phUAON9g7DugcCo6UJkLUsa1hWs7SwrGJZydLM soJlOcsylqUsS1gWsyxiaWJpZGlgWchSx7KAZT5LLcs8lrksc1hqWKpZZrNUsVSyVLCUs5SxeFlK WWaxlLDMZJnBUsxSxOJhcbNMZ5nG4mIpZClgmcqSz5LHMoVlMsskloksuSwTWHJYslnGs2SxOFky WTJY0lnGsThY0ljGslzKMoZlNMsolpEsqSwjWIazDGMZypLCcgnLEJbBLMksg1iSWBJZElguZhnI MoDlIpZ4ljiW/iwySz+WWBY7i42lL0sMSx8WK0tvll4s0Sw9WaJYIlkiWHqwhLOEsVhYQllCWMws wSwmliCWQJYAFn8WPxZfFh8WI4uBRWIR3SJ1sZxh6WT5k+U0yymWf7H8wfI7y28sv7L8wvIzy08s P7L8wPI9y3csJ1m+ZfmG5WuWr1i+ZPmC5XOWz1g+ZfmE5WOWEyzHWT5i+ZDlA5b3Wd5jeZflHZa3 Wd5ieZPlDZbXWV5jOcbyKssrLEdZXmZ5ieVFlhdYnmd5juVZlmdYnmZ5iuUIy5Msh1meYDnEcpDl cZbHWB5leYTlYZYDLB0s+1keYnmQ5QGWfSwqSzuLwrKX5X6W+1juZWljuYflbpY9LLtZdrHcxXIn yx0st7PcxrKTZQfLdpZbWW5huZnlJpYbWW5guZ5lG8t1LNeybGW5huVqli0sV7FcybKZ5QqWTSyt LJezbGTZwHIZy3qWdSxrWdawrGZpYVnFspKlmWUFy3KWZSxLWZawLGZZxNLE0sjSwFLPspCljmUB y3yWWpZ5LHNZ5rDUsFSzzGapYqlkqWApZylj8bKUssxiKWGZyTKDpZiliMXD4maZzjKNxcVSyFLA MpUlj2UKy2SWiSy5LBNYcliyWcazZLE4WTJZMvZpvy3jt2a171gbfmdW+0Yi1lBrtdp3FFot1FpF sVLtG4xiM7VWUCynWEaxVI0ZhyFL1JgMxGKKRRRN1NdIrQaKeiouVGPSMaGOYgHFfBpSSzGPYq7a x4mRcyhqKKopZlNUqX0yMaSSWhUU5RRlFF6KUopZFCU0bya1ZlAUUxRReCjcFNMpplG4KAopCiim UuRT5FFMoZhMMYliIkUuxQTVmoNzyKHIVq0T0BpPkaVac9FyqtaJiEyKDIp06htH8xwUaTRvLMWl FGNo5GiKUTR9JEUqxQiK4RTDaLGhFCm0yiUUQygG02LJFINoXhJFIkUCxcUUAykGUFxES8dTxNGa /Slkin60dCyFnebZKPpSxFD0obBS9FZ7T8Zm9aKIVntPQasnRRQVIykiqNiDIpwijPosFKFUDKEw UwRTn4kiiCKQ+gIo/Cn81F55eHRftVc+wofCSEUDtSQKoYfURXFGHyJ1UutPitMUp6jvX9T6g+J3 it8oflWjC20d0i9qdAHiZ2r9RPEjxQ/U9z21vqM4SfEt9X1D8TUVv6L4kuILis9pyGfU+pRan1Dr Y4oTFMep7yOKD6n4AcX7FO9RvEtD3qHW2xRvqT2n41TeVHtOQ7xB8ToVX6M4RvEqxSs05CjFy1R8 ieJFihconqchz1E8S8VnKJ6meIriCMWTNPIwtZ6gOERxkPoep3iMio9SPELxMMUBig4auZ9aD1E8 SPEAxT41Kg0nrapRxYh2CoViL8X9FPdR3EvRRnGPGoV3feluWmUPxW7q20VxF8WdFHdQ3E5xG8VO ih202HZa5VaKW6jvZoqbKG6kuIEmXE+tbRTXUVxLfVtplWsorqa+LRRXUVxJsZniChq5iVqtFJdT bKTYQHGZGunFua9XI8sQ6yjWqpFVaK2hWK1GutBqUSPxw0ZapUYOR6ykaKbpK2jecoplamQFhiyl 6UsoFlMsomiiaKRooKXrafpCijo1shyrLKDF5tPIWop5FHMp5lDU0Lxqitl0ZFU0vZKigkaWU5RR eClKKWZRlNBJz6Qjm0FRTCddREt76IHcFNPpcKfRA7lolUKKAoqpFPlqhAMnlqdGaNs6RY3QXrCT 1Yi1iElqRBJiIg3JpZigRuAXCSmHWtkU46mYpUasRJ9TjdiAyFQjViEy1IgWRLoanoUYR+GgSKMY q4bj9wLpUmqNUcM8aI2mGKWGaa+jkRSpath4tEaoYW7EcDWsCDGM+oZSpKhhiSheQiOHqGHaiQ1W w7Q3pGSKQTQ9iR4hkSKBFruYYiAtNoDiIop4ijg1TNul/hQyrdmP1oylxey0io2iL82LoehDYaXo TdFLtczEmtGqpQTRU7XMQkRRRFJEUPSgCKcJYTTBQsVQihAKM0UwjTTRyCAqBlIEUPhT+NFIXxrp Q0UjhYFCohCOrtAym8aZ0HJbZ2iF7U/4aXAK/Au1P1D7HfwGfgW/oP4z+Al9P6L9A/gefAdOov4t +AZ9X6P9FfgSfAE+D5lt+yyk2vYp+AR8DE6gdhz5EfgQfID2+8j3wLvgHfC2ea7tLfMQ25vIN8zz bK+b422vgWPwV80JtlfAUfAy+l9C7UVzre0F+PPw5+DPmufYnjHX2J42V9ueMs+2HcHcJ7HeYfAE cHQdwv1B8Dh4LHih7dHgetsjwQ22h4MbbQdAB9iP+kPgQfQ9gL59qKmgHShgr2mp7X7TMtt9phW2 e03NtjbTSts94G6wB+wGu8BdpiTbncg7wO2Ycxtyp2mubQd8O/xWcAv8Zqx1E9a6EWvdgNr1YBu4 DlwLtoJrMO9qrLclaLLtqqAptiuDZts2B91luyJot229Mc62zphqWyul2ta4Wlyr21pcq1zNrpVt zS5Ts2RqtjbnNi9vbmt+r9kR7he0wrXMtbxtmWupa7FrSdti18OGy0SVYb1jjGtRW5PLpymiqbHJ +EuT1NYkZTZJg5skg2iyNNmbjMGNrnpXQ1u9S9Tn1bfUK/U+o5X64/UGUS8FdXQd2ldv7ZuFdKyo N1uyFroWuOraFrjmV9W65uAAa1Jnu6rbZruqUitclW0VrvLUMpc3tdQ1K3Wmq6RtpmtGapGruK3I 5Ul1u6Zj/LTUQperrdBVkJrvmtqW75qSOtk1GfVJqbmuiW25rgmp2a6ctmzX+NQslxMnL/pY+tj7 GC3aAUzugyMRVil9sNVhPW79weojrIr1kNUYHtrb1tswMLSXlDGll7Sg16peV/UyhkYfjTY4ogcm ZoX2PNrzo57f9/Tp4eg5cFCWiLJE2aOMkdq5RU0q1M5tX1RaJuWQYfq5ToqS47NCI6XQSFukwWmL lETY8bAfwoyRBy1HLYbQUCk0tCvU4AjF8NAQW4hBu+sKMTpChozICjXbzAbtrstsjHKYUdEO/qLg vMKsUJPNZHClmaaYDA5TWkaWw5Q0OEsYJbuE//JjQRgDtKORIm1ZHZLYFyX5Sh3SlvbCgoSE3I4A MTVXCcgrVqSNSlyBdu/IL1L8NirCVVTsbpekKz3tkiGjUInIzS+i9vrNm0V6TK4SU+BWdsZ4cpUW iEOTLoiIaY8S6Z6EkoamhoSExhLclTQ0JujfaElNWgs3dOC7oRFt7QuBttB6/v5GwzBuVgNu+jK0 +t9P+S/okf4LjvEffojtAk9R97guwzpRYVgL1oDVoAWsAitBM1gBloNlYClYAhaDRaAJNIIGsBDU gQVgPqgF88BcMAfUgGowG1SBSlABykEZ8IJSMAuUgJlgBigGRcAD3GA6mAZcoBAUgKkgH+SBKWAy mAQmglwwAeSAbDAeZAEnyAQZIB2MAw6QBsaCS8EYMBqMAiNBKhgBhoNhYChIAZeAIWAwSAaDQBJI BAngYjAQDAAXgXgQB/oDGfQDscAObKAviAF9gBX0Br1ANOgJokAkiAA9QDgIAxYQCkKAGQQDEwgC gSAA+AM/4At8xnXh3ggMQAJCVEioSWdAJ/gTnAanwL/AH+B38Bv4FfwCfgY/gR/BD+B78B04Cb4F 34CvwVfgS/AF+Bx8Bj4Fn4CPwQlwHHwEPgQfgPfBe+Bd8A54G7wF3gRvgNfBa+AYeBW8Ao6Cl8FL 4EXwAngePAeeBc+Ap8FT4Ah4EhwGT4BD4CB4HDwGHgWPgIfBAdAB9oOHwIPgAbAPqKAdKGAvuB/c B+4FbeAecDfYA3aDXeAucCe4A9wObgM7wQ6wHdwKbgE3g5vAjeAGcD3YBq4D14Kt4BpwNdgCrgJX gs3gCrAJtILLwUawAVwG1ouKcS3SOthasAasBi1gFVgJmsEKsBwsA0vBErAYLAJNoBE0gHqwENSB BWA+qAXzwFwwB9SAajAbVIFKUAHKQRnwglIwC5SAmWAGKAZFwAPcYDqYBlygEBSAqSAPTAGTwUSQ CyaAHJANxoMs4ASZIENU/MPfpv/ph+f5px/gP/z4omeVaH8xJMSZref+kZDIE3NEg2jB12Vis9gq Dor3RJlYC7tR7BS7xN1CEU+I58Rb5836fzbOLPWtFcHG/cJP9BCi61TXyTO7QIdvyDmVrWj18LH/ VemydH13Qe27M1u7LGc6/MJFkD7XbDiG1X6WOrtO4eernzB3Ddfahg3wUP2RfvTffmbvmd3nnUCe yBdFoljMEDNFqfDi/CtEtajBzswV80StmK+35qNvNrwKrVkYhfcS3f8atUDUiQWiXjSKJrEIX3Xw hu6W1rdQbzeJxfhaIpaKZWK5WCGau+8X65UV6FmmV5egZ6VYhSuzWqzRjZMqa8U6sR5XbYPYKC7H Ffv71uVnR7WKTeIKXOcrxVXi73zzeT1bxBZxtbgGz4drxXVim7gBz4ubxS0XVK/X6zeJ7WIHnjPa jOtQ2aHbNnG9eFQ8LR4U94u94iF9L8uxt7QjvC9V+k7XYQ9W4JzXnnPEtJuLz+7WSuyGdt6t3ee9 BPu35pwZi7r3Udu9tRip7U5r93XQVmnurvBObMGZkf91ntoeaedw1XnnyTP+r6p2xto+3YL94p3R 9mwbajf9r+q5I871beJWvAJvw722q5rdDifbofu59e1nx+7U++4Qd4q7cC12C804qbILtd1iD17b 94g2cS++/vJzjXrvF/fpV04R7UIV+8QDuJIPif2iQ6//p769eO+4cM6+7rXUs6scEA+LR/AMeVwc wjvNYXxx5THUDnZXj+ijqH0Yf0t5RB+l9R7Gc+sZvEM9L14QL4qj4im0Xtbvn0XrFXFMvCbeksyw V8VXuO8Ur/h+KkLEOPzh5cO4GreIElHiGF8xq2TmjOIij9tVWDA1P2/K5EkTcyfkZI/PcmZmpI9z pI29dMzoUSNTRwwfljwoKXFAfFx/uZ8tOiLMEmo2BQUG+Pv5+hjxm22iU84qtSvxpYpPvJydnaS1 ZS8K3nMKpYodpazzxyh2bZ4XXeeNdGBk1QUjHTTScXakZLGPEWOSEu1O2a68lCnbO6SifDd8c6bs sSsndZ+ku0+83jCjERuLGXZndHWmXZFK7U4la1F1q7M0MylRajcFZcgZlUFJiaI9yAQ1wZQBcl27 NGCspIthgHNUu0EEmLWHVYxxTm+FkpfvdmZaY2M9ek1k6GspfhmKv76WvUbBMYtN9vbEQ61XdFhE WWlCcIVc4Z3hVoxeTGo1OltbNyhhCcpAOVMZuOzTaGxgpZIoZzqVBBkHljv17ANIim+cRba3/ipw 8PLJb3HU51S83RW/OMuvQuvUTvHsNimSl13g2HCEOL/YWO1YNnU4RBkaSku+m9p2UWZVhSM5waMY SrWeQ9wT6dJ6Wrjn7PRSGTvrlJ2l3d+LqqOVljJ7UiKurP4dp/jEod+uGONLy8qrtfRWtsqZOEPs pSjEhzaZEIe3ezOd7YOTMd5bipOo0bYh360ky3VKhJxOu40CFolz1hS49SlUdSoRGYooLe+epSQ7 MRdPEWerdmG0A9TWkvPdB0RK1/H2oXbrvhQxVHi041CiMnBR4p2t7ooqxVZqrcDzs8rutsYqDg+2 zyO7Kz3aVZItysDjeDjccAH1WTi3C0bzYJy24h8XYHcbrEaPdrVQsGfhTk4fgw6L4kdN7Yqmj7G7 JavgYXiU7hGanbcOGsa4jGxMRmJqRrY1Fk9u/fYfDslKJ4DDUALOHpMPDsL3r2Oix/nbQ6PR2gEN tDsrM885wPMWRUM/wO7V/v1xGrS96N4MHEKAdjmztXNISjTA7egOUAw4T72kXcVouyLy7G65UvbI eA458tzaxdH2Wr++uQWy9sGgfrW7nyWF57WoP5X6FBGbW+jmhvaZjZKVoF9X7bLq7fF6+2wz+4Lu HO62twbIuQWt2oPL3QsKO15BuDh+8TneTanhQ/FizcIbpZzlle0We1art6Orpay13eForXOWVo/C y6BVzqlolQvcY3At9dd9s3WZ9tDhIlfKLUxPSsR7T3q7LG3Mb3dIGwuK3AfwB/r2jYVu1YAPRUvT Pe390ec+YBfCoVcNWlUrakPsWkNbaSoaAfp46wGHEC16r49e0Nvl+FxWr9Eg1CRR3mGgmoXHGVDz oZpDr3lwwyssuhqXAO/DTnuFdnlWeKpbSz3ai0tE4VLiW1IkeaxQDPJYfJTrF6wEyZXpiklO1+pp Wj2N6n5a3V9OV6QoCZvTgfek1lIZ71N4yrnxEbkHzw6L9uw3xNk7uroK3bEvWU96YvGSmAGK3Epg An4O+MZNwLjxGqUoj1dayr3acQgXXuraKzOn3IPXAi+IITlKIFYI7F4BI7L0OdrTEZPKcW1wAfX5 LWgoLR7Fk6A9qLtGOyK73aKIbHkULjut6RuvPVCypzVcvkR7YmOoEhS3QYtAHJvAh9R6xYomHgxv uNoZ+QfjyMtldJWX2nEFfER5AZ7q9F4apF03VCrxlugTX6kTZO3uFNppGeNM5iAlcBAWxLfmpkFY EN/+HmyKdvJ6a0P3ADy2RTHhiOLP2cruCdgddOVox4LvDTh4begT2jL5HWKqvARvjdpB6w/lj27F HJfjxZs/zTehIqfyZKwVEKeVtDWOUNVfO/Ng7LsxrrCja7e8VHsH4FtSoqz9cNCemMJ6AE9s4Wm9 sKAUJyQlBlxYNevl1tYA87+fQPsVYD6b2ip2J37WCOGj/W8sR/GQCHxpt2D8eyoYGXu2IvD76W2o +OJfmA3GY/jXmBH/v8tIMUlMFsWPCjM+NokSo6QHH4zMzAxI8n8cH4kYhB0fqgQIScpwhPoYzPt7 906T9w/z22wMy+mQkh5I89+MjwvTOj/sfDm588OT4SOTT0rJH5z48ITlx5fDRiannHj9xJDBUlhs mE5EiMHfP8JP7jfIMOyi+OEpKZeMNQwbGi/3CzHotaHDR4w1plzS12DESKqMNWhtyXjszyLjlE4/ w0o5bVqKb9/eoRFmP19Dn+jwpDFxloLiuDGDYvyN/n5G3wD/ASPS++XOc/Z71z8sJjIqJjwgIDwm KjImzL/zPd+QUz/5hpzO8Jl3+lqj3+gZaf2NNwQFGHz8/Dr6Rve6eHRszrTQHhYfUw9LWFSAf3hY 8IDMGZ2XRfbR1ugTGUlrdU7Sthe7Gt690374TVXkTZowMaMgIcM7r6asvuZ/ABmTduUKZW5kc3Ry ZWFtCmVuZG9iago1OCAwIG9iago1OTIxCmVuZG9iago4IDAgb2JqCjw8IC9UeXBlIC9Gb250IC9T dWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL1pESUJZUStBcmlhbC1Cb2xkTVQgL0ZvbnREZXNj cmlwdG9yCjU5IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAzMiAv TGFzdENoYXIgMTE3IC9XaWR0aHMgWyAyNzgKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDcyMgowIDAgNzc4IDAgMCAw IDAgMCA4MzMgMCAwIDAgMCAwIDAgMCAwIDAgOTQ0IDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDU1 NiA2MTEKNTU2IDMzMyA2MTEgMCAyNzggMCA1NTYgMjc4IDAgNjExIDYxMSA2MTEgMCAzODkgNTU2 IDMzMyA2MTEgXSA+PgplbmRvYmoKNTkgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9G b250TmFtZSAvWkRJQllRK0FyaWFsLUJvbGRNVCAvRmxhZ3MgMzIgL0ZvbnRCQm94ClstNjI4IC0z NzYgMjAwMCAxMDE4XSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9D YXBIZWlnaHQKNzE2IC9TdGVtViAxNDUgL0xlYWRpbmcgMzMgL1hIZWlnaHQgNTE5IC9TdGVtSCAx MjEgL0F2Z1dpZHRoIDQ3OSAvTWF4V2lkdGgKMjAwMCAvRm9udEZpbGUyIDYwIDAgUiA+PgplbmRv YmoKNjAgMCBvYmoKPDwgL0xlbmd0aCA2MSAwIFIgL0xlbmd0aDEgMTU4MDQgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBpXsJfFTV2fc5525zZ5/JZLYsM5NJJiGTkJBMCIFIbiCJYETC agZNCUsQ3EgExB1ckeAS942WaF0o2DKZACYsNWpduliptlZ9a+VtsaiVT9oiWiUz3//cCahtf+/3 +75vwrnP2f5nec5znvOc517WXrGui5jJRiIQbdllS7qJ/gsOgfxs2ZVrg5l0VhkhyqIV3Rddlkn7 bydE+v1Fl169IpMOPUtIzoMru5Ysz6TJKdCJK5GRSdMYaOHKy9ZelUkHO0HbL129bKw8dB3S4y9b ctVY/+QPSAcvX3JZFyh+Z92PR0n36jVr9SQ5qwm0rfuKrrH6tJ0Qx5vfTVsJoajlJn8n9eRuIhNG 7KSCLMBM6tmLREKal0u2C38ya9PLi231nxt8Br35J/5cn8cjLz+2dMFXX50atRNDIeqqen1eAJwy NXUemW4nX3311TX2TE+85PTPPTB/Y6NFeJbsQkDHeAYR+hHAaOHZQcVSpQ2BOl06TbqjVcPpEeHZ 5ORqPb/8/qqNB4SdZDGpRvbO5AKevXNQa+LVdw5WT8nQigk6TRoyxYqrKtDoB6wCgRHbWGw26N0I 2xCeR5AxoJ3kA4Q0giBsF55ItgTQ8FNoyNboEp7CFDU830BIIwgY/VOYy1Pks7EcEaP64aBq5t3/ UEflCD8EyoanHWEjwi6ENxAkshrPbQhpBAGxJ1D2BGHCE8LjSXvA3mgUfkA2IDDhUWKjlATQ+sOD dp03jwzasqq0RrvwAGlDYCQhzCIjCAzN3gPYPYShemuyfILOwtZBo7XKjvpbMOgtGMgWdNmPJ9XT GmK8/pbBLDcf/M1Jm0PHXZusjGUig3ZvVRu4cBWhQpdwOQmTgHADaD7oMtA80KXCcmLRx6kN2uxV G9FfA6o3CNlkHIobBTepAm0S/CRHr7Yuac30sy5ZUlqFGU8XvHoVm2AhMVQ1CEqyKhDcL2g6828f VE18fLcn7dlVB4VbBYW4UGsjankCtoOCEWts1Gcyf1C1VPU1moX5mOZ8sCWAMVJwmT814fIkGmp0 CM1CLjZDQLhEyCPZoC1Cvk6fER4nLUh/fzCSGxjZL9yno+7ljaL7qRnRmjposVaNNKrCVJQmhLuw AHfpnfcNRiZVkcaIUEIqERh4vAGxDYjZhV7EerFqvVipXqxULwbVC+kjwmaUbEadCuEa0i2sJ30I 2xDnYpWdBEP5ZshOFpZUDQs+wQvG2PeDlRS5/kHVykfmTTqz9GreQbO1quGgsIbMRmCY8tpBj7dq 9X6hVJ9K2aA3hwO6kxDXg4InszRoyc2X5KCQC0ZwxuQJ+cnsQKIxgDQX5ACh7BfsEGcSe4v9ji83 ewNpTn85Rl8fo7/O0PQIO5TZFOxNTg835rIP0dhi9j7Zhhhj+9lLpBINvMeG+Oqzd9kwaQB9B+nl oMOg1aD7kqHXAkNsaBAEY38saXHzybKXktGKsUigaCziyRmLON1VjUXsRfYCyUUTvwctBH2BjZAC 0OdBvaAjbC15DXQPqyFTQHeP0Z+xA1zE2XNsL5kEOpi08iEkkgonu5IyJz9JkkyqrSJwgP2E7SR+ VP1xMuJH4fbBSGHAth/tUfYUW5vMCzgbjexx2k5PoFI/eYdT4mRPJGt5I33JA8HAMOtjfZq3VivS yrWnhcqiyvLKp4VgUbA8WBt8OthoZ3dBgWxj2L9sC561JMggPQgaQh/bnBRrE42jmBOfFyMb8ezX Y514dusxgqddj/HS43qsgd1KZiMwtHEDwgaEjQg3EhHPaxCuRbgO4Xo9Zy1i6xDWQ5t0A9ENRDcQ 3TqiG4huILqB6NYRvOduILp1RCcQnUB0AtGpIzqB6ASiE4hOHcHH2wlEp45oA6INiDYg2nREGxBt QLQB0aYj2oBoA6JNR2hAaEBoQGg6QgNCA0IDQtMRGhAaEJqOqASiEohKICp1RCUQlUBUAlGpIyqB qASiUkcEgQgCEQQiqCOCQASBCAIR1BFBIIJABHWEHQg7EHYg7DrCDoQdCDsQdh1hB8IOhF1HHAbi MBCHgTisIw4DcRiIw0Ac1hGHgTgMxGG2fkA41PgyIIcAOQTIIR1yCJBDgBwC5JAOOQTIIUAOjU2d M4ILzAiwI8COADuiY0eAHQF2BNgRHTuCmiPAjujYBBAJIBJAJHREAogEEAkgEjoiAUQCiISO6Aei H4h+IPp1RD8Q/UD0A9GvI/qB6AeiX0f0AdEHRB8QfTqiD4g+IPqA6NMRfUD0AdGnI/6vl4bdSNsN OGvZRjpOpxvIpzq9gbyj0+vJgE6vI0/r9Fpyk06vIbU6XU8iOsVS63QtCRhoMlBra3RDBcxGWIyw GmEbwi6E5xEUPfYGYh8gpFmNViDalNnKNmWX8rwi7VIOK8wmz5a3ybvk52Vpl3xYZsHGHGbR9ShU C7kbOEo24PkZAg4RPBv0WAOLod8Y9GwN/mIspjmOBT8rpW+U0udL6a5SencpbVTZ2VTUNV2Q1DIw gLZr5sjUwDsItZHiqdBMd+391BNIRiYGhuiBDBmnRZH8FGEA4WmEmxBqEaoQyhGKEAIItZFSwNq1 grEmD4AWI4QQggi1xO2Gmeh0GLRhZqFPD75sISrvp7gEuP3J4kqQoWTxbJDnksVLA40q3UuKuVVE 92BT7QTdlQwcQfGPM+TZZGA/UtuTgRhIR7J4PMgFyeLXA40WuoAERA6dP0bnYcF5em4ysBDV5iQD 40CiyeIIr12KjopQOg4W9RFQxHV0YaancDIwBbULkoE6XttAivnCU5mU68OTEOdpYRAD+myYtotU MwWOBe4LfIrx/hWMhXi8GxwSQd4oGqILNWPgQPkPULkxkGw08vo4HwbGaILTPYGnizYHHkNbtGhv 4JHA+MBd5UMGZN+JcW/Wu0gGbgoOsZ1aVmBjoDKwtvxIYE3gnMCSwNxARxHyk4ELAwf4MEmctrOd ewNtaHAmZlGUDJxdhLFgiC2BqwNaoDhQFzzA+Usm8a4hyeUHOAdIVab3MvC3tAi9JwMLaoeoQytV jit9ygXKNGWKElYKlHwlT3EZnAa7wWowG4wGg0E2iAZmIAbXUPqwFuX3BJesXxdkkSdEPW5nPI4H noRRAyPnkESW0Mpa502jrYmRZaR1aTBxcl54iBrnLEpI4Wk04WwlrfOnJSZFW4eU9NxEbbQ1obRd 0D5A6V1x5CbY7UOUzG8fommedWtOwjkdheTWO3OGCaW+W++Mx4nXfWWDt8E51VHX0vQfHp16ZmdT 9Juf99vRvMSDrfPaEzvy4okqHknnxVsTN84LXtg+zGzM0tw0zKycxNuHxW5ma57L88XupjiqHdGr QZqtqEaKOUE1wzQS5NWgT6bxalijTL0I4KgX4gT1jBYS0etFjBa9nkh5vYF3gs1NA0E8UKeIkHf0 Ou8UkW/VgcQA2zQQwQO1wkHazmvR9nBQH9g4vaFAAFXK8UAVCntPbyhA9c4SFd9UKRqrUnOmSo3e l5AZj94Mf6AZV8npOq4S1PmGkf9vsa5pUTo4Yd0NLzV3hZs7w81dCJ2JLVeu9CY2Lg0GB25YxwuC CSHSuXTZSk6XdCXWhbuaEjeEm4IDE3TcvxS/xIsnhJsGyEvN89sHXtK6mpITtAnN4SVN8cGG+vbG 7/S1+Uxf7fX/oa963lg776tBx/1LX428uIH31cj7auR9NWgNel/Nq7jct7UPGMi0+HSsK6eDzGSE DHfmhOLT3PbuqVygh6eEvDfk7BMJ3U5M0XjCHJ6WsCDwovLG8kZehH3Gi6zIto0VeW+YEsrZR7eP FdmR7QhPI6cXgnB8a6JmTmsiNG9ROxeVhAYW/Kc1W8N/erGXNK9qwj+k1+ph7Zq1p1vklPCa//5b +59+69atW7MWj3XRNYS0JkrntSYmzsFIFAVddTbFkTf+dJ4g6HkDqto8lB5BYRSDoGt5dzwWpVFw UDMSmSisX+5XGL9FrB3051WtPgi7YQMCrsNsfRKuBF60frCgCLclVKmoyVBcV3k66Q9VoYfBWkA5 LcpQzVGOSF9RX3lfbX9Rf3l/rYzSvU8jM/A0P0qTFU8LZG10zWlmILo2DmZjWLy/x5O5eXrH/TwS jcaja6jOr9P1v6F6PpLfMBZz1H9r9OY5v3UO48mjYDovxXpkel/HU/yXiehY8FkHIRe1Mik9iz++ +SEFV9E+kquHZ0iuGMEdi6SPnA6pVekjvIxT9gk0OTxIPIz9kuRZ8ntaQoNkkH5FPORL6qMTyExI 5xe4T+wio+QBXO/nkwepkxTiNrqAzKQi6kTJHfSx9JXpj8lZ5F7yRPo5elN6B8rvJq+QLzGCP+LE rCXnof4C0kU+Fj4k8fSjxEA2EROZQuZSN1lC3sbf5xjHfeR+8lN6XfpL9OoiN6G9etJIGtMvpE+R UnKH2Ce9o+4h95D9VE4vS6+ChVRAelk0/Xb6AxIhcfJD8izGFKUj4gwSIpeQW8nD1Ce8gtgD5EmS ombWIUyXnkdPM8lCcjlZT3rJDvIL6qRt0jvS8fS16aOQwixSgjGtIh/TGjqLPSWa01PT75ELyDB5 DfPlfyPiBeIz0gWphvT30y/i9v0cNdID9AWpSrpr9Mb04+mfwF8ZIRPAkfPQz1JyM3mB/Jz8jfyd bUhvIDPIPPT8Ms2jQRoBx99mPnYDu0F4i4zHbDsw2nVkG0mQJNlH9pOD4M1/kcPkQ+qiOfQcupTe Q//OzGw5e0N4TNgt/Fak4o/A7zApAo/WkqfIXvIr8jp5g0pov5K20YvpavoQ/T49zBLsU/aFaBBv Fr8WR6VI6nDq6/R56c9x5/aTc8k1ZAN4+0MySHaTX5PfwSv5D3KS2ukkupI+ThP0MP2UqayAzWbd 7EHcnn8snCfcI7wg1ojTxEvE18X3pNukLcoSJXXq6dR9qR+nfpN+Lv0byI4V7UfgwFlFboRUPEWe J2+h9XfJ++RPXH7Q/hS6iH4Pvayht9P76Y/py/Q39BPMEhYH/grYFNaEXlezK8Cnm9h97H70/gb3 dMBJ8T77K/tckIQCYaLQIzwuJIQh4ZDwF9EuRsTx4gRxtrhITGNlqqSzpXnSdmmn9KJ0XK6Xl8vd 8kfKTcothl+Nlo7+MUVSK1OJ1CBk1wBJugac+AGBExC82E9+AY7+GiM+TE5gFfw0RIsx7jraQlvp LHo+vZB20ZvoJnovfZg+Rp+gP8EMMAemYOxR1sjmsSWsi93CNrE74cvYzfaxn7O34VA5hpF7hLAQ FSYIM4VFwgXC5ZjDWrjybgFn7xF2CG8IbwlHhY+EY1g1j5gvrhOvER8RnxF3i7+RzpUuw98T0vPS iPQb6ZR0SmayX86VK+SL5e3ynxRZmai0KZuV3yr/MHTTXFqKkQch+2d+zIc9mM92MJe4gR5Ddh5u HTbMPIp1mIdd8Q/SIKSwLlZejrFlM5+YxeGyJiZgCK6l+0kNfZlskJkAw1A8TJL0D+yw+BI7i/yO dlKf+IxwufQLFiI7oY362AG2n04ju1k9W8i2CoR+iFPxQ8j7VeR+egldQ3bSY3QyvZ7W0g3kt8wt zKO3kPr0E0ykKp1JjxOMgNwoLiffOzOF/xihdfDOf5z6gWgRr4N+GiIPYkWfJR/QH5GvqJT+FNpN gDZaAi1zB+T9VsK1Xgf22QbsRx80yKXyG2Q3leFDr5WniteQ4+Sf5GNpHyRqGrTp0dQq8Qfin9O1 6XLsMOwysh37biU5GzvmQ0jJQaR56kLsdCN0CZyPpI0sgvPsemi9e9KJ9Nb0zemr06vJL4H9ipbR r2g/dsQQEPXwe72GXfIu3YJ9ePZ/nN7/MTO1nIyQT6iXFtEq7Idj0pVSn7RD2i39VHpdngBu30Ie g0T/CdJsxAyWkd+QT8gX1IC18ZEyEsN4J2Hs7eRSFhcOkunUT7qxZ0ugx6eNzWQNWrkJ3NuK/XwQ e+M49MSF5KfwnzHqwYyWoX8D2mkFnxeTNeRprODNdBA5y6G1S8lfMW8rnQT3QBnR0NKD0FojGNMf yF/A7bQ+rjLohSa6EG19Qc4ny9HDRNJGB7ACe0kdNGuT8Cvwu5DayTRaQJ8ErhM71Arnd530Z8pI Weq89CS2SjiIMyaN/H6cXjnkLNqDUdgwj1GSTWeTmtRcjOEtKogJ+qY+ikdYV3qTsD51Kfkl+RHW RBOvVJoI0Rrnaw1Tz6qfMrluUm1NrLpqQmXF+PKyaOm4kuJIUWG4IBQM5Ofl5vh9Xo8725XldNht VovZZFQNiiyJAqOkrDnc0hlMRDoTYiQ8Y0Y5T4eXIGPJtzI6E0FktXy3TiLIcUtQ9J2aGmqu+Jea WqamdqYmtQfrSX15WbA5HEy83hQODtFFc3CbSNzZFI4HE8f0+Cw93qfHLYiHQgAEm70rm4IJ2hls TrRcubK3ubOpvIwOmIzTw9O7jOVlZMBoQtSEWMIT7h6gnqlUjzBP8+QBRgwWTDHhDzc1J3xhQNGM UNS8ZHmibU57c1NOKBQvL0vQ6cvCSxOEW79RvQqZrneTkKcnFL2b4CpYtwmyJThQNtJ7x5CdLO2M mpeHly+5sD0hLEEbzQlHFP02JTzXHPF+k0TjsJM3fbs0R+ht9q4K8sq9vZuCiZE57d/C5oR4C/E4 2gCWFbV09rag6zuwUq38SpVgt8bbE/RWdInLQpE+q8z8MjeZos6Lgwk1PC28svfiTiyNvzdB5l4d Svr92nD6MPE3B3vnt4dDiYaccHxJU+6Ai/TOvXrQpwV93y0pLxuwOzKMHbDaxiJmy7cjXWB6pkyP 6dV5rHXuGc5SPsbwTNjjieCyIEbSHsacJvFH1yTSu2wSFgC/OAUqsRwrsiqhTu/stU/m+ZgiTUhF 9nCw93MCCQgf+/S7OUvGcuQi++eEF3I5OSNqCbrkdDwRjSZKS7mIKNOxphjjVD1dU1525RCbGO62 wzcyERdB0gbeLolPrgD7QyG+wFuGNLIUicTGOe2ZdJAszUkSrQL3JdbJS7CAmZLsBbxk4+mSM/DO MCR5N/dbkOyEIXLmn83uzmpeOTlB3f9DcVemvHVeuBW3m2Bzb+eY1LbO/04qU84ZCr6hbCyWyJre LuQw5PEYyxH0UgjlhYvOVEGi3ZwQi/BP5oPG7hAglHoGDbYk7J0zMs+4MRQa2zL/jhlSDN8CDaWP c5ROvoGNzSIxOTo2zsyoE1O+k/7O6My9Qut8aBzWOn9Rb6/xO2Ut0GW9vS3hYEtvZ++SofTGpeGg Pdw7zJ5hz/R2N0MLZRZ0KL1vS06i5Y44prKSTobYMjJtIExvnzOg0dtxfR2Giyl4+/z2JKNseue0 +EAhytqHg1C5ei47k8vrBHmKtFIIepIZ9KKcYY2QjXpdUc/Q08vgXtLzMpWQR8myIZbJs+v14vF4 OQx+eLbqcHd6ldwv15Gl8g5yj3InUcQ1ZCbCAvHPZD5oI9tBvDyOuvchvVmnfyb3IG8uwha8tNyE /ErUCyB9JyFomIsdwW1AxslCSBC3gUyOnv3/9eDOOLym/FYbcBb820/6txwYb8hTYOWqsE5MiJsR LDgfCU5FO3GAOnEHcuFew38T8beTnseuEh4R+6Wp0l75gFJvKDVcqzrUs9UDxpgxaSo0v2o53/JL 1MYhB07iDyNTyLTdjKZkZYg1aFlEElMCMSpiihKfQZZSTDhAI0TFxcJLvFH7yfrR+vPsJ+pnjdaT BsTtp/CYUBlyhBxFeMATSU4FhZFTmkS+JkFxBH3htkikJbjT2uEB3aBVl0glxrM9XWKXWSr11Hlm uOPulW6pzjMxZ1POI9KDJingKMJaZzmLbHaDr3iXQhXuJlBNMQzxDi1rY4gGQ5UhFnI4gyRor7Qz +xDbMhicMM8bxdA6+Nhm2Tt6TkZ7Zh3TB8kHOqGSdPTQjqxQlcftdma7YHfjLxyijuqq2qmsJhaJ FEfC97O85zpvHOosr10x6+alT46+RUvev652xuL6+kvnTd0j7cuNvJg6+us9N/cvay0NiC+eqrE6 F768Y8feFU79K5Gl6aPSQektSNA7Wsuk/Nb8hcqVhivNtxpuMd/quSVHlT1yjtPjzClxlHhL/CX5 hhmmC8T56iLTxeK14jXetf691r32Vy2v2H9vP2q3CrlykGDqWsBfh3fIpIhR6s4tl1WnZnXGnK2z s2iWlu2NZQ3REq3UXW6DrU6DvsXILnYuZIFgUGD+YEFlASvwFfcbqc0YMFYaBSO4OBi6YVuGW+DR efaOk5xp9hPHehzOugqs7OiJaMeRaMMxB1KjPdF6ZHMG0o4OWhNyyGK4oBAsc9ZOrA6KHikSCRfI 2XZnddXE2hqhgd3Qkdq25y+pHc+ODN/5JnXQ6rLUe4GdG1/88KMDHfuns5wvRocWbX6BXvTWh3T5 4pkf/qL20utP/j31derrmbF9mOc9EH4f5MXMvJrJJEQMEZMgClSA8tLU3MkxY3DylJgKR/jgGNWe zB2PXDxk1WD8s/qpURRVozGL5Yp2NWAMszIxqFYYL2IrxS71YuN6dpX4pLrDuEfdZzypfmV0bxP7 1G3GV9SfG3/P3hHfVt81HmUfiR+qnxgt69WrjDezO8Sb1TuMfUxpN3Wxi8WL1JXGK9nVotLEWsUm tdV4vuF8td2oeI0V1hibLMbUKcYGqyIwsyirqjGb+UWPqgzIbPr8di3ARMGoSmZFqZKt5ipsQbvA DG0GS8zEH/osrSZLzKBZi2Mm/kDWVs3OIyaDgB1GmWKEYmior2/AwnjqMt6lDlpxzP7bYzwjZyg9 RStHL0HRoKpVgugSBBFuT2OVwBBlaEYwi4yZjUZVVQwBK7UOUcsgt3/3sUlEwm67oCMmcdHzzJsf k6oUTdlgoIaDG7AKB01Bk5kNsUmaE1pEQ0WioRKpCpipmTdjmbAOiuJEz7Fo1F7/v+z1fp99tGe0 p97vtY9Go8iwH+nB4EExfox2kzQ+uun6n20a7+UkGp9QiXcVWfPgvTekDw+YgpMmxSF3/NdzBZ8q ifZ0VEPVUK50cMl33EP34yai0AOpY6n3U39O/VHad8orfPRVi3jT1zfwAJlSoEy3cJmiac0ZFaJy 0FRtEolMTZp/cgyexo2DoJz5p2nSVwMZO6qp/ryY0YeH+XSK8BS4c1iLu/NiYhAPBcssm/0kWx1H ilTlY+NR8xfqP41fmKVXpZ8bXzW/R34LqXrb/An5UFV3ij+UdhqfMu8XB6X9xj3m10R1vFggVRiD 5sfE+6THjA+YDRlh2W2gVgt3gw5aQ3xwI5qKCIQixIe8dTAjL1u1bC49y3nKJEMJKBARVZcQyMg3 EkKxi+tydr9oEqXgULpyUIaADKWrtAsFYg4SgbEg3irhvZtRlqQqk9FlwqVIVpSgQXUZDKpoMpvH RAmdCGYcIqJZkIwmRcXbKUWRJBEiRTNCRQxWj8dfAZkZopWaMSgfNB3UKvgeRtIc5B4vRn2W7y3L KCG/b9Zoh987Our3jXZ4z2vuavrLGQnhcsL/9NFjAo66OjyJgwvOrG9LzpgAnZYjeIAhSbrYZDaI 7sPt6QjRUBakJguUUtqVeoJWvE/NMIrpf9PS1NbUK6k/pN6HBDmEz07hNIMUzfh6CKfYzPRH8FRN hQevivZoKxW/IVfKc/vPyZmRO7Pov+wfONSJvhbf+ZEVvosit0Xu9d3nf9o/nPOq/7Ucsyxbst2y z10sj8uO+9az29jT8h75Fdn8fOxdO8srrJrgKLMUatHxsUKtoAQPX15sdeGpQlbYkscXvdJqi52V R0mePS+R9888MS+vjFYTDbk2HKmMLAhpuY6GkJZjx8Prj4XgZd8jKmaLsYzLDsp0imKdokYZamia y5Q/IWIYp5ZY4gHzNjPDDk5jE2tWd8zsnx2jsU7snLsqwabqcaHFHvqBh872LPas9ggeX/WqxrED 5IpZx7DZO/gpEsUWReoINw6w/aMN9Q3Y8tETHdEjOFc6eqIZsU5W5NGe+LFMYpgUpkeey8mLzS9c Xsg6ovEOICCpgtVeX49jm/Z08JO7eOLE6iq3O1twuT0hHNXFshwuiNTEJk6sxaET4ycQlXGiZ7vc ONCRWUO70tE33zgw1CrkFKU+MdkVYcaTHU8eXPjYvS+f27a6dT793sRPCmvbm85trrab2J/GP3p/ fPNzqaE7bj03t9ZnaGlJ3r7oztbcomDunOYpqTedVd7i+ikLqyK1hV3gygJIQwOkwUf+W5vTbos7 YcTYVjlXua/3Xu17iD1kfsX+ivf39re9H8sfGz7O+jj7SzlrUtak7HOc57hbvHHzKrMy2VnrrvUK 66X1tk3SbbbNvu3OZ9zDzr1u1cpXzZsT43SP0xWzVlt4ji8/plObI2bZBx+gEWvodJiIhqpEQz1S 3Ye12octLKIo6FEoz6UhUmHhEUtoNjS9P0cJuXz+9szy8dP/ZMesY9ETx6L82MepH+WnfxQ0YzL1 dNCxA55zdmKtxBlPHHaC5RAnpP5qXTZ71fUbLmlbkU1d0ROvf5z6K3Ufe/FD9mnVvPn37Di49YLV FT99ER47ERq66BluD84H77g9aMN7hz6t3BmX48a4c6F7oTee+7DyiPqlqnbnb8xnk4WYeXJ2zHeO 0GQ+J7vJ94iquvj7I8nk5+JrNSlWG5bC6BlntUToEB2n2WzEf3c+zbeHDL689npdQPkMe2DfHBut 50oFf8cajunGTE/H9HbNskpeZVzlXOFe4V2VK3fAo1IzNkGYMx4cMy4Pn3ZGwsQlqa8bBxY9B1vl xeRN1DfqrGi6Zsntt1y0fNPWC+JwN0NfU9/9zH6qe8e5lz/15HOPb8N8GzHfYsiKi+TSHw4Te/pL rcVU94j6qOVB+3bpGeN+db9lyG8wuOgMdrbcYpydv92yV97rf9X4mvlt4zvmL5UvLJZcW262hl2S rVkdMVv289lvZAvZXCps+Q06tXpA2Z2a2WZ1tlk7rczqdVJU2OvLidFqJzckB/OCMZ0WjMvQaHmG enN1qtmgUvrBUpjqjCx2OsHmQdHk9HJ2F5oUEqIV2RkhqshfnL86f1u+mG8LGTSLLQaGj2mEaMai hFCdgPl9jL81dHm1EleDV8u34QE15OX6imvleMMof31HnBgcajj5IFFJp6jHafJ01RPQH/ynAwgK nHV8MkkPJ4lB1ThVTzaGGvTXdfEjXIt06N1bNXDJyju18u6tGpilHwdxmLfRKMwKHC/V/LjoIR1R ykU8WByp4TJOhJCbC0AWN3IV2cO+ot6JH+9K/fXWVdT11jHqlEc14aYl0xYVC1ctvLC+ntK5FY8+ vuee9yEL0dSrqYPXb5lBL71mw/TpeAVL8Y6FsL/ghuAmQ1rVRJGWikF70BEXN3olg/i8l2W7Hczl dDusWbjlWbMoPmVzqQabiS42pU3MxBfCKFOHzU3TburmyXz+6cdxNC1nuYxqdYNhNoxJwVBir3As djDHEBU1izUrwlyLSb97xM3c4Nle1Rxz+zxXDbNVuNTh0hTtqZ/Fb3KnOupPdPiOEC+2SUdP/ShC Ax51VTb8xnRxVjXXutgcCle62dnV2WEYYmHv1rpH1l21JjJ96lk1b76ZOrpVjLTddsu8wp/Z6+a0 vn/qOWGmvvdTc8RO/RStoOdpS9fnbcpjTrOle8Jtlo0TxCANs7BQSatZtaDR6Wy6cIEt7ooXLRy3 MBqvuMT2pePLLOcUS7V7Skl1Waulyd1a0lR23DzqMd6Fc8tktphKzZZiq9uTXW4xe9yit5DvgD36 DtAF3+rQhWTQZM7QktLMBggXZeiEWGYjqNk5+uG3WAKLkwFbMSdWYzlnuClb8frk0nGmiN/LlY7q 8/n9d0+gE6CChvCCvLow5PRVntE+J8b0j/2YffQIV0BQP9CwuikbHTsQh+Eth43n0DvH18Ux7Iwj UVg8kG1utPGgGOz8Egt13NGj6y3bKteqoovGrYiuqoDeIh0eyc1VlX721UBHjwmwBxc2l5WFgzgs s3QVntFlV9NGQ17Jwstri7IsN4y8ff1SSp9/eSNVpnbvvzv19z+durnzortuX9l1c0vxpOz8kHtC +HuPPbvn7t9RE/X/+IFTZx/Yd3H98F1WdvOPvv/4D57q/z4Uxn0QxGeh17lPYf0wUWG5NDiMDZra prKNakIdUQ+pn6lSQO1UN6j9yJAEWYHDQYAW18ghvBUQSAdcE7IkK6KRKTgzsHqaGiqMiT5DQ0ad R8dcD1yTc/EUJJgJ+KcL5xXRLH4nQLiP+lJH8WZrLxVTp74+R4x8/R62yGa8/VqMEZrIP4aJkH5/ 0OJo0M3q633lMQUXsSy5WF0h7zI+b3xN/aXxPaNxntApMIviVVvk8w1XytJe9QPxmHhK/FyWzlPO M6yQrxfvEB8Tt0qPyo8qjxqMAdEpR8WoVCqXKqWGCkur2CoZYZeoeL9glIyqIIsmSZS5A8ZkMii4 jRtN4hC7TPNLFYa6AHwdXRZmitCNhPIrv8/ccO2YmcXn7bOf7PFCrXJ7GKKEJ2cDv0MZrrf/zFB/ 2qIS0q8l1VCMnDaBe8gVsKpwaeL3JfxTHJvxBm0mXZR6gN6a+k3q85th8J6kV6auG/0efX9z6ll0 /c1qzhvmV0JtHF9LqU1iG6UE3mUekj6TpIDUKW2Q+pEhYUpwHDEhQvlO01eN+MR/W7WxdeJjwRpJ +75qQV+48YtxaAU32aZ5lSxP1iLDSoOIT+pihpi9ydBk+9guyXzv5TkUXIjMJhOOfUYjbqIFC2O7 8Dk/GsFuRL/ugsJYn7ffy7q9x73sMy/1Gk0RM+6345IWC65wI5oNkH4zPQ6N4fOMjQ83S/iMsEPh 3OLXzJN6hu7jyjD5tMUQCjngKYLek7Mxg1A29GA+yxbjqaOFc+pmro1C6KQtb3U8OjvA8p/tmtR2 SzIVECNbd09fecu1XP/NhS3wKGZqgeX4kDbjI3rU8EXWF9niq+wjiTl9kk9lcfvCrIXuuPch9rD8 sOEh85D6O/Zf0h/U35mPSkfljyz2Zwy/ZL+SXzK8YpbWGTbLtxgEB1dPRpOHs8glKq46xd+Z053D cqwhXFa/Zer1nOQusYwBdFqTqKvsK2D/rPKKtANqBD6ymBPTItkuAjdPpOhbOmNu7+jWv9FY6uef 3pv6opcGH7z88gceuPzyB1nBHVTuTb362d9SL92S3v6D7dv7t27fzue7JXWp+BDma4et96g2flLW jCzmjAl1lrqsWE6TMNMyM6sp55856kJ54Rkb8KTyzxx8ZylzKy8pKdzm09wmE97TeUIGfzfsO8c4 q9UWsdt1o8/UTTaiJ19eQ8akhUerHgtpP8LtPt0DqKtcriFwk6Bcd66QV3zb5iNwC2bzI42btbhV FHOzD6p0zOrbQuXqn1w8TFnq1HD73bOxxO67Viy96bZlF92OpW1bnvpjajR1MvVuy4LRj4XhwZ3f H3zmiW0QyE2ECLX63LdrJQ9JVLXSedIKaZ0kVDjbrSut3U7RqNrMATO725w2swbzbDMzD7H12jhF gXwLTDaWENWuVqrdqqj6Nzi3Odli5wbnLuchp+i0kwi/To/TTAwfXvfz+7SjYZjmZg50nOdnxPlk h29W5kjH4QPprsM7Uc6KHnz+5cHnXzX8kzBj1SQsPsQ7w4nM4S47aD+X6OmXNHXGzz/7rClzK8TI Q5c01Xw+vnFH6m+YYyXk2Y45lrIXtRHZIYcNxR6HJ/yw82HXQ8UPlKqKq8XFnPstw9ZXQx+Gv7Sc LJDHWRZYuiwPmB5yPlMwbFYaw1phU+SiguWRTc5NrtsKbi5UayPNcovpHMtsW0toWoFSUFgcqTXX hGoKasI1hYpslBxqyGspNhcUFISVwgKtbI35KtfV2VeOW1d6e/YtpY9mP1C6u2B32LKR3u25w/tI 6Y9KE2WyJ+TWQuGYW8vF17du+gHMp2pDqK3o7iJWpHnzYkV+fjnWPNBybWW0soxWlNGy/FClndqr aUi3Hmxqg05RJaPjVEuM+KJXDXEVfQqmqX4THtMg3Pt8gnusjpGMWtZqZEpl6qaRgomhltB8Gvcs p6s8J+G78jDRHypgJVkWMyvxL8a3Qi0lpjY/9bdkKbC/8I+bAqdDR0/OMClI/3IQ1ktoKEMLuDs0 v5CnDw8GCmN62sddAXBT5SByiYVOLGgpeNhyf8HPCn5bIIcKzBZR9PN5cPuIVHNLadBT3gCqG9N6 uqAoxqmW58cNAU4bDR8qiZ10Iz1O4WeyI9WJix1HZrlRk1JtFvyTi8XjIuNTcGto2l3t0dCuR4OF 7tFqamMe7unwaEXj8EC7Nk9AdyqIngV+Ddrb5qdt/rSfjU2+h7sP9B8c0jjx4ZnmXOU3VM6QsUuB ftLBU9CDXwc3+rlb4eeaanI22ErwCA2lP91rqTO7zHU8mjTXgUOfDJjq9GsAPgiMw7LKKuKmPlwH MfgXIHSwc3HJzfi3uWcBFiX/ZgC2VaSS+p2XL7ustsiVPTP17AU3vPfhe78tSX3hWNy+ujKYG6Ev xNtPfPbuKK2Izl1QklsRzHY5WqcufKT3wF1bJkydFnCH87NzV5zTetu9byawiwLpj9g90vdxJryu jQsSmMHGcbbJ1nOscZviyyZewZ1NPM4sF/U4mYt6BVUxKmYYn1SzEU+/J+EROkFG4JeBuZ/ERRwq c5Bk83c6uCebTXB+VxBSQRdDS/ALQYlXiHicC7IbXNtcu1xCp2ujq891yHXcJRGX3RV0VbpEuAiu 6h8zPa5oTdRCT0yBnhgmrvTIpHjmtoB3LfYT+m3hmP4uCDe0IzBVHdVjt4UOiquBS+ephzMNbpsa R7imuqbIwa4ZMRXnFp/jXXrdudfUmdQbb6R+MXI4Nf+maG7Oe6XVc5onPEDfOPzWk6nN4M+d0DLz 8G2Sm2zVPOc7LnI8KAmq7JPrWb0DX7c7jjLFxqfqEE1uYsx24SKE21AkO5twBWl161ZC5sr0P1gJ qoGLum4eGOhx+C6/ax582zbIHDFnTLCMddCRcR1EMEmY3PqtcSKPCudNPrjqkh3nUl9gbsOMK0qp b9uCpd/b8SDrT3kPd02Zve4IHYF5yt/L8QfuAsXk95nYvzz5//cQSDG+zKkkk0kTvtY7G18AzcRn /ufiS5vZZA6Zi68WF+D95fn4Loj/KHEi8B//YpIsapo5LT4n2njFqiWXlk9bfenyWfNR9L8B6sO4 hwplbmRzdHJlYW0KZW5kb2JqCjYxIDAgb2JqCjExMzI1CmVuZG9iago5IDAgb2JqCjw8IC9UeXBl IC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0dYVVhCTitBcmlhbE1UIC9Gb250 RGVzY3JpcHRvcgo2MiAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIg MzIgL0xhc3RDaGFyIDEyMiAvV2lkdGhzIFsgMjc4CjAgMCAwIDAgMCA2NjcgMCAzMzMgMzMzIDAg MCAyNzggMzMzIDI3OCAyNzggNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1Ngo1NTYgNTU2 IDI3OCAwIDAgMCAwIDAgMCA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggMCAyNzggNTAwIDAg NTU2IDgzMyA3MjIKNzc4IDY2NyAwIDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyAwIDAgMCAw IDAgMCAwIDAgNTU2IDU1NiA1MDAgNTU2IDU1NgoyNzggNTU2IDU1NiAyMjIgMCA1MDAgMjIyIDgz MyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwCjUwMCA1MDAgXSA+ PgplbmRvYmoKNjIgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvR1hV WEJOK0FyaWFsTVQgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTY2NSAtMzI1IDIwMDAgMTAwNl0KL0l0 YWxpY0FuZ2xlIDAgL0FzY2VudCA5MDUgL0Rlc2NlbnQgLTIxMiAvQ2FwSGVpZ2h0IDcxNiAvU3Rl bVYgOTUgL0xlYWRpbmcKMzMgL1hIZWlnaHQgNTE5IC9TdGVtSCA4NCAvQXZnV2lkdGggNDQxIC9N YXhXaWR0aCAyMDAwIC9Gb250RmlsZTIgNjMgMCBSID4+CmVuZG9iago2MyAwIG9iago8PCAvTGVu Z3RoIDY0IDAgUiAvTGVuZ3RoMSAzMzY4MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGMvQlgFEX2P15V3T330XNPZiZzZJIJYQKBJBACkTRHQETuwwSJBLlB5Aig4kFQOUQUdFe8BW88 kBACBmSXqKzuqiysuu56sy6eK8rusqwKmfw/VT0B3P3+f99vhqp6XV3TXVXvqPdevRqWLV0+i9hI E5GINmPh9MVE/IWOo/j9jBXL4vq1PUiIYeLsxXMW6teeq3B99ZyrrputX0eqCJm9ce6s6TP1a3IW Zd+5qNCvaTnK/LkLl12rX+d8RAg1XbVoRvZ+uBX1axdOvzb7foL7JH719IWz9Pa38Pr44kWNy/Tr m3+LcvvipbOy7WktIdZf//zagVeg1WDyD1JFHiZGwohKSshkQuTn5Vyi4JrfV5xTf7H/6X7TnFX/ MoVN4vGP/bWwOwd+8+CVl/20s2OOSkw2XJpFe34D3zMOzIwmQ1Ty086fVqr6m/idrr/B+8hEqdvu VDB29IBURI4hMamoJZ0b2ycVSrktA2Jam5Tc7faVOgf1kOJ4YonI48gXIe1EOogkk2lSFHdV5KuQ mpB2Ih1EOopkIAQ5vxtHWoS0FekYkkHKlSIt8Zg6qFDKwXdzMF6nFCDfI3UiSSSGvARpDNI0pE1I W5EMoh2vWYS0Cukg0kkkA9GkQMvdZeh7oOV2Ueyef1WpuJyuX06tF5e7L6vTy1Hj9HLoCL1Zf71Z 73K9uudgvSws1kt3QWkTHr7bYi9tH+SX/BikHx1fjJyyQ8RJKYmRbZKPNCMxCV0VNZrk3p2fKt16 UJIJlZhEyUwS62yXaIvdVTrIwjrZ98RNYuw7dkK/w07sdrhKtw66hH1GdiIdRJLYZ/j8hf2FrGLH +Jwjr0bainQQ6QjS90gGdgyfT/H5hH1CnOxjUoJUjTQNaSvSQaTvkYzsY+Qq+4hTjMg5XI3E2EfI VfYhhvUhcif7ANAH7IPOdvZOS0Vl6T4BpEuyQKwgCwTCWcDtL21jb7f8WASKSgHToKiXpDwykJRJ eS0FvWNtUrClal6sjf11dzwd2zaoF3uXNCMx9ORdvPldEkcai9SAtBjJAOg9QO+RJqTNSNuQmpFA ZchVpDh7A+ktpPdILyQNaSySiR1twWva2JGW1ODYID/7PXudBDDjh9lvRfkWe02Ub7LfiPJ3KKO4 /wZ7rSUaI4OsuE/wHRWlirIE9xX28u58d6xzkIsdxAzGkJcgVSONQZqGtAnJwA6yvJaZMTce8hJ5 AzwcYy3ka1E+RR4zEW1+TEsNAQHGeZbqfxEgZFvjW1NMS225H5c8S915NyCepW7dCIhnqZWrAfEs ddUKQDxLzZwPiGepKdMA8Sw1ZiIgZG3skRfzC2MVYxbQ+CAnuwazdA1m6RrM0jVEZtfwD/lR5n18 sKV7d8zYA1q6qHusaT9tOkCbxtOmx2jTLNp0E21aTZuqaNMVtClNmyK0KUqbNNr0Eu2HqWiiWuvP Liu1IG16gzbtoE2NtClFmwpoUz5titMKrY0lWkaA61DUiGL3IM50LLH7ooGQPk6WwIwmQPMJyISD yI8gdYorDY3ieXrjnCgv83Z3r9ave/YvXTToYvYqvvgq0PAq+RRJBoJeBRm9ioe8isc5kVcjTUNq R/oeqRPJgNZ5GMcmkTuRlyBVI01DWoX0PZJBdOd7dIWRRch5F3eKjpUgr0Yaw6/Yq/jk4ZNgCS1X jahp9WJpU4Q6o3RMtDPKKojfD7nsdplcbdS+99/2H/5tJ+ZBZnYn20RygYjN2XJTy4+5sTZ6X0vq pdggH72XRGVQHa0kKVqAsh9pFNd9SMTE68tJhD2HsrQlMhlfc7akimP7qYN/a2/sx8jx2NeRNgbw q8hLsT/F22TaEvsjap7bG3s3clvsdyVtJtQcSLVRFPvjoum+SL/YjjdE09W48UBL7CZe7I3dGBke WxARN2bpN65oxJXmjI1PTYldjOcNjVwZ0xrxzL2x6sgVsSq9VR/+nb2xXuhCWge7o7NFEfHSZFQ8 cFJFG52rFRu3GGuNY4x9jaXGYmPCGDPmGsNGr8ltUk0Ok81kMZlMBpNsYiZi8rZ1HtPSfNXzGsTi ZwBBUyILWIWEoVzMICeMmhi5hDR7pJFs5ITBdGRz+wwy8sp48+kJyTZqGTelWUkOps3ukWTkxMHN /dIj24yd45sr0iObjWMvr91F6Z11qG1m69somVjbRjt51Zpws3tI7T5CqWvNHWFedltzR10dCfpX VAer3QNdlcOG/g9Zg6hsGJo+/xc8D6aD6dzmLSMn1DY/m1vXXMqBzty6kc2/mBCfWruP/oOerBm6 j/6dF3W1+6SB9B8143m9NHBoXd3INjpZtCNx+ne0A8WgQDsTFmbejsRNUb3dA3q7Anwf7fJ5gXZm MykQ7QrMZtFOprzdrsb8mqG78pGhTSBOGkWbxkD8wjZvFKBNATK08TeRN0SbN/xNvE3zQPGYSARN osjQhIZIRDSJ0JBoInq+SzQpyTa57VyT28SbJL03og3P8Bj7sa429mNoc8FE/r/BWYPTabp7QN2M qTWzkjUNyZpZSA3Nt6+YG2xuujIe3zWjjt+IN0uphitnzOXl9FnNdclZQ5tnJIfGdw0Q3/uP21P5 7QHJobvI1JqJtbumarOGtgzQBtQkpw+t2z18bHnFz95127l3lY/9H941lj+snL9ruPjef7yrgt8e zt9Vwd9Vwd81XBsu3kUEjY+t3WUig+uGAH+83M2sFtBrQzhRN9ivLh4oiHdAInhTeD+0le3Emq5r tiUHN9uROF33GNRjEL8FnuK3HKh2Zm8FbxqQCO+n27O3VFS7koNJetnyxuUkWDNvqP6vEX+oWrac o0LP07zuf/xDk5pmbfpQrluPbO4+YWRz9bgptbuMRtQ2DK1DXf+uOqu1pq2zXa/sicr+vKEknWvI 66p4ndmcbfjftCD6hGrMzj4oGi/tplqULiONdVJzdOREBlEwcQqmYeqU2v3Qpfgi0ViHATbSNG3s ehofh4CJXkMw7MautGx5FsrOxbJsKZo2pkm6sWtKuh6X5pMlMjFXy9IQbcp+koMUUp4mOXKKwP7p /BLpK15m5nV+xe/zkn0DQdeWTbBJyA46j+wgB8kr9CS+tZPsI62Eq0BDyUPkBvJLsg7L2hTU3EbG 46Og/pc0p7MVlsmjWDAfJYfR9jJyE9lP/DTY+TVZRdZI7+Bba4id5JFBZCxZRO6gl3YuJ1PJp/It pIJcSq4mi2lTZ23nnZ13dz5BniT7pN92dhArCZEZ+Bzu/E75c+dHpAe+cQ+5n3xK7zbvIRre0oSW D5Ol5AGpXqadczp/Qg8S5Br0QSajyGHaztJ4+izyJQ3SG6QheMrjnc2dh9AqQurJXPIA2U/70OEs oUztHNV5mPjxjmvx1PtJC9mLTxv5FfmA2pSTnU90niQ5pJiMwHhaye9pu5TpWJ2pxrwpmKUiUok7 i8ivyevkKE3Sl9kixaaUKpqysvNd4iW9yST09ml88wv6b3YTPquk1+RhnYOJA/NyF59t8hvyFxqi JXQMncyK2CL2iLSUmPDG3vjMJPMw3/fh6Z+AjPYyGzsiPS4/J58x5GaOdTqAkRR5kDxMXqZ2jDRO G+nN9D36VzaETWMPss+kX8rPyG8bp2PUV5CF5A7yHPk3ddN+dBy9nM6lN9B19C56Pz1Mj9Kv2CA2 kS1g30tzpSXSr+TB+EyQG+VblLXK7YavMrWZQ5k/ZP7dWdq5lowDPaxG7+8hj2Bk+8gR8j4+n5LP qEKt1IFPnCboJHo9PjfRO+hjdDt9hrbiLUfpZ/RrLEn/omcYVlpmYGEoP1wFSrKl0DB/yR5iR/A5 yr5lP0oBKU9KS32kKqlOWoRerZM247NH+oscko/InZjnUmWLslXZrjynvKKcNNiMN2ONf+vs4x3d Oz7JkMz6zJZMS6a18y/EBxxi9YAJVoXeT8dnPvC9BRS3k7xDbZi7EO1OB9JLMTPT6Hy6hF6LmbyV PkCfFH1/gR7ALP2Jfo8+21lE9Lkn68MGszH4XMFmsSVQxu5mrew99pNklKySU/JJ3aXhUr00S1om XSdtkZqlt6SPpc+k09JZfDplixyT8+SUnJaHy9Pk5fIj8pfyl8pU5U3lc4PFsNCw1tBm+Du0moHG scZxxnrjJuNe47umBlDnq2QPeREUeO6PHpNWSzXSHnInK5NzYML8HvQ8jcyURjFQKttO17MbaSvL V641DGAD6GhyUk5hrl9jW9lpNkAaRUfSCWQ+660/0OCVnwVUJb9KTsgHMLbf48nXGmz0Jva9wUZa oCNVQkf6jdRLTktvkg+kT6lRfpR8KFtogJ5gT0tjQQW/kgcqtSQhPURekJbQG8keVkOI5YxpI+h4 NH0WcmEiLaU/SJ1Qg0eDiiqkv5JbyAL2Z3ICfLye3EtnynPInaSM3kC+JE+BK4qUqw3dDT76OzZP 3sA8tJUw+RmMrpLmU0nxkltpvfSA4Xv2PllOjsgW8on0PHp/hL0gjZJPKuPpXHDAjWQtWdK5mlyn 1Mpv0zlEopNJgXwM0u0GqVROoFwFqTIVMm0vuHs/5MAgaRRqgqCcS0EXkyAhHsDnPsgJGRQ0Dzx+ GaTY70mrYSJrI3MUB4XUgafmzcx4MqXzKXJ/5xxydefdpAfkwbrOG/DE7eRzsolsp2sy15PFMCXf B29fqgxjR5RhnT3YBvY+m8C2/By/mO0CGiTf4PMCMDNQeYlskP9EJpDqzo2dfwR1d4OEvZ9cCYX1 OEb5Hd5wsdROyjKj2a7OYdJijPdTMq7z6c4YtZC5nVeRMeQAedKokOnGNHDcTN/GeK8ns9j4zmXS rMw8zMMmzIKG2VoO+XObNmTSxEFa9cCLqgb0r+xX0ae8rLR3r5KePYrT3Yu6FaYK8pN5iXgsmhsJ h3KCAb/P63G7VKfDbrNazCajQZElRklxTXJYQ7w51dAsp5IXX9yDXyeno2L6BRUNzXFUDft5m+Y4 /9503PpZSw0tZ/9HS01vqZ1rSdV4FanqURyvScabDw9NxtvolHG1gO8YmqyLN58Q8CgBbxawHXAi gS/Ea4Jzh8abaUO8pnnYirkbahqG9iimu6yWIckhsyw9iskuixWgFVBzILl4Fw0MpAJggZr+uxgx 2THE5lByaE1zThJfxWOkgprpM5vHjqutGRpOJOp6FDfTITOSVzYTrimlRRMyRLym2TCk2SheE58H HaeZ3B7fVdy+YWObSq5sSNtmJmdOn1rbLE3HM2qaXWm8d2hzYOXx4PlLPBw62boL74alDTXBeXHe eMOGdfHmbeNqL/huOMGfUFeHZ+C7rGBYw4ZhePVGYGok18Wb2Zq62ma6Bq+EYlkgRqWPT9d6Cxrm x5vNycHJuRvmNwA1oQ3NZPx1iZZQSNvXeYyEauIbJtYmE83V4WTd9KGRXV6yYfx1u3O0eM7P7/Qo 3qW69Ind5XBmAZv9QmAWJl2/JyDRnEMjx5+bWcr7mBwBTbA5PiOOntQmMaZ+PJvVj2yY0Q8IwF8d xbeaZwIj85rNQxo2qP15PYZIm5UCNRnf8C8CCkie+PbnNdOzNYYC9V+E3+R0co7Umun0Lrg5nW7u 3p2TiHEIcIo+DhTXfXoUr2hjyeRiFfYzNxrIWMzt9Lr+JZj+RIIj+PY2jVyJi+amcbX6dZxcGW4h Wgl0a9bA77R33fFN4neauu6c+3pDEpTcyu1Z4ms2pc79c6p+T83c/s3U//+4PUu/P3JCciRU43jN hoYs1Y6c+LMr/T6fUMwb7mWhZs+QWinMUMchFpbEXV1D7moCdbnW1iwX4J9BEPXMNqMJVClqaHxY s9pwsZ7XWRKJLM/8b19q6zzJvyWK81/LDqO5fzrbUb3bzQN+dv2z7tk2SCMnQuQwaPYbNlh+dg+k pvdyRLYAxcPQT8SHNJNJ4MwC/IPJ0Y+nunCzhinDnYngIlFdF85e/qxhOPulOvxx6uxRPAwyc8OG Ycn4sA0NG6a3dTZdmYyryQ372CvslQ2LayDtdMJp69x/e7h52MY6zNhc2h/swcjgXUm6ftwuja6f MKV2H1wc8fUTa1sYZUMaBtftyse92n1xQjRRy3gtr+RN4vyCjKQYZAszifbhfRohTeKuLCrE9Qx4 N0Sd3gh1lMxoY3qd2tWOoU7W6zRRx8fHZcyQibVZtAiC4KwHGsIODR7DdQxlMqllz5IbRKokz6Ic hPr9/J7cSCYhfYpUhTQZKYTE60YhTUeC/komoe0+ZXJnB561RXmdzEZ6BPBj8l/JdkMlWYj7B2GV VqDtFsOz5D7cfwj1M9DmEcCPopyKtr2ysNl4B+yrycSM9pcgrcV3x6IchjQSz/KgHIy0jr5O1uPe epS34LnreB3S0Gx5McayBver8Z181N0COIR3cIeUEymB1I0QTARnXoKdLgNpRxknl2dreC3UHySJ W9z4U9DGCNvBTCywoWywuxzEib0jF3ETj2jRlXmhM/hhrwWFXkxIGLoxgUsRjm28IQE4jyRJPimA fVEo+tH1Tb0sIt1JGjZKD9ITulIvWCqElJIyUk76kL6w7PrBLupPBkDbvgiO/WpoEoOyD/ARH7XQ S+jD9H16loXYeKmX9Ii8W9lmGGvsYQqarja3Wd62EusfbY/aB9o/cwx1bHXOcb6vjlLvdhe6z3q2 eHN8Y/xP+M8E7ggOz5kd+jYyKXdoNBr9AZ7K1Ynr8kbm/Sbflb+p4OnUhsIF3UYVBYseTC8qpsVH e3zay9s7VTq+bBh6AnWET5fC586IyXYlXAXI4AkkZ+NS+1lNIWdIXG7n92s7P1EKlXcwM8WkL71I ++1K31L/0sDKnitL1vqfKvmYmLbkPu5nt5Xc0pfdErk1wVr9tCEwPcH8Ps0/n0jPRj/ws8ZIYy5b HloaZsvJ9X62IXBLmD3je8HPboluiLMNllsi7M34a4XssP+VMNsfes3L5vXd72fzArPK2KwSOrls al82rGxKjI3yDw6zXqHKGEuF8+OM9OgR7dHTYiFhvz/XF/f74/H9lh5ei6VHqkil5UXR/pI1vDY3 eUWDZ7Fnm0cq8Wge5vkod1OQBtvYFC2SMzC6NJ5Lc/v1K7pim53at/W+Im6kxvkVS+4LptXT9SdO 1Z9QT9UfP3WiHgXg46T6+InqE+scPdOOG9VDRkfVOgcv1CoB9O5F6//7j2SrCgyGZF5hqk9534oU z8tKoSwqtG9FwGD0B4wp2rdvn/JUMs/g8/oDlBp4WVbaVzpc9/bKv9y6YOcLMwYfeXjLwczfqLFH zku9xs9qum5hJrq8ZtrwEdOTSToqs/fu2XfePG7Hjhkz7rvh/vUfTlh65+BbX21b/YdfZnbVLuvW fsPayzcNk9bUzK0eOe2KoXkju3f0ofdfds+IuvZZ4KobMuNYAzCtkos0S6ETG2luo0lV22jZbrLV YUKpuYxbHVcQSZXikiQ973p4o5ikjtMn1NMnSHVVdRUfP00xV3lF34oygxEfn0rpp/f8ftSUA6uv K7womabpzLgD9Afq+O6DjjNH6zZseelXmVgm/rP3z9Js3Vg3lZktKiVuM++BZatEUbZip/MKB9a2 VlVlkwD80Op0CuB4q90ugG81p8XCJjkdMQdzPO/O9pH7jP6jn54kcZUXpvAp80NrV1nHappO511U uHL1gSmjjmTG0WP0Lwf2bdkw5e0zHR98l/lHxoRePpv5hN4CT4uFjN5jAfs8Z2ijY7UUlaoYA2tX EQu2MaUqYuhn7D8GVugi2FTbwGrbrI9ykjpVf+q4eqJKrSLVPFdPqB0nqMtd2btXWZ8yn9dgLOzb t2Lv4bGXlVYC74eX3J4alTOdy7xBtI3NZwvBkcVazmK2WGKj6Ci8MklYSFmMBjny4juC6dHq8Xr1 C1Iy6kTvXmQJrff0SfgGsSLatmcPl6b7ka1D7yVSoAUZ72yV3sWdRN6G+9tk0cvTIHV0UO/U/sOH D/PvwoPGKkEfEpmwj0idn7R4K1lb5yda3Ft5r0SZtFXaiS3cFYR60RoiRiIW6SvCvgLensHL5d0r Mf4q9dQJVaeVdUrPdD14iNNMOu2jZZQ+szlTm6N8+xOewMikzi9ll9IOesylk3ZhhZ5Yq1lCUVnx Ru32gLmt8yuBew5oORz5ZhexcWogfpsNuY3XkRIg/jCywxgPH1F4l+G/n3QKTzJMwpO+ABUJ4Dst x2oF5CIqryGqzcZzXnfukeef2WqI56gRkCWUB+uvoe77kdxITmy4XCkb1rH11vXO3zkUs9EaZDWe S32X5AwJT/RM9U3NGR9eYFxgneG5yrcgpyF8HbvGsMK60rnOcJ9xi/q74AfsPcN71g+doXMDbzRr iWR5LzMlZtXMzJtjrkYCNUtzoDaOpYaRzdHXbxeMmQZf1i9Jc1TyodP6JXD/9eN/FKmuzqO6uQzy u0H8QjJ5VC5vXCpkkNEwacE721a0LBs8/51H373urn3P3HDDM8/cdMMl9ewdKtOLnp+2O9P5QSaT eXXHfS/ShzP3fn8SPrX5381by2nlUyDwDHBnITu1uKTZXeUL5FVsE7vfhCAOaiYGhUlmhdoYfcMi em/hYyI0ju9ik0pwN4BvNJdAaEQg1CEQilnWcji6unAi8BOyKZrdWa50zUQvhcbhh2RKjnU/raJr iM4aS9KQ6ln/MWamalQHGLE6UEld4EBaT+rTiaTLYDD2AReWsTOtg96ZeO9nJcvk6wfeEHth+BvT +NiqQMtGjC1KX8/Sktml2oMej2GSva3zVKvLJYDvNLOqAop6lSgn0QBvEI3yu9GIA3eiIFDkbewl zcYsgQBiPlyMxWOQBiXvHub5YVJygne2mueH4HQIZ9mAv9DmdjPxQs3sdAHS33NMs7o9bFLUy+v4 s1vwaM4qViubBOBbTczi//Q2ziP8ffxt4mVa3wHKAMNLykHDS8bXTb+LGEfY6mwTHQtsMx0r3Ss9 t7kPuD8PfR4+GbIdtL7oYWFs4eaqUdXwaziNjSB+E0ozsBWKWlSTwfBGJOSNREKmSAjSwhSKSPao 2sae2D3GRbHBG9zDR0DEdDgps1kaA+9gtjmt05fYahInKu2n2Vx7quHcXcRWMZntZ/nYxt20Syd2 yJXTaS5esBB1VFWf6Kg/7nJzzCLrWq51SStYgHNAP1JP65fW1RX4EqkKYLxr+eVCWKzNoAT8k41n K1ig4PEHvt9+//U3P0T3eX74wzunL376lcemRnfsGFQ1o/2mQ5/PXvCLhzZ4jrz/zY7aZw88sX56 b1DK5M4vZD8oJU3rsoiz5gQ1TsXBCKGcVNM2XNCipMXutDmjFkuRLxqRo0URpcietNuCOVj+4hA9 bFLcmOJY5M1TJVygHS7hH+KurK7GInIC1HLiNfU1d6V6KF3KE4hF66bY/fYa+1q7XOO6zLUiLI33 X6XO9870L7df511r3+C9Lfyk3aLEJb4vbLXa7A7ZSPFeLDVP7NYwgJfgdisidtqn1WbzycH97AmS w+Zqheilgm7a3Y3T4oviLB7klBxvMjamhGxKUZJSUww9PvUiv5Pa3CPYRvu15LxD99N+WEjaNet5 aVXcRu/O4jB9QmCRy6xTabEEAY9AIwanCnzq6ASrQoSBW+mSOk+Fn8ssoTcZK86BYiHlso2vqTwn ybzU5NbYPQtW7XzsxrJLvW5rY9va+fM2elsT37xw7RsLZs+8eXPmq/de7qS3BO9f13zzDY96H2HX 3jjj5ltvje95fU7LzGkP9Yz+6s72zL++gIgNQQaoyn7INztNaX3dtba5tgdsz9h+Z1MulS61/1KW 3KBxYjNIRsVilYzEBmZ/Q5K9kiRLdsJsdtkovYSwFxOU8W2ahcgympA3LHIbm/2ioli03Fi5pUsS AuALE5sE4DuxQlnaaIVmN2p5yXJjU6KPcbMTSzFm1e4tJ0yFBSvh+pj4DoDjezkW2B5HG90oZvrb dLpeCMJTXLxUqV+oQg6qp6pOV7kq+SRXVq7rmZaxOjudTky32PWzY813V0LGvatZyyqlvB6Vkpyb W8UfUQdkoI3mtWnWSlvT2Eqblqq05UVQ9qjkDdJ1MDD60DJXmS/pklyUbem4lT38i9dea830odOe lPaeveTJzKNg6ns6FoDw+NqfUJ6CjJ2scw6iBTA+O58EGnFYoj5fxM0lp9Upy9GI3UGJMYj1QmgE AhBcxtd9ziV8/QMRdRwCZ3DGKHIL2esU+cjQdbkbcrd4nva8anvP9mHYZPYEHd1DkrmX0su6H3JM AneoHovP7fG84XB6HR6vw2kHi2ge3hHNsQ2KpsOp+Wi2Uy86ZfoOZx9INS3Ou+eapi5SV6mbVFkF kwQFkwQpCapBhs7qTBLcHHcfoH0QGXcPiKpfi2PP/8QsCFi5kFnOs0s91yjBI2Kg9a7KknqIhePr TD3TCrBIgFHBNeCbJdC2fsY24BVPwpeQIPOIz2uEJpCa9Cvf/Vfd3Lpj42Ubuz1zJ3u/48Uxt97V Tk3L7jj12w7apG64/dBjD7SMqfazvz+fWTE1c/oPr9/VcoxrbaOAOR9kXi7pTsdkpV7MSWPYWJJo uFtUg5Vlx5IYVvKiXrslSkmBiinQNTg1GlD5gh8QMi8A9ADOanCH3z2s/qYLk7DEDtVzTPZYkEOH GjXf0Jyh8SnuifEF0kzjTNN898z4MtPyyBrT2sh7pnf9LmOcc0ChzhOGSUkh8HhVQtww8huF8WQ8 wW+4eC/H2hn6GabvTOOIhNAzd/UZ+mw/zU32FDSqApGwUVRYIxjFyRe5lqhuLrZwMRellZq/OjAt sCiwKiAHoJQaJgX8/KWBNpa/O60raeDEE3zlEjJP19R0SVdSz1U2vkpx9uHSro4aYa1w1cxg5AuU G7INyCIutQJXfuo9LwkN0pndweIRCyYPmnQlG3RgTmvHNUdv/Uvm+MO3fbXj446KMXeOXvrEY9ev fFae4Jjfa1Svgd99NKMh8++3N5y4CZthN9BnXt7+ytmP65+ta3vkvp07MQHTIe/82FO3k8Wa45Cd yvjHTLIZsoxzYS9GZbPN3ihJjE/JGLFESyzkNDWa/0bGAPfTmFSNYhFdBeUxB4JIUPFo2ENLqkad OjFaPc21MW4Z8NW70iVkEMa/RFgwBiIZjMm+bnfFdGnPxsyJkX2d+6Sb/3mb/NOOjfdk3JkzbR/u oN/Q1x/iHosJoMAcUGAAPpxejOg02Goj4WhPLiOhh7FJPXu6E1GD0i3qtkfNNr7AQvk/BTEJIO3k 9iUnQwC64sQBcdMZxFqpG58C4K0AZMlXyvfZuJ7lE0/0CfL1ZclXt0IuMEUgj9InKsGVWYvkRdER YXzwjgDgHTkuLBMOiLrs+7n6i9ee1fJ4Q/5aTlz8hTznIz0/vi6WwbuokId6T4RNxDmooo+fFvlH +EekvrB93Usx98J25Y30BnmZaYl1qW25fWXgdrKBbpTXmlZbb7Wttd8ReMv1msedB05picRDvIjH S3jRI44V/5gWLYrbSDRIbOjGtp70fE+ijQfN1NzG5mhqutGpxaHxw8vgVJ3M2Ubv2lsabGyG6Yz7 LfmNvi5FPu7TfMy3ufc5k0b3yHANIasguCvrS/jg+KKV5RjONdDslpAldXX0vKvlnCZA4HzxCN+K 7m+RLmQdOn/xVV8cbP9mwcJ1d2ROv/9+5vRdV65dMHfNbbPnrO8/YvOE1dt33LzqaSlcdN/8bR98 um32vUXFh9Yf6CSUtm96mU6ce+st02asu/Vs56jNY55quvnZ7V22LKfJKKTiC7rV8KI1hiWgwIUF 4LRAMl8JxOIO4KTWjWM06BIodQnr0xV0Faet3aLcszHGITkcXjKWUqFG2lVYFZSvNBCqisD4oXR9 KUis/kSpmBhgnhOiyqXox7/hRCcM6gs6cX7t1LqLxdMlqPj/560/f9d/vApvOv8irbx/6FK/lrzc f1lytnSVf2FoTnJl6MboxtDt0Qf8z4QOhL7xfxE/Hfdc5H/Ev8Mv9S+aaWCFfN1NgpiCibgh3i06 xjGNL7IRPjz6zlhdJLfyTiB0s5JYIZFdP19WNxdzOd3KxbTrHC25NBdzbc5K3npd2+SCl8vdc2tn l9gl9fCfwEgWCuZA1qe8kEtblATCFju83GRO0S5/HXTQxTv8N0yfcOPYvrTvSwv3nqXG1zaduH7l 3x97/gP25pPLrm155oYbH6UT1JVXX7rqz4ttwckLqOnPn1L1gcxf4Vv6MrP7hYNS+YN7Dz20ESIX K+k+mD9rEcPEfbT9oEfAv200M0OVLFVRgwzPDfQawuKYi0dNWd/SEi4/YQ0IlAt28MCrJCHtgxNH qjt8+OzTcOYwRBkRpQ76q5E46Jy91OGENw2K4j9as8APghBRc0qr44TIZaRhkiLyErWXOsc019yg rpc2q79TXjO0qydVq0mpQwjPWHWutVn9p+2f9n86zLJNtssOCdvgiizDujAZjEYbYBNiVeBPgvdO cwrLPm60eXGLSRBqP2iQZpCqcdnmxbfMUUUxRQ2SoY0t1sw40fG1hj0ctp9awXBWzW2Lk1lGafxY hMR8KkubZSojRlazjrW1Gz+1SZtt1MavVafxiJGtMjYZmfEXzvf+JDxxS3Kw+uBfEDMWylFBBcHq qtCJ6uNwy+Ef90+loTut64lwU5RiUqEdr1MPHXIcOrRO0UuInJHNVkTQRbFN2Co7JZNxPwxf0vkD l0J1dCnXt/hfEh6upJSQPAkpVWgwSqzsD6z24+c6Hnz0ffr3+4flRcqU/T8NowcyQ9kUumXfNXfc zlezLVh5vwamXEKj8uwjMnAynPuhZHlYcnJydrLRfKvZMC+0XFlsbrTeotxiNRT6zVKwsHvUn2s2 e9zR7t2LikgkN4p5i8EBQUzBlMHG/acG2BVaGV/DDG7O8gYDn3mDiT8dIDBu8PIlxTCxIGWL8G/Y LLydjdOFj7eyhYpzo3Hhtonz+8ApF2ZZgLdFzU+wHs8B8Ntw8YbnAKpPD5jKPVX6BNVj5YcigItR MP/0PxA0t+aRIMyqYKZUlrgqIekprHrMPPfYlLkSF9h5DpakiVLdlE8lYXSUVnDeTQHewlLb32yc PWfNpsuaXt6Y+QW9aHW/S0YOu/mRzId04RWpIVP6T7xnY2aHsr9u36wrniorPNA0Z1dDb2m8yz97 1IhFRWe2GW39Fgwbfx22eyiZ3fmlsgLe0Fzyzp4ZbH4ugyDmyoIY31faNA7FSal9BqJcluU2kVtz N5MHlOekJ+37pFb76/aj5HjuP3NdDneuKzdX6m7o5uoeiceG2yd7L/NNzpmrLMi93n27+wHpfscD ke30Cbbd9UeHB/E2IdWrhmRw5ict3SqF8O/RrVJ1EiqHPVGbFI7KZjXlvISk4lgbQrFAKm6iJmgl hkmmnOgMzDZ0rnT9KK5xIefeEthGLjGZUEW5hxDK5lIaMMjJvHxMnDu/rFTG3gT0TgPzed3cwpZb X7ko8+rnJzJ/enAnHfLKR7R4wMGyV37xzF+nLvxi7eOfMdb7+zMv06vf/hx+22Nv9th292OZ7+96 KfP1hgNcrj0C2TMFFO3E3H2ulcRjdIhJp06XGnUSE7pspjHhJjELojJbOEWZ4WTQ1TQuICCSQrFc 9f9Mev8GDQrU/NBFetH/JL0sGXKtIktyvXsNuU7rK4WNiKBXEEMvG3KCoSAzWC3gA4tk8Pm9fo9f MoSlQIK6HciCpkiC+i2uBCJcsZnQHX+raT2n0AD2GKCwM9BnQaI062sqBFU+Qn98bspNdcsaR6+8 6/CazC5aedeTvWtG3XvV6B2Zt5T9vtxLr8wcOfR0JvPM9NIdfXvXfP3UF//uzs+WPQbJwONZreQe zWdQoiaT0UgkmbO5xRy1EhOsmnYcrHCXGydKl8QtcTuzhOyy+f88Z5xvf86utgGX6wQkmLOeu08F HZ06nj43aVk+xd6BC0ZlNj0m5599REqf/aN0q7J/R6b6+Yx9B+ciKEfyGozBTO7Q0mIMm7D91jUM DOGhODzqjIWs/4d+a1YhZwSxQ8hk/qv7Fo5yTv/63/n+Y1cvK2LquYy5sO/bpY/Pfs6aO8byfvff 0TEbvV4I3t8H3i+gHi0U9oZ9rKGQXmHyULeUn08S7gArIEADn/44n0Js5QWiDgkWh5nSVGFBPrbP MK7CBuGm4Sp+dvXlFA7W/kAITLH6hvn32dKmQlqYm4pbqEWogpac1IwsJsDEo9R6IUExHnQewvGc wyMNQsY1l5dI3AUAgh4qJ8ORUCQnIhlsKbXAl4qlTAUISisI2nMTxO/0JNDY64kbcZWnFCRoxArK 9rqQRc2JBMmXkIkIblA4NnSEA0jMKKd1OOX6FLh+Jj2wtdmTQXzw3UCvW4YAqXBJl7KFmzJHt/05 s7V1Nx374VZK707tTFy5d9GaV65J9FtH2V03nRzIqp+nHceWNu6jV/z5PdrYOqftl70WN40ad+uY 9VsPZX5oml5BXcDHQZDSalCRRN7aQxF6xvg2wO5+F4ntgN1l5XrZo5dedivSy2SBXuZG9TIYEiW0 X7U8rmxWdirAEtSUTdi/ayZyCfZWxmJj4yRR3HFUbiaS2G2wilUumF39vu1a/bifTl8GNeHMIHGx Njwmv1d3wYoHn1lLExSZ+rolS6s6sooCPHKgR06EZa6Dr3ClAGOs6PxSmo4xusgzmjqLzTEsY8sN 6+3rXQazoLRWKye0NhrSrHLUaTanLBZTyspdYrxnAuAdAsD5QgD6csVrNOGcsNbHPTSOLfKxngaP 7KEpMBFczvra/U0XN32UFaAj3Xu7RnJCrV+ir+Fcb8KKciKN7pP6rG+2bx8MRLgqUgN2GhfPGDG/ 2yt1L9/88mG6Lbj9hiGNN0n/OJvT9sb8T7hE4PpOd4xTIQs1G2WyFFWIKc7VOva05jQyoCSOZv8H beN0V4/PiXzDf4n8L+p1uaVPdsK35RX2Nib8nzvwivsQieNET1R2vMsHaeo8rQsZk8OO/RVwKNAM AITwndaNQzY3ny/FaZNw7JiZzFYHMZmZxWoQWMBeopj5n/YKFKiY4C+69rr0nWzUnNUph5tr3Ejn u4zV7e3q0aPtfCsjDQcm+C5NujYyY0ZBWQaRSyKXRa6I3AStXkty2mNCMILpuURx8FzX6i1C08Ni oSv9+MIPWoyrZyls0MUt7nKnyBSbRKgDy4oJ6wsfOH+mAPijLC+xyYizUdlkzU50CSxehPHojyXc +ZA+VQLhiymvroJc4oOBE4+PRvzpp0LC2irCnCYvC5vkFba1tt9iKm0jbCOcUpFcYC921EqXyyvs 1zrW2U1Wppgq7X0dY9hICU5A0yj7YIflPna/tMW4xbRdetpocDOnw9FLYV5FYSbY0r0UE0CTbbxz PNVgRphMZosVHOxw4LC4mTW4m9zMvZ9thwe2d4sSR9BDb81iM1vimm2VlVr3Y5AOasUd1gbjwwz3 Rdy5WKXYx5r8YlxpUJoUCAW2fbdrAHgjh+/211cFO8AU3L4AHDp3cbwe1gamgQvQrk8INgi3Otbd KIwOFOCi88bFr4it8wx21d6DAfeesC1GNttgeHSD4bGP2Dt/2OWwcIsj66x/d2+i0lGcEA77vRWV jtIKAe7pgdqsUz5dB+uELMEuWF0dlmvqD/StoAlX0oXDHK77EFl+eS9/DvzzVHkpM3lnplbZf+Yf d1089kHp7E/D5DfP9JGPneHMCLebEgOnmOmNu9yQJ+2axeMrNwVtfuEd+0pLcMgE8y5uNMHQMzGj JJnMMmNmo0mW4gYDGEiXnAD+gW0MsImic1Jb57+1ECc1pT5upXHrWGuDdbG1yapYTdBkQF7YFcDL /heZkFUNZCGD8cj/Eg0WjrAuQwSbI1g4IdSy2yN8cwQkC4Ma+8SV62SBId2LwyMhjr1oc5Wb4shA wXW9e3HVDzhoNWnDKmHQtu8dVmnSSnWwtNKYlyPiJvbmACzVQV6b1KMprMlKo8OL5OHXp/Z6AObq YC5AHwd/2OXTN1WEksl5R7AOUFhGIWqBu4del9j+189mgLDV8iogq+lME9e9Z0Bz+Vh5F5FxYfKG NjbkpF7V6w0HwmFZVmWvNWANy88E9jpec0iBQDDM4rmaa4xnTEAL1Sq15svUSa5pnimBacHJocvC twfuZ2pOVJLcUavZl+JxU3y94IIOgL7+ATgpVhAA3wiJAUD3cgH4CYQB2WEMNSEEy5niODQIDOmi IyfSZa/oBouu5UBmjNKtFm7/wV6B0eJRSaJU5uq1sFoqVLhoENzDYLSQGXQ97fsmHfZca2bvwSOZ /dt/S3P/9CENX/f1Xb/P/Im9QRfSh1/JPPnRp5lte35Lp/w68+/MEVpOw7up9ReZz3V7Re4AddtJ kLRoxbNcC7xspDrSe7l6uVe22uCPc5BAkKvdxOROmWDZgtZFpAhE6SlNaHCmUDxE8S8UtP+v69d/ qLH/rYXnXLiMpXWreYmYHD4xXbYyV2O5OiaMjyhMN5ZIuGCI8K1SYXewortHXXV33XeZ32XW0+sP PFJ/ae9bM7cp+x3uWXsXvpTp6HheohtXTb3FZ+eU8yh4HKYx5iCPntUSbquDuvtGpsRmmxbGYHLy 9cIkcqPI80H3AvEiJIKvdtxpIGogIHTA3db52W53qBzlyd15heXw0322O7ewHDspooTXW5S4/+fd uSn9PtqL+yj5fW0EgALHJZFL4hOsUyMLI0vN1zquc66xrHfea3/G2eb8yvGlU8VqF3c5vS6X0+W0 md04dRXyWwzw4dltStBs9gdCOVEER7TrQT+BAEnkCXwGg06nwxRNOR6Cq0QPNwJwWizQAI5peXxk BoNwktTH8xfnN+VL+XnB/yuOdWr/n+RRcsD2/zJVsmp+zvEg0CwWjSyu0xBWcIxgQaWw5HmwA9/z 4+jXF9ZszoWE2KW1mDRnpVPt73L3R1UdXSJWDAdiuUI5lS7IJzeSQ4tUqnlepBjSOYHD14kudwts Wk9S6slATklBWmIbPvEo23DorZVvvDOq26RLO0+9Munqy3okRv6FPrpmy+h7H8/0UvaP+e11D72X W5A/enlmCe1968Z+VmPHcqms4rrhc0X00FTs4PwN9lUv5tMKZ0gz5EZpmSwXFPaRKiNDpBHGS3Nr YkPzhxVOkOqMU3Mv63abx5HkzksuekB4OlDQBaS6gMIuAI2BQ72xDqCxDqCxDqDxaW0Yb9TNnspn +VJhQV8nThcX1JRMiU9OTiq4yjrfvsAx2zsreJ11pX2l80Z1eX5jwVppg/U2+wbnHeqa/FsK7rZv cW7xRbNhQj0SKXc4FTKniqBak6KQWy7tncIxTUbsPa4L3xZm4QK/vUe0sIAWKH4shKc03esa7WGO Rv2S8NSkYcfV6yYdL+phqgUQHaF/sB1akO+wW5UE/ClhHD3CySMDLcjPQx2M63CPEJ7IJm2CHDqB M5/CQBWrrErjdCxtoIvpZmqAEdGseXrwVyp4NXp8iTlFimgRF+EOB5sE4JRm508qCpViTDQFDv1W 3AKA6YMABJB17mJTFnI9p3fWYK0fdRw0B4+r8PSdd0EhviN9nGen+IhAxhid8PJhQYUnPkvCKCDz PRVRBitSl2T5hWKDh++A8hha7qfyeQN+bLjy2A/46PNTU1+0T/vtjYuenTB26oDMVePmzbnpH798 /Me1yn7njmeaH63sR9+vbVq59szDr2f+eT/9k3r1HZcNbhxaMycZmJ6ueHzWopdnzntrteP2O1df PqasbEG3AXtWLD/SuOxrgmH1grWyH1LRiFNidoVFMeFwWuDIF7a5GncLs4XSFw1xykr41hale6gw XyBNNCsnV2LKekv/IWQj9JnPugzHs6gR7pcMajiAJ5r23n9eTYGvAiql2nG8/guuQeqiv3cvHmjB PS/Mk8mVN2TCin3Hjp/+yXv7KFb/PPTWS97XLClnrVxr+p1J9nPB54cOVS4PMA2TLzGtcD6lfOU0 2ghzYXO31WD2pqB06PoZgKx+xoRZi+tjWoQv2qw+7qdx/1g/a/Av9jfhR4DswmHBn87VQYsw2WAw 6A5iAXBKAfCTvuRZhHqGa109A5C13Cz1Pq6enffcYM8cTo+s0alrA2K1S8P7AFNT1wKE1Sm2xF1y wyszM2fe/X3mp8WvDN9x43t7lf1nd32cOfv4ndT+tTTmbMvBPVe+IuJW4YkiyjDMkYUOzEYvuBUK lwJf3S1EMZsUypSSj7GLdthVVoY5rwah8n3U/BKFdifdpAJLia2XrcF2m+k282Zbu+2kzRq3jbUh tMVqYtmtPzO1wZDCI6urxa4Cvm0xm+MmxWsyKXAHxJniZUwx41Vfxy2wTGaZ6CwGdQIhPt0qx5po k2kzftGD72zYmdatchqjm3CalcEqoZorroxVWC9YI5uVduWkosAiWb/b2oAFhVskS46Dm3gK8rgx LCShnBPY9+B2R3azg+916FaHF5ZFC3ECE39vMbshL/7eAsMMyh2sD/zVoVk3GCB9hQGCsC7ElAql jAcrJLDdIeyJMsoGdfz2bXpjz1heD7rxtQ64NM78qWnxtdfKRXBtcOGA3+VawXUL+qGWKiIpV5E7 FawkfV2V7r7BEWS4a4R7eLCWXOaqdV8WVO8z3efMTqRWptJQTtpXrpTbhipDbSN9E5WJtst9M5WZ tgW+Zcoy2/U+p+LjlqsbZ6OdOM0jJl1gLSCkZ2VlWItKMuxDgxGTb4EP0Wx3OJ02nOJ0+/yBYBBb 0VW7cdw9zkub28VLbYoP5gd+6YjF8WMqFKE8iskU9QW9Pl/QbTOboz43QLcL8chx1eVVVZfbbDMF fYoTe7mEoUuKFESoi9lsMiGImwXdbhc2ZkKBQEgdZKbjSJzYkPuQNKLQcXvj3J2fk9NGb9+lKwb1 oZxRHTAnO0I5HcHRNbOGfnFOJ+gyJ7k+ACHKBalIMF1GXWhc8o2t86YmRCs/ynAIWRXPBHRhBmQ7 gWwXpwm3hW9b6xRQgMru5ykga7A6ULPbpikaGnGiWFoPgvDoBOFxw870YDcMzlCDkdJHMte//ml+ qB9OUH/z9phkpMcXr2aufinzZqEx4M38Drxafe89f8uXPukIZb795+2t0gswaOo3xmcNP/M4qIdz 7AhQj4ft0YqwGuVQv5UVuYs8/WiF1M/Uz9zP3t/Rx13hsbg9cXei3M0zHB04thsl1FNRIvxDlOCx Y9pVuCHzVhLPrqHXWFlKLjJ2s3Z3pNx95f6m/lb+xItNE+V601TrFMdE9xw6S55vWmCd55jlXi6v NHGd4Br3NZ618gbjBss9cpvpRfdr8u9Mf5L/bHrf8Z77S/kr01eOL9zFUCMR5WyD60j189xq4jlY 7YfdHMiqDlYbIrPUoAXb/PjCV5qDQ6oBx/EhlRjkCMxTjmMsj7wIa/WgZrOZ8sPHEhYaD44j26mq 2l0IYrNizpjdKtk8Fis1qMxjtng8cWJG1L1ZQtRT3CZ5bTYJEgnxPMxjx1JPTCUIbwN1xm0IVsaW 6rQX45bNlnaLhEjEtj3TssKnTbMYWjV1rHpElXBwZJpmiZMcr++VBBc+6dGnOM3WBz/POVF/oh6A IFvugeMUq+frlJ+RKI9bw5/TyamyyiSIs6vQifRQnbB+dVvnnCtJKLRWKLTWnErKldlguBIqySct 4UqPXsiYxr3hSlNeuBK4b2+JcOdIuxaLVHqg+EpIdoc/UOVx+wMXmWAhVEkyINgun2g94U7Pc1da bbmJiyjJTVRZLRxiHLJ5AqjzBFDHIQbovOrCoXNdBAzNG9oMzj2ck5RdLGFmFRnbl9QyIdl7CC18 p6ODpU9mNsUSvX2Zzews+3Vm/fLqsZfRNR2jzv7IrD36jI1mKLfSLun8So7IA3FmrYL10IrNdnP3 HHuoe5G9e3c4ynwV4f7dR3Svt9d3n2+f172h1wb72qIH/A+GnrH7unEDh6/jUHxxnoJDT+U8221v zkvdDuUc6fa27+NupqF+ilD2UyBXKCZuaI5dIQF9ONdM4texQCyYLu5eXilXFo+QLy6ebKpLzzbN S6+wrUNw7I/2H9OuinIHldWS/PJAacIbnFa0qIgVRUoc1Y5Njq2OToey1bHT8T3iW8RZDvCp7sEG gD1nHlHvEDExDgMPgkJIiIRoumf3Bu9BbLkR6tMpLSTUpppCS2lEshZNV6cT2GfQtAoSsA2+7TIS vtW9TPky12Nx4zgGL4BTYhZQ8xHX0AyT8sWLcK3rY/lt7HLNUajxCOd4qldqZ0qpBOEI7RfGw3t7 uYac6s3rNHsUIU6V7ZVsWyWthH15ShvEnxgoCOaV5B80HDGwmKHawAxYbmBFYljIg8KihAeV13As GMC5yMW+j6F3v/M+qiXYvU3DSZWG6x0H1brIrKoj/fnn3FY4jkh+PXha3KpfcmIJuIkzlDAauFrN b4h4ULJEnE3jh9KwNck/CHfhqrSxcCBUbWjWfh8/lJZMIRDPAWcC3wZGI6lq5r75Ow8Mb7y4z4IP 5tCymvWrrsttDl599Lb1z45VzYG8A5HAlYcWTS1dOG/uY6ncWyYNe27N6NWjvQ57KL/AcnWPi+qW BJfcPlKbfknPa0+eWXNRP/pxt4jabVTJxQ2Xj7noGlD0WlA09y3yU0BN2oNUsTnzlT5KjaJUx5pj LBZD3ERkcGRxbHPM0N9T5a9CsNGloXpTvb3WWe+/IjTfdJV9rvNq/9Wh9tj7tg8CH+R85vk28G3O X3OPxTpjOXGlxFni7aVUOzXlUudYZbbyQe6/5J9Um+pzyAZGwhEsUBZfxGEN5h+1UtWqwf/YZJX1 /WmroFGr2JmGaOA7DsK/f1LQkHB0cCoFcEwo87xGK+H4tC6Dp44I4iOyUO/LpALG2ikssG20mZ6k coxW41dxcOwNOzbcVABwVsvl5EUFqVChgFM3JxXokyAVvmqgqQDOan7+agp6Qu7lr6A50eEVP1Oj QTjYd8KuIagHxlcXCYFUOAHhn4i14JQCObWULMHhmDIXLC24k1QE1BdKMLRACHoQHe3xdOvSXVfu XKJl/vGrAwtY+aS7Vjz/5PIVzyv7O/61acymNxoz32fee5huOTjp9sNvHn3tMNbusZ1fSScgr0J0 SlbbLnesclKnlfLNtsXY0ZPdEasxGJHxyzo+o4mP3ihGb4RtDBh+NuR8ayF9+N3XhImMyGCcgKgX JyCGm200FhniGRKY4JkQaPA0BB5kD0oP2J9QnwjZTPYcy3w2T5qvLLcttjfZn7LtMe+17LHZ/Nh2 +CuTHHnTnIucq5ySEwcintWu6yV2ABvQrc3YEjyGnUAzcTqtMAG7+hhB1/MdJj7ZjrwwxpdvTceg HUJ30wSCNIGdiwVOQgInIyK+/CNGGjNWIzTJwRsZLbyRUYhXY+9w+aGsxQes6MxfvzR7bFwExfer O7H0VPrEUjF27P0i9FutP45/wm4G3uoQzAEzGP5QcdrrnI3MMSdV7cr9/oUPMv9e+vVtOz6K7cxZ NWX9s0/cOv9Ouibw4hGaSy3PU7Z656PhBVe9+s57r9zM15hhwNmn4EhEJNFJ2hMWJtsL7OX2oXal j7dP5DI20TLeOyEyh81UZplneBsi7bF3lT96Ps753PO59/vA33I+F5znj8XSIc6uI0Ocd7FDnG/v 6e/P+thHshr7MO+IyGWWyfY59s8NX/p/oqccKvVJDisCXcKgBxcBS0rWYBkPoHQWqOpRF1UR3Nfg anKBNTlN6AzqcnPOgWMRixYXsi4DpyCXYFjUwpTlM+5y8BnH9XeCSwH8oA3m2HEtc+cfROTYp8ZO o8xRNMYoGaOC5IScNuIkIidIgTaxLBnF6mPMiZaPvYDT6peMOnGOuzjTYUcIW/UIOzgBzQ3pPJ/x /ZhEH+CLezV0hIHnENt9js+kfrMOrfrj8vnv3tKwpWR3R/z55Sue3H79tY+ufWTjmce3UmnDuEHM 8dMw5n7rjZdf++CtQxxnIyFFo+AzH3A2QQvESMSHrZl6pd48yTpLWqAsMs+ymmDo8FO0YiaOa+M5 lBvheaH7feUn7+mQ3NvdP6d3ZJB7VGhQZJwbZxcj090LQ9Mj1xqu9Z1mp4MqfvzMaQ8Exvq5D0Dy R5yb1W0IjVflcMRixC8XPMuPcXRJs3ZwA+YdB4TpPR5weECDCvaRcH8A0A+6ANB3noV2Zi7sXt6M AwShGJbX3QWpcl5qg/gyG6Mxf5mab9Tyu5d3YQoboMCOjikMBLDOYDhOCAbz86FxTF0oE+vTozqO j1bhb0JAOv6Ec4FvzGcPVlR1LKkSKrY4T8HDz/gKyuOlBIvpGw9eY0L4HWhCxOsbpCv2F3+37+vM 99T70R/x+2Bnv7K0rJmxseMDNs7Wb/JtNzxDJwceb8UZCQk/xtUt80nmRzW+c/9ces/aIXOfghTx AIVN8IcGqF2Les3UmVOS0ysHx4BzHrQ9ZH/GbgrZu9mbc9pz5Bw+H91CsfJck12yOSMW6mNpr0fG Ly5btnqpt9OjyYECGb86dTfEEp/E3v3KeamlI7HyzYTmaJxNcjQ72IR4hYeqm/BQ5XHGIcVCkxKM w8Uv8XLKx/e5jiaAL0QoM2p+EmchyOPBnAN0P0mQ0/jtJdgAepgAn1mwAT96dAqqP/wQJ2AGYDeU B16dQPS/CFTxIqrZbDSYoCGpcNoTl8EZxu9npbuvxkFt8MlSbHX1KeuDs+ZYkiDWuOfPx88XtWzd 6gndsuLSqeF+peOHHjkiPbBxyYLyYZe5H7YMa7hy49nZ4IjBmXHSN+AIHpG9SGuwWhVvsbXAe6m1 xmsw5+bkFltT3uJkpbWv9xLrMO9kY611rvUny798jp7J4sKByYGFlxZuLt5WbOyb6FtUXTzMOixR UzQxMbFonnFGYkZRQ3FT8QeFXyW+S35f6Ar4Db42tqu1W8RjFCuJGofjkK8jTaSdHIXzsI3dqJUq kYjTUpMXsVn8vrKCMktBMHg0QNWAFmgINAXkYjjJ2KRiERcXEGJNaJRCrAWEWOOHS8Qhz290scZb 8cMmWbEG4Kx2CSf6wDInLSB5sfyDziPOT52dTjnmrHaOwUInOMYJGYbDDzhbgFz49vSDUrzeMMmZ ky5eluDiDQZdFpEQbziJ9B8SruP4aX4mCYwjQquP678OgA27JQEeDCcUyEJwDQ8y5Ajs0xUkcmFk /uyd1tIhy25cH3TQFc0fnrz6D3ccWPnUrA+3/fqb+5+68YbtO1Zeu702NK6gdOaUiubbadXH91G6 8b6ms/N/OHLtc1L3P7QffOvV117lPqZ1CKbl0XJeOn0fjme37/YFyrE5e4yfhzVMKpD74Bfk9ttl UdU/kFMeMMEo90rw/TkjitGLkL8Cs1bWt7zTTNvN1I8ZZpP8EGAISewmci9nEJiS32ouPnEIfsYk mrF1LWoRN8JZxQyWQs4XGGxyA0Joo7g+jYgQAKOFMzZQ3re82X/Szxb7t/mb/Z1+2c+8Bfpmt4o+ nMR44CE6Ch1E5qwmBCoHtIDgUl2tRBgvOLRry/snXR/E0UO8B34DvJyM9g0HGs9ZFPwMkr7vnT5n TQg+FUfI+TqFZYq7lAR3OgwOY4HDYAtTuwl8iUOu6fRqAqamiMgVWiIc8AglEAHyBp9rXetN7Ste GNm6fMHYO6qgEv7j7vonHuqYxh5dd/2EO2/seAk8uR6Iwi1ofUZyWLvC3JePYIx5s3mbudncbv7U fNJsJOaYebG5ybw1W3XM3Gm2xHAaHr/ChzPlBukmbCIriI83GAsUIm+Vt8nNcrt8TDa0yydlRuS4 fBRXsqzrymwSgOy8IdocKJMREIJcSDbc0yUbAN0LD+AsIkIwh/Jo03/OHkK4hBe+Wg/A56YW90ss XZIWYfiYlfWtra3y344cOeOTU2c+4HSJMUs/YMxWNl0LcxsQa5JhsmGKWXLa/6mcNiD4hZMXvD76 pil8sToAItIBkOxXmth0nSRdY2FuQ9yTKIcf6+Rud2E5Wp1sRenGfhIqEqJCuxU1BllWZEOFebis FBh6WGot10jLLR9IfzUYnzLQpCFlLDBVGvqZq+1j7HVynaHWWGe+Ub5Oud/8muFt+T3DccPXxn8b fjT53BYLAuVkhvA+eDNxAZdmgdGAMA+DhE07xYKAG4sFiJG5w1tWuJvVaiU46UqdOFSHOYcXIQ++ bKeWiAstWJi6xtBmLPTWAsIKYBMRWo1f7WOg8YzWW9A4BgzqFiYQERgjMIRA00Jtxq/PcfrOsdn/ khg++wJJxVWvUdzvjSUeZ+54nPn5vVSoYdg9hR+cn3tFGdR/4kU1VZmqJJFnvXH2kQhQNt8qMcQk 86AP6NjAM3xOmsVcnFtpNuFULBD2SUtuJYp3W+Ki2JXQgzZwVhYRN0uwGyu8VAY4nxIiOKTFz4tP WlTenBfiyiaKXdZsxEcddyDxV7k/lqnJ68fbvN4qkeFbp1uC/Mvf7grrzRHYo1v5fNtM8CV8TXAy GUGJ9NmvM/PpwU8yj66Ci/UAbc6s6JjJYiszl3O6vAVZheDFv+5VBCOCgtp3V/TTgyXL++hlr956 macHU2oFEKtOBANtVT5V5DHITipSTFmMwKhOBb/Czn8dRRdk/ElAZ7vmwwq+ldB2mFPsQqnGLVlg mHOnMHqzxrKOa13vwK/TAMtdrAmgU+jvALI8SkbLP+dRoGoptA7Bppw1+RX/4xLrllYRaomxY60w pKAbJOnrPK5Kj1cBR+kAWOrP2iirvbxAPi4fN/8l8Hlc+aNyOs4CpnjSHAzH4TZNRiMGH186jdSQ ROyX5WgB3VywrYAVwIfqKNiMnzyQ+fBcCDAQ9gncUZysXV4ugmCA4PciuBhyMU7ULogA5MIRhXt6 RAi3UrLaOq3XbMGCzWEaFo8L80VIPC4sHofr7zQXf1xYrAZhYWCiNqMvQmF4MQyTcK17uMJteB7+ 946yZAE9SsB72wiL4ajRGMhl/h0dGxfyn/BWEb/gP/6ULFpOaV7+YCLEJRHrLMnJL2ij1+5OcLSc 0x+AAOGH6Dh+LjYbNeddWrjoEL5i+CC4kghNUTAx2JXr4l0LErZsUl6bK0zddl/XgsQjYHT8+riW iP0HZPqyJPTFCxeoR0ufmr/i3thNbzzy7O7k1IGLf9laO/PS1f3l1D2jp11Zu3/n3o5C9vBV0/rf 80THvazl2mvHPnBXx/ucV7hu8QXoxU9v1DyKZPCw7Wqb+lfpS89J6bTHgDXjpFYFgrlOpfepR4PH gp1BOW7yOrx+N3QLavDbLXaHzZEfFPpEUOgWVqFVWIVWAbdRVquwiiXKmseRKZxJQquwCq0C1z/q CLUKrQLXp3E+CuLVKhQXK+1ECONobNy0ayGuYQRPBtni4LZgc7A9KAdxHsnnF7x5Gj9honPeeRa8 ULHQWfC8YgEVFFjWFQvdl8Vf4f5PRWV0QPwaDWc38QcuhPLP/ZdIF/7xH0biOxo4l3JO2/AbXGaL yWLEqQs1BSs+TJ0WdxbJPOwc4hSedPy6AMcv91YKxOooXvfY8o8bHh2rWlq7L7i48Wk5de/OmsWj Sm/saGRrr1446O63OsS5lKGwkQuBRTvJoQv2+sRvWmCz4CvBZIg1+kpr5KtKjrjhNlpybMMNF5sm G+pMcwzzTKZytb+7v79PsEYd6R7prwlOVaaax6v17nr/+OBCZaF5prrQvdA/M3gN9ZkNiv1yCVuV lsttV0mzlFmWq2yWQEQ2uiAyvPlhoeOHBRkYoYHorgujcFpkHV58VefshtsnRf8EwPEgAI50AO2a J7+gvBfO2hlVYxyui96fQkbw+hHcZAbsyCc2ByQQEee/8BMUkD4EnUAuTOUs1wr5w39WCXjW8Egu DhjpHeKmM5B6DnknYDjX48ejzlWc/+0h7tfgy5Z5gjLBfKVypVnmaxNv6BHH17G/JUzoC5X/oU/c 9psPqf/6v93+aebEvpZ1a1t2r1nXgh8/LrxzReYvHYf/djONUvtbb771h9+8+QY6tC4zT04Ag26c vb9Su9Om/n+NXQt0lOWZ/r9/Zv7bXP7LTOaay2SSyQyZSGguYAKaX0QDpBLuJRAsLoqbgCIQESRF OIv1RlHxbIHT7pEKK3LqLrdAuJSVtZWKbiq7gla6VPYIFmndZXtStpZmss/7zSSCdc/Zgfnn+/+5 ZOa7vN/3Pu/zPt8txm1Gi+Fsiu+NiyXxEZ6yopqCmqLxRY/EX4grjaHG2OTQ5FibMs/THmqPdSqL PR3GQ6HFsRPx9wPnw+ej7xdfDFwsvhAfjAfLnBkjU1DvbDTAkDDmGpfcvy3KGm7TB5CDIGIpCIhY 8EXKT2vM0GxtgbZOc8Z5E8Z5c2Ld9inUKlDXGm9InJMdz2t6UFvylR01IQqX7TKqbK2L+WvFWisp CF+PDA8Bwtwa5wFhDokOA8LXuDXm2HEOEOacIphIdGUWKQEgzG4kVuQMMQDhr8LBWP3TeCRbO4QG +2m48fEGciEcuYqUiUTqYZzqqZ2Nm//66dOdj368Zu7zI81XV6768a6uFfuyHa7jz06btnFw647s 9ee+2Thw3bGz72fvnn33nQ8JqZqY7XBcQBsaQiEbbW9yixmxMjxWbBFXe6SmgqZIS+SF4u3Frjp/ XaypeIJ/QgzAbmyhf2FsQfG64jPSWetT6TPPlbAxQkx4MmDL1nsmiXd75ood4keeX4U/CX4W+TT2 Z1GHgkEgCiTRJwWAPAm+kK8WQhTGaZ0Zuq0v0NfpzmLucEMKgtxg7nDDCORxRJ073Dp3uHEVEyk1 pR6kmY9MBV+H8Jc3UUXrXeZf4ojlNMwIL8SR+9oyH2Ayx4XlSFHxzV7212CIA/3kbnylYaD6BgUr jvdyXARu9U3oYVXlllnHs/+19P21by17ZaD09VUrXt2z8tEd2Q5RGTuFjWTy9uzfvLrpT3c6/qGv 76c/P/PBz2mGexJNcxKtYgqn7LHVfmY4WZmzznknRPIXObuckmoqqqJ6/abqFRwKc/MhIWhq+gVk HybifuYXE+b/7cEOr/X+aJs3eLCgR/J56IYVBe/DQo4fnFvkT7GahxBybnYwmYzDQmJ+/3LK6qI+ C6eVrxMaBOPUUz5Oqp+/nLLyct03hxwhN8l88pXbO5rm3Xv7+PFj7w0UOyt+tGxi465Uc9OC5QNn qBaagHzvQy2McoTsNc5EINGoTlYnlM9OPJDoVjepG8pf9f+46k2HVw1Fw6FRLVUfhFwxZImIRg3T wu1Ku9qutbvbPe3eTqVT7dQ63Z2eTm9PRU9KT1WUp8pHjC6fq7W576+4P91V1gUq6UvaDz2b01uq /nbUTm23Z0dqJ3ame6siiFBtbiWaGCqUDRXKhwr8NWRC+GuowF9DBf4aKhRRMNsqbpirpJIezRmN VxQ43SOLohTsSESqqPJLIk2R1si3I3si70UkPVISWRr5OOIsiTwfESPH0TYF6Bcc07WxIgeFgSGp wsA+B6LADGgAYqo5EAjW0aNt+Mw6xka2Fy0pEosKC2SsiijUyh1wSoKBR00m0k8W0Fk40l0ClmJ5 xPaH62ro7dUcl+TrW5qBgVFitOAYp3dG4vSuCHccIxzXjSBMu18ur8RbDxY2nK5kKH3K7S0KOSYv L1A9oHDlEA3Tyij/U6VAmRfUnKgRm2rW1Yg1hE+XC/xv5sUA47laFmfxAn0BKuRU6eLlOjfAOv96 epxbD3Ji8BVhIXjeTR5OS3w85NZGvpEHoTHI89ALSb4ZIEoun5IP8WYyy27Ii6ZnAK7hRU2fL0PU h6+gOYESLg0pZuF/PsyLlD87dUtxGQDOCtOwDL/hkBLeeExQ03KMuW7BoTiA01JfWUxIQP5LGaHF WDqlalLGGRNKjCJaZ+Uy/YiokaMwVGbWrwfcM3QjrQTkkgyrcaUqUtghAkKnuQliOOhEyF+I2Ohk oiqa9uvPrOleVZ986eS21jturXxxxneOzzX3elZ0dHcGg9WxDW9smd1x8jvvfcRuK1y8/IEJt5WF kzWT1k9pXp0uyUxc82B4evv0MWWFRX6tvPaO7va5L3/rdRqn5YO/Fytd26AA88sjgoY+WFZBuAci BSisg6gaAqgacwhBAxorGqZuh1s3EiC2e62khw3Kyl3qXQvkR6AW8ILsFLBy2i7vlU/Ip6FnSmAq OW4okGgkL/yeB/9xhfwxfuWPvKfhCkFzuTUZzf0occuFJ3KrSvmo2AnW2+h9wCi+hOEwB3ORULC6 L5KFR3wIaZyYekE4NE6R25rJJENUfxX1hICbY7iqFtcwEY3oN8f91ZKqDRsOHDzoz6SLf/SycfsD r4gLNzJ5SfZ7GwdeuqcK4mXw72HLLtAOOaz1iBBF3ajw3MW4P0i0+qt2rRWoy/hZueIPepg/6Eb8 wEQ1CbXBZDhE7kSU+yoh7qWELDLawJfhdlINhLiXwuFp7p+EAlQLOM+jniHucOL8GtGIpVmDIXYi xEJTICYDPIBck+jVqPhIdHt0b3Qw6owCeqVnOPRJupdx9bR6QQXHloe7Ob6anzjyqCs8lByqmgM9 Ve6bgPOEMa5OidwECWC6oPTFrzghmEGo3pvG5WYODnhGnYbPq3uJJ0jp4HBEnJ6Y4FXMGLJhEZWo XI+FEcZDPnoHnV+ACgiQ04qIp0A6mrrP3ruj1XD3uM2Hp03bNLbnhz0TH2qtXyFuHjjwvW80T5vx /NNiA2BBJqCJHJfROhq7ko+Lh1yKoCkSk4ZJqOXU/VzVmRu5qLQ8i/XWu5iQMBs0su9es0GFm1mn 0AHUzSsH8AiDzB/xil/aanFpnZDGAWeXbRVIjhDEAWfn7LXpkXVCHAfdM0JII6m0QajXJgrN2mxo fbQpc9RFbJHYoXSoqwTQ5MTVyir1Me0p9pT4Xccz8tPKs+rfCVvVF7XXhVe040KvvE87JbylnRPO ar8TPtGuC/1aFX6OFhaCWlqo0MZorQIgNJdtBetc6Ep1ebwNSqEC/XQB36nf1qkZNZJ3hTcCtJGu 8eUsUXP5VdHl8rhhAKvPZ8DTxb0v05cRqoepumM0YJBJVQuoqoZQGBBGzuEETIklCydkSrKmgjTq qoZ+SEKxbRuIswgh4thBG1AW8otZzFbjos0S7iv/RmMXCX4DoLRFw59fJF4+BmvDMK/N5KDil0xL gIUwnJx3M2Q+wWHjjFlOkAQzkv1jdsk/XUyCS/W7I9mHnRUDGx5cOnOl+HQOM5bAeOxF77CcRUOZ qRatTLn1yZGd+BHVdYZLRmJmBd+cxCPNOB3xBBhLMGN4AlMrlUybn2umg0G2UEZt66gNrwcGC7k7 EOzDjj0mkByOTuUMnYlZp6/P+KDPOMOTVPOsWv7r6IfRYIhhBAZYpXOEJk4255mboP2HKZH7OCRP yCf9XAF41lVbLSmtMwqRA4SxfdXuLSmvc0oe1S/F1IjlwtZqkhsZtYplCH5HQC5UYu4ieLBJuVLJ +CC+LjcqY30THM2SLd+jtLjv1JvNydY8fbq1GJpwD1qrpcflLuWIdFQ/ZP1Buq6m3WZaSHtTvrSe sqoDtwpjrMeU7ypbHVs8u9hr4mtuEEKEQ9JR39vAuz9SLzsv67+x+qU/qYVunvHj4UeDH338qPOj le+2Mc2nOy3BVGQA4nrSR26cT3Z4mSeJaPYH9hiyUl70vkoqYA+rgF/S3GaFljFnOqdr7eYSs9t8 1tRMzYm+SM2Raxha1lJfHiIwVyOtNpc2YVykf7nZH8eYjQAWEZtll4p0cPgomoEcqMODLeAzW1iz TLIXabov/lNTVuKyaVkZRLpcLtmHdk56fQHkxSoAdzKaAkl1hdjO+ZEC0UrZciq66fF5+dezYMdJ fwJcZslCzpRP0ALXDC9b4CVijcN7mO0CF7RVY0u1JzSkD4uzbBW6r0vNJyDIRGduw8UWcJwYCbRs 10F2zX8NkyIo/5F7ILweHpi/DP9pkM0Pfz3TOT/qsNbH2Pt/EJ1lMErpTlRnurfsLZkxpwfk17j4 E4hPMdx9g6d7hFF6HMzRC1yJj5PeW/bWzUC+rTJ4ep9MAn3YrbEUFOhaToFWBi/sk+O5qxaukijQ EfqgQ1gK4rNhrU7vl0fRJ+4XbhVJ5gp/afjD+afR+0L8fSZIyVrcGSfFWs6i5hED3+CZQ1aDUIU7 Bvg+P0H9bTTgyHnHkVZlPKe3FIxrzrT2hzjd2pFysJbssaO7m5y1u4+8XH/boT3ZnmO7R3wIA/OD i+Y74sMDW9/tExddPyd2H/zze5iHdMxD/w1LY7B/z89DBTpzS05RRVDeix6p8xW5Xo2kbuqTpCMT 69UtpoN0S1EMe2qkYa7+fef3FQjZ6CdcJ6QT8ru6qtvBhqjDrxZ4o0Y9a3SvZ5vcSrX1LWeb3Oae 49vCtmpb3b3iYc/b7nd8/2Kcc5xV/9X7K+OSZg0NLjCiLVMPe7GwwN8BI5pKOmdEQ/5dIvzwZkb0 IglirJwTLSHqBFa0jrxAkKJ13WsMM6INTYIanWacFE6qopEc5kSfRCwqeSMtWgLiAlq01moxa5J3 rSeh6fdJ6lobdOhYry1NldZxyao7bV/csVZMtKIuJ5nd3FGd35+bLDBXGJegV8w1CG5kQEMWPT9Z kDw6p0CDAM3Jzz/LHfFAXRdxKcwlFHjq8YWLGgD4gvBcBN3VENRZQ/wcoSWkSyIDpwCc5dIGFbxm 6ih0a+OgKcz0/DaiIGNdPnrMGIoOOVJMZxuy2/5jx8jCquSBD7MvsufOn2vMfiamWfaL5lHja69n PQO/YJPbsvPxu0rBpPhP9JEo+598HynSAjo2gSuM6Jbklvy2BV6B7Ynn+0qkOhM9Hw33ISxCD9xJ hy1DxzmgY/df+hEPFTakA7P1PRqkw200SDw9qs6gA+TDrKA3bKXcKU/KO9oz2lvv22a601baPzHY ZrX52wo6rA5/R8FqaaV3tfl44PGCJ73Pmhutjf5nAlu119w/MY6ZRwNXtN8E/uAdML4IDBYWD/Wo oN9dGHPqE/QNIEJEhr9+DkTIpdoRs34MckOQzmFh5RAJ+P1JSwvgBPLNpifp1uAGa0gc8XjcEv1+ odAoFKsL3ygUsYNw00EddWEHDoszbXeTZVvit603oDdwmI0/pLOEcFcMhnFmrrYgHDPK0+pxTPUM cr79+APV4BbiM3pi8W4YRlTeAGmXoRORtEDY6L8YgfT/ss+jSOvhJcgLwHGgfkUhTeXGkCZ1KZg8 ItS37PXB2oRhbY5BXeCy4B68TMYr362OCIHBX0M7QEtAPwCj7GAB0kNzqaDoPbA00DZD9/GnaI3L ecP5HA8sYbCGgIvyRGBs1biJIbPC5c4+9Ob5TKIk80lPdskd5aO6Z9dlH9xtpMtji/UiZ3pg26Pr u1eKi6+/vWd82wzyUNKwPWfQr3xsj+2F2O8pRbRYjRWi2PYvbBUFdjtWrTh7056MwggxrVYbYFpr k9jd4t3KJLXVaGczxZnKXHWqsYQtFBcCdlnDupQ16nPsSaRnfcH6xVhEqWAjlIzaoPy98iGTabT0 GgV1IswrFiFn7DI40mKjqomIbSeZiGQfkZGUnXifK4OfqN3nFTCb99sqn80zPg1JWHoPJkOXdExE KBVS6P02j40B5dsOoWKf7VvgW+e76nNxTjtgQLBFuwRtLWOQWm3FjhHYFVAI02UhohtdpWQ2KFaW j10PUOEitpKgxh0gEGCccQku4iVOIqTGhvUwfKR0TCswAO802mEkDiLvFAlQQ7WnUF3i7M1eqkWq Sv5CaGozyhKmGe7X+3WqhPzD5V7kSijB2G20ONsfomeQoBdsEBGFFqPBLw1LbT2inpSEyOTRtaUF aXHnijnZVsf9A/+8dHUn++1mhyJtfmzg3jXqDwjx5bfBFCm/fM1tPK45QLSlHX2+3M3n5h18aP+e ohv266H9eWh3ntzePLQzz8378kwQ7hLuFpqFidi9dLLQgr1SpyC6ORV7Y07HroIzsWvpbOxrOEdo w46v87AT4Hz+vaDFjl5JNwn6CULznFlzxk/J3LG8474l98z8X0V7UV8KZW5kc3RyZWFtCmVuZG9i ago2NCAwIG9iagoyMzg2NwplbmRvYmoKNjUgMCBvYmoKKHJhZGV4dCBjaGFydGVyLW1pbGVzdG9u ZXMpCmVuZG9iago2NiAwIG9iagooTWFjIE9TIFggMTAuNy4yIFF1YXJ0eiBQREZDb250ZXh0KQpl bmRvYmoKNjcgMCBvYmoKKE1hdXJpY2lvKQplbmRvYmoKNjggMCBvYmoKKCkKZW5kb2JqCjY5IDAg b2JqCihXb3JkKQplbmRvYmoKNzAgMCBvYmoKKEQ6MjAxMjAxMjMyMTUxMTFaMDAnMDAnKQplbmRv YmoKNzEgMCBvYmoKKCkKZW5kb2JqCjcyIDAgb2JqClsgKCkgXQplbmRvYmoKMSAwIG9iago8PCAv VGl0bGUgNjUgMCBSIC9BdXRob3IgNjcgMCBSIC9TdWJqZWN0IDY4IDAgUiAvUHJvZHVjZXIgNjYg MCBSIC9DcmVhdG9yCjY5IDAgUiAvQ3JlYXRpb25EYXRlIDcwIDAgUiAvTW9kRGF0ZSA3MCAwIFIg L0tleXdvcmRzIDcxIDAgUiAvQUFQTDpLZXl3b3Jkcwo3MiAwIFIgPj4KZW5kb2JqCnhyZWYKMCA3 MwowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAxMDIwNzUgMDAwMDAgbiAKMDAwMDAxNjYwNiAwMDAw MCBuIAowMDAwMDQ0MDUyIDAwMDAwIG4gCjAwMDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAxNjU4NSAw MDAwMCBuIAowMDAwMDE2NzEwIDAwMDAwIG4gCjAwMDAwMjMwMTQgMDAwMDAgbiAKMDAwMDA2NTAx MiAwMDAwMCBuIAowMDAwMDc3MTA1IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA0 NDIxMyAwMDAwMCBuIAowMDAwMDUzODMyIDAwMDAwIG4gCjAwMDAwMTY5MDEgMDAwMDAgbiAKMDAw MDAxNzIyNSAwMDAwMCBuIAowMDAwMDIwMjQxIDAwMDAwIG4gCjAwMDAwMTcyNDQgMDAwMDAgbiAK MDAwMDAxNzQ4MyAwMDAwMCBuIAowMDAwMDE3NTAyIDAwMDAwIG4gCjAwMDAwMjAyMjAgMDAwMDAg biAKMDAwMDAyMDI3OCAwMDAwMCBuIAowMDAwMDIyOTkzIDAwMDAwIG4gCjAwMDAwMzQ5MDUgMDAw MDAgbiAKMDAwMDAyMzA1MCAwMDAwMCBuIAowMDAwMDM0ODgzIDAwMDAwIG4gCjAwMDAwMzUwMTIg MDAwMDAgbiAKMDAwMDAzNTE5NCAwMDAwMCBuIAowMDAwMDQ5ODEzIDAwMDAwIG4gCjAwMDAwMzUz MzggMDAwMDAgbiAKMDAwMDAzNjAxNSAwMDAwMCBuIAowMDAwMDQxMzU2IDAwMDAwIG4gCjAwMDAw MzYwMzUgMDAwMDAgbiAKMDAwMDA0MTMzNSAwMDAwMCBuIAowMDAwMDQxNDYzIDAwMDAwIG4gCjAw MDAwMDAwMDAgMDAwMDAgbiAKMDAwMDA1ODI1MiAwMDAwMCBuIAowMDAwMDQxNjU4IDAwMDAwIG4g CjAwMDAwNDE4MDAgMDAwMDAgbiAKMDAwMDA0MTk0MiAwMDAwMCBuIAowMDAwMDQyOTk3IDAwMDAw IG4gCjAwMDAwNDI5NzcgMDAwMDAgbiAKMDAwMDA0NDAzMiAwMDAwMCBuIAowMDAwMDQ0MTQ5IDAw MDAwIG4gCjAwMDAwNDQ2OTggMDAwMDAgbiAKMDAwMDA0NDM3OSAwMDAwMCBuIAowMDAwMDQ0Njc4 IDAwMDAwIG4gCjAwMDAwNDQ5NTMgMDAwMDAgbiAKMDAwMDA0OTc5MiAwMDAwMCBuIAowMDAwMDUw MTE5IDAwMDAwIG4gCjAwMDAwNTAzNjYgMDAwMDAgbiAKMDAwMDA1MzgxMSAwMDAwMCBuIAowMDAw MDU0MTkwIDAwMDAwIG4gCjAwMDAwNTQ0MzIgMDAwMDAgbiAKMDAwMDA1ODIzMSAwMDAwMCBuIAow MDAwMDU4NzQ0IDAwMDAwIG4gCjAwMDAwNTg0MTUgMDAwMDAgbiAKMDAwMDA1ODcyNCAwMDAwMCBu IAowMDAwMDU4OTc5IDAwMDAwIG4gCjAwMDAwNjQ5OTEgMDAwMDAgbiAKMDAwMDA2NTQwMCAwMDAw MCBuIAowMDAwMDY1NjY3IDAwMDAwIG4gCjAwMDAwNzcwODMgMDAwMDAgbiAKMDAwMDA3NzU4NiAw MDAwMCBuIAowMDAwMDc3ODQ2IDAwMDAwIG4gCjAwMDAxMDE4MDQgMDAwMDAgbiAKMDAwMDEwMTgy NiAwMDAwMCBuIAowMDAwMTAxODcwIDAwMDAwIG4gCjAwMDAxMDE5MjIgMDAwMDAgbiAKMDAwMDEw MTk0OSAwMDAwMCBuIAowMDAwMTAxOTY4IDAwMDAwIG4gCjAwMDAxMDE5OTEgMDAwMDAgbiAKMDAw MDEwMjAzMyAwMDAwMCBuIAowMDAwMTAyMDUyIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUgNzMg L1Jvb3QgNDIgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw0ZTBmYTllZWIwNWY0ZGY1MDg2NjNlOTdi ZmZiOWJmND4KPDRlMGZhOWVlYjA1ZjRkZjUwODY2M2U5N2JmZmI5YmY0PiBdID4+CnN0YXJ0eHJl ZgoxMDIyNTAKJSVFT0YK --_003_CB431B0A1C095mauriciosanchezhpcom_-- From bernard_aboba@hotmail.com Mon Jan 23 14:26:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37C21F8794 for ; Mon, 23 Jan 2012 14:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSPw+UD1tdKK for ; Mon, 23 Jan 2012 14:26:45 -0800 (PST) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2505D21F8744 for ; Mon, 23 Jan 2012 14:26:45 -0800 (PST) Received: from BLU152-W10 ([65.55.111.72]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 14:26:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_" X-Originating-IP: [98.96.213.230] From: Bernard Aboba To: , Date: Mon, 23 Jan 2012 14:26:43 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jan 2012 22:26:44.0387 (UTC) FILETIME=[163CF730:01CCDA1E] Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:26:46 -0000 --_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks good to me. Hasn't the RADIUS over TLS draft already been submitted?= (it's in IETF LC) From: mauricio.sanchez@hp.com To: radext@ietf.org Date: Mon=2C 23 Jan 2012 22:11:22 +0000 Subject: [radext] RADEXT recharter At IETF 82=2C the RADEXT WG discussed (see notes section 7 http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the charter to position the WG to be able to embrace several work items that the WG believes relevant=2C as well as recalibrating dates on several committed goals. =20 =20 Below is the new proposed WG charter that your chairs and AD agreed upon. Attached are a PDF version of updated milestones and a marked version detailing changes introduced from existing charter. At this time the chairs would like to open up the list for discussion. Propose your changes and justify why. =20 =20 Our aim is to have this re-chartering discussion completed by next IETF meeting. =20 =20 - Mauricio and Jouni =09 =20 --------- =20 Description of Working Group =20 The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space=2C address cryptographic algorithm agility=2C use of new secure transports and clarify its usage and definition. =20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments=2C all RADEXT WG work items MUST contain a Diameter compatibility section=2C outlining how interoperability with Diameter will be maintained. Furthermore=2C to ensure backward compatibility with existing RADIUS implementations=2C as well as compatibility between RADIUS and Diameter=2C = the following restrictions are imposed on extensions considered by the RADEXT WG: =20 - All documents produced MUST specify means of interoperation with legacy RADIUS and=2C if possible=2C be backward compatible with existing RADIUS RF= Cs=2C including RFCs 2865-2869=2C 3162=2C 3575=2C 3579=2C 3580=2C 4668-4673=2C467= 5=2C 5080=2C 5090 and 5176. Transport profiles should=2C if possible=2C be compatible wi= th RFC 3539. =20 - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible=2C new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items The immediate goals of the RADEXT working group are to address the following issues: =20 -RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner=2C maintaining backwards compatibility with existing RADIUS RFCs=2C across all the classes of attributes: Standard=2C Vendor-Specific and SDO-Specific. In addition=2C it will review RADIUS data types and associated backwards compatibility issues. =20 -RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. =20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space=2C while maintaining backward compatibility with existing attributes. =20 -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5=2C the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements=2C as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. =20 -IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication=2C authorization and accounting attributes needed by IEEE 80= 2 groups including IEEE 802.1=2C IEEE 802.11 and IEEE 802.16. =20 - New RADIUS transports. A reliable transport profile for RADIUS will be developed=2C as well as specifications for Secure transports=2C including TCP/TLS (RADSEC) and UDP/DTLS. =20 - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. =20 - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify egregious issues present with RFC4282 in two phases. In first phase=2C RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase=2C a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. =20 Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC=20 =20 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext = --_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looks good to me.  =3BHasn't the RADIUS over TLS draft already been sub= mitted? (it's in IETF LC)

From: mauricio.sanchez@hp.com
To: radext@ietf.org
Date: Mon=2C 23= Jan 2012 22:11:22 +0000
Subject: [radext] RADEXT recharter

=
At IETF 82=2C the RADEXT WG discussed (see notes section 7
http=
://www.ietf.org/proceedings/82/minutes/radext.txt) updating the
char=
ter to position the WG to be able to embrace several work items that
the=
 WG believes relevant=2C as well as recalibrating dates on several
commi=
tted goals.  
 
Below is the new proposed WG charter that your chairs=
 and AD agreed upon.
Attached are a PDF version of updated milestones an=
d a marked version
detailing changes introduced from existing charter. A=
t this time the
chairs would like to open up the list for discussion. Pr=
opose your changes
and justify why.  
 
Our aim is to have this re=
-chartering discussion completed by next IETF
meeting.  
 
- Mauri=
cio and Jouni
 	
 
---------
 
Description of Working Group<=
br> 
The RADIUS Extensions Working Group will focus on extensions to the=
 RADIUS
protocol required to expand and enrich the standard attribute sp=
ace=2C
address cryptographic algorithm agility=2C use of new secure tran=
sports and
clarify its usage and definition.
 
In order to enable =
interoperation of heterogeneous RADIUS/Diameter
deployments=2C all RADEX=
T WG work items MUST contain a Diameter
compatibility section=2C outlini=
ng how interoperability with Diameter will
be maintained.
Furthermore=
=2C to ensure backward compatibility with existing RADIUS
implementation=
s=2C as well as compatibility between RADIUS and Diameter=2C the
followi=
ng restrictions are imposed on extensions considered by the RADEXT
WG: 
- All documents produced MUST specify means of interoperation with l=
egacy
RADIUS and=2C if possible=2C be backward compatible with existing =
RADIUS RFCs=2C
including RFCs 2865-2869=2C 3162=2C 3575=2C 3579=2C 3580=
=2C 4668-4673=2C4675=2C 5080=2C
5090 and 5176. Transport profiles should=
=2C if possible=2C be compatible with
RFC 3539.
 
- All RADIUS wor=
k MUST be compatible with equivalent facilities in
Diameter. Where possi=
ble=2C new attributes should be defined so that the
same attribute can b=
e used in both RADIUS and Diameter without
translation. In other cases a=
 translation considerations section should be
included in the specificat=
ion.
 
Work Items
The immediate goals of the RADEXT working group =
are to address the
following issues:
 
-RADIUS design guidelines. =
This document will provide guidelines for
design of RADIUS attributes. I=
t will specifically consider how complex
data types may be introduced in=
 a robust manner=2C maintaining backwards
compatibility with existing RA=
DIUS RFCs=2C across all the classes of
attributes: Standard=2C Vendor-Sp=
ecific and SDO-Specific. In addition=2C it
will review RADIUS data types=
 and associated backwards compatibility
issues.
 
-RADIUS Manageme=
nt authorization. This document will define the use of
RADIUS for NAS ma=
nagement over IP.
 
-RADIUS attribute space extension. The standard R=
ADIUS attribute space is
currently being depleted. This document will pr=
ovide additional standard
attribute space=2C while maintaining backward =
compatibility with existing
attributes.
 
-RADIUS Cryptographic Al=
gorithm Agility. RADIUS has traditionally relied
on MD5 for both per-pac=
ket integrity and authentication as well as
attribute confidentiality. G=
iven the increasingly successful attacks being
mounted against MD5=2C th=
e ability to support alternative algorithms is
required. This work item =
will include documentation of RADIUS
crypto-agility requirements=2C as w=
ell as development of one or more
Experimental RFCs providing support fo=
r negotiation of alternative
cryptographic algorithms to protect RADIUS.=

 
-IEEE 802 attributes. New attributes have been proposed to support=
 IEEE
802 standards for wired and wireless LANs. This work item will sup=
port
authentication=2C authorization and accounting attributes needed by=
 IEEE 802
groups including IEEE 802.1=2C IEEE 802.11 and IEEE 802.16. 
- New RADIUS transports. A reliable transport profile for RADIUS will=
 be
developed=2C as well as specifications for Secure transports=2C incl=
uding
TCP/TLS (RADSEC) and UDP/DTLS.
 
- Documentation of Status-S=
erver usage. A document describing usage of the
Status-Server facility w=
ill be developed.
 
- Update and clarification of Network Access Iden=
tifiers (RFC4282).This
work item will correct and clarify egregious issu=
es present with RFC4282
in two phases.  In first phase=2C RFC4282bis wil=
l be issued to eliminate
fundamental incompatibilities with RADIUS aroun=
d character encoding and
NAI modifications by proxies.  In second phase=
=2C a fresh review of NAI
internationalization requirements and behavior=
 will be undertaken with a
clear goal of maintaining compatibility with =
RADIUS.
 
Goals and Milestones
Done		Updates to RFC 2618-2621 RADI=
US MIBs submitted for publication
Done		SIP RADIUS authentication draft =
submitted as a Proposed Standard RFC
Done		RFC 2486bis submitted as a Pr=
oposed Standard RFC
Done		RFC 3576 MIBs submitted as an Informational RF=
C
Done		RADIUS VLAN and Priority Attributes draft submitted as a Propose=
d
Standard RFC (reduced in scope)
Done		RADIUS Implementation Issues =
and Fixes draft submitted as an
Informational RFC
Done		RADIUS Filter=
ing Attributes draft submitted as a Proposed Standard
RFC (split out fro=
m VLAN &=3B Priority draft)
Done		RFC 3576bis submitted as an Informa=
tional RFC (split out from Issues
&=3B Fixes draft)
Done		RADIUS R=
edirection Attributes draft submitted as a Proposed Standard
RFC (split =
out from VLAN &=3B Priority draft)
Done		RADIUS Design Guidelines sub=
mitted as a Best Current Practice RFC
Done		RADIUS Management Authorizat=
ion I-D submitted as a Proposed Standard
RFC
Done		Reliable Transport=
 Profile for RADIUS I-D submitted as a Proposed
Standard RFC
Done		St=
atus-Server I-D submitted as a Proposed Standard RFC
Done		RADIUS Crypto=
-agility Requirements submitted as an Informational RFC
Jan 2012	RADSEC =
(RADIUS over TCP/TLS) draft submitted as an Experimental
RFC
Feb 2012=
	IPv6 Access I-D submitted as a Proposed Standard RFC
Feb 2012	Extended =
Attributes I-D submitted as a Proposed Standard RFC
Feb 2012	Dynamic Dis=
covery I-D submitted as a Proposed Standard RFC
Mar 2012	RFC 4282bis sub=
mitted as a Proposed Standard RFC
Mar 2012	RADIUS over DTLS I-D submitte=
d as an Experimental RFC
Apr 2012	IEEE 802 Attributes I-D submitted as a=
 Proposed Standard RFC
Oct 2012	RADIUS support for NAI Internationalizat=
ion I-D submitted as a
Proposed Standard RFC

________= _______________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
= --_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_-- From radext-bounces@ietf.org Mon Jan 23 14:26:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67421F8794; Mon, 23 Jan 2012 14:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327357608; bh=smT4YR2KmDkKXLKPrjiMUOvql3753OQd9MMP7kmfEE0=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=OdyJxsqZSPg8VHX6tkWMj+3aD+/DEtaw1Ld/J0eVAPazmein4BBHI/V2zNpjlZ1pL Ys7BquIF1Ln8z3uLXddzWGkCTDYNU+xj75hNbg7jfGS14NbiDPtVcs3aHst6M0vRd4 KzcfhCdvoJ5eYUWCRDC6+8ye0X64wXcxvKIsJLrA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A37C21F8794 for ; Mon, 23 Jan 2012 14:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSPw+UD1tdKK for ; Mon, 23 Jan 2012 14:26:45 -0800 (PST) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2505D21F8744 for ; Mon, 23 Jan 2012 14:26:45 -0800 (PST) Received: from BLU152-W10 ([65.55.111.72]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 14:26:44 -0800 Message-ID: X-Originating-IP: [98.96.213.230] From: Bernard Aboba To: , Date: Mon, 23 Jan 2012 14:26:43 -0800 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jan 2012 22:26:44.0387 (UTC) FILETIME=[163CF730:01CCDA1E] Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1939921864601823554==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============1939921864601823554== Content-Type: multipart/alternative; boundary="_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_" --_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks good to me. Hasn't the RADIUS over TLS draft already been submitted?= (it's in IETF LC) From: mauricio.sanchez@hp.com To: radext@ietf.org Date: Mon=2C 23 Jan 2012 22:11:22 +0000 Subject: [radext] RADEXT recharter At IETF 82=2C the RADEXT WG discussed (see notes section 7 http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the charter to position the WG to be able to embrace several work items that the WG believes relevant=2C as well as recalibrating dates on several committed goals. =20 =20 Below is the new proposed WG charter that your chairs and AD agreed upon. Attached are a PDF version of updated milestones and a marked version detailing changes introduced from existing charter. At this time the chairs would like to open up the list for discussion. Propose your changes and justify why. =20 =20 Our aim is to have this re-chartering discussion completed by next IETF meeting. =20 =20 - Mauricio and Jouni =09 =20 --------- =20 Description of Working Group =20 The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space=2C address cryptographic algorithm agility=2C use of new secure transports and clarify its usage and definition. =20 In order to enable interoperation of heterogeneous RADIUS/Diameter deployments=2C all RADEXT WG work items MUST contain a Diameter compatibility section=2C outlining how interoperability with Diameter will be maintained. Furthermore=2C to ensure backward compatibility with existing RADIUS implementations=2C as well as compatibility between RADIUS and Diameter=2C = the following restrictions are imposed on extensions considered by the RADEXT WG: =20 - All documents produced MUST specify means of interoperation with legacy RADIUS and=2C if possible=2C be backward compatible with existing RADIUS RF= Cs=2C including RFCs 2865-2869=2C 3162=2C 3575=2C 3579=2C 3580=2C 4668-4673=2C467= 5=2C 5080=2C 5090 and 5176. Transport profiles should=2C if possible=2C be compatible wi= th RFC 3539. =20 - All RADIUS work MUST be compatible with equivalent facilities in Diameter. Where possible=2C new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. =20 Work Items The immediate goals of the RADEXT working group are to address the following issues: =20 -RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner=2C maintaining backwards compatibility with existing RADIUS RFCs=2C across all the classes of attributes: Standard=2C Vendor-Specific and SDO-Specific. In addition=2C it will review RADIUS data types and associated backwards compatibility issues. =20 -RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. =20 -RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space=2C while maintaining backward compatibility with existing attributes. =20 -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5=2C the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements=2C as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. =20 -IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication=2C authorization and accounting attributes needed by IEEE 80= 2 groups including IEEE 802.1=2C IEEE 802.11 and IEEE 802.16. =20 - New RADIUS transports. A reliable transport profile for RADIUS will be developed=2C as well as specifications for Secure transports=2C including TCP/TLS (RADSEC) and UDP/DTLS. =20 - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. =20 - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify egregious issues present with RFC4282 in two phases. In first phase=2C RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase=2C a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. =20 Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC=20 =20 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext = --_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looks good to me.  =3BHasn't the RADIUS over TLS draft already been sub= mitted? (it's in IETF LC)

From: mauricio.sanchez@hp.com
To: radext@ietf.org
Date: Mon=2C 23= Jan 2012 22:11:22 +0000
Subject: [radext] RADEXT recharter

=
At IETF 82=2C the RADEXT WG discussed (see notes section 7
http=
://www.ietf.org/proceedings/82/minutes/radext.txt) updating the
char=
ter to position the WG to be able to embrace several work items that
the=
 WG believes relevant=2C as well as recalibrating dates on several
commi=
tted goals.  
 
Below is the new proposed WG charter that your chairs=
 and AD agreed upon.
Attached are a PDF version of updated milestones an=
d a marked version
detailing changes introduced from existing charter. A=
t this time the
chairs would like to open up the list for discussion. Pr=
opose your changes
and justify why.  
 
Our aim is to have this re=
-chartering discussion completed by next IETF
meeting.  
 
- Mauri=
cio and Jouni
 	
 
---------
 
Description of Working Group<=
br> 
The RADIUS Extensions Working Group will focus on extensions to the=
 RADIUS
protocol required to expand and enrich the standard attribute sp=
ace=2C
address cryptographic algorithm agility=2C use of new secure tran=
sports and
clarify its usage and definition.
 
In order to enable =
interoperation of heterogeneous RADIUS/Diameter
deployments=2C all RADEX=
T WG work items MUST contain a Diameter
compatibility section=2C outlini=
ng how interoperability with Diameter will
be maintained.
Furthermore=
=2C to ensure backward compatibility with existing RADIUS
implementation=
s=2C as well as compatibility between RADIUS and Diameter=2C the
followi=
ng restrictions are imposed on extensions considered by the RADEXT
WG: 
- All documents produced MUST specify means of interoperation with l=
egacy
RADIUS and=2C if possible=2C be backward compatible with existing =
RADIUS RFCs=2C
including RFCs 2865-2869=2C 3162=2C 3575=2C 3579=2C 3580=
=2C 4668-4673=2C4675=2C 5080=2C
5090 and 5176. Transport profiles should=
=2C if possible=2C be compatible with
RFC 3539.
 
- All RADIUS wor=
k MUST be compatible with equivalent facilities in
Diameter. Where possi=
ble=2C new attributes should be defined so that the
same attribute can b=
e used in both RADIUS and Diameter without
translation. In other cases a=
 translation considerations section should be
included in the specificat=
ion.
 
Work Items
The immediate goals of the RADEXT working group =
are to address the
following issues:
 
-RADIUS design guidelines. =
This document will provide guidelines for
design of RADIUS attributes. I=
t will specifically consider how complex
data types may be introduced in=
 a robust manner=2C maintaining backwards
compatibility with existing RA=
DIUS RFCs=2C across all the classes of
attributes: Standard=2C Vendor-Sp=
ecific and SDO-Specific. In addition=2C it
will review RADIUS data types=
 and associated backwards compatibility
issues.
 
-RADIUS Manageme=
nt authorization. This document will define the use of
RADIUS for NAS ma=
nagement over IP.
 
-RADIUS attribute space extension. The standard R=
ADIUS attribute space is
currently being depleted. This document will pr=
ovide additional standard
attribute space=2C while maintaining backward =
compatibility with existing
attributes.
 
-RADIUS Cryptographic Al=
gorithm Agility. RADIUS has traditionally relied
on MD5 for both per-pac=
ket integrity and authentication as well as
attribute confidentiality. G=
iven the increasingly successful attacks being
mounted against MD5=2C th=
e ability to support alternative algorithms is
required. This work item =
will include documentation of RADIUS
crypto-agility requirements=2C as w=
ell as development of one or more
Experimental RFCs providing support fo=
r negotiation of alternative
cryptographic algorithms to protect RADIUS.=

 
-IEEE 802 attributes. New attributes have been proposed to support=
 IEEE
802 standards for wired and wireless LANs. This work item will sup=
port
authentication=2C authorization and accounting attributes needed by=
 IEEE 802
groups including IEEE 802.1=2C IEEE 802.11 and IEEE 802.16. 
- New RADIUS transports. A reliable transport profile for RADIUS will=
 be
developed=2C as well as specifications for Secure transports=2C incl=
uding
TCP/TLS (RADSEC) and UDP/DTLS.
 
- Documentation of Status-S=
erver usage. A document describing usage of the
Status-Server facility w=
ill be developed.
 
- Update and clarification of Network Access Iden=
tifiers (RFC4282).This
work item will correct and clarify egregious issu=
es present with RFC4282
in two phases.  In first phase=2C RFC4282bis wil=
l be issued to eliminate
fundamental incompatibilities with RADIUS aroun=
d character encoding and
NAI modifications by proxies.  In second phase=
=2C a fresh review of NAI
internationalization requirements and behavior=
 will be undertaken with a
clear goal of maintaining compatibility with =
RADIUS.
 
Goals and Milestones
Done		Updates to RFC 2618-2621 RADI=
US MIBs submitted for publication
Done		SIP RADIUS authentication draft =
submitted as a Proposed Standard RFC
Done		RFC 2486bis submitted as a Pr=
oposed Standard RFC
Done		RFC 3576 MIBs submitted as an Informational RF=
C
Done		RADIUS VLAN and Priority Attributes draft submitted as a Propose=
d
Standard RFC (reduced in scope)
Done		RADIUS Implementation Issues =
and Fixes draft submitted as an
Informational RFC
Done		RADIUS Filter=
ing Attributes draft submitted as a Proposed Standard
RFC (split out fro=
m VLAN &=3B Priority draft)
Done		RFC 3576bis submitted as an Informa=
tional RFC (split out from Issues
&=3B Fixes draft)
Done		RADIUS R=
edirection Attributes draft submitted as a Proposed Standard
RFC (split =
out from VLAN &=3B Priority draft)
Done		RADIUS Design Guidelines sub=
mitted as a Best Current Practice RFC
Done		RADIUS Management Authorizat=
ion I-D submitted as a Proposed Standard
RFC
Done		Reliable Transport=
 Profile for RADIUS I-D submitted as a Proposed
Standard RFC
Done		St=
atus-Server I-D submitted as a Proposed Standard RFC
Done		RADIUS Crypto=
-agility Requirements submitted as an Informational RFC
Jan 2012	RADSEC =
(RADIUS over TCP/TLS) draft submitted as an Experimental
RFC
Feb 2012=
	IPv6 Access I-D submitted as a Proposed Standard RFC
Feb 2012	Extended =
Attributes I-D submitted as a Proposed Standard RFC
Feb 2012	Dynamic Dis=
covery I-D submitted as a Proposed Standard RFC
Mar 2012	RFC 4282bis sub=
mitted as a Proposed Standard RFC
Mar 2012	RADIUS over DTLS I-D submitte=
d as an Experimental RFC
Apr 2012	IEEE 802 Attributes I-D submitted as a=
 Proposed Standard RFC
Oct 2012	RADIUS support for NAI Internationalizat=
ion I-D submitted as a
Proposed Standard RFC

________= _______________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext
= --_5deb379a-c8f0-4b21-bc64-89bbbfd93bee_-- --===============1939921864601823554== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1939921864601823554==-- From dnelson@elbrys.com Mon Jan 23 14:28:43 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFA921F85A1 for ; Mon, 23 Jan 2012 14:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9R6oiNXA6UJ for ; Mon, 23 Jan 2012 14:28:43 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id BBBD821F8577 for ; Mon, 23 Jan 2012 14:28:42 -0800 (PST) Received: from mail-vw0-f48.google.com ([209.85.212.48]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTx3fGvgv66fBb8qWljzKtUaIb5Y4lWNc@postini.com; Mon, 23 Jan 2012 14:28:42 PST Received: by mail-vw0-f48.google.com with SMTP id fn1so3065730vbb.21 for ; Mon, 23 Jan 2012 14:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.30.81 with SMTP id q17mr4825307vdh.115.1327357721861; Mon, 23 Jan 2012 14:28:41 -0800 (PST) Received: by 10.52.89.179 with HTTP; Mon, 23 Jan 2012 14:28:41 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Jan 2012 17:28:41 -0500 Message-ID: From: Dave Nelson To: "Sanchez, Mauricio (HP Networking)" X-Gm-Message-State: ALoCoQn7tePMBF/CLCbxY5ceCFe8s6uhgHvOcRrEQOj8q+RnJe9dT02TFRqATRl94puXqVkHXyMG Content-Type: multipart/alternative; boundary=20cf30776151805ca304b7398d20 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:28:44 -0000 --20cf30776151805ca304b7398d20 Content-Type: text/plain; charset=ISO-8859-1 Hi Mauricio, I'm a bit confused about a couple of the RADEXT work items that remain in the revised charter proposal, specifically" -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it > will review RADIUS data types and associated backwards compatibility > issues. > This has been published as RFC 6158 for "classic" RADIUS atributes, and the corresponding guidance for "extended" atributes is included in the extended attributes ID. -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > This has been published as RFC 5607. > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied > on MD5 for both per-packet integrity and authentication as well as > attribute confidentiality. Given the increasingly successful attacks being > mounted against MD5, the ability to support alternative algorithms is > required. This work item will include documentation of RADIUS > crypto-agility requirements, as well as development of one or more > Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > This has been published as RFC 6421 . - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. This has been published as RFC 5997. Unless there are new problem statements in any of these areas, I think that these work items can be removed from teh revised charter. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf30776151805ca304b7398d20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mauricio,

I'm a bit confused about a couple of th= e RADEXT work items that remain in the revised charter proposal, specifical= ly"

-RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how complex
data types may be introduced in a robust manner, maintaining backwards
compatibility with existing RADIUS RFCs, across all the classes of
attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it
will review RADIUS data types and associated backwards compatibility
issues.

This has been published as RFC = 6158 for "classic" RADIUS atributes, and the=A0corresponding=A0gu= idance for "extended" atributes is included in the extended attri= butes ID.

-RADIUS Management authorization. This document will define the use of
RADIUS for NAS management over IP.

This= has been published as RFC 5607.
=A0
-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as
attribute confidentiality. Given the increasingly successful attacks being<= br> mounted against MD5, the ability to support alternative algorithms is
required. This work item will include documentation of RADIUS
crypto-agility requirements, as well as development of one or more
Experimental RFCs providing support for negotiation of alternative
cryptographic algorithms to protect RADIUS.

=
This has been published as RFC 6421 .

- Documentation of Status-Server usage. A document describing usage of= the
Status-Server facility will be developed.

This has been=A0published=A0as RFC 5997.

Unless=A0there=A0are new problem statements in any of these areas, I t= hink that these work items can be removed from teh revised charter.<= /span>

Regards,

Dave

David B. Nelson
Sr. Sof= tware Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf30776151805ca304b7398d20-- From radext-bounces@ietf.org Mon Jan 23 14:28:44 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A3F21F85A1; Mon, 23 Jan 2012 14:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327357724; bh=0ViFcoYjOFVrPqdg1rH+kFEimYQ5WMEn2Bla1AvPcJo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=xsjVck5C/xuZN2bGaDInrU2FJfG65Mcd1FnJ9DvQZ+6x+HmnrW3twlGlqfp0vEV+9 /srOSGmZuk3ULxP22f/C8maQrMG2a32zzIYfKL5gBTIZDNvjhob1kSpcXF9mNRaL8N 6AfFiU9OZvoqWh3uHqiYmkMQxxNDf+S/oowAlX9g= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFA921F85A1 for ; Mon, 23 Jan 2012 14:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9R6oiNXA6UJ for ; Mon, 23 Jan 2012 14:28:43 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with SMTP id BBBD821F8577 for ; Mon, 23 Jan 2012 14:28:42 -0800 (PST) Received: from mail-vw0-f48.google.com ([209.85.212.48]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTx3fGvgv66fBb8qWljzKtUaIb5Y4lWNc@postini.com; Mon, 23 Jan 2012 14:28:42 PST Received: by mail-vw0-f48.google.com with SMTP id fn1so3065730vbb.21 for ; Mon, 23 Jan 2012 14:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.30.81 with SMTP id q17mr4825307vdh.115.1327357721861; Mon, 23 Jan 2012 14:28:41 -0800 (PST) Received: by 10.52.89.179 with HTTP; Mon, 23 Jan 2012 14:28:41 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Jan 2012 17:28:41 -0500 Message-ID: From: Dave Nelson To: "Sanchez, Mauricio (HP Networking)" X-Gm-Message-State: ALoCoQn7tePMBF/CLCbxY5ceCFe8s6uhgHvOcRrEQOj8q+RnJe9dT02TFRqATRl94puXqVkHXyMG Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4458445422379790763==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============4458445422379790763== Content-Type: multipart/alternative; boundary=20cf30776151805ca304b7398d20 --20cf30776151805ca304b7398d20 Content-Type: text/plain; charset=ISO-8859-1 Hi Mauricio, I'm a bit confused about a couple of the RADEXT work items that remain in the revised charter proposal, specifically" -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it > will review RADIUS data types and associated backwards compatibility > issues. > This has been published as RFC 6158 for "classic" RADIUS atributes, and the corresponding guidance for "extended" atributes is included in the extended attributes ID. -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > This has been published as RFC 5607. > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied > on MD5 for both per-packet integrity and authentication as well as > attribute confidentiality. Given the increasingly successful attacks being > mounted against MD5, the ability to support alternative algorithms is > required. This work item will include documentation of RADIUS > crypto-agility requirements, as well as development of one or more > Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > This has been published as RFC 6421 . - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. This has been published as RFC 5997. Unless there are new problem statements in any of these areas, I think that these work items can be removed from teh revised charter. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf30776151805ca304b7398d20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mauricio,

I'm a bit confused about a couple of th= e RADEXT work items that remain in the revised charter proposal, specifical= ly"

-RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how complex
data types may be introduced in a robust manner, maintaining backwards
compatibility with existing RADIUS RFCs, across all the classes of
attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it
will review RADIUS data types and associated backwards compatibility
issues.

This has been published as RFC = 6158 for "classic" RADIUS atributes, and the=A0corresponding=A0gu= idance for "extended" atributes is included in the extended attri= butes ID.

-RADIUS Management authorization. This document will define the use of
RADIUS for NAS management over IP.

This= has been published as RFC 5607.
=A0
-RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as
attribute confidentiality. Given the increasingly successful attacks being<= br> mounted against MD5, the ability to support alternative algorithms is
required. This work item will include documentation of RADIUS
crypto-agility requirements, as well as development of one or more
Experimental RFCs providing support for negotiation of alternative
cryptographic algorithms to protect RADIUS.

=
This has been published as RFC 6421 .

- Documentation of Status-Server usage. A document describing usage of= the
Status-Server facility will be developed.

This has been=A0published=A0as RFC 5997.

Unless=A0there=A0are new problem statements in any of these areas, I t= hink that these work items can be removed from teh revised charter.<= /span>

Regards,

Dave

David B. Nelson
Sr. Sof= tware Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf30776151805ca304b7398d20-- --===============4458445422379790763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4458445422379790763==-- From radext-bounces@ietf.org Mon Jan 23 15:44:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E6321F86B0; Mon, 23 Jan 2012 15:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327362259; bh=N5PEPUwj8qBi8W3DdSFd5TwP7I3nIiUKeBeLyZwrUZ0=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=mnU+cE6HGUO7wf06HehYXt0LHml5W/Er1+eQ3yxw9kG0aJfploVrcxuSiESCP4mrO 1gofXk7xFmq8u/X5LPG39LxGlOihR4sW9NpzpGeiwv2evfLH8xX4ONRZBZ2wANt7tK Mqw2AGYEfklwv0Fz+ZDMm/Y/cl2ZJH5d4jvo3zc0= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710DB21F86B0 for ; Mon, 23 Jan 2012 15:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vh0ZmrbgYao for ; Mon, 23 Jan 2012 15:44:16 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9898F21F8681 for ; Mon, 23 Jan 2012 15:44:16 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 23 Jan 2012 15:44:15 -0800 Date: Mon, 23 Jan 2012 15:44:14 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1DD563.2060802@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Mon, 23 Jan 2012, Alan DeKok wrote: > Peter Deacon wrote: >>> Inserting a new attribute into the middle of a list of attributes is >>> wrong. >> Says who? > Says the extensions draft. My impression the goal was backwards compatibility with systems predating the extensions draft to at least inject or forward unknown attributes. In this case text of the extensions draft has no "say". It didn't exist when these systems were deployed. Backwards compatibility is the only reason I bring this up. If backwards compatibility is not desired then I agree with you there are no issues, full steam ahead. Forwarding or otherwise processing unknown attributes is not risk free such as forwarding an attribute requiring per-hop encryption. I would loose no sleep over requiring all implementations in the chain to fully support extensions. >> Although it is tempting to draw parallels with EAP experience there is >> only one instance of an *EAP packet* allowed per RADIUS message. > RFC 2865 says nothing about EAP packets. It's perfectly legal under > RFC 2865 to insert one instance of attribute 79 in the middle of a list > of attribute 79's. You brought up EAP as evidence my concerns are without merit. I pointed out there are important differences between EAP and extensions which limit the applicability of this analogy. > Doing so will break EAP. So by your argument, adding EAP to RADIUS is > impossible. RFC 3579 dictates how EAP-Message may be used. EAP-Message is not defined anywhere else. The important distinction not accounted for in your analogy is extensions further constrains allowed behavior of existing RFCs. If you do this there are consequences with regard to backward compatibility as existing implementations can not be made retroactively aware of additional constraints. >> Who has seen even a single WIMAX VSA with continuation bit set? > Is it really necessary to ask a rhetorical question? I assume the reason WIMAX was brought up was to provide evidence against my concerns. My response simply suggests this specific scenario is not really all that widespread in the "real world" even in cases where these specific wimax VSAs are used and therefore not such a great measuring stick of the existence or nonexistence of the potential for any problems. > There's also RFC 5904, which defines two more attributes that can span > multiple RADIUS attributes. My EAP caution applies here as well. There is only one cert per message of a specific attribute type allowed. >> I understand you may disagree with regards to the degree this may be a >> problem. I don't believe this warrants marking my issue 'invalid'. > I don't see it as a valid objection. It's based on assumptions which > have proven to be false for a decade. I don't follow what was proven false? >> Fundamentally I think it is better to work from the position of what the >> RFCs actually say rather than what we all wish they would have said. > Let's discard RFC 2869 because it's "Informational" and RFC 2865 is > "Standards Track". 2869 CLEARLY VIOLATES 2865. Then, we'll deploy an > RFC 2865 compliant RADIUS proxy. We'll have it mangle attribute 79 as > per your argument. It's allowed under 2865. It's exactly your See above for my thoughts on this EAP-Message analogy. > scenario. You MUST then agree that 2869 is wrong and impossible to > implement. Do I think it is wrong and costly when two RFCs disagree with each other? Yes. Would it have been possible to implement 2869 in a way that did not violate 2865? Yes. > Except we've already proven that argument false. RFC 2869 has proven > it false for over a decade. Therefore, your arguments against the > extensions draft don't apply, either. There is always a cost when RFCs contradict each other. I'm simply suggesting a way forward which seeks to limit any effect of legacy problems where backwards compatibility is desired. >> I am not seeking major unreasonable disruptive change. Only to mitigate >> against possibilities that MAY exist in a fully RFC compliant system. > It's impossible to be fully compliant to the RADIUS RFCs. They are > contradictory, incomplete, and often plain wrong. See RFC 5080. Contradictions are not cost free. My intent is simply to mitigate these costs as much as reasonable within the current framework of extensions. I have on multiple occasions stated I don't care about perfect backwards compatibility. My goal is simply providing a good chance of detecting the presence of errors. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Mon Jan 23 15:44:17 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710DB21F86B0 for ; Mon, 23 Jan 2012 15:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vh0ZmrbgYao for ; Mon, 23 Jan 2012 15:44:16 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9898F21F8681 for ; Mon, 23 Jan 2012 15:44:16 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 23 Jan 2012 15:44:15 -0800 Date: Mon, 23 Jan 2012 15:44:14 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1DD563.2060802@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:44:17 -0000 On Mon, 23 Jan 2012, Alan DeKok wrote: > Peter Deacon wrote: >>> Inserting a new attribute into the middle of a list of attributes is >>> wrong. >> Says who? > Says the extensions draft. My impression the goal was backwards compatibility with systems predating the extensions draft to at least inject or forward unknown attributes. In this case text of the extensions draft has no "say". It didn't exist when these systems were deployed. Backwards compatibility is the only reason I bring this up. If backwards compatibility is not desired then I agree with you there are no issues, full steam ahead. Forwarding or otherwise processing unknown attributes is not risk free such as forwarding an attribute requiring per-hop encryption. I would loose no sleep over requiring all implementations in the chain to fully support extensions. >> Although it is tempting to draw parallels with EAP experience there is >> only one instance of an *EAP packet* allowed per RADIUS message. > RFC 2865 says nothing about EAP packets. It's perfectly legal under > RFC 2865 to insert one instance of attribute 79 in the middle of a list > of attribute 79's. You brought up EAP as evidence my concerns are without merit. I pointed out there are important differences between EAP and extensions which limit the applicability of this analogy. > Doing so will break EAP. So by your argument, adding EAP to RADIUS is > impossible. RFC 3579 dictates how EAP-Message may be used. EAP-Message is not defined anywhere else. The important distinction not accounted for in your analogy is extensions further constrains allowed behavior of existing RFCs. If you do this there are consequences with regard to backward compatibility as existing implementations can not be made retroactively aware of additional constraints. >> Who has seen even a single WIMAX VSA with continuation bit set? > Is it really necessary to ask a rhetorical question? I assume the reason WIMAX was brought up was to provide evidence against my concerns. My response simply suggests this specific scenario is not really all that widespread in the "real world" even in cases where these specific wimax VSAs are used and therefore not such a great measuring stick of the existence or nonexistence of the potential for any problems. > There's also RFC 5904, which defines two more attributes that can span > multiple RADIUS attributes. My EAP caution applies here as well. There is only one cert per message of a specific attribute type allowed. >> I understand you may disagree with regards to the degree this may be a >> problem. I don't believe this warrants marking my issue 'invalid'. > I don't see it as a valid objection. It's based on assumptions which > have proven to be false for a decade. I don't follow what was proven false? >> Fundamentally I think it is better to work from the position of what the >> RFCs actually say rather than what we all wish they would have said. > Let's discard RFC 2869 because it's "Informational" and RFC 2865 is > "Standards Track". 2869 CLEARLY VIOLATES 2865. Then, we'll deploy an > RFC 2865 compliant RADIUS proxy. We'll have it mangle attribute 79 as > per your argument. It's allowed under 2865. It's exactly your See above for my thoughts on this EAP-Message analogy. > scenario. You MUST then agree that 2869 is wrong and impossible to > implement. Do I think it is wrong and costly when two RFCs disagree with each other? Yes. Would it have been possible to implement 2869 in a way that did not violate 2865? Yes. > Except we've already proven that argument false. RFC 2869 has proven > it false for over a decade. Therefore, your arguments against the > extensions draft don't apply, either. There is always a cost when RFCs contradict each other. I'm simply suggesting a way forward which seeks to limit any effect of legacy problems where backwards compatibility is desired. >> I am not seeking major unreasonable disruptive change. Only to mitigate >> against possibilities that MAY exist in a fully RFC compliant system. > It's impossible to be fully compliant to the RADIUS RFCs. They are > contradictory, incomplete, and often plain wrong. See RFC 5080. Contradictions are not cost free. My intent is simply to mitigate these costs as much as reasonable within the current framework of extensions. I have on multiple occasions stated I don't care about perfect backwards compatibility. My goal is simply providing a good chance of detecting the presence of errors. regards, Peter From stefan.winter@restena.lu Mon Jan 23 23:01:00 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FEB21F85EA for ; Mon, 23 Jan 2012 23:01: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea0KoOODFquk for ; Mon, 23 Jan 2012 23:00:59 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3847321F85E1 for ; Mon, 23 Jan 2012 23:00:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A32FE10590 for ; Tue, 24 Jan 2012 08:00:57 +0100 (CET) Received: from [IPv6:2001:a18:1:8:538:831c:8410:85ff] (unknown [IPv6:2001:a18:1:8:538:831c:8410:85ff]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9265510581 for ; Tue, 24 Jan 2012 08:00:57 +0100 (CET) Message-ID: <4F1E5725.1030205@restena.lu> Date: Tue, 24 Jan 2012 08:00:53 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE808B65443C571E8FE7F753E" X-Virus-Scanned: ClamAV Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:01:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE808B65443C571E8FE7F753E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Looks good to me. Hasn't the RADIUS over TLS draft already been > submitted? (it's in IETF LC) Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is sketched as Proposed Standard. The dynamic discovery draft has RADIUS/TLS as a normative reference. I'm not entirely sure about the process, but - is it okay for Standards track to have a normative reference on Experimental? Also, Feb 2012 for submission seems a bit too ambitious for me. I will certainly issue a new rev before Paris, but it will need WGLC etc. so I don't see how Feb 2012 could be achievable. I'm thinking April at the earliest. (If we aim to approve the new charter by Paris, it will already be March; seems odd that we will have to discuss dates in the past then) Greetings, Stefan Winter > From: mauricio.sanchez@hp.com > To: radext@ietf.org > Date: Mon, 23 Jan 2012 22:11:22 +0000 > Subject: [radext] RADEXT recharter >=20 > At IETF 82, the RADEXT WG discussed (see notes section 7 > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > charter to position the WG to be able to embrace several work items tha= t > the WG believes relevant, as well as recalibrating dates on several > committed goals. =20 > =20 > Below is the new proposed WG charter that your chairs and AD agreed upo= n. > Attached are a PDF version of updated milestones and a marked version > detailing changes introduced from existing charter. At this time the > chairs would like to open up the list for discussion. Propose your chan= ges > and justify why. =20 > =20 > Our aim is to have this re-chartering discussion completed by next IETF= > meeting. =20 > =20 > - Mauricio and Jouni > =09 > =20 > --------- > =20 > Description of Working Group > =20 > The RADIUS Extensions Working Group will focus on extensions to the RAD= IUS > protocol required to expand and enrich the standard attribute space, > address cryptographic algorithm agility, use of new secure transports a= nd > clarify its usage and definition. > =20 > In order to enable interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability with Diameter wil= l > be maintained. > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and Diameter, = the > following restrictions are imposed on extensions considered by the RADE= XT > WG: > =20 > - All documents produced MUST specify means of interoperation with lega= cy > RADIUS and, if possible, be backward compatible with existing RADIUS RF= Cs, > including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080,= > 5090 and 5176. Transport profiles should, if possible, be compatible wi= th > RFC 3539. > =20 > - All RADIUS work MUST be compatible with equivalent facilities in > Diameter. Where possible, new attributes should be defined so that the > same attribute can be used in both RADIUS and Diameter without > translation. In other cases a translation considerations section should= be > included in the specification. > =20 > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: > =20 > -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it= > will review RADIUS data types and associated backwards compatibility > issues. > =20 > -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > =20 > -RADIUS attribute space extension. The standard RADIUS attribute space = is > currently being depleted. This document will provide additional standar= d > attribute space, while maintaining backward compatibility with existing= > attributes. > =20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relie= d > on MD5 for both per-packet integrity and authentication as well as > attribute confidentiality. Given the increasingly successful attacks be= ing > mounted against MD5, the ability to support alternative algorithms is > required. This work item will include documentation of RADIUS > crypto-agility requirements, as well as development of one or more > Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > =20 > -IEEE 802 attributes. New attributes have been proposed to support IEEE= > 802 standards for wired and wireless LANs. This work item will support > authentication, authorization and accounting attributes needed by IEEE = 802 > groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > =20 > - New RADIUS transports. A reliable transport profile for RADIUS will b= e > developed, as well as specifications for Secure transports, including > TCP/TLS (RADSEC) and UDP/DTLS. > =20 > - Documentation of Status-Server usage. A document describing usage of = the > Status-Server facility will be developed. > =20 > - Update and clarification of Network Access Identifiers (RFC4282).This= > work item will correct and clarify egregious issues present with RFC428= 2 > in two phases. In first phase, RFC4282bis will be issued to eliminate > fundamental incompatibilities with RADIUS around character encoding and= > NAI modifications by proxies. In second phase, a fresh review of NAI > internationalization requirements and behavior will be undertaken with = a > clear goal of maintaining compatibility with RADIUS. > =20 > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication > Done SIP RADIUS authentication draft submitted as a Proposed Standard = RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed= > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed Standar= d > RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out from Iss= ues > & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed Stand= ard > RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current Practice RFC= > Done RADIUS Management Authorization I-D submitted as a Proposed Stand= ard > RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed= > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an Informational = RFC > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimenta= l > RFC > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC > Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a= > Proposed Standard RFC=20 > =20 >=20 >=20 > _______________________________________________ radext mailing list > radext@ietf.org https://www.ietf.org/mailman/listinfo/radext >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE808B65443C571E8FE7F753E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8eVykACgkQ+jm90f8eFWYTzgCeKTyRNpjxLMOgJm4Uwot2/ENA +nUAn0GXHkp0rVIEK+pa/bL5lLZKMefr =i70U -----END PGP SIGNATURE----- --------------enigE808B65443C571E8FE7F753E-- From radext-bounces@ietf.org Mon Jan 23 23:01:03 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92321F85ED; Mon, 23 Jan 2012 23:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327388463; bh=iXmWGFWT3gowKNI7srFDIjRMwM3We0aIfC2vzgIcigg=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=wYlzl9/Crpd5p1sy5KjSuYjtb4NFyAfLwn8JN65/xTyuMiJYhabnuProrC2xyv9nU vc5+ceSTrrBZhgzohqWhMvVxWVXcCSF3Whykm1fuApxYHWIaIKHi5uZ5AFvIYjfWvX G2QliB7LDAB/yLbZffOuk8tauD0xdGxR6/GMI1YQ= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FEB21F85EA for ; Mon, 23 Jan 2012 23:01: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea0KoOODFquk for ; Mon, 23 Jan 2012 23:00:59 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3847321F85E1 for ; Mon, 23 Jan 2012 23:00:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A32FE10590 for ; Tue, 24 Jan 2012 08:00:57 +0100 (CET) Received: from [IPv6:2001:a18:1:8:538:831c:8410:85ff] (unknown [IPv6:2001:a18:1:8:538:831c:8410:85ff]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9265510581 for ; Tue, 24 Jan 2012 08:00:57 +0100 (CET) Message-ID: <4F1E5725.1030205@restena.lu> Date: Tue, 24 Jan 2012 08:00:53 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9068621452978785413==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============9068621452978785413== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE808B65443C571E8FE7F753E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE808B65443C571E8FE7F753E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Looks good to me. Hasn't the RADIUS over TLS draft already been > submitted? (it's in IETF LC) Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is sketched as Proposed Standard. The dynamic discovery draft has RADIUS/TLS as a normative reference. I'm not entirely sure about the process, but - is it okay for Standards track to have a normative reference on Experimental? Also, Feb 2012 for submission seems a bit too ambitious for me. I will certainly issue a new rev before Paris, but it will need WGLC etc. so I don't see how Feb 2012 could be achievable. I'm thinking April at the earliest. (If we aim to approve the new charter by Paris, it will already be March; seems odd that we will have to discuss dates in the past then) Greetings, Stefan Winter > From: mauricio.sanchez@hp.com > To: radext@ietf.org > Date: Mon, 23 Jan 2012 22:11:22 +0000 > Subject: [radext] RADEXT recharter >=20 > At IETF 82, the RADEXT WG discussed (see notes section 7 > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > charter to position the WG to be able to embrace several work items tha= t > the WG believes relevant, as well as recalibrating dates on several > committed goals. =20 > =20 > Below is the new proposed WG charter that your chairs and AD agreed upo= n. > Attached are a PDF version of updated milestones and a marked version > detailing changes introduced from existing charter. At this time the > chairs would like to open up the list for discussion. Propose your chan= ges > and justify why. =20 > =20 > Our aim is to have this re-chartering discussion completed by next IETF= > meeting. =20 > =20 > - Mauricio and Jouni > =09 > =20 > --------- > =20 > Description of Working Group > =20 > The RADIUS Extensions Working Group will focus on extensions to the RAD= IUS > protocol required to expand and enrich the standard attribute space, > address cryptographic algorithm agility, use of new secure transports a= nd > clarify its usage and definition. > =20 > In order to enable interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability with Diameter wil= l > be maintained. > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and Diameter, = the > following restrictions are imposed on extensions considered by the RADE= XT > WG: > =20 > - All documents produced MUST specify means of interoperation with lega= cy > RADIUS and, if possible, be backward compatible with existing RADIUS RF= Cs, > including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080,= > 5090 and 5176. Transport profiles should, if possible, be compatible wi= th > RFC 3539. > =20 > - All RADIUS work MUST be compatible with equivalent facilities in > Diameter. Where possible, new attributes should be defined so that the > same attribute can be used in both RADIUS and Diameter without > translation. In other cases a translation considerations section should= be > included in the specification. > =20 > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: > =20 > -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it= > will review RADIUS data types and associated backwards compatibility > issues. > =20 > -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > =20 > -RADIUS attribute space extension. The standard RADIUS attribute space = is > currently being depleted. This document will provide additional standar= d > attribute space, while maintaining backward compatibility with existing= > attributes. > =20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relie= d > on MD5 for both per-packet integrity and authentication as well as > attribute confidentiality. Given the increasingly successful attacks be= ing > mounted against MD5, the ability to support alternative algorithms is > required. This work item will include documentation of RADIUS > crypto-agility requirements, as well as development of one or more > Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > =20 > -IEEE 802 attributes. New attributes have been proposed to support IEEE= > 802 standards for wired and wireless LANs. This work item will support > authentication, authorization and accounting attributes needed by IEEE = 802 > groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > =20 > - New RADIUS transports. A reliable transport profile for RADIUS will b= e > developed, as well as specifications for Secure transports, including > TCP/TLS (RADSEC) and UDP/DTLS. > =20 > - Documentation of Status-Server usage. A document describing usage of = the > Status-Server facility will be developed. > =20 > - Update and clarification of Network Access Identifiers (RFC4282).This= > work item will correct and clarify egregious issues present with RFC428= 2 > in two phases. In first phase, RFC4282bis will be issued to eliminate > fundamental incompatibilities with RADIUS around character encoding and= > NAI modifications by proxies. In second phase, a fresh review of NAI > internationalization requirements and behavior will be undertaken with = a > clear goal of maintaining compatibility with RADIUS. > =20 > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication > Done SIP RADIUS authentication draft submitted as a Proposed Standard = RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed= > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed Standar= d > RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out from Iss= ues > & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed Stand= ard > RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current Practice RFC= > Done RADIUS Management Authorization I-D submitted as a Proposed Stand= ard > RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed= > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an Informational = RFC > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimenta= l > RFC > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC > Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a= > Proposed Standard RFC=20 > =20 >=20 >=20 > _______________________________________________ radext mailing list > radext@ietf.org https://www.ietf.org/mailman/listinfo/radext >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE808B65443C571E8FE7F753E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8eVykACgkQ+jm90f8eFWYTzgCeKTyRNpjxLMOgJm4Uwot2/ENA +nUAn0GXHkp0rVIEK+pa/bL5lLZKMefr =i70U -----END PGP SIGNATURE----- --------------enigE808B65443C571E8FE7F753E-- --===============9068621452978785413== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============9068621452978785413==-- From Tina.Tsou.Zouting@huawei.com Mon Jan 23 23:11:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534F521F8601 for ; Mon, 23 Jan 2012 23:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=-2.080, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWJAf7YxXqLD for ; Mon, 23 Jan 2012 23:11:23 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2F21F85FD for ; Mon, 23 Jan 2012 23:11:23 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYA0086PJYRVK@szxga05-in.huawei.com> for radext@ietf.org; Tue, 24 Jan 2012 15:11:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYA003CQJYRWP@szxga05-in.huawei.com> for radext@ietf.org; Tue, 24 Jan 2012 15:11:15 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGM61799; Tue, 24 Jan 2012 15:11:14 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jan 2012 15:10:57 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 24 Jan 2012 15:11:29 +0800 Date: Tue, 24 Jan 2012 07:11:07 +0000 From: Tina TSOU In-reply-to: <4F1E5725.1030205@restena.lu> To: Stefan Winter Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: [radext] RADEXT recharter Thread-index: AczaG/xDKiJT9gNoRwm22tOW8sfaJP//fhaAgACPqICAAIj4cw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F1E5725.1030205@restena.lu> Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:11:24 -0000 DQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIEphbiAyMywgMjAxMiwgYXQgMTE6MDEgUE0sICJT dGVmYW4gV2ludGVyIiA8c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1PiB3cm90ZToNCg0KPiBIaSwN Cj4gDQo+PiBMb29rcyBnb29kIHRvIG1lLiAgSGFzbid0IHRoZSBSQURJVVMgb3ZlciBUTFMgZHJh ZnQgYWxyZWFkeSBiZWVuDQo+PiBzdWJtaXR0ZWQ/IChpdCdzIGluIElFVEYgTEMpDQo+IA0KPiBS ZWxhdGVkOiBSQURJVVMvVExTIHdpbGwgYmUgRXhwZXJpbWVudGFsLCB3aGlsZSBEeW5hbWljIERp c2NvdmVyeSBpcw0KPiBza2V0Y2hlZCBhcyBQcm9wb3NlZCBTdGFuZGFyZC4gVGhlIGR5bmFtaWMg ZGlzY292ZXJ5IGRyYWZ0IGhhcw0KPiBSQURJVVMvVExTIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5j ZS4NCj4gSSdtIG5vdCBlbnRpcmVseSBzdXJlIGFib3V0IHRoZSBwcm9jZXNzLCBidXQgLSBpcyBp dCBva2F5IGZvciBTdGFuZGFyZHMNCj4gdHJhY2sgdG8gaGF2ZSBhIG5vcm1hdGl2ZSByZWZlcmVu Y2Ugb24gRXhwZXJpbWVudGFsPw0KSW4gdGhlb3J5LCB5ZXMuDQo+IA0KPiBBbHNvLCBGZWIgMjAx MiBmb3Igc3VibWlzc2lvbiBzZWVtcyBhIGJpdCB0b28gYW1iaXRpb3VzIGZvciBtZS4gSSB3aWxs DQo+IGNlcnRhaW5seSBpc3N1ZSBhIG5ldyByZXYgYmVmb3JlIFBhcmlzLCBidXQgaXQgd2lsbCBu ZWVkIFdHTEMgZXRjLiBzbyBJDQo+IGRvbid0IHNlZSBob3cgRmViIDIwMTIgY291bGQgYmUgYWNo aWV2YWJsZS4gSSdtIHRoaW5raW5nIEFwcmlsIGF0IHRoZQ0KPiBlYXJsaWVzdC4NCj4gDQo+IChJ ZiB3ZSBhaW0gdG8gYXBwcm92ZSB0aGUgbmV3IGNoYXJ0ZXIgYnkgUGFyaXMsIGl0IHdpbGwgYWxy ZWFkeSBiZQ0KPiBNYXJjaDsgc2VlbXMgb2RkIHRoYXQgd2Ugd2lsbCBoYXZlIHRvIGRpc2N1c3Mg ZGF0ZXMgaW4gdGhlIHBhc3QgdGhlbikNCj4gDQo+IEdyZWV0aW5ncywNCj4gDQo+IFN0ZWZhbiBX aW50ZXINCj4gDQo+PiBGcm9tOiBtYXVyaWNpby5zYW5jaGV6QGhwLmNvbQ0KPj4gVG86IHJhZGV4 dEBpZXRmLm9yZw0KPj4gRGF0ZTogTW9uLCAyMyBKYW4gMjAxMiAyMjoxMToyMiArMDAwMA0KPj4g U3ViamVjdDogW3JhZGV4dF0gUkFERVhUIHJlY2hhcnRlcg0KPj4gDQo+PiBBdCBJRVRGIDgyLCB0 aGUgUkFERVhUIFdHIGRpc2N1c3NlZCAoc2VlIG5vdGVzIHNlY3Rpb24gNw0KPj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9taW51dGVzL3JhZGV4dC50eHQpIHVwZGF0aW5nIHRo ZQ0KPj4gY2hhcnRlciB0byBwb3NpdGlvbiB0aGUgV0cgdG8gYmUgYWJsZSB0byBlbWJyYWNlIHNl dmVyYWwgd29yayBpdGVtcyB0aGF0DQo+PiB0aGUgV0cgYmVsaWV2ZXMgcmVsZXZhbnQsIGFzIHdl bGwgYXMgcmVjYWxpYnJhdGluZyBkYXRlcyBvbiBzZXZlcmFsDQo+PiBjb21taXR0ZWQgZ29hbHMu ICANCj4+IA0KPj4gQmVsb3cgaXMgdGhlIG5ldyBwcm9wb3NlZCBXRyBjaGFydGVyIHRoYXQgeW91 ciBjaGFpcnMgYW5kIEFEIGFncmVlZCB1cG9uLg0KPj4gQXR0YWNoZWQgYXJlIGEgUERGIHZlcnNp b24gb2YgdXBkYXRlZCBtaWxlc3RvbmVzIGFuZCBhIG1hcmtlZCB2ZXJzaW9uDQo+PiBkZXRhaWxp bmcgY2hhbmdlcyBpbnRyb2R1Y2VkIGZyb20gZXhpc3RpbmcgY2hhcnRlci4gQXQgdGhpcyB0aW1l IHRoZQ0KPj4gY2hhaXJzIHdvdWxkIGxpa2UgdG8gb3BlbiB1cCB0aGUgbGlzdCBmb3IgZGlzY3Vz c2lvbi4gUHJvcG9zZSB5b3VyIGNoYW5nZXMNCj4+IGFuZCBqdXN0aWZ5IHdoeS4gIA0KPj4gDQo+ PiBPdXIgYWltIGlzIHRvIGhhdmUgdGhpcyByZS1jaGFydGVyaW5nIGRpc2N1c3Npb24gY29tcGxl dGVkIGJ5IG5leHQgSUVURg0KPj4gbWVldGluZy4gIA0KPj4gDQo+PiAtIE1hdXJpY2lvIGFuZCBK b3VuaQ0KPj4gICAgDQo+PiANCj4+IC0tLS0tLS0tLQ0KPj4gDQo+PiBEZXNjcmlwdGlvbiBvZiBX b3JraW5nIEdyb3VwDQo+PiANCj4+IFRoZSBSQURJVVMgRXh0ZW5zaW9ucyBXb3JraW5nIEdyb3Vw IHdpbGwgZm9jdXMgb24gZXh0ZW5zaW9ucyB0byB0aGUgUkFESVVTDQo+PiBwcm90b2NvbCByZXF1 aXJlZCB0byBleHBhbmQgYW5kIGVucmljaCB0aGUgc3RhbmRhcmQgYXR0cmlidXRlIHNwYWNlLA0K Pj4gYWRkcmVzcyBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBhZ2lsaXR5LCB1c2Ugb2YgbmV3IHNl Y3VyZSB0cmFuc3BvcnRzIGFuZA0KPj4gY2xhcmlmeSBpdHMgdXNhZ2UgYW5kIGRlZmluaXRpb24u DQo+PiANCj4+IEluIG9yZGVyIHRvIGVuYWJsZSBpbnRlcm9wZXJhdGlvbiBvZiBoZXRlcm9nZW5l b3VzIFJBRElVUy9EaWFtZXRlcg0KPj4gZGVwbG95bWVudHMsIGFsbCBSQURFWFQgV0cgd29yayBp dGVtcyBNVVNUIGNvbnRhaW4gYSBEaWFtZXRlcg0KPj4gY29tcGF0aWJpbGl0eSBzZWN0aW9uLCBv dXRsaW5pbmcgaG93IGludGVyb3BlcmFiaWxpdHkgd2l0aCBEaWFtZXRlciB3aWxsDQo+PiBiZSBt YWludGFpbmVkLg0KPj4gRnVydGhlcm1vcmUsIHRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRpYmls aXR5IHdpdGggZXhpc3RpbmcgUkFESVVTDQo+PiBpbXBsZW1lbnRhdGlvbnMsIGFzIHdlbGwgYXMg Y29tcGF0aWJpbGl0eSBiZXR3ZWVuIFJBRElVUyBhbmQgRGlhbWV0ZXIsIHRoZQ0KPj4gZm9sbG93 aW5nIHJlc3RyaWN0aW9ucyBhcmUgaW1wb3NlZCBvbiBleHRlbnNpb25zIGNvbnNpZGVyZWQgYnkg dGhlIFJBREVYVA0KPj4gV0c6DQo+PiANCj4+IC0gQWxsIGRvY3VtZW50cyBwcm9kdWNlZCBNVVNU IHNwZWNpZnkgbWVhbnMgb2YgaW50ZXJvcGVyYXRpb24gd2l0aCBsZWdhY3kNCj4+IFJBRElVUyBh bmQsIGlmIHBvc3NpYmxlLCBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgUkFE SVVTIFJGQ3MsDQo+PiBpbmNsdWRpbmcgUkZDcyAyODY1LTI4NjksIDMxNjIsIDM1NzUsIDM1Nzks IDM1ODAsIDQ2NjgtNDY3Myw0Njc1LCA1MDgwLA0KPj4gNTA5MCBhbmQgNTE3Ni4gVHJhbnNwb3J0 IHByb2ZpbGVzIHNob3VsZCwgaWYgcG9zc2libGUsIGJlIGNvbXBhdGlibGUgd2l0aA0KPj4gUkZD IDM1MzkuDQo+PiANCj4+IC0gQWxsIFJBRElVUyB3b3JrIE1VU1QgYmUgY29tcGF0aWJsZSB3aXRo IGVxdWl2YWxlbnQgZmFjaWxpdGllcyBpbg0KPj4gRGlhbWV0ZXIuIFdoZXJlIHBvc3NpYmxlLCBu ZXcgYXR0cmlidXRlcyBzaG91bGQgYmUgZGVmaW5lZCBzbyB0aGF0IHRoZQ0KPj4gc2FtZSBhdHRy aWJ1dGUgY2FuIGJlIHVzZWQgaW4gYm90aCBSQURJVVMgYW5kIERpYW1ldGVyIHdpdGhvdXQNCj4+ IHRyYW5zbGF0aW9uLiBJbiBvdGhlciBjYXNlcyBhIHRyYW5zbGF0aW9uIGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gc2hvdWxkIGJlDQo+PiBpbmNsdWRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCj4+ IA0KPj4gV29yayBJdGVtcw0KPj4gVGhlIGltbWVkaWF0ZSBnb2FscyBvZiB0aGUgUkFERVhUIHdv cmtpbmcgZ3JvdXAgYXJlIHRvIGFkZHJlc3MgdGhlDQo+PiBmb2xsb3dpbmcgaXNzdWVzOg0KPj4g DQo+PiAtUkFESVVTIGRlc2lnbiBndWlkZWxpbmVzLiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlk ZSBndWlkZWxpbmVzIGZvcg0KPj4gZGVzaWduIG9mIFJBRElVUyBhdHRyaWJ1dGVzLiBJdCB3aWxs IHNwZWNpZmljYWxseSBjb25zaWRlciBob3cgY29tcGxleA0KPj4gZGF0YSB0eXBlcyBtYXkgYmUg aW50cm9kdWNlZCBpbiBhIHJvYnVzdCBtYW5uZXIsIG1haW50YWluaW5nIGJhY2t3YXJkcw0KPj4g Y29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5nIFJBRElVUyBSRkNzLCBhY3Jvc3MgYWxsIHRoZSBj bGFzc2VzIG9mDQo+PiBhdHRyaWJ1dGVzOiBTdGFuZGFyZCwgVmVuZG9yLVNwZWNpZmljIGFuZCBT RE8tU3BlY2lmaWMuIEluIGFkZGl0aW9uLCBpdA0KPj4gd2lsbCByZXZpZXcgUkFESVVTIGRhdGEg dHlwZXMgYW5kIGFzc29jaWF0ZWQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkNCj4+IGlzc3Vlcy4N Cj4+IA0KPj4gLVJBRElVUyBNYW5hZ2VtZW50IGF1dGhvcml6YXRpb24uIFRoaXMgZG9jdW1lbnQg d2lsbCBkZWZpbmUgdGhlIHVzZSBvZg0KPj4gUkFESVVTIGZvciBOQVMgbWFuYWdlbWVudCBvdmVy IElQLg0KPj4gDQo+PiAtUkFESVVTIGF0dHJpYnV0ZSBzcGFjZSBleHRlbnNpb24uIFRoZSBzdGFu ZGFyZCBSQURJVVMgYXR0cmlidXRlIHNwYWNlIGlzDQo+PiBjdXJyZW50bHkgYmVpbmcgZGVwbGV0 ZWQuIFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGFkZGl0aW9uYWwgc3RhbmRhcmQNCj4+IGF0 dHJpYnV0ZSBzcGFjZSwgd2hpbGUgbWFpbnRhaW5pbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3 aXRoIGV4aXN0aW5nDQo+PiBhdHRyaWJ1dGVzLg0KPj4gDQo+PiAtUkFESVVTIENyeXB0b2dyYXBo aWMgQWxnb3JpdGhtIEFnaWxpdHkuIFJBRElVUyBoYXMgdHJhZGl0aW9uYWxseSByZWxpZWQNCj4+ IG9uIE1ENSBmb3IgYm90aCBwZXItcGFja2V0IGludGVncml0eSBhbmQgYXV0aGVudGljYXRpb24g YXMgd2VsbCBhcw0KPj4gYXR0cmlidXRlIGNvbmZpZGVudGlhbGl0eS4gR2l2ZW4gdGhlIGluY3Jl YXNpbmdseSBzdWNjZXNzZnVsIGF0dGFja3MgYmVpbmcNCj4+IG1vdW50ZWQgYWdhaW5zdCBNRDUs IHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcyBpcw0KPj4gcmVx dWlyZWQuIFRoaXMgd29yayBpdGVtIHdpbGwgaW5jbHVkZSBkb2N1bWVudGF0aW9uIG9mIFJBRElV Uw0KPj4gY3J5cHRvLWFnaWxpdHkgcmVxdWlyZW1lbnRzLCBhcyB3ZWxsIGFzIGRldmVsb3BtZW50 IG9mIG9uZSBvciBtb3JlDQo+PiBFeHBlcmltZW50YWwgUkZDcyBwcm92aWRpbmcgc3VwcG9ydCBm b3IgbmVnb3RpYXRpb24gb2YgYWx0ZXJuYXRpdmUNCj4+IGNyeXB0b2dyYXBoaWMgYWxnb3JpdGht cyB0byBwcm90ZWN0IFJBRElVUy4NCj4+IA0KPj4gLUlFRUUgODAyIGF0dHJpYnV0ZXMuIE5ldyBh dHRyaWJ1dGVzIGhhdmUgYmVlbiBwcm9wb3NlZCB0byBzdXBwb3J0IElFRUUNCj4+IDgwMiBzdGFu ZGFyZHMgZm9yIHdpcmVkIGFuZCB3aXJlbGVzcyBMQU5zLiBUaGlzIHdvcmsgaXRlbSB3aWxsIHN1 cHBvcnQNCj4+IGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIGF0 dHJpYnV0ZXMgbmVlZGVkIGJ5IElFRUUgODAyDQo+PiBncm91cHMgaW5jbHVkaW5nIElFRUUgODAy LjEsIElFRUUgODAyLjExIGFuZCBJRUVFIDgwMi4xNi4NCj4+IA0KPj4gLSBOZXcgUkFESVVTIHRy YW5zcG9ydHMuIEEgcmVsaWFibGUgdHJhbnNwb3J0IHByb2ZpbGUgZm9yIFJBRElVUyB3aWxsIGJl DQo+PiBkZXZlbG9wZWQsIGFzIHdlbGwgYXMgc3BlY2lmaWNhdGlvbnMgZm9yIFNlY3VyZSB0cmFu c3BvcnRzLCBpbmNsdWRpbmcNCj4+IFRDUC9UTFMgKFJBRFNFQykgYW5kIFVEUC9EVExTLg0KPj4g DQo+PiAtIERvY3VtZW50YXRpb24gb2YgU3RhdHVzLVNlcnZlciB1c2FnZS4gQSBkb2N1bWVudCBk ZXNjcmliaW5nIHVzYWdlIG9mIHRoZQ0KPj4gU3RhdHVzLVNlcnZlciBmYWNpbGl0eSB3aWxsIGJl IGRldmVsb3BlZC4NCj4+IA0KPj4gLSBVcGRhdGUgYW5kIGNsYXJpZmljYXRpb24gb2YgTmV0d29y ayBBY2Nlc3MgSWRlbnRpZmllcnMgKFJGQzQyODIpLlRoaXMNCj4+IHdvcmsgaXRlbSB3aWxsIGNv cnJlY3QgYW5kIGNsYXJpZnkgZWdyZWdpb3VzIGlzc3VlcyBwcmVzZW50IHdpdGggUkZDNDI4Mg0K Pj4gaW4gdHdvIHBoYXNlcy4gIEluIGZpcnN0IHBoYXNlLCBSRkM0MjgyYmlzIHdpbGwgYmUgaXNz dWVkIHRvIGVsaW1pbmF0ZQ0KPj4gZnVuZGFtZW50YWwgaW5jb21wYXRpYmlsaXRpZXMgd2l0aCBS QURJVVMgYXJvdW5kIGNoYXJhY3RlciBlbmNvZGluZyBhbmQNCj4+IE5BSSBtb2RpZmljYXRpb25z IGJ5IHByb3hpZXMuICBJbiBzZWNvbmQgcGhhc2UsIGEgZnJlc2ggcmV2aWV3IG9mIE5BSQ0KPj4g aW50ZXJuYXRpb25hbGl6YXRpb24gcmVxdWlyZW1lbnRzIGFuZCBiZWhhdmlvciB3aWxsIGJlIHVu ZGVydGFrZW4gd2l0aCBhDQo+PiBjbGVhciBnb2FsIG9mIG1haW50YWluaW5nIGNvbXBhdGliaWxp dHkgd2l0aCBSQURJVVMuDQo+PiANCj4+IEdvYWxzIGFuZCBNaWxlc3RvbmVzDQo+PiBEb25lICAg ICAgICBVcGRhdGVzIHRvIFJGQyAyNjE4LTI2MjEgUkFESVVTIE1JQnMgc3VibWl0dGVkIGZvciBw dWJsaWNhdGlvbg0KPj4gRG9uZSAgICAgICAgU0lQIFJBRElVUyBhdXRoZW50aWNhdGlvbiBkcmFm dCBzdWJtaXR0ZWQgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCj4+IERvbmUgICAgICAgIFJG QyAyNDg2YmlzIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KPj4gRG9uZSAg ICAgICAgUkZDIDM1NzYgTUlCcyBzdWJtaXR0ZWQgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMNCj4+ IERvbmUgICAgICAgIFJBRElVUyBWTEFOIGFuZCBQcmlvcml0eSBBdHRyaWJ1dGVzIGRyYWZ0IHN1 Ym1pdHRlZCBhcyBhIFByb3Bvc2VkDQo+PiBTdGFuZGFyZCBSRkMgKHJlZHVjZWQgaW4gc2NvcGUp DQo+PiBEb25lICAgICAgICBSQURJVVMgSW1wbGVtZW50YXRpb24gSXNzdWVzIGFuZCBGaXhlcyBk cmFmdCBzdWJtaXR0ZWQgYXMgYW4NCj4+IEluZm9ybWF0aW9uYWwgUkZDDQo+PiBEb25lICAgICAg ICBSQURJVVMgRmlsdGVyaW5nIEF0dHJpYnV0ZXMgZHJhZnQgc3VibWl0dGVkIGFzIGEgUHJvcG9z ZWQgU3RhbmRhcmQNCj4+IFJGQyAoc3BsaXQgb3V0IGZyb20gVkxBTiAmIFByaW9yaXR5IGRyYWZ0 KQ0KPj4gRG9uZSAgICAgICAgUkZDIDM1NzZiaXMgc3VibWl0dGVkIGFzIGFuIEluZm9ybWF0aW9u YWwgUkZDIChzcGxpdCBvdXQgZnJvbSBJc3N1ZXMNCj4+ICYgRml4ZXMgZHJhZnQpDQo+PiBEb25l ICAgICAgICBSQURJVVMgUmVkaXJlY3Rpb24gQXR0cmlidXRlcyBkcmFmdCBzdWJtaXR0ZWQgYXMg YSBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gUkZDIChzcGxpdCBvdXQgZnJvbSBWTEFOICYgUHJpb3Jp dHkgZHJhZnQpDQo+PiBEb25lICAgICAgICBSQURJVVMgRGVzaWduIEd1aWRlbGluZXMgc3VibWl0 dGVkIGFzIGEgQmVzdCBDdXJyZW50IFByYWN0aWNlIFJGQw0KPj4gRG9uZSAgICAgICAgUkFESVVT IE1hbmFnZW1lbnQgQXV0aG9yaXphdGlvbiBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3Rh bmRhcmQNCj4+IFJGQw0KPj4gRG9uZSAgICAgICAgUmVsaWFibGUgVHJhbnNwb3J0IFByb2ZpbGUg Zm9yIFJBRElVUyBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQNCj4+IFN0YW5kYXJkIFJGQw0K Pj4gRG9uZSAgICAgICAgU3RhdHVzLVNlcnZlciBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQg U3RhbmRhcmQgUkZDDQo+PiBEb25lICAgICAgICBSQURJVVMgQ3J5cHRvLWFnaWxpdHkgUmVxdWly ZW1lbnRzIHN1Ym1pdHRlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KPj4gSmFuIDIwMTIgICAg UkFEU0VDIChSQURJVVMgb3ZlciBUQ1AvVExTKSBkcmFmdCBzdWJtaXR0ZWQgYXMgYW4gRXhwZXJp bWVudGFsDQo+PiBSRkMNCj4+IEZlYiAyMDEyICAgIElQdjYgQWNjZXNzIEktRCBzdWJtaXR0ZWQg YXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCj4+IEZlYiAyMDEyICAgIEV4dGVuZGVkIEF0dHJp YnV0ZXMgSS1EIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KPj4gRmViIDIw MTIgICAgRHluYW1pYyBEaXNjb3ZlcnkgSS1EIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5k YXJkIFJGQw0KPj4gTWFyIDIwMTIgICAgUkZDIDQyODJiaXMgc3VibWl0dGVkIGFzIGEgUHJvcG9z ZWQgU3RhbmRhcmQgUkZDDQo+PiBNYXIgMjAxMiAgICBSQURJVVMgb3ZlciBEVExTIEktRCBzdWJt aXR0ZWQgYXMgYW4gRXhwZXJpbWVudGFsIFJGQw0KPj4gQXByIDIwMTIgICAgSUVFRSA4MDIgQXR0 cmlidXRlcyBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDDQo+PiBPY3Qg MjAxMiAgICBSQURJVVMgc3VwcG9ydCBmb3IgTkFJIEludGVybmF0aW9uYWxpemF0aW9uIEktRCBz dWJtaXR0ZWQgYXMgYQ0KPj4gUHJvcG9zZWQgU3RhbmRhcmQgUkZDIA0KPj4gDQo+PiANCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gcmFkZXh0 IG1haWxpbmcgbGlzdA0KPj4gcmFkZXh0QGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcmFkZXh0DQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4+IHJh ZGV4dEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y YWRleHQNCj4gDQo+IA0KPiAtLSANCj4gU3RlZmFuIFdJTlRFUg0KPiBJbmdlbmlldXIgZGUgUmVj aGVyY2hlDQo+IEZvbmRhdGlvbiBSRVNURU5BIC0gUqimc2VhdSBUqKZsqKZpbmZvcm1hdGlxdWUg ZGUgbCdFZHVjYXRpb24gTmF0aW9uYWxlIGV0DQo+IGRlIGxhIFJlY2hlcmNoZQ0KPiA2LCBydWUg UmljaGFyZCBDb3VkZW5ob3ZlLUthbGVyZ2kNCj4gTC0xMzU5IEx1eGVtYm91cmcNCj4gDQo+IFRl bDogKzM1MiA0MjQ0MDkgMQ0KPiBGYXg6ICszNTIgNDIyNDczDQo+IA0K From radext-bounces@ietf.org Mon Jan 23 23:11:25 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221CE21F8601; Mon, 23 Jan 2012 23:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327389085; bh=4Is7vKYg4W9PH4cdHxBUcPqtfXyV2CF0t3lyCgqU7VY=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=kIkjjveRIxiSQpyjSr0VjEdiJeLIdS+/dm/XVyH/d80cls0fNL2tI2QOp2OxaAix9 OViKTXvW2rLgQQVMQaVv/XpJQtTgZyq4teBfZP5yKB6xmSLL+3ZsVwWIVgqqT5EmSF 6hRU6wP14jkpYd7nd+bETh1yxK0N5KiM4ETcwBDk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534F521F8601 for ; Mon, 23 Jan 2012 23:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.476 X-Spam-Level: X-Spam-Status: No, score=-4.476 tagged_above=-999 required=5 tests=[AWL=-2.080, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWJAf7YxXqLD for ; Mon, 23 Jan 2012 23:11:23 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2F21F85FD for ; Mon, 23 Jan 2012 23:11:23 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYA0086PJYRVK@szxga05-in.huawei.com> for radext@ietf.org; Tue, 24 Jan 2012 15:11:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYA003CQJYRWP@szxga05-in.huawei.com> for radext@ietf.org; Tue, 24 Jan 2012 15:11:15 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGM61799; Tue, 24 Jan 2012 15:11:14 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jan 2012 15:10:57 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Tue, 24 Jan 2012 15:11:29 +0800 Date: Tue, 24 Jan 2012 07:11:07 +0000 From: Tina TSOU In-reply-to: <4F1E5725.1030205@restena.lu> To: Stefan Winter Message-id: MIME-version: 1.0 Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [radext] RADEXT recharter Thread-index: AczaG/xDKiJT9gNoRwm22tOW8sfaJP//fhaAgACPqICAAIj4cw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F1E5725.1030205@restena.lu> Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org DQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCk9uIEphbiAyMywgMjAxMiwgYXQgMTE6MDEgUE0sICJT dGVmYW4gV2ludGVyIiA8c3RlZmFuLndpbnRlckByZXN0ZW5hLmx1PiB3cm90ZToNCg0KPiBIaSwN Cj4gDQo+PiBMb29rcyBnb29kIHRvIG1lLiAgSGFzbid0IHRoZSBSQURJVVMgb3ZlciBUTFMgZHJh ZnQgYWxyZWFkeSBiZWVuDQo+PiBzdWJtaXR0ZWQ/IChpdCdzIGluIElFVEYgTEMpDQo+IA0KPiBS ZWxhdGVkOiBSQURJVVMvVExTIHdpbGwgYmUgRXhwZXJpbWVudGFsLCB3aGlsZSBEeW5hbWljIERp c2NvdmVyeSBpcw0KPiBza2V0Y2hlZCBhcyBQcm9wb3NlZCBTdGFuZGFyZC4gVGhlIGR5bmFtaWMg ZGlzY292ZXJ5IGRyYWZ0IGhhcw0KPiBSQURJVVMvVExTIGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5j ZS4NCj4gSSdtIG5vdCBlbnRpcmVseSBzdXJlIGFib3V0IHRoZSBwcm9jZXNzLCBidXQgLSBpcyBp dCBva2F5IGZvciBTdGFuZGFyZHMNCj4gdHJhY2sgdG8gaGF2ZSBhIG5vcm1hdGl2ZSByZWZlcmVu Y2Ugb24gRXhwZXJpbWVudGFsPw0KSW4gdGhlb3J5LCB5ZXMuDQo+IA0KPiBBbHNvLCBGZWIgMjAx MiBmb3Igc3VibWlzc2lvbiBzZWVtcyBhIGJpdCB0b28gYW1iaXRpb3VzIGZvciBtZS4gSSB3aWxs DQo+IGNlcnRhaW5seSBpc3N1ZSBhIG5ldyByZXYgYmVmb3JlIFBhcmlzLCBidXQgaXQgd2lsbCBu ZWVkIFdHTEMgZXRjLiBzbyBJDQo+IGRvbid0IHNlZSBob3cgRmViIDIwMTIgY291bGQgYmUgYWNo aWV2YWJsZS4gSSdtIHRoaW5raW5nIEFwcmlsIGF0IHRoZQ0KPiBlYXJsaWVzdC4NCj4gDQo+IChJ ZiB3ZSBhaW0gdG8gYXBwcm92ZSB0aGUgbmV3IGNoYXJ0ZXIgYnkgUGFyaXMsIGl0IHdpbGwgYWxy ZWFkeSBiZQ0KPiBNYXJjaDsgc2VlbXMgb2RkIHRoYXQgd2Ugd2lsbCBoYXZlIHRvIGRpc2N1c3Mg ZGF0ZXMgaW4gdGhlIHBhc3QgdGhlbikNCj4gDQo+IEdyZWV0aW5ncywNCj4gDQo+IFN0ZWZhbiBX aW50ZXINCj4gDQo+PiBGcm9tOiBtYXVyaWNpby5zYW5jaGV6QGhwLmNvbQ0KPj4gVG86IHJhZGV4 dEBpZXRmLm9yZw0KPj4gRGF0ZTogTW9uLCAyMyBKYW4gMjAxMiAyMjoxMToyMiArMDAwMA0KPj4g U3ViamVjdDogW3JhZGV4dF0gUkFERVhUIHJlY2hhcnRlcg0KPj4gDQo+PiBBdCBJRVRGIDgyLCB0 aGUgUkFERVhUIFdHIGRpc2N1c3NlZCAoc2VlIG5vdGVzIHNlY3Rpb24gNw0KPj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9taW51dGVzL3JhZGV4dC50eHQpIHVwZGF0aW5nIHRo ZQ0KPj4gY2hhcnRlciB0byBwb3NpdGlvbiB0aGUgV0cgdG8gYmUgYWJsZSB0byBlbWJyYWNlIHNl dmVyYWwgd29yayBpdGVtcyB0aGF0DQo+PiB0aGUgV0cgYmVsaWV2ZXMgcmVsZXZhbnQsIGFzIHdl bGwgYXMgcmVjYWxpYnJhdGluZyBkYXRlcyBvbiBzZXZlcmFsDQo+PiBjb21taXR0ZWQgZ29hbHMu ICANCj4+IA0KPj4gQmVsb3cgaXMgdGhlIG5ldyBwcm9wb3NlZCBXRyBjaGFydGVyIHRoYXQgeW91 ciBjaGFpcnMgYW5kIEFEIGFncmVlZCB1cG9uLg0KPj4gQXR0YWNoZWQgYXJlIGEgUERGIHZlcnNp b24gb2YgdXBkYXRlZCBtaWxlc3RvbmVzIGFuZCBhIG1hcmtlZCB2ZXJzaW9uDQo+PiBkZXRhaWxp bmcgY2hhbmdlcyBpbnRyb2R1Y2VkIGZyb20gZXhpc3RpbmcgY2hhcnRlci4gQXQgdGhpcyB0aW1l IHRoZQ0KPj4gY2hhaXJzIHdvdWxkIGxpa2UgdG8gb3BlbiB1cCB0aGUgbGlzdCBmb3IgZGlzY3Vz c2lvbi4gUHJvcG9zZSB5b3VyIGNoYW5nZXMNCj4+IGFuZCBqdXN0aWZ5IHdoeS4gIA0KPj4gDQo+ PiBPdXIgYWltIGlzIHRvIGhhdmUgdGhpcyByZS1jaGFydGVyaW5nIGRpc2N1c3Npb24gY29tcGxl dGVkIGJ5IG5leHQgSUVURg0KPj4gbWVldGluZy4gIA0KPj4gDQo+PiAtIE1hdXJpY2lvIGFuZCBK b3VuaQ0KPj4gICAgDQo+PiANCj4+IC0tLS0tLS0tLQ0KPj4gDQo+PiBEZXNjcmlwdGlvbiBvZiBX b3JraW5nIEdyb3VwDQo+PiANCj4+IFRoZSBSQURJVVMgRXh0ZW5zaW9ucyBXb3JraW5nIEdyb3Vw IHdpbGwgZm9jdXMgb24gZXh0ZW5zaW9ucyB0byB0aGUgUkFESVVTDQo+PiBwcm90b2NvbCByZXF1 aXJlZCB0byBleHBhbmQgYW5kIGVucmljaCB0aGUgc3RhbmRhcmQgYXR0cmlidXRlIHNwYWNlLA0K Pj4gYWRkcmVzcyBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBhZ2lsaXR5LCB1c2Ugb2YgbmV3IHNl Y3VyZSB0cmFuc3BvcnRzIGFuZA0KPj4gY2xhcmlmeSBpdHMgdXNhZ2UgYW5kIGRlZmluaXRpb24u DQo+PiANCj4+IEluIG9yZGVyIHRvIGVuYWJsZSBpbnRlcm9wZXJhdGlvbiBvZiBoZXRlcm9nZW5l b3VzIFJBRElVUy9EaWFtZXRlcg0KPj4gZGVwbG95bWVudHMsIGFsbCBSQURFWFQgV0cgd29yayBp dGVtcyBNVVNUIGNvbnRhaW4gYSBEaWFtZXRlcg0KPj4gY29tcGF0aWJpbGl0eSBzZWN0aW9uLCBv dXRsaW5pbmcgaG93IGludGVyb3BlcmFiaWxpdHkgd2l0aCBEaWFtZXRlciB3aWxsDQo+PiBiZSBt YWludGFpbmVkLg0KPj4gRnVydGhlcm1vcmUsIHRvIGVuc3VyZSBiYWNrd2FyZCBjb21wYXRpYmls aXR5IHdpdGggZXhpc3RpbmcgUkFESVVTDQo+PiBpbXBsZW1lbnRhdGlvbnMsIGFzIHdlbGwgYXMg Y29tcGF0aWJpbGl0eSBiZXR3ZWVuIFJBRElVUyBhbmQgRGlhbWV0ZXIsIHRoZQ0KPj4gZm9sbG93 aW5nIHJlc3RyaWN0aW9ucyBhcmUgaW1wb3NlZCBvbiBleHRlbnNpb25zIGNvbnNpZGVyZWQgYnkg dGhlIFJBREVYVA0KPj4gV0c6DQo+PiANCj4+IC0gQWxsIGRvY3VtZW50cyBwcm9kdWNlZCBNVVNU IHNwZWNpZnkgbWVhbnMgb2YgaW50ZXJvcGVyYXRpb24gd2l0aCBsZWdhY3kNCj4+IFJBRElVUyBh bmQsIGlmIHBvc3NpYmxlLCBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgUkFE SVVTIFJGQ3MsDQo+PiBpbmNsdWRpbmcgUkZDcyAyODY1LTI4NjksIDMxNjIsIDM1NzUsIDM1Nzks IDM1ODAsIDQ2NjgtNDY3Myw0Njc1LCA1MDgwLA0KPj4gNTA5MCBhbmQgNTE3Ni4gVHJhbnNwb3J0 IHByb2ZpbGVzIHNob3VsZCwgaWYgcG9zc2libGUsIGJlIGNvbXBhdGlibGUgd2l0aA0KPj4gUkZD IDM1MzkuDQo+PiANCj4+IC0gQWxsIFJBRElVUyB3b3JrIE1VU1QgYmUgY29tcGF0aWJsZSB3aXRo IGVxdWl2YWxlbnQgZmFjaWxpdGllcyBpbg0KPj4gRGlhbWV0ZXIuIFdoZXJlIHBvc3NpYmxlLCBu ZXcgYXR0cmlidXRlcyBzaG91bGQgYmUgZGVmaW5lZCBzbyB0aGF0IHRoZQ0KPj4gc2FtZSBhdHRy aWJ1dGUgY2FuIGJlIHVzZWQgaW4gYm90aCBSQURJVVMgYW5kIERpYW1ldGVyIHdpdGhvdXQNCj4+ IHRyYW5zbGF0aW9uLiBJbiBvdGhlciBjYXNlcyBhIHRyYW5zbGF0aW9uIGNvbnNpZGVyYXRpb25z IHNlY3Rpb24gc2hvdWxkIGJlDQo+PiBpbmNsdWRlZCBpbiB0aGUgc3BlY2lmaWNhdGlvbi4NCj4+ IA0KPj4gV29yayBJdGVtcw0KPj4gVGhlIGltbWVkaWF0ZSBnb2FscyBvZiB0aGUgUkFERVhUIHdv cmtpbmcgZ3JvdXAgYXJlIHRvIGFkZHJlc3MgdGhlDQo+PiBmb2xsb3dpbmcgaXNzdWVzOg0KPj4g DQo+PiAtUkFESVVTIGRlc2lnbiBndWlkZWxpbmVzLiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlk ZSBndWlkZWxpbmVzIGZvcg0KPj4gZGVzaWduIG9mIFJBRElVUyBhdHRyaWJ1dGVzLiBJdCB3aWxs IHNwZWNpZmljYWxseSBjb25zaWRlciBob3cgY29tcGxleA0KPj4gZGF0YSB0eXBlcyBtYXkgYmUg aW50cm9kdWNlZCBpbiBhIHJvYnVzdCBtYW5uZXIsIG1haW50YWluaW5nIGJhY2t3YXJkcw0KPj4g Y29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5nIFJBRElVUyBSRkNzLCBhY3Jvc3MgYWxsIHRoZSBj bGFzc2VzIG9mDQo+PiBhdHRyaWJ1dGVzOiBTdGFuZGFyZCwgVmVuZG9yLVNwZWNpZmljIGFuZCBT RE8tU3BlY2lmaWMuIEluIGFkZGl0aW9uLCBpdA0KPj4gd2lsbCByZXZpZXcgUkFESVVTIGRhdGEg dHlwZXMgYW5kIGFzc29jaWF0ZWQgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkNCj4+IGlzc3Vlcy4N Cj4+IA0KPj4gLVJBRElVUyBNYW5hZ2VtZW50IGF1dGhvcml6YXRpb24uIFRoaXMgZG9jdW1lbnQg d2lsbCBkZWZpbmUgdGhlIHVzZSBvZg0KPj4gUkFESVVTIGZvciBOQVMgbWFuYWdlbWVudCBvdmVy IElQLg0KPj4gDQo+PiAtUkFESVVTIGF0dHJpYnV0ZSBzcGFjZSBleHRlbnNpb24uIFRoZSBzdGFu ZGFyZCBSQURJVVMgYXR0cmlidXRlIHNwYWNlIGlzDQo+PiBjdXJyZW50bHkgYmVpbmcgZGVwbGV0 ZWQuIFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGFkZGl0aW9uYWwgc3RhbmRhcmQNCj4+IGF0 dHJpYnV0ZSBzcGFjZSwgd2hpbGUgbWFpbnRhaW5pbmcgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3 aXRoIGV4aXN0aW5nDQo+PiBhdHRyaWJ1dGVzLg0KPj4gDQo+PiAtUkFESVVTIENyeXB0b2dyYXBo aWMgQWxnb3JpdGhtIEFnaWxpdHkuIFJBRElVUyBoYXMgdHJhZGl0aW9uYWxseSByZWxpZWQNCj4+ IG9uIE1ENSBmb3IgYm90aCBwZXItcGFja2V0IGludGVncml0eSBhbmQgYXV0aGVudGljYXRpb24g YXMgd2VsbCBhcw0KPj4gYXR0cmlidXRlIGNvbmZpZGVudGlhbGl0eS4gR2l2ZW4gdGhlIGluY3Jl YXNpbmdseSBzdWNjZXNzZnVsIGF0dGFja3MgYmVpbmcNCj4+IG1vdW50ZWQgYWdhaW5zdCBNRDUs IHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcyBpcw0KPj4gcmVx dWlyZWQuIFRoaXMgd29yayBpdGVtIHdpbGwgaW5jbHVkZSBkb2N1bWVudGF0aW9uIG9mIFJBRElV Uw0KPj4gY3J5cHRvLWFnaWxpdHkgcmVxdWlyZW1lbnRzLCBhcyB3ZWxsIGFzIGRldmVsb3BtZW50 IG9mIG9uZSBvciBtb3JlDQo+PiBFeHBlcmltZW50YWwgUkZDcyBwcm92aWRpbmcgc3VwcG9ydCBm b3IgbmVnb3RpYXRpb24gb2YgYWx0ZXJuYXRpdmUNCj4+IGNyeXB0b2dyYXBoaWMgYWxnb3JpdGht cyB0byBwcm90ZWN0IFJBRElVUy4NCj4+IA0KPj4gLUlFRUUgODAyIGF0dHJpYnV0ZXMuIE5ldyBh dHRyaWJ1dGVzIGhhdmUgYmVlbiBwcm9wb3NlZCB0byBzdXBwb3J0IElFRUUNCj4+IDgwMiBzdGFu ZGFyZHMgZm9yIHdpcmVkIGFuZCB3aXJlbGVzcyBMQU5zLiBUaGlzIHdvcmsgaXRlbSB3aWxsIHN1 cHBvcnQNCj4+IGF1dGhlbnRpY2F0aW9uLCBhdXRob3JpemF0aW9uIGFuZCBhY2NvdW50aW5nIGF0 dHJpYnV0ZXMgbmVlZGVkIGJ5IElFRUUgODAyDQo+PiBncm91cHMgaW5jbHVkaW5nIElFRUUgODAy LjEsIElFRUUgODAyLjExIGFuZCBJRUVFIDgwMi4xNi4NCj4+IA0KPj4gLSBOZXcgUkFESVVTIHRy YW5zcG9ydHMuIEEgcmVsaWFibGUgdHJhbnNwb3J0IHByb2ZpbGUgZm9yIFJBRElVUyB3aWxsIGJl DQo+PiBkZXZlbG9wZWQsIGFzIHdlbGwgYXMgc3BlY2lmaWNhdGlvbnMgZm9yIFNlY3VyZSB0cmFu c3BvcnRzLCBpbmNsdWRpbmcNCj4+IFRDUC9UTFMgKFJBRFNFQykgYW5kIFVEUC9EVExTLg0KPj4g DQo+PiAtIERvY3VtZW50YXRpb24gb2YgU3RhdHVzLVNlcnZlciB1c2FnZS4gQSBkb2N1bWVudCBk ZXNjcmliaW5nIHVzYWdlIG9mIHRoZQ0KPj4gU3RhdHVzLVNlcnZlciBmYWNpbGl0eSB3aWxsIGJl IGRldmVsb3BlZC4NCj4+IA0KPj4gLSBVcGRhdGUgYW5kIGNsYXJpZmljYXRpb24gb2YgTmV0d29y ayBBY2Nlc3MgSWRlbnRpZmllcnMgKFJGQzQyODIpLlRoaXMNCj4+IHdvcmsgaXRlbSB3aWxsIGNv cnJlY3QgYW5kIGNsYXJpZnkgZWdyZWdpb3VzIGlzc3VlcyBwcmVzZW50IHdpdGggUkZDNDI4Mg0K Pj4gaW4gdHdvIHBoYXNlcy4gIEluIGZpcnN0IHBoYXNlLCBSRkM0MjgyYmlzIHdpbGwgYmUgaXNz dWVkIHRvIGVsaW1pbmF0ZQ0KPj4gZnVuZGFtZW50YWwgaW5jb21wYXRpYmlsaXRpZXMgd2l0aCBS QURJVVMgYXJvdW5kIGNoYXJhY3RlciBlbmNvZGluZyBhbmQNCj4+IE5BSSBtb2RpZmljYXRpb25z IGJ5IHByb3hpZXMuICBJbiBzZWNvbmQgcGhhc2UsIGEgZnJlc2ggcmV2aWV3IG9mIE5BSQ0KPj4g aW50ZXJuYXRpb25hbGl6YXRpb24gcmVxdWlyZW1lbnRzIGFuZCBiZWhhdmlvciB3aWxsIGJlIHVu ZGVydGFrZW4gd2l0aCBhDQo+PiBjbGVhciBnb2FsIG9mIG1haW50YWluaW5nIGNvbXBhdGliaWxp dHkgd2l0aCBSQURJVVMuDQo+PiANCj4+IEdvYWxzIGFuZCBNaWxlc3RvbmVzDQo+PiBEb25lICAg ICAgICBVcGRhdGVzIHRvIFJGQyAyNjE4LTI2MjEgUkFESVVTIE1JQnMgc3VibWl0dGVkIGZvciBw dWJsaWNhdGlvbg0KPj4gRG9uZSAgICAgICAgU0lQIFJBRElVUyBhdXRoZW50aWNhdGlvbiBkcmFm dCBzdWJtaXR0ZWQgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCj4+IERvbmUgICAgICAgIFJG QyAyNDg2YmlzIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KPj4gRG9uZSAg ICAgICAgUkZDIDM1NzYgTUlCcyBzdWJtaXR0ZWQgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkMNCj4+ IERvbmUgICAgICAgIFJBRElVUyBWTEFOIGFuZCBQcmlvcml0eSBBdHRyaWJ1dGVzIGRyYWZ0IHN1 Ym1pdHRlZCBhcyBhIFByb3Bvc2VkDQo+PiBTdGFuZGFyZCBSRkMgKHJlZHVjZWQgaW4gc2NvcGUp DQo+PiBEb25lICAgICAgICBSQURJVVMgSW1wbGVtZW50YXRpb24gSXNzdWVzIGFuZCBGaXhlcyBk cmFmdCBzdWJtaXR0ZWQgYXMgYW4NCj4+IEluZm9ybWF0aW9uYWwgUkZDDQo+PiBEb25lICAgICAg ICBSQURJVVMgRmlsdGVyaW5nIEF0dHJpYnV0ZXMgZHJhZnQgc3VibWl0dGVkIGFzIGEgUHJvcG9z ZWQgU3RhbmRhcmQNCj4+IFJGQyAoc3BsaXQgb3V0IGZyb20gVkxBTiAmIFByaW9yaXR5IGRyYWZ0 KQ0KPj4gRG9uZSAgICAgICAgUkZDIDM1NzZiaXMgc3VibWl0dGVkIGFzIGFuIEluZm9ybWF0aW9u YWwgUkZDIChzcGxpdCBvdXQgZnJvbSBJc3N1ZXMNCj4+ICYgRml4ZXMgZHJhZnQpDQo+PiBEb25l ICAgICAgICBSQURJVVMgUmVkaXJlY3Rpb24gQXR0cmlidXRlcyBkcmFmdCBzdWJtaXR0ZWQgYXMg YSBQcm9wb3NlZCBTdGFuZGFyZA0KPj4gUkZDIChzcGxpdCBvdXQgZnJvbSBWTEFOICYgUHJpb3Jp dHkgZHJhZnQpDQo+PiBEb25lICAgICAgICBSQURJVVMgRGVzaWduIEd1aWRlbGluZXMgc3VibWl0 dGVkIGFzIGEgQmVzdCBDdXJyZW50IFByYWN0aWNlIFJGQw0KPj4gRG9uZSAgICAgICAgUkFESVVT IE1hbmFnZW1lbnQgQXV0aG9yaXphdGlvbiBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3Rh bmRhcmQNCj4+IFJGQw0KPj4gRG9uZSAgICAgICAgUmVsaWFibGUgVHJhbnNwb3J0IFByb2ZpbGUg Zm9yIFJBRElVUyBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQNCj4+IFN0YW5kYXJkIFJGQw0K Pj4gRG9uZSAgICAgICAgU3RhdHVzLVNlcnZlciBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQg U3RhbmRhcmQgUkZDDQo+PiBEb25lICAgICAgICBSQURJVVMgQ3J5cHRvLWFnaWxpdHkgUmVxdWly ZW1lbnRzIHN1Ym1pdHRlZCBhcyBhbiBJbmZvcm1hdGlvbmFsIFJGQw0KPj4gSmFuIDIwMTIgICAg UkFEU0VDIChSQURJVVMgb3ZlciBUQ1AvVExTKSBkcmFmdCBzdWJtaXR0ZWQgYXMgYW4gRXhwZXJp bWVudGFsDQo+PiBSRkMNCj4+IEZlYiAyMDEyICAgIElQdjYgQWNjZXNzIEktRCBzdWJtaXR0ZWQg YXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMNCj4+IEZlYiAyMDEyICAgIEV4dGVuZGVkIEF0dHJp YnV0ZXMgSS1EIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQw0KPj4gRmViIDIw MTIgICAgRHluYW1pYyBEaXNjb3ZlcnkgSS1EIHN1Ym1pdHRlZCBhcyBhIFByb3Bvc2VkIFN0YW5k YXJkIFJGQw0KPj4gTWFyIDIwMTIgICAgUkZDIDQyODJiaXMgc3VibWl0dGVkIGFzIGEgUHJvcG9z ZWQgU3RhbmRhcmQgUkZDDQo+PiBNYXIgMjAxMiAgICBSQURJVVMgb3ZlciBEVExTIEktRCBzdWJt aXR0ZWQgYXMgYW4gRXhwZXJpbWVudGFsIFJGQw0KPj4gQXByIDIwMTIgICAgSUVFRSA4MDIgQXR0 cmlidXRlcyBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDDQo+PiBPY3Qg MjAxMiAgICBSQURJVVMgc3VwcG9ydCBmb3IgTkFJIEludGVybmF0aW9uYWxpemF0aW9uIEktRCBz dWJtaXR0ZWQgYXMgYQ0KPj4gUHJvcG9zZWQgU3RhbmRhcmQgUkZDIA0KPj4gDQo+PiANCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gcmFkZXh0 IG1haWxpbmcgbGlzdA0KPj4gcmFkZXh0QGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcmFkZXh0DQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHJhZGV4dCBtYWlsaW5nIGxpc3QNCj4+IHJh ZGV4dEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y YWRleHQNCj4gDQo+IA0KPiAtLSANCj4gU3RlZmFuIFdJTlRFUg0KPiBJbmdlbmlldXIgZGUgUmVj aGVyY2hlDQo+IEZvbmRhdGlvbiBSRVNURU5BIC0gUqimc2VhdSBUqKZsqKZpbmZvcm1hdGlxdWUg ZGUgbCdFZHVjYXRpb24gTmF0aW9uYWxlIGV0DQo+IGRlIGxhIFJlY2hlcmNoZQ0KPiA2LCBydWUg UmljaGFyZCBDb3VkZW5ob3ZlLUthbGVyZ2kNCj4gTC0xMzU5IEx1eGVtYm91cmcNCj4gDQo+IFRl bDogKzM1MiA0MjQ0MDkgMQ0KPiBGYXg6ICszNTIgNDIyNDczDQo+IA0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcmFkZXh0IG1haWxpbmcgbGlzdApyYWRl eHRAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yYWRleHQK From radext-bounces@ietf.org Tue Jan 24 00:05:58 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBC621F85D0; Tue, 24 Jan 2012 00:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327392358; bh=EQlwswm8Mh1CRtr71y5GnOKBLFv4VvZKPSUF5F24L4A=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mZjGOnhC9mN/DgwDSrDgkhiwjZw7zHGlpGjR3SaLQkJx7yj71Jf72ElairPKJxo5E lXJBL3zZpzNg/DW2EnKRJ3LW8TGG1bVr6PToEFHZorECpoijTf5kae44nNapZofOEg wJ1rwIZv5eMAiId7iyEw0nt6XnDzrufewTVUBVOo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DBB21F85D0 for ; Tue, 24 Jan 2012 00:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNYoldm3eAFy for ; Tue, 24 Jan 2012 00:05:55 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8233C21F85CD for ; Tue, 24 Jan 2012 00:05:55 -0800 (PST) Message-ID: <4F1E6646.9090709@deployingradius.com> Date: Tue, 24 Jan 2012 09:05:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > On Mon, 23 Jan 2012, Alan DeKok wrote: >>> Says who? >> Says the extensions draft. > > My impression the goal was backwards compatibility with systems > predating the extensions draft to at least inject or forward unknown > attributes. In this case text of the extensions draft has no "say". It > didn't exist when these systems were deployed. No. You can't have it both ways. Your example was a new format VSA inserted in the middle of a fragmented new format VSA: >>> This means if I started a fragment with vendor id 4444 and before >>> finishing that fragment start a new fragment with vendor id 3333 Any implementation which does that is in violation of this draft. > You brought up EAP as evidence my concerns are without merit. I pointed > out there are important differences between EAP and extensions which > limit the applicability of this analogy. I responded to that. Since you ignored it, here it is again: RFC 2865 says nothing about EAP packets. It's perfectly legal under RFC 2865 to insert one instance of attribute 79 in the middle of a list of attribute 79's. It's the same thing. Proxies which are UNAWARE of EAP are permitted by RFC 2865 to mangle EAP. This is EXACTLY your argument against this draft. If your best proof is to ignore my counter-arguments, then I think we're done here. >> Doing so will break EAP. So by your argument, adding EAP to RADIUS >> is impossible. > > RFC 3579 dictates how EAP-Message may be used. EAP-Message is not > defined anywhere else. Addressed. See above. > The important distinction not accounted for in your analogy is > extensions further constrains allowed behavior of existing RFCs. If you > do this there are consequences with regard to backward compatibility as > existing implementations can not be made retroactively aware of > additional constraints. Addressed. See above. >> There's also RFC 5904, which defines two more attributes that can span >> multiple RADIUS attributes. > > My EAP caution applies here as well. There is only one cert per message > of a specific attribute type allowed. My EAP response appears above. Limitations in RFCs I haven't read and haven't implemented don't apply to me. >> I don't see it as a valid objection. It's based on assumptions which >> have proven to be false for a decade. > > I don't follow what was proven false? Because you deleted my argument. See above. >> Let's discard RFC 2869 because it's "Informational" and RFC 2865 is >> "Standards Track". 2869 CLEARLY VIOLATES 2865. Then, we'll deploy an >> RFC 2865 compliant RADIUS proxy. We'll have it mangle attribute 79 as >> per your argument. It's allowed under 2865. It's exactly your > > See above for my thoughts on this EAP-Message analogy. Nope. You haven't addressed my point. Your counterpoint was to point at RFC 3579. I haven't read it. I've only read 2865, and implemented proxies based on that. I've assigned attribute 79 as my own personal VSA, just like people have done with 241..245. I've decided to mangle lists of attribute 79. This is allowed under 2865. Now explain to me how that's different from your arguments against this draft. In response, use only 2865. Don't use 2869 or 3579. Don't refer to any real-world experience with the non-EAP/EAP transition. You can't have it both ways. You're arguing against this draft by pretending it doesn't exist. You're arguing for EAP by referring to the EAP specs. You're ignoring my counter-argument which uses EXACTLY your method to prove it's impossible to deploy EAP. If you're applying a certain standard, apply it the same way everywhere. It's not nice to apply it to me, and then give yourself an exemption. > I have on multiple occasions stated I don't care about perfect backwards > compatibility. My goal is simply providing a good chance of detecting > the presence of errors. Make a concrete proposal. And address my points on EAP, without referring to any EAP RFC. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Jan 24 00:05:56 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DBB21F85D0 for ; Tue, 24 Jan 2012 00:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNYoldm3eAFy for ; Tue, 24 Jan 2012 00:05:55 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 8233C21F85CD for ; Tue, 24 Jan 2012 00:05:55 -0800 (PST) Message-ID: <4F1E6646.9090709@deployingradius.com> Date: Tue, 24 Jan 2012 09:05:26 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 08:05:56 -0000 Peter Deacon wrote: > On Mon, 23 Jan 2012, Alan DeKok wrote: >>> Says who? >> Says the extensions draft. > > My impression the goal was backwards compatibility with systems > predating the extensions draft to at least inject or forward unknown > attributes. In this case text of the extensions draft has no "say". It > didn't exist when these systems were deployed. No. You can't have it both ways. Your example was a new format VSA inserted in the middle of a fragmented new format VSA: >>> This means if I started a fragment with vendor id 4444 and before >>> finishing that fragment start a new fragment with vendor id 3333 Any implementation which does that is in violation of this draft. > You brought up EAP as evidence my concerns are without merit. I pointed > out there are important differences between EAP and extensions which > limit the applicability of this analogy. I responded to that. Since you ignored it, here it is again: RFC 2865 says nothing about EAP packets. It's perfectly legal under RFC 2865 to insert one instance of attribute 79 in the middle of a list of attribute 79's. It's the same thing. Proxies which are UNAWARE of EAP are permitted by RFC 2865 to mangle EAP. This is EXACTLY your argument against this draft. If your best proof is to ignore my counter-arguments, then I think we're done here. >> Doing so will break EAP. So by your argument, adding EAP to RADIUS >> is impossible. > > RFC 3579 dictates how EAP-Message may be used. EAP-Message is not > defined anywhere else. Addressed. See above. > The important distinction not accounted for in your analogy is > extensions further constrains allowed behavior of existing RFCs. If you > do this there are consequences with regard to backward compatibility as > existing implementations can not be made retroactively aware of > additional constraints. Addressed. See above. >> There's also RFC 5904, which defines two more attributes that can span >> multiple RADIUS attributes. > > My EAP caution applies here as well. There is only one cert per message > of a specific attribute type allowed. My EAP response appears above. Limitations in RFCs I haven't read and haven't implemented don't apply to me. >> I don't see it as a valid objection. It's based on assumptions which >> have proven to be false for a decade. > > I don't follow what was proven false? Because you deleted my argument. See above. >> Let's discard RFC 2869 because it's "Informational" and RFC 2865 is >> "Standards Track". 2869 CLEARLY VIOLATES 2865. Then, we'll deploy an >> RFC 2865 compliant RADIUS proxy. We'll have it mangle attribute 79 as >> per your argument. It's allowed under 2865. It's exactly your > > See above for my thoughts on this EAP-Message analogy. Nope. You haven't addressed my point. Your counterpoint was to point at RFC 3579. I haven't read it. I've only read 2865, and implemented proxies based on that. I've assigned attribute 79 as my own personal VSA, just like people have done with 241..245. I've decided to mangle lists of attribute 79. This is allowed under 2865. Now explain to me how that's different from your arguments against this draft. In response, use only 2865. Don't use 2869 or 3579. Don't refer to any real-world experience with the non-EAP/EAP transition. You can't have it both ways. You're arguing against this draft by pretending it doesn't exist. You're arguing for EAP by referring to the EAP specs. You're ignoring my counter-argument which uses EXACTLY your method to prove it's impossible to deploy EAP. If you're applying a certain standard, apply it the same way everywhere. It's not nice to apply it to me, and then give yourself an exemption. > I have on multiple occasions stated I don't care about perfect backwards > compatibility. My goal is simply providing a good chance of detecting > the presence of errors. Make a concrete proposal. And address my points on EAP, without referring to any EAP RFC. Alan DeKok. From radext-bounces@ietf.org Tue Jan 24 03:52:21 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E713621F84BF; Tue, 24 Jan 2012 03:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327405940; bh=2wXqQ8flCNZM6VBXj5XDZn8ts2kvgGEAcckFqvs6fEU=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=x+1XGRgnPk2FAC71HzcP/sTNYcXypAk+5JGhHRLrGg6vZAvDFenB/c10qGdbG0G7d Em04NQ5COhwm5IdGIryx0uKfQ4DY0aNzYkU8/F3O07uGZY/4M3RKIbk6VuKuq8W2T4 +Ni9qn5dJENP0RgO+dZgd+rHD/fHuFVNnHs+qrNo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDF021F84BF for ; Tue, 24 Jan 2012 03:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.328 X-Spam-Level: X-Spam-Status: No, score=-103.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk7Y6Rnyh6Lv for ; Tue, 24 Jan 2012 03:52:19 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 450BC21F84BD for ; Tue, 24 Jan 2012 03:52:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFSaHk+HCzI1/2dsb2JhbABCri2BBYFyAQEBAQMBAQEJBh4+FwQCAQgNBAMBAQELBgwLAQYBJh8JCAEBBAESCAELAgyHYp1Dmz6JAQIDASIDI4JrgQYcglBjBIgMkwmMVw X-IronPort-AV: E=Sophos;i="4.71,561,1320642000"; d="scan'208";a="326132314" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Jan 2012 06:52:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2012 06:38:40 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jan 2012 12:52:16 +0100 Message-ID: In-Reply-To: <4F1E5725.1030205@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADEXT recharter Thread-Index: AczaZfGkwKl4IY93QvueTCImu7++YgAJ6ltQ References: <4F1E5725.1030205@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi, A normative document referencing an Experimental RFC is a downref. Although= it is recommended to avoid them to the possible extent, they can be approv= ed if the community agrees, or in other terms of they are explicitly spelle= d out during the IETF Last Call. = A list of downrefs and a few more details on the procedures can be found at= http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Stefan Winter > Sent: Tuesday, January 24, 2012 9:01 AM > To: radext@ietf.org > Subject: Re: [radext] RADEXT recharter > = > Hi, > = > > Looks good to me. Hasn't the RADIUS over TLS draft already been > > submitted? (it's in IETF LC) > = > Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is > sketched as Proposed Standard. The dynamic discovery draft has > RADIUS/TLS as a normative reference. > I'm not entirely sure about the process, but - is it okay for Standards > track to have a normative reference on Experimental? > = > Also, Feb 2012 for submission seems a bit too ambitious for me. I will > certainly issue a new rev before Paris, but it will need WGLC etc. so I > don't see how Feb 2012 could be achievable. I'm thinking April at the > earliest. > = > (If we aim to approve the new charter by Paris, it will already be > March; seems odd that we will have to discuss dates in the past then) > = > Greetings, > = > Stefan Winter > = > > From: mauricio.sanchez@hp.com > > To: radext@ietf.org > > Date: Mon, 23 Jan 2012 22:11:22 +0000 > > Subject: [radext] RADEXT recharter > > > > At IETF 82, the RADEXT WG discussed (see notes section 7 > > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > > charter to position the WG to be able to embrace several work items > > that the WG believes relevant, as well as recalibrating dates on > > several committed goals. > > > > Below is the new proposed WG charter that your chairs and AD agreed > upon. > > Attached are a PDF version of updated milestones and a marked version > > detailing changes introduced from existing charter. At this time the > > chairs would like to open up the list for discussion. Propose your > > changes and justify why. > > > > Our aim is to have this re-chartering discussion completed by next > > IETF meeting. > > > > - Mauricio and Jouni > > > > > > --------- > > > > Description of Working Group > > > > The RADIUS Extensions Working Group will focus on extensions to the > > RADIUS protocol required to expand and enrich the standard attribute > > space, address cryptographic algorithm agility, use of new secure > > transports and clarify its usage and definition. > > > > In order to enable interoperation of heterogeneous RADIUS/Diameter > > deployments, all RADEXT WG work items MUST contain a Diameter > > compatibility section, outlining how interoperability with Diameter > > will be maintained. > > Furthermore, to ensure backward compatibility with existing RADIUS > > implementations, as well as compatibility between RADIUS and > Diameter, > > the following restrictions are imposed on extensions considered by > the > > RADEXT > > WG: > > > > - All documents produced MUST specify means of interoperation with > > legacy RADIUS and, if possible, be backward compatible with existing > > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, > > 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if > > possible, be compatible with RFC 3539. > > > > - All RADIUS work MUST be compatible with equivalent facilities in > > Diameter. Where possible, new attributes should be defined so that > the > > same attribute can be used in both RADIUS and Diameter without > > translation. In other cases a translation considerations section > > should be included in the specification. > > > > Work Items > > The immediate goals of the RADEXT working group are to address the > > following issues: > > > > -RADIUS design guidelines. This document will provide guidelines for > > design of RADIUS attributes. It will specifically consider how > complex > > data types may be introduced in a robust manner, maintaining > backwards > > compatibility with existing RADIUS RFCs, across all the classes of > > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, > > it will review RADIUS data types and associated backwards > > compatibility issues. > > > > -RADIUS Management authorization. This document will define the use > of > > RADIUS for NAS management over IP. > > > > -RADIUS attribute space extension. The standard RADIUS attribute > space > > is currently being depleted. This document will provide additional > > standard attribute space, while maintaining backward compatibility > > with existing attributes. > > > > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally > > relied on MD5 for both per-packet integrity and authentication as > well > > as attribute confidentiality. Given the increasingly successful > > attacks being mounted against MD5, the ability to support alternative > > algorithms is required. This work item will include documentation of > > RADIUS crypto-agility requirements, as well as development of one or > > more Experimental RFCs providing support for negotiation of > > alternative cryptographic algorithms to protect RADIUS. > > > > -IEEE 802 attributes. New attributes have been proposed to support > > IEEE > > 802 standards for wired and wireless LANs. This work item will > support > > authentication, authorization and accounting attributes needed by > IEEE > > 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > > > - New RADIUS transports. A reliable transport profile for RADIUS will > > be developed, as well as specifications for Secure transports, > > including TCP/TLS (RADSEC) and UDP/DTLS. > > > > - Documentation of Status-Server usage. A document describing usage > of > > the Status-Server facility will be developed. > > > > - Update and clarification of Network Access Identifiers > > (RFC4282).This work item will correct and clarify egregious issues > > present with RFC4282 in two phases. In first phase, RFC4282bis will > > be issued to eliminate fundamental incompatibilities with RADIUS > > around character encoding and NAI modifications by proxies. In > second > > phase, a fresh review of NAI internationalization requirements and > > behavior will be undertaken with a clear goal of maintaining > compatibility with RADIUS. > > > > Goals and Milestones > > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for > publication > > Done SIP RADIUS authentication draft submitted as a > Proposed Standard RFC > > Done RFC 2486bis submitted as a Proposed Standard RFC > > Done RFC 3576 MIBs submitted as an Informational RFC > > Done RADIUS VLAN and Priority Attributes draft submitted > as a Proposed > > Standard RFC (reduced in scope) > > Done RADIUS Implementation Issues and Fixes draft > submitted as an > > Informational RFC > > Done RADIUS Filtering Attributes draft submitted as a > Proposed Standard > > RFC (split out from VLAN & Priority draft) > > Done RFC 3576bis submitted as an Informational RFC (split > out from Issues > > & Fixes draft) > > Done RADIUS Redirection Attributes draft submitted as a > Proposed Standard > > RFC (split out from VLAN & Priority draft) > > Done RADIUS Design Guidelines submitted as a Best Current > Practice RFC > > Done RADIUS Management Authorization I-D submitted as a > Proposed Standard > > RFC > > Done Reliable Transport Profile for RADIUS I-D submitted > as a Proposed > > Standard RFC > > Done Status-Server I-D submitted as a Proposed Standard > RFC > > Done RADIUS Crypto-agility Requirements submitted as an > Informational RFC > > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an > Experimental > > RFC > > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard > RFC > > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard > RFC > > Oct 2012 RADIUS support for NAI Internationalization I-D submitted > as a > > Proposed Standard RFC > > > > > > > > _______________________________________________ radext mailing list > > radext@ietf.org https://www.ietf.org/mailman/listinfo/radext > > > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > = > = > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > = > Tel: +352 424409 1 > Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dromasca@avaya.com Tue Jan 24 03:52:20 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDF021F84BF for ; Tue, 24 Jan 2012 03:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.328 X-Spam-Level: X-Spam-Status: No, score=-103.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk7Y6Rnyh6Lv for ; Tue, 24 Jan 2012 03:52:19 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 450BC21F84BD for ; Tue, 24 Jan 2012 03:52:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFSaHk+HCzI1/2dsb2JhbABCri2BBYFyAQEBAQMBAQEJBh4+FwQCAQgNBAMBAQELBgwLAQYBJh8JCAEBBAESCAELAgyHYp1Dmz6JAQIDASIDI4JrgQYcglBjBIgMkwmMVw X-IronPort-AV: E=Sophos;i="4.71,561,1320642000"; d="scan'208";a="326132314" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Jan 2012 06:52:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2012 06:38:40 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2012 12:52:16 +0100 Message-ID: In-Reply-To: <4F1E5725.1030205@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADEXT recharter Thread-Index: AczaZfGkwKl4IY93QvueTCImu7++YgAJ6ltQ References: <4F1E5725.1030205@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 11:52:20 -0000 Hi, A normative document referencing an Experimental RFC is a downref. = Although it is recommended to avoid them to the possible extent, they = can be approved if the community agrees, or in other terms of they are = explicitly spelled out during the IETF Last Call.=20 A list of downrefs and a few more details on the procedures can be found = at http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Stefan Winter > Sent: Tuesday, January 24, 2012 9:01 AM > To: radext@ietf.org > Subject: Re: [radext] RADEXT recharter >=20 > Hi, >=20 > > Looks good to me. Hasn't the RADIUS over TLS draft already been > > submitted? (it's in IETF LC) >=20 > Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is > sketched as Proposed Standard. The dynamic discovery draft has > RADIUS/TLS as a normative reference. > I'm not entirely sure about the process, but - is it okay for = Standards > track to have a normative reference on Experimental? >=20 > Also, Feb 2012 for submission seems a bit too ambitious for me. I will > certainly issue a new rev before Paris, but it will need WGLC etc. so = I > don't see how Feb 2012 could be achievable. I'm thinking April at the > earliest. >=20 > (If we aim to approve the new charter by Paris, it will already be > March; seems odd that we will have to discuss dates in the past then) >=20 > Greetings, >=20 > Stefan Winter >=20 > > From: mauricio.sanchez@hp.com > > To: radext@ietf.org > > Date: Mon, 23 Jan 2012 22:11:22 +0000 > > Subject: [radext] RADEXT recharter > > > > At IETF 82, the RADEXT WG discussed (see notes section 7 > > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > > charter to position the WG to be able to embrace several work items > > that the WG believes relevant, as well as recalibrating dates on > > several committed goals. > > > > Below is the new proposed WG charter that your chairs and AD agreed > upon. > > Attached are a PDF version of updated milestones and a marked = version > > detailing changes introduced from existing charter. At this time the > > chairs would like to open up the list for discussion. Propose your > > changes and justify why. > > > > Our aim is to have this re-chartering discussion completed by next > > IETF meeting. > > > > - Mauricio and Jouni > > > > > > --------- > > > > Description of Working Group > > > > The RADIUS Extensions Working Group will focus on extensions to the > > RADIUS protocol required to expand and enrich the standard attribute > > space, address cryptographic algorithm agility, use of new secure > > transports and clarify its usage and definition. > > > > In order to enable interoperation of heterogeneous RADIUS/Diameter > > deployments, all RADEXT WG work items MUST contain a Diameter > > compatibility section, outlining how interoperability with Diameter > > will be maintained. > > Furthermore, to ensure backward compatibility with existing RADIUS > > implementations, as well as compatibility between RADIUS and > Diameter, > > the following restrictions are imposed on extensions considered by > the > > RADEXT > > WG: > > > > - All documents produced MUST specify means of interoperation with > > legacy RADIUS and, if possible, be backward compatible with existing > > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, > > 4668-4673,4675, 5080, 5090 and 5176. Transport profiles should, if > > possible, be compatible with RFC 3539. > > > > - All RADIUS work MUST be compatible with equivalent facilities in > > Diameter. Where possible, new attributes should be defined so that > the > > same attribute can be used in both RADIUS and Diameter without > > translation. In other cases a translation considerations section > > should be included in the specification. > > > > Work Items > > The immediate goals of the RADEXT working group are to address the > > following issues: > > > > -RADIUS design guidelines. This document will provide guidelines for > > design of RADIUS attributes. It will specifically consider how > complex > > data types may be introduced in a robust manner, maintaining > backwards > > compatibility with existing RADIUS RFCs, across all the classes of > > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, > > it will review RADIUS data types and associated backwards > > compatibility issues. > > > > -RADIUS Management authorization. This document will define the use > of > > RADIUS for NAS management over IP. > > > > -RADIUS attribute space extension. The standard RADIUS attribute > space > > is currently being depleted. This document will provide additional > > standard attribute space, while maintaining backward compatibility > > with existing attributes. > > > > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally > > relied on MD5 for both per-packet integrity and authentication as > well > > as attribute confidentiality. Given the increasingly successful > > attacks being mounted against MD5, the ability to support = alternative > > algorithms is required. This work item will include documentation of > > RADIUS crypto-agility requirements, as well as development of one or > > more Experimental RFCs providing support for negotiation of > > alternative cryptographic algorithms to protect RADIUS. > > > > -IEEE 802 attributes. New attributes have been proposed to support > > IEEE > > 802 standards for wired and wireless LANs. This work item will > support > > authentication, authorization and accounting attributes needed by > IEEE > > 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > > > - New RADIUS transports. A reliable transport profile for RADIUS = will > > be developed, as well as specifications for Secure transports, > > including TCP/TLS (RADSEC) and UDP/DTLS. > > > > - Documentation of Status-Server usage. A document describing usage > of > > the Status-Server facility will be developed. > > > > - Update and clarification of Network Access Identifiers > > (RFC4282).This work item will correct and clarify egregious issues > > present with RFC4282 in two phases. In first phase, RFC4282bis will > > be issued to eliminate fundamental incompatibilities with RADIUS > > around character encoding and NAI modifications by proxies. In > second > > phase, a fresh review of NAI internationalization requirements and > > behavior will be undertaken with a clear goal of maintaining > compatibility with RADIUS. > > > > Goals and Milestones > > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for > publication > > Done SIP RADIUS authentication draft submitted as a > Proposed Standard RFC > > Done RFC 2486bis submitted as a Proposed Standard RFC > > Done RFC 3576 MIBs submitted as an Informational RFC > > Done RADIUS VLAN and Priority Attributes draft submitted > as a Proposed > > Standard RFC (reduced in scope) > > Done RADIUS Implementation Issues and Fixes draft > submitted as an > > Informational RFC > > Done RADIUS Filtering Attributes draft submitted as a > Proposed Standard > > RFC (split out from VLAN & Priority draft) > > Done RFC 3576bis submitted as an Informational RFC (split > out from Issues > > & Fixes draft) > > Done RADIUS Redirection Attributes draft submitted as a > Proposed Standard > > RFC (split out from VLAN & Priority draft) > > Done RADIUS Design Guidelines submitted as a Best Current > Practice RFC > > Done RADIUS Management Authorization I-D submitted as a > Proposed Standard > > RFC > > Done Reliable Transport Profile for RADIUS I-D submitted > as a Proposed > > Standard RFC > > Done Status-Server I-D submitted as a Proposed Standard > RFC > > Done RADIUS Crypto-agility Requirements submitted as an > Informational RFC > > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an > Experimental > > RFC > > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard > RFC > > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard > RFC > > Oct 2012 RADIUS support for NAI Internationalization I-D submitted > as a > > Proposed Standard RFC > > > > > > > > _______________________________________________ radext mailing list > > radext@ietf.org https://www.ietf.org/mailman/listinfo/radext > > > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From radext-bounces@ietf.org Tue Jan 24 03:58:47 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698CE21F8504; Tue, 24 Jan 2012 03:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327406327; bh=VRtHEbxdoQHUGMw5aZ0buMoh1Wi/QUo+yQrnfcYyNzQ=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=REckNOVn3+toDwBy4LAWLXHd0AMmZ4hI6jGwFyTosvSjTwXFNt0Sr03WZ0oMa6qm8 C5NMuJxkwYH0hghgBsaru7wYv6ki7i3WHZT5B71AjxO8q3abBnY2MlCo/H1tWkNhqI UzY8jyUjWHL3L/+MoQJ/J8e3mVgG1DkUe6eUxlrU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FB421F8504 for ; Tue, 24 Jan 2012 03:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu2c9ejaookN for ; Tue, 24 Jan 2012 03:58:45 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE621F8503 for ; Tue, 24 Jan 2012 03:58:45 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1F5BE20378; Tue, 24 Jan 2012 06:57:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B18B84690; Tue, 24 Jan 2012 06:58:39 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <4F1E5725.1030205@restena.lu> Date: Tue, 24 Jan 2012 06:58:39 -0500 In-Reply-To: <4F1E5725.1030205@restena.lu> (Stefan Winter's message of "Tue, 24 Jan 2012 08:00:53 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: radext@ietf.org Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> Looks good to me. Hasn't the RADIUS over TLS draft already been >> submitted? (it's in IETF LC) Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic Stefan> Discovery is sketched as Proposed Standard. The dynamic Stefan> discovery draft has RADIUS/TLS as a normative reference. Stefan> I'm not entirely sure about the process, but - is it okay Stefan> for Standards track to have a normative reference on Stefan> Experimental? There is a procedure for doing this, but I don't understand why it is appropriate in this instance. In my mind the dynamic discovery stuff is far more experimental than RADIUS over TLS. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Tue Jan 24 03:58:45 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FB421F8504 for ; Tue, 24 Jan 2012 03:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu2c9ejaookN for ; Tue, 24 Jan 2012 03:58:45 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE621F8503 for ; Tue, 24 Jan 2012 03:58:45 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1F5BE20378; Tue, 24 Jan 2012 06:57:54 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B18B84690; Tue, 24 Jan 2012 06:58:39 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <4F1E5725.1030205@restena.lu> Date: Tue, 24 Jan 2012 06:58:39 -0500 In-Reply-To: <4F1E5725.1030205@restena.lu> (Stefan Winter's message of "Tue, 24 Jan 2012 08:00:53 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 11:58:46 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> Looks good to me. Hasn't the RADIUS over TLS draft already been >> submitted? (it's in IETF LC) Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic Stefan> Discovery is sketched as Proposed Standard. The dynamic Stefan> discovery draft has RADIUS/TLS as a normative reference. Stefan> I'm not entirely sure about the process, but - is it okay Stefan> for Standards track to have a normative reference on Stefan> Experimental? There is a procedure for doing this, but I don't understand why it is appropriate in this instance. In my mind the dynamic discovery stuff is far more experimental than RADIUS over TLS. From dromasca@avaya.com Tue Jan 24 04:21:15 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A7421F8566 for ; Tue, 24 Jan 2012 04:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4PlcdlkxP0t for ; Tue, 24 Jan 2012 04:21:15 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF621F8562 for ; Tue, 24 Jan 2012 04:21:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOigHk+HCzI1/2dsb2JhbABCri2BBYFyAQEBAQMSHgpLBAIBCA0EBAEBCwYMCwEGAUUJCAEBBAESCAEZh2KdPps7iSkDIwiCY4EGHIJQYwSbFYxX X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="287764523" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jan 2012 07:21:12 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2012 07:07:33 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jan 2012 13:21:08 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADEXT recharter Thread-Index: AczaG/xDKiJT9gNoRwm22tOW8sfaJAAdk5+w References: From: "Romascanu, Dan (Dan)" To: "Sanchez, Mauricio (HP Networking)" , Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:21:15 -0000 Hi, As Dave Nelson already pointed out, two of the documents in the charter were already approved as RFCs. Also the milestones need to be revisited in case the discussions of this new charter continue until IETF-83 (end of March 2012) because most of them target January - March 2012.=20 Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Sanchez, Mauricio (HP Networking) > Sent: Tuesday, January 24, 2012 12:11 AM > To: radext@ietf.org > Subject: [radext] RADEXT recharter >=20 > At IETF 82, the RADEXT WG discussed (see notes section 7 > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > charter to position the WG to be able to embrace several work items > that the WG believes relevant, as well as recalibrating dates on > several committed goals. >=20 > Below is the new proposed WG charter that your chairs and AD agreed > upon. > Attached are a PDF version of updated milestones and a marked version > detailing changes introduced from existing charter. At this time the > chairs would like to open up the list for discussion. Propose your > changes and justify why. >=20 > Our aim is to have this re-chartering discussion completed by next IETF > meeting. >=20 > - Mauricio and Jouni >=20 >=20 > --------- >=20 > Description of Working Group >=20 > The RADIUS Extensions Working Group will focus on extensions to the > RADIUS protocol required to expand and enrich the standard attribute > space, address cryptographic algorithm agility, use of new secure > transports and clarify its usage and definition. >=20 > In order to enable interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability with Diameter > will be maintained. > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and Diameter, > the following restrictions are imposed on extensions considered by the > RADEXT > WG: >=20 > - All documents produced MUST specify means of interoperation with > legacy RADIUS and, if possible, be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668- > 4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, > be compatible with RFC 3539. >=20 > - All RADIUS work MUST be compatible with equivalent facilities in > Diameter. Where possible, new attributes should be defined so that the > same attribute can be used in both RADIUS and Diameter without > translation. In other cases a translation considerations section should > be included in the specification. >=20 > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: >=20 > -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it > will review RADIUS data types and associated backwards compatibility > issues. >=20 > -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. >=20 > -RADIUS attribute space extension. The standard RADIUS attribute space > is currently being depleted. This document will provide additional > standard attribute space, while maintaining backward compatibility with > existing attributes. >=20 > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally > relied on MD5 for both per-packet integrity and authentication as well > as attribute confidentiality. Given the increasingly successful attacks > being mounted against MD5, the ability to support alternative > algorithms is required. This work item will include documentation of > RADIUS crypto-agility requirements, as well as development of one or > more Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. >=20 > -IEEE 802 attributes. New attributes have been proposed to support IEEE > 802 standards for wired and wireless LANs. This work item will support > authentication, authorization and accounting attributes needed by IEEE > 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. >=20 > - New RADIUS transports. A reliable transport profile for RADIUS will > be developed, as well as specifications for Secure transports, > including TCP/TLS (RADSEC) and UDP/DTLS. >=20 > - Documentation of Status-Server usage. A document describing usage of > the Status-Server facility will be developed. >=20 > - Update and clarification of Network Access Identifiers (RFC4282).This > work item will correct and clarify egregious issues present with > RFC4282 in two phases. In first phase, RFC4282bis will be issued to > eliminate fundamental incompatibilities with RADIUS around character > encoding and NAI modifications by proxies. In second phase, a fresh > review of NAI internationalization requirements and behavior will be > undertaken with a clear goal of maintaining compatibility with RADIUS. >=20 > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for > publication > Done SIP RADIUS authentication draft submitted as a Proposed > Standard RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a > Proposed > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as > an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out > from Issues > & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current > Practice RFC > Done RADIUS Management Authorization I-D submitted as a Proposed > Standard > RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a > Proposed > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an > Informational RFC > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an > Experimental > RFC > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard > RFC > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard > RFC > Oct 2012 RADIUS support for NAI Internationalization I-D submitted > as a > Proposed Standard RFC From radext-bounces@ietf.org Tue Jan 24 04:21:16 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B1221F8566; Tue, 24 Jan 2012 04:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327407676; bh=DgbKZSbIQqAlNBkJri02RlDPrHh6hJFjNxJsPmPl/60=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=mh9pGVt6TrnQdKu7wOmiC1J10kGX/y698CgUH2sjuohfFtgZEJRZeaI79qDGlHNGt WOY+RQ3VNSWZ6oRtR2xjZrdVKOI2kAV77man/8k8V9zlA5DnxTtjyXFq7K+cGhhH5c FRzShlWtfc89b+m4kb1rGgoVPPo+ofYEWQyF8M/I= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A7421F8566 for ; Tue, 24 Jan 2012 04:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4PlcdlkxP0t for ; Tue, 24 Jan 2012 04:21:15 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 75FF621F8562 for ; Tue, 24 Jan 2012 04:21:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOigHk+HCzI1/2dsb2JhbABCri2BBYFyAQEBAQMSHgpLBAIBCA0EBAEBCwYMCwEGAUUJCAEBBAESCAEZh2KdPps7iSkDIwiCY4EGHIJQYwSbFYxX X-IronPort-AV: E=Sophos;i="4.71,562,1320642000"; d="scan'208";a="287764523" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jan 2012 07:21:12 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2012 07:07:33 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jan 2012 13:21:08 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] RADEXT recharter Thread-Index: AczaG/xDKiJT9gNoRwm22tOW8sfaJAAdk5+w References: From: "Romascanu, Dan (Dan)" To: "Sanchez, Mauricio (HP Networking)" , Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi, As Dave Nelson already pointed out, two of the documents in the charter were already approved as RFCs. Also the milestones need to be revisited in case the discussions of this new charter continue until IETF-83 (end of March 2012) because most of them target January - March 2012. Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Sanchez, Mauricio (HP Networking) > Sent: Tuesday, January 24, 2012 12:11 AM > To: radext@ietf.org > Subject: [radext] RADEXT recharter > > At IETF 82, the RADEXT WG discussed (see notes section 7 > http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the > charter to position the WG to be able to embrace several work items > that the WG believes relevant, as well as recalibrating dates on > several committed goals. > > Below is the new proposed WG charter that your chairs and AD agreed > upon. > Attached are a PDF version of updated milestones and a marked version > detailing changes introduced from existing charter. At this time the > chairs would like to open up the list for discussion. Propose your > changes and justify why. > > Our aim is to have this re-chartering discussion completed by next IETF > meeting. > > - Mauricio and Jouni > > > --------- > > Description of Working Group > > The RADIUS Extensions Working Group will focus on extensions to the > RADIUS protocol required to expand and enrich the standard attribute > space, address cryptographic algorithm agility, use of new secure > transports and clarify its usage and definition. > > In order to enable interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items MUST contain a Diameter > compatibility section, outlining how interoperability with Diameter > will be maintained. > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and Diameter, > the following restrictions are imposed on extensions considered by the > RADEXT > WG: > > - All documents produced MUST specify means of interoperation with > legacy RADIUS and, if possible, be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668- > 4673,4675, 5080, 5090 and 5176. Transport profiles should, if possible, > be compatible with RFC 3539. > > - All RADIUS work MUST be compatible with equivalent facilities in > Diameter. Where possible, new attributes should be defined so that the > same attribute can be used in both RADIUS and Diameter without > translation. In other cases a translation considerations section should > be included in the specification. > > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: > > -RADIUS design guidelines. This document will provide guidelines for > design of RADIUS attributes. It will specifically consider how complex > data types may be introduced in a robust manner, maintaining backwards > compatibility with existing RADIUS RFCs, across all the classes of > attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it > will review RADIUS data types and associated backwards compatibility > issues. > > -RADIUS Management authorization. This document will define the use of > RADIUS for NAS management over IP. > > -RADIUS attribute space extension. The standard RADIUS attribute space > is currently being depleted. This document will provide additional > standard attribute space, while maintaining backward compatibility with > existing attributes. > > -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally > relied on MD5 for both per-packet integrity and authentication as well > as attribute confidentiality. Given the increasingly successful attacks > being mounted against MD5, the ability to support alternative > algorithms is required. This work item will include documentation of > RADIUS crypto-agility requirements, as well as development of one or > more Experimental RFCs providing support for negotiation of alternative > cryptographic algorithms to protect RADIUS. > > -IEEE 802 attributes. New attributes have been proposed to support IEEE > 802 standards for wired and wireless LANs. This work item will support > authentication, authorization and accounting attributes needed by IEEE > 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. A reliable transport profile for RADIUS will > be developed, as well as specifications for Secure transports, > including TCP/TLS (RADSEC) and UDP/DTLS. > > - Documentation of Status-Server usage. A document describing usage of > the Status-Server facility will be developed. > > - Update and clarification of Network Access Identifiers (RFC4282).This > work item will correct and clarify egregious issues present with > RFC4282 in two phases. In first phase, RFC4282bis will be issued to > eliminate fundamental incompatibilities with RADIUS around character > encoding and NAI modifications by proxies. In second phase, a fresh > review of NAI internationalization requirements and behavior will be > undertaken with a clear goal of maintaining compatibility with RADIUS. > > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for > publication > Done SIP RADIUS authentication draft submitted as a Proposed > Standard RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a > Proposed > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as > an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out > from Issues > & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed > Standard > RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current > Practice RFC > Done RADIUS Management Authorization I-D submitted as a Proposed > Standard > RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a > Proposed > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an > Informational RFC > Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an > Experimental > RFC > Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Feb 2012 Extended Attributes I-D submitted as a Proposed Standard > RFC > Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC > Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard > RFC > Oct 2012 RADIUS support for NAI Internationalization I-D submitted > as a > Proposed Standard RFC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dnelson@elbrys.com Tue Jan 24 05:07:41 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2964B21F854D for ; Tue, 24 Jan 2012 05:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4v9042hsH6L for ; Tue, 24 Jan 2012 05:07:40 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with SMTP id 45F3C21F859B for ; Tue, 24 Jan 2012 05:07:40 -0800 (PST) Received: from mail-vw0-f49.google.com ([209.85.212.49]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTx6tGxdZ6god83j8r76Rhr82/PERIbA/@postini.com; Tue, 24 Jan 2012 05:07:40 PST Received: by vbbff1 with SMTP id ff1so3678627vbb.36 for ; Tue, 24 Jan 2012 05:07:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.94.211 with SMTP id de19mr5839251vdb.98.1327410458941; Tue, 24 Jan 2012 05:07:38 -0800 (PST) Received: by 10.52.89.179 with HTTP; Tue, 24 Jan 2012 05:07:38 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Jan 2012 08:07:38 -0500 Message-ID: From: Dave Nelson To: "Romascanu, Dan (Dan)" X-Gm-Message-State: ALoCoQnf2RR88koU/hsb/NIMNnMhBSz3BtWEDNf/H0rID35cgaYBuX+//kvG43FnPXi+PvXvkDd7 Content-Type: multipart/alternative; boundary=20cf307cfec6e0576004b745d46f Cc: radext@ietf.org, "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:07:41 -0000 --20cf307cfec6e0576004b745d46f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 24, 2012 at 7:21 AM, Romascanu, Dan (Dan) wrote: > > As Dave Nelson already pointed out, two of the documents in the charter > were already approved as RFCs. By the time I finished composing my reply, I actually found four such RFCs: 5607, 5997, 6158, 6421. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf307cfec6e0576004b745d46f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 7:21 AM, Romascanu, Dan (Dan) <= ;dromasca@avaya.com> wr= ote:

As Dave Nelson already pointed out, two of the documents in the charter
were already approved as RFCs.

By the time I finished = composing my reply, I actually found four such RFCs: 5607, 5997, 6158, 6421= .

Regards,

Dave

David B. Nelson
Sr. Sof= tware Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf307cfec6e0576004b745d46f-- From radext-bounces@ietf.org Tue Jan 24 05:07:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5BA21F859F; Tue, 24 Jan 2012 05:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327410467; bh=N64AtImZQKF2409fOaxKeVoFmpKheTaBYwBzwcdnVpw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=w+hn3waXqB7Ml7zToCdUdHHUo5cu8aH+yPR268iisL6LB6x9Pju1ZsPuAC3Cxw9LQ vW7ZvihCE8VbfqpSx4dG7/MWdptM1kjJc7sd5cJ0fS2FYyhOX6nintmCsYgK94a0dQ 1IVtAaZjUewD8CU6fCirqQ9CN1YqtoJOLI0yh3dQ= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2964B21F854D for ; Tue, 24 Jan 2012 05:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4v9042hsH6L for ; Tue, 24 Jan 2012 05:07:40 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with SMTP id 45F3C21F859B for ; Tue, 24 Jan 2012 05:07:40 -0800 (PST) Received: from mail-vw0-f49.google.com ([209.85.212.49]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTx6tGxdZ6god83j8r76Rhr82/PERIbA/@postini.com; Tue, 24 Jan 2012 05:07:40 PST Received: by vbbff1 with SMTP id ff1so3678627vbb.36 for ; Tue, 24 Jan 2012 05:07:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.94.211 with SMTP id de19mr5839251vdb.98.1327410458941; Tue, 24 Jan 2012 05:07:38 -0800 (PST) Received: by 10.52.89.179 with HTTP; Tue, 24 Jan 2012 05:07:38 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Jan 2012 08:07:38 -0500 Message-ID: From: Dave Nelson To: "Romascanu, Dan (Dan)" X-Gm-Message-State: ALoCoQnf2RR88koU/hsb/NIMNnMhBSz3BtWEDNf/H0rID35cgaYBuX+//kvG43FnPXi+PvXvkDd7 Cc: radext@ietf.org, "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4204451143172190862==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============4204451143172190862== Content-Type: multipart/alternative; boundary=20cf307cfec6e0576004b745d46f --20cf307cfec6e0576004b745d46f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 24, 2012 at 7:21 AM, Romascanu, Dan (Dan) wrote: > > As Dave Nelson already pointed out, two of the documents in the charter > were already approved as RFCs. By the time I finished composing my reply, I actually found four such RFCs: 5607, 5997, 6158, 6421. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf307cfec6e0576004b745d46f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 7:21 AM, Romascanu, Dan (Dan) <= ;dromasca@avaya.com> wr= ote:

As Dave Nelson already pointed out, two of the documents in the charter
were already approved as RFCs.

By the time I finished = composing my reply, I actually found four such RFCs: 5607, 5997, 6158, 6421= .

Regards,

Dave

David B. Nelson
Sr. Sof= tware Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf307cfec6e0576004b745d46f-- --===============4204451143172190862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============4204451143172190862==-- From aland@deployingradius.com Tue Jan 24 06:04:44 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57421F8566 for ; Tue, 24 Jan 2012 06:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn05zyLs5uj9 for ; Tue, 24 Jan 2012 06:04:43 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9621F8565 for ; Tue, 24 Jan 2012 06:04:43 -0800 (PST) Message-ID: <4F1EBA5F.8070101@deployingradius.com> Date: Tue, 24 Jan 2012 15:04:15 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 14:04:44 -0000 Peter Deacon wrote: > I simply meant multiple EAP Packets are not actually sent in single > RADIUS Messages whereas with extensions it would be allowed and > expected. And again my response: systems which implement the draft are expected to be compliant with it. Adding something in the middle of a fragmented attribute is forbidden by this specification. So there's no problem. For systems *not* implementing this specification, see my previous arguments. > My issue is "implementations" are allowed to be conduits for data they > do not understand and there seem to be insufficient constraints in the > "protocol" to support extensions. See below. This has happened already with Operator-Name. > The key to understanding the difference per your query is a separation > of "protocol" from "implementation" and separation of protocol layers. Sure. RFC 3579 violates RFC 2865. But people can implement both, if they do things which are not mandated by 2865. Like *not* inserting attributes into a list of unknown attributes. Your argument is that the problem comes from a system which does not implement the extensions draft, but still edits the extension attributes. The eduroam consortium has done surveys of precisely this issue in relation to the Operator-Name attribute. This survey is discussed in the extensions draft. The *real world* problems seen with the erroneous use of attributes are: - filtering unknown attributes (i.e. deleting them from the packet) - truncating these attributes - discarding the request entirely All of these issues can be trivially discovered with the draft as-is. The systems which do this are in an absolute minority. They are *also* in the process of being updated to support Operator-Name. When that is done, they will also trivially support proxying the extensions attrs. All possible evidence leads me to conclude that inter-operation with legacy systems will have minimal problems. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type |M| Sequence | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Sequence > > When Value field of attribute is fragmented into multiple attributes the > first fragment having M flag set is set to 1 and increased by 1 with > each subsequent fragment including the final fragment where the M flag > is clear. > > If a Value field does not span multiple attributes the sequence field is > set to 1. > > When receiving fragmented attributes sequence field is checked to ensure > each fragment is received in the proper order. If there are gaps in > sequence numbers or fragments are out of order the attribute including > all fragments are discarded. An implementation MUST NOT attempt to > reorder attribute fragments based on sequence. That isn't enough. I can still take two fragmented attributes, and intermix them undetectable Take A1..A4, and B1..B4. Then, change them to A1,A2,B3,B4 and B1,B2,A3,A4. You're assuming that the implementation is aware of this draft, and chooses to violate it. So am I. If you assume that the implementation isn't aware of this draft, then the comments about eduroam apply. Alan DeKok. From radext-bounces@ietf.org Tue Jan 24 06:04:46 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09821F8566; Tue, 24 Jan 2012 06:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327413886; bh=+/iSkA4R7KHzzXw5MsJLSt1nLTJZ5aHNwOpNuLBgxKI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=daEmz4QP/UaQZK2kX3M3oF0Xf1BaztlqzJ3iDbpXuKIKZUSG040CY+jgrcTIRoKO6 vemQE1ojfZ4jEPXL0YvM2n5EbHUsbyWg2+2A36XnPCOzVHVIlI1h6pg9u9UkmIzR4o Kpnx7aS3E5xW0nwrC3s0njiJT0r9TbIvL5+681jk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57421F8566 for ; Tue, 24 Jan 2012 06:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xn05zyLs5uj9 for ; Tue, 24 Jan 2012 06:04:43 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 32A9621F8565 for ; Tue, 24 Jan 2012 06:04:43 -0800 (PST) Message-ID: <4F1EBA5F.8070101@deployingradius.com> Date: Tue, 24 Jan 2012 15:04:15 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > I simply meant multiple EAP Packets are not actually sent in single > RADIUS Messages whereas with extensions it would be allowed and > expected. And again my response: systems which implement the draft are expected to be compliant with it. Adding something in the middle of a fragmented attribute is forbidden by this specification. So there's no problem. For systems *not* implementing this specification, see my previous arguments. > My issue is "implementations" are allowed to be conduits for data they > do not understand and there seem to be insufficient constraints in the > "protocol" to support extensions. See below. This has happened already with Operator-Name. > The key to understanding the difference per your query is a separation > of "protocol" from "implementation" and separation of protocol layers. Sure. RFC 3579 violates RFC 2865. But people can implement both, if they do things which are not mandated by 2865. Like *not* inserting attributes into a list of unknown attributes. Your argument is that the problem comes from a system which does not implement the extensions draft, but still edits the extension attributes. The eduroam consortium has done surveys of precisely this issue in relation to the Operator-Name attribute. This survey is discussed in the extensions draft. The *real world* problems seen with the erroneous use of attributes are: - filtering unknown attributes (i.e. deleting them from the packet) - truncating these attributes - discarding the request entirely All of these issues can be trivially discovered with the draft as-is. The systems which do this are in an absolute minority. They are *also* in the process of being updated to support Operator-Name. When that is done, they will also trivially support proxying the extensions attrs. All possible evidence leads me to conclude that inter-operation with legacy systems will have minimal problems. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Extended-Type |M| Sequence | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Value ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Sequence > > When Value field of attribute is fragmented into multiple attributes the > first fragment having M flag set is set to 1 and increased by 1 with > each subsequent fragment including the final fragment where the M flag > is clear. > > If a Value field does not span multiple attributes the sequence field is > set to 1. > > When receiving fragmented attributes sequence field is checked to ensure > each fragment is received in the proper order. If there are gaps in > sequence numbers or fragments are out of order the attribute including > all fragments are discarded. An implementation MUST NOT attempt to > reorder attribute fragments based on sequence. That isn't enough. I can still take two fragmented attributes, and intermix them undetectable Take A1..A4, and B1..B4. Then, change them to A1,A2,B3,B4 and B1,B2,A3,A4. You're assuming that the implementation is aware of this draft, and chooses to violate it. So am I. If you assume that the implementation isn't aware of this draft, then the comments about eduroam apply. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Tue Jan 24 07:08:42 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059DB21F8671 for ; Tue, 24 Jan 2012 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZi+QT89FgDj for ; Tue, 24 Jan 2012 07:08:41 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E768921F8663 for ; Tue, 24 Jan 2012 07:08:39 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Jan 2012 04:08:03 -0800 Date: Tue, 24 Jan 2012 04:07:59 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1E6646.9090709@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:08:42 -0000 On Tue, 24 Jan 2012, Alan DeKok wrote: > No. You can't have it both ways. Your example was a new format VSA > inserted in the middle of a fragmented new format VSA: >> You brought up EAP as evidence my concerns are without merit. I pointed >> out there are important differences between EAP and extensions which >> limit the applicability of this analogy. > I responded to that. Since you ignored it, here it is again: > RFC 2865 says nothing about EAP packets. It's perfectly legal under > RFC 2865 to insert one instance of attribute 79 in the middle of a list > of attribute 79's. Your making an argument since EAP-Message can be inserted anywhere including at the start or end of the packet it breaks the EAP RFC but not RFC 2865. This is true. The same idea applies to extensions. If you add in the wrong place it breaks. RFC 2865 does not. > It's the same thing. Proxies which are UNAWARE of EAP are permitted by > RFC 2865 to mangle EAP. This is EXACTLY your argument against this > draft. RFC 2865 also says nothing about sending garbage in the Value field of attributes defined in other RFCs. > It's impossible to be fully compliant to the RADIUS RFCs. They are > contradictory, incomplete, and often plain wrong. This also seems to be true. (Cut from previous message) > If your best proof is to ignore my counter-arguments, then I think > we're done here. I agree with your argument of course it is true. My concern with this line of thinking is examples of broken RFCs and silly what-ifs can be used to justify pretty much anything no matter the consequences. They also ignore logical separation of "protocol" from "implementation". It is not enough to respond in the abstract. The unique details of each situation should be closely examined. This is where EAP-Message and Extensions diverge. You may view my argument as equally silly as the above and therefore no different than sending garbage Values or extra EAP-Messages and this is fine. When I said there was only one EAP Packet per RADIUS message it was a statement in terms of what actually occurs. I did not mean to imply that RFC 2865 prohibits all harmful effects or that something else couldn't throw a wrench into the works. I simply meant multiple EAP Packets are not actually sent in single RADIUS Messages whereas with extensions it would be allowed and expected. This was only intended to be a caution against assuming EAP-Message has the same issues and properties as extensions for the purpose of understanding potential risks from the perspective of what is observed with existing implementations. > Your counterpoint was to point at RFC 3579. I haven't read it. I've > only read 2865, and implemented proxies based on that. I've assigned > attribute 79 as my own personal VSA, just like people have done with > 241..245. I've decided to mangle lists of attribute 79. This is > allowed under 2865. > Now explain to me how that's different from your arguments against > this draft. In response, use only 2865. Don't use 2869 or 3579. Don't > refer to any real-world experience with the non-EAP/EAP transition. My issue is "implementations" are allowed to be conduits for data they do not understand and there seem to be insufficient constraints in the "protocol" to support extensions. As much as reasonable I believe extensions rather than "protocol" should be changed to attempt to correct the mismatch. The key to understanding the difference per your query is a separation of "protocol" from "implementation" and separation of protocol layers. Sending garbage values is an "implementation" concern. Interpreting attribute id's not defined in the "protocol" is not a protocol issue. Ordering constraints are defined in the "protocol". Allowing a protocol layered on top of an existing "protocol" to modify the properties of lower "protocol" is generally best avoided if possible. >> I have on multiple occasions stated I don't care about perfect backwards >> compatibility. My goal is simply providing a good chance of detecting >> the presence of errors. > Make a concrete proposal. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type |M| Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence When Value field of attribute is fragmented into multiple attributes the first fragment having M flag set is set to 1 and increased by 1 with each subsequent fragment including the final fragment where the M flag is clear. If a Value field does not span multiple attributes the sequence field is set to 1. When receiving fragmented attributes sequence field is checked to ensure each fragment is received in the proper order. If there are gaps in sequence numbers or fragments are out of order the attribute including all fragments are discarded. An implementation MUST NOT attempt to reorder attribute fragments based on sequence. regards, Peter From radext-bounces@ietf.org Tue Jan 24 07:08:43 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43F021F8663; Tue, 24 Jan 2012 07:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327417723; bh=6p/zKGXsVwFIAExFuaMLHFZSzenvRQGpDpS/gEGF674=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=QyoSaqawPrUgOuHyDsrzEuqNuevN3ENcIIvBdWBU5AX4r/pXuWQ5V5zdiyTnfR+7K qC9hjTove4zz3R5MtJ6TTRgGhAdkOD1n0veOLNp5CjayJCUxjwfL/5mXtj6tpDEcNg HVibhbarnr/uQJN3f2WJpcNEzetWGKctl9Ul43ow= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059DB21F8671 for ; Tue, 24 Jan 2012 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZi+QT89FgDj for ; Tue, 24 Jan 2012 07:08:41 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E768921F8663 for ; Tue, 24 Jan 2012 07:08:39 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Jan 2012 04:08:03 -0800 Date: Tue, 24 Jan 2012 04:07:59 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1E6646.9090709@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Tue, 24 Jan 2012, Alan DeKok wrote: > No. You can't have it both ways. Your example was a new format VSA > inserted in the middle of a fragmented new format VSA: >> You brought up EAP as evidence my concerns are without merit. I pointed >> out there are important differences between EAP and extensions which >> limit the applicability of this analogy. > I responded to that. Since you ignored it, here it is again: > RFC 2865 says nothing about EAP packets. It's perfectly legal under > RFC 2865 to insert one instance of attribute 79 in the middle of a list > of attribute 79's. Your making an argument since EAP-Message can be inserted anywhere including at the start or end of the packet it breaks the EAP RFC but not RFC 2865. This is true. The same idea applies to extensions. If you add in the wrong place it breaks. RFC 2865 does not. > It's the same thing. Proxies which are UNAWARE of EAP are permitted by > RFC 2865 to mangle EAP. This is EXACTLY your argument against this > draft. RFC 2865 also says nothing about sending garbage in the Value field of attributes defined in other RFCs. > It's impossible to be fully compliant to the RADIUS RFCs. They are > contradictory, incomplete, and often plain wrong. This also seems to be true. (Cut from previous message) > If your best proof is to ignore my counter-arguments, then I think > we're done here. I agree with your argument of course it is true. My concern with this line of thinking is examples of broken RFCs and silly what-ifs can be used to justify pretty much anything no matter the consequences. They also ignore logical separation of "protocol" from "implementation". It is not enough to respond in the abstract. The unique details of each situation should be closely examined. This is where EAP-Message and Extensions diverge. You may view my argument as equally silly as the above and therefore no different than sending garbage Values or extra EAP-Messages and this is fine. When I said there was only one EAP Packet per RADIUS message it was a statement in terms of what actually occurs. I did not mean to imply that RFC 2865 prohibits all harmful effects or that something else couldn't throw a wrench into the works. I simply meant multiple EAP Packets are not actually sent in single RADIUS Messages whereas with extensions it would be allowed and expected. This was only intended to be a caution against assuming EAP-Message has the same issues and properties as extensions for the purpose of understanding potential risks from the perspective of what is observed with existing implementations. > Your counterpoint was to point at RFC 3579. I haven't read it. I've > only read 2865, and implemented proxies based on that. I've assigned > attribute 79 as my own personal VSA, just like people have done with > 241..245. I've decided to mangle lists of attribute 79. This is > allowed under 2865. > Now explain to me how that's different from your arguments against > this draft. In response, use only 2865. Don't use 2869 or 3579. Don't > refer to any real-world experience with the non-EAP/EAP transition. My issue is "implementations" are allowed to be conduits for data they do not understand and there seem to be insufficient constraints in the "protocol" to support extensions. As much as reasonable I believe extensions rather than "protocol" should be changed to attempt to correct the mismatch. The key to understanding the difference per your query is a separation of "protocol" from "implementation" and separation of protocol layers. Sending garbage values is an "implementation" concern. Interpreting attribute id's not defined in the "protocol" is not a protocol issue. Ordering constraints are defined in the "protocol". Allowing a protocol layered on top of an existing "protocol" to modify the properties of lower "protocol" is generally best avoided if possible. >> I have on multiple occasions stated I don't care about perfect backwards >> compatibility. My goal is simply providing a good chance of detecting >> the presence of errors. > Make a concrete proposal. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type |M| Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence When Value field of attribute is fragmented into multiple attributes the first fragment having M flag set is set to 1 and increased by 1 with each subsequent fragment including the final fragment where the M flag is clear. If a Value field does not span multiple attributes the sequence field is set to 1. When receiving fragmented attributes sequence field is checked to ensure each fragment is received in the proper order. If there are gaps in sequence numbers or fragments are out of order the attribute including all fragments are discarded. An implementation MUST NOT attempt to reorder attribute fragments based on sequence. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Jan 24 07:52:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0921F8589 for ; Tue, 24 Jan 2012 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8JU5bK8FsrN for ; Tue, 24 Jan 2012 07:52:08 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A273E21F84D0 for ; Tue, 24 Jan 2012 07:52:06 -0800 (PST) Message-ID: <4F1ED389.8040901@deployingradius.com> Date: Tue, 24 Jan 2012 16:51:37 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:52:10 -0000 Sanchez, Mauricio (HP Networking) wrote: > - All documents produced MUST specify means of interoperation with legacy > RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, > including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, > 5090 and 5176. Transport profiles should, if possible, be compatible with > RFC 3539. Add 6158. > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: I agree with Dave's comments here. > - Update and clarification of Network Access Identifiers (RFC4282).This > work item will correct and clarify egregious issues present with RFC4282 > in two phases. While I might like the word "egregious", it might be too strong for charter text. > In first phase, RFC4282bis will be issued to eliminate > fundamental incompatibilities with RADIUS around character encoding and > NAI modifications by proxies. In second phase, a fresh review of NAI > internationalization requirements and behavior will be undertaken with a > clear goal of maintaining compatibility with RADIUS. I don't see how the two phases can be separated. A solution to either phase involves using much of the work from the other phase. > Goals and Milestones ... > Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a > Proposed Standard RFC I like that timeframe. But I having a 2 year deadline is more realistic. The issues were first brought up as important 2-3 years ago, and little has happened since. Alan DeKok. From radext-bounces@ietf.org Tue Jan 24 07:52:12 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6FE21F8589; Tue, 24 Jan 2012 07:52:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327420332; bh=0WeoNmk1JfIHim+//hxLfq9Vc6jRzKU8urgCog6OKus=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=Vj/vo33z6c35RX9bFAOhhy80Nf20KbGxjlc1faPK36dywuO5TrN+sIkvVTXCgFezY vL2R8yRIUSiCADJCdwzt7HQ8Ms2mA1dCTCyvrTPTTrQhPoFxu7+kuo7JfxEopvBQH5 QyBX2NJ4+Tt4hoIwhOp8i6k2bSEiyYCebvugGcoc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF0921F8589 for ; Tue, 24 Jan 2012 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8JU5bK8FsrN for ; Tue, 24 Jan 2012 07:52:08 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A273E21F84D0 for ; Tue, 24 Jan 2012 07:52:06 -0800 (PST) Message-ID: <4F1ED389.8040901@deployingradius.com> Date: Tue, 24 Jan 2012 16:51:37 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Sanchez, Mauricio (HP Networking) wrote: > - All documents produced MUST specify means of interoperation with legacy > RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, > including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, > 5090 and 5176. Transport profiles should, if possible, be compatible with > RFC 3539. Add 6158. > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: I agree with Dave's comments here. > - Update and clarification of Network Access Identifiers (RFC4282).This > work item will correct and clarify egregious issues present with RFC4282 > in two phases. While I might like the word "egregious", it might be too strong for charter text. > In first phase, RFC4282bis will be issued to eliminate > fundamental incompatibilities with RADIUS around character encoding and > NAI modifications by proxies. In second phase, a fresh review of NAI > internationalization requirements and behavior will be undertaken with a > clear goal of maintaining compatibility with RADIUS. I don't see how the two phases can be separated. A solution to either phase involves using much of the work from the other phase. > Goals and Milestones ... > Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a > Proposed Standard RFC I like that timeframe. But I having a 2 year deadline is more realistic. The issues were first brought up as important 2-3 years ago, and little has happened since. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Tue Jan 24 12:34:45 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25DF11E8088 for ; Tue, 24 Jan 2012 12:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=-2.531, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+UPbQib8sxo for ; Tue, 24 Jan 2012 12:34:44 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id AD81311E807A for ; Tue, 24 Jan 2012 12:34:44 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Jan 2012 12:34:44 -0800 Date: Tue, 24 Jan 2012 12:34:43 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1EBA5F.8070101@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:34:45 -0000 On Tue, 24 Jan 2012, Alan DeKok wrote: > Peter Deacon wrote: >> I simply meant multiple EAP Packets are not actually sent in single >> RADIUS Messages whereas with extensions it would be allowed and >> expected. > And again my response: systems which implement the draft are expected > to be compliant with it. Adding something in the middle of a fragmented > attribute is forbidden by this specification. So there's no problem. Not to sound like a broken record my issue is only with implementations that do not support extensions but are expected to interop with systems that do. > The eduroam consortium has done surveys of precisely this issue in > relation to the Operator-Name attribute. This survey is discussed in > the extensions draft. The *real world* problems seen with the erroneous > use of attributes are: Are you able to provide a reference? The only "Eduoroam" documents I've been able to find really seem to be focused on fixing vendor dictionaries so that they line up and do not cause requests to be discarded. Any study that has looked into the issue of behavior of RADIUS implementations in detail and current practices of aggregation networks is welcome. I expect we can all appreciate the *real world* encompasses more than the sum of our individual experiences. It is not just RADIUS servers acting as proxies but policy systems and intermediate middle boxes that filter process and forward AAA signals to do their jobs. > The systems which do this are in an absolute minority. They are *also* > in the process of being updated to support Operator-Name. When that is > done, they will also trivially support proxying the extensions attrs. > All possible evidence leads me to conclude that inter-operation with > legacy systems will have minimal problems. >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Extended-Type |M| Sequence | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Value ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Sequence >> >> When Value field of attribute is fragmented into multiple attributes the >> first fragment having M flag set is set to 1 and increased by 1 with >> each subsequent fragment including the final fragment where the M flag >> is clear. >> >> If a Value field does not span multiple attributes the sequence field is >> set to 1. >> >> When receiving fragmented attributes sequence field is checked to ensure >> each fragment is received in the proper order. If there are gaps in >> sequence numbers or fragments are out of order the attribute including >> all fragments are discarded. An implementation MUST NOT attempt to >> reorder attribute fragments based on sequence. > That isn't enough. I can still take two fragmented attributes, and > intermix them undetectable Take A1..A4, and B1..B4. Then, change them > to A1,A2,B3,B4 and B1,B2,A3,A4. I previously posted a laundry list of issues that can creep up in an "implementation" which does not follow the ordering constraint. Even with all three of the mechanisms I proposed working together there were still seemingly unlikely loopholes possible as I pointed out in a follow up post. While I believe there is operational value to at least allowing detection of the condition of attributes being removed, reorganized..etc it does most likely require something not following 2865 and we all know that road leads to absurd crackpot counterexamples of what "could" break even if it may be operationally useful. With the "protocol" described in RFC 2865 sequence is sufficient. When the extensions protocol is layered on top of RFC 2865 "protocol" the proper constraints exist in 2865 to allow the "extensions protocol" to detect insertion when sequence is present or detect nonconsecutive attributes. Without sequence RFC 2865 is not sufficient to prevent insertion from causing undetectable errors. Note I don't care if it works. I only care if error is detectable. > You're assuming that the implementation is aware of this draft, and > chooses to violate it. So am I. Not I. > If you assume that the implementation isn't aware of this draft, then > the comments about eduroam apply. Yes. regards. Peter From radext-bounces@ietf.org Tue Jan 24 12:34:47 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F227211E8088; Tue, 24 Jan 2012 12:34:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327437287; bh=/VdjMQFdPSatV7iS6RjpzlON5PEKpdN+83lSpCwEZTo=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=aU0CdVTLnxZ4vI9IWT/zsAC/w9GRYzFOeTbuGjic6fnyhc3bCm6AVuBJj0GXtxmW3 lg/Mg1FQZ5T0tf3HmZqLvApHxv8xWhK2VBc+qdZNozzuAWRtOyxknuk7mRj4pHtnom y5dwLfikpUBLRlfNd+dZkzuwYxJRFBo5iaZ1ncYE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25DF11E8088 for ; Tue, 24 Jan 2012 12:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.13 X-Spam-Level: X-Spam-Status: No, score=-0.13 tagged_above=-999 required=5 tests=[AWL=-2.531, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+UPbQib8sxo for ; Tue, 24 Jan 2012 12:34:44 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id AD81311E807A for ; Tue, 24 Jan 2012 12:34:44 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Jan 2012 12:34:44 -0800 Date: Tue, 24 Jan 2012 12:34:43 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1EBA5F.8070101@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Tue, 24 Jan 2012, Alan DeKok wrote: > Peter Deacon wrote: >> I simply meant multiple EAP Packets are not actually sent in single >> RADIUS Messages whereas with extensions it would be allowed and >> expected. > And again my response: systems which implement the draft are expected > to be compliant with it. Adding something in the middle of a fragmented > attribute is forbidden by this specification. So there's no problem. Not to sound like a broken record my issue is only with implementations that do not support extensions but are expected to interop with systems that do. > The eduroam consortium has done surveys of precisely this issue in > relation to the Operator-Name attribute. This survey is discussed in > the extensions draft. The *real world* problems seen with the erroneous > use of attributes are: Are you able to provide a reference? The only "Eduoroam" documents I've been able to find really seem to be focused on fixing vendor dictionaries so that they line up and do not cause requests to be discarded. Any study that has looked into the issue of behavior of RADIUS implementations in detail and current practices of aggregation networks is welcome. I expect we can all appreciate the *real world* encompasses more than the sum of our individual experiences. It is not just RADIUS servers acting as proxies but policy systems and intermediate middle boxes that filter process and forward AAA signals to do their jobs. > The systems which do this are in an absolute minority. They are *also* > in the process of being updated to support Operator-Name. When that is > done, they will also trivially support proxying the extensions attrs. > All possible evidence leads me to conclude that inter-operation with > legacy systems will have minimal problems. >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Extended-Type |M| Sequence | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Value ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Sequence >> >> When Value field of attribute is fragmented into multiple attributes the >> first fragment having M flag set is set to 1 and increased by 1 with >> each subsequent fragment including the final fragment where the M flag >> is clear. >> >> If a Value field does not span multiple attributes the sequence field is >> set to 1. >> >> When receiving fragmented attributes sequence field is checked to ensure >> each fragment is received in the proper order. If there are gaps in >> sequence numbers or fragments are out of order the attribute including >> all fragments are discarded. An implementation MUST NOT attempt to >> reorder attribute fragments based on sequence. > That isn't enough. I can still take two fragmented attributes, and > intermix them undetectable Take A1..A4, and B1..B4. Then, change them > to A1,A2,B3,B4 and B1,B2,A3,A4. I previously posted a laundry list of issues that can creep up in an "implementation" which does not follow the ordering constraint. Even with all three of the mechanisms I proposed working together there were still seemingly unlikely loopholes possible as I pointed out in a follow up post. While I believe there is operational value to at least allowing detection of the condition of attributes being removed, reorganized..etc it does most likely require something not following 2865 and we all know that road leads to absurd crackpot counterexamples of what "could" break even if it may be operationally useful. With the "protocol" described in RFC 2865 sequence is sufficient. When the extensions protocol is layered on top of RFC 2865 "protocol" the proper constraints exist in 2865 to allow the "extensions protocol" to detect insertion when sequence is present or detect nonconsecutive attributes. Without sequence RFC 2865 is not sufficient to prevent insertion from causing undetectable errors. Note I don't care if it works. I only care if error is detectable. > You're assuming that the implementation is aware of this draft, and > chooses to violate it. So am I. Not I. > If you assume that the implementation isn't aware of this draft, then > the comments about eduroam apply. Yes. regards. Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Tue Jan 24 14:37:31 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559121F855F for ; Tue, 24 Jan 2012 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.896 X-Spam-Level: X-Spam-Status: No, score=-99.896 tagged_above=-999 required=5 tests=[AWL=-2.297, BAYES_00=-2.599, GB_SUMOF=5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0bucydg5l3Q for ; Tue, 24 Jan 2012 14:37:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 360F121F84F1 for ; Tue, 24 Jan 2012 14:37:31 -0800 (PST) Message-ID: <4F1F328F.8010308@deployingradius.com> Date: Tue, 24 Jan 2012 23:37:03 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:37:32 -0000 Peter Deacon wrote: > Not to sound like a broken record my issue is only with implementations > that do not support extensions but are expected to interop with systems > that do. See my previous response, which you deleted (again): For systems *not* implementing this specification, see my previous arguments. I am aware of this issue. I have directly addressed it. Your response has been to delete my arguments, and to pretend that they don't exist. > Are you able to provide a reference? The reference is in the draft. I asked the Eduroam people, and saw internal eduroam documents. You can ask them, too. > Any study that has looked into the issue of behavior of RADIUS > implementations in detail and current practices of aggregation networks > is welcome. I expect we can all appreciate the *real world* encompasses > more than the sum of our individual experiences. Which is why the draft references Eduroam. Which is why I repeatedly referred to real-world experiences. Your last sentence implies that I haven't done that, and instead have relied on personal experiences. > It is not just RADIUS servers acting as proxies but policy systems and > intermediate middle boxes that filter process and forward AAA signals to > do their jobs. That sentence sounds suspiciously like bafflegab to me. "policy systems" and "intermediate middle boxes"? Really? What's wrong with just saying "proxy" ? Do proxies not implement "policy systems", and act as "intermediate middle box"? > I previously posted a laundry list of issues that can creep up in an > "implementation" which does not follow the ordering constraint. Even > with all three of the mechanisms I proposed working together there were > still seemingly unlikely loopholes possible as I pointed out in a follow > up post. i.e. systems which don't implement the draft properly will not be inter-operable. Systems which don't implement the draft at all will behave as we've seen before. Problems have been minimal. We have real-world data, for both EAP and Operator-Name. You've talked about real-world issues. I'll challenge you to come up with ONE real-world system which causes the problems you've noted above. It must satisfy the following criteria: a) NOT implement the draft b) act as a RADIUS proxy c) NOT violate 2865 by using unassigned attributes You'll be hard-pressed to find that, I think. Alan DeKok. From radext-bounces@ietf.org Tue Jan 24 14:37:34 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7D21F855F; Tue, 24 Jan 2012 14:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327444654; bh=zWuqjP7B5aQjZOFq0h3pjwWT7ZRI/Zbi0szmCU8wEww=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=JTRs8vJ42SKCdj2L1uGvbPGqfKw6RqLL3GFrfoQiQjG81x9TrkBDh1UNO8f8KeCpb GFAmw7nlOOs0HwNM1lwoKhouTbwtff6T4q5QZbeXXXmY+orW1jzHeEdvi5Y2rVdZzJ RZT9yMGK8cS9Pw45Incdb+tgTVxbTCElqTjXY9sU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559121F855F for ; Tue, 24 Jan 2012 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.896 X-Spam-Level: X-Spam-Status: No, score=-99.896 tagged_above=-999 required=5 tests=[AWL=-2.297, BAYES_00=-2.599, GB_SUMOF=5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0bucydg5l3Q for ; Tue, 24 Jan 2012 14:37:31 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 360F121F84F1 for ; Tue, 24 Jan 2012 14:37:31 -0800 (PST) Message-ID: <4F1F328F.8010308@deployingradius.com> Date: Tue, 24 Jan 2012 23:37:03 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Peter Deacon wrote: > Not to sound like a broken record my issue is only with implementations > that do not support extensions but are expected to interop with systems > that do. See my previous response, which you deleted (again): For systems *not* implementing this specification, see my previous arguments. I am aware of this issue. I have directly addressed it. Your response has been to delete my arguments, and to pretend that they don't exist. > Are you able to provide a reference? The reference is in the draft. I asked the Eduroam people, and saw internal eduroam documents. You can ask them, too. > Any study that has looked into the issue of behavior of RADIUS > implementations in detail and current practices of aggregation networks > is welcome. I expect we can all appreciate the *real world* encompasses > more than the sum of our individual experiences. Which is why the draft references Eduroam. Which is why I repeatedly referred to real-world experiences. Your last sentence implies that I haven't done that, and instead have relied on personal experiences. > It is not just RADIUS servers acting as proxies but policy systems and > intermediate middle boxes that filter process and forward AAA signals to > do their jobs. That sentence sounds suspiciously like bafflegab to me. "policy systems" and "intermediate middle boxes"? Really? What's wrong with just saying "proxy" ? Do proxies not implement "policy systems", and act as "intermediate middle box"? > I previously posted a laundry list of issues that can creep up in an > "implementation" which does not follow the ordering constraint. Even > with all three of the mechanisms I proposed working together there were > still seemingly unlikely loopholes possible as I pointed out in a follow > up post. i.e. systems which don't implement the draft properly will not be inter-operable. Systems which don't implement the draft at all will behave as we've seen before. Problems have been minimal. We have real-world data, for both EAP and Operator-Name. You've talked about real-world issues. I'll challenge you to come up with ONE real-world system which causes the problems you've noted above. It must satisfy the following criteria: a) NOT implement the draft b) act as a RADIUS proxy c) NOT violate 2865 by using unassigned attributes You'll be hard-pressed to find that, I think. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Tue Jan 24 17:43:51 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D427B11E8096 for ; Tue, 24 Jan 2012 17:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTN4vwrBGh6Y for ; Tue, 24 Jan 2012 17:43:51 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 4F27411E8086 for ; Tue, 24 Jan 2012 17:43:51 -0800 (PST) Received: from BLU152-DS5 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 17:43:51 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Alan DeKok'" , "'Sanchez, Mauricio \(HP Networking\)'" References: <4F1ED389.8040901@deployingradius.com> In-Reply-To: <4F1ED389.8040901@deployingradius.com> Date: Tue, 24 Jan 2012 17:44:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGUaOAFoeS1c1+GFWiIzjO2hPznJgFI8FAXloLobWA= Content-Language: en-us X-OriginalArrivalTime: 25 Jan 2012 01:43:51.0058 (UTC) FILETIME=[C9E57F20:01CCDB02] Cc: radext@ietf.org Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 01:43:51 -0000 Alan said: "While I might like the word "egregious", it might be too strong for charter text" [BA] I would prefer not to use the word "egregious" as a bar for deciding which mistakes in RFC 4282 will be fixed and which won't. The main constraint should be scope -- the problem with RFC 4282 was (incorrectly) expanding the scope of what the document covered, beyond just fixing errors in RFC 2486. We should try to not make the same mistake with RFC 4282. The focus of RFC 4282bis should be on the NAI, not on internationalization in AAA -- that is for a separate document. Alain said: "I don't see how the two phases can be separated. A solution to either phase involves using much of the work from the other phase." [BA] The major error of RFC 4282 is its implicit assertion that internationalization is somehow a function of the NAI itself, rather than being dictated by the protocol within which the NAI is transmitted. If we correct this basic error in RFC 422, and fix the ABNF, then we will have defused the ticking time bomb that is RFC 4282. We can then move on to another document describing internationalization issues in RADIUS. From radext-bounces@ietf.org Tue Jan 24 17:43:54 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128C411E8096; Tue, 24 Jan 2012 17:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327455834; bh=fAbJOyUv7VMGvd7eKODE4Qql356AYkW4Wl4o8HjOGM4=; h=Message-ID:From:To:References:In-Reply-To:Date:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=ygRV1FGhiDHTLQ+OZp4n/MqppFqCLBeMrHrnSYdtCWzq0MUTwP3gs4H3Y2X65QnnD SWG12BUQL0hjohgD94KgPK2H0UFi6eDBY36q5RidqamM04khxnsvx4qiTtN3y4G+Y2 m6zQCTCXScuIGFPaIZiIH3BRN1j4/PWG4wZKtIJg= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D427B11E8096 for ; Tue, 24 Jan 2012 17:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTN4vwrBGh6Y for ; Tue, 24 Jan 2012 17:43:51 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 4F27411E8086 for ; Tue, 24 Jan 2012 17:43:51 -0800 (PST) Received: from BLU152-DS5 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 17:43:51 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Alan DeKok'" , "'Sanchez, Mauricio \(HP Networking\)'" References: <4F1ED389.8040901@deployingradius.com> In-Reply-To: <4F1ED389.8040901@deployingradius.com> Date: Tue, 24 Jan 2012 17:44:08 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGUaOAFoeS1c1+GFWiIzjO2hPznJgFI8FAXloLobWA= Content-Language: en-us X-OriginalArrivalTime: 25 Jan 2012 01:43:51.0058 (UTC) FILETIME=[C9E57F20:01CCDB02] Cc: radext@ietf.org Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Alan said: "While I might like the word "egregious", it might be too strong for charter text" [BA] I would prefer not to use the word "egregious" as a bar for deciding which mistakes in RFC 4282 will be fixed and which won't. The main constraint should be scope -- the problem with RFC 4282 was (incorrectly) expanding the scope of what the document covered, beyond just fixing errors in RFC 2486. We should try to not make the same mistake with RFC 4282. The focus of RFC 4282bis should be on the NAI, not on internationalization in AAA -- that is for a separate document. Alain said: "I don't see how the two phases can be separated. A solution to either phase involves using much of the work from the other phase." [BA] The major error of RFC 4282 is its implicit assertion that internationalization is somehow a function of the NAI itself, rather than being dictated by the protocol within which the NAI is transmitted. If we correct this basic error in RFC 422, and fix the ABNF, then we will have defused the ticking time bomb that is RFC 4282. We can then move on to another document describing internationalization issues in RADIUS. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Tue Jan 24 18:48:41 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E7511E80A2 for ; Tue, 24 Jan 2012 18:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nupYcTnEwO2A for ; Tue, 24 Jan 2012 18:48:40 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6345911E8086 for ; Tue, 24 Jan 2012 18:48:40 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Jan 2012 15:39:27 -0800 Date: Tue, 24 Jan 2012 15:39:26 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1F328F.8010308@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> <4F1F328F.8010308@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 02:48:41 -0000 On Tue, 24 Jan 2012, Alan DeKok wrote: I'm exhausted so I must narrow my point to issues which do not require surveys or opinion. RFC 2865 protocol does not prevent insertion. It only requires order of attributes within RADIUS message be maintained. The constraints of RFC 2865 are therefore NOT sufficient to support the extensions protocol as currently written. As a result if extensions protocol does not explicitly deal with the properties of RFC 2865 the extensions protocol can fail in the narrow case there is interaction with systems not supporting extensions protocol. The failure occurs because there is no restriction on where attributes may be inserted within a RADIUS message in the RFC 2865 protocol. The failure does not apply to implementations supporting extensions protocol. I no longer care what the chance of occurrence is. I only care that this case exists and that I have contributed text to resolve it. I'll let the WG decide what if anything further should be done about it. regards, Peter From radext-bounces@ietf.org Tue Jan 24 18:48:42 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7C011E80A2; Tue, 24 Jan 2012 18:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327459722; bh=pPUpSw7Ykc0A9Y9Hq3Vu/hjUfX5c4iNccnDK87d6zPw=; h=Date:From:To:In-Reply-To:Message-ID:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=NPY6o6OOej0eXhpIWojLfxixnrVAEjSVw8528TPs4AVh1SUWGDVhkDY3tT4DlA2bb yoZc3mwL+GgLz6z0kOk8AJbfFaVtJTspEazzXGLmhnZCFoSqAxM1EJUX+Fgx9UtjoF Fx2QaClPXKgvlDBKkoj63l1vN1VxdbRAfnEXXQVA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E7511E80A2 for ; Tue, 24 Jan 2012 18:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nupYcTnEwO2A for ; Tue, 24 Jan 2012 18:48:40 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6345911E8086 for ; Tue, 24 Jan 2012 18:48:40 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Jan 2012 15:39:27 -0800 Date: Tue, 24 Jan 2012 15:39:26 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <4F1F328F.8010308@deployingradius.com> Message-ID: References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> <4F1F328F.8010308@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Tue, 24 Jan 2012, Alan DeKok wrote: I'm exhausted so I must narrow my point to issues which do not require surveys or opinion. RFC 2865 protocol does not prevent insertion. It only requires order of attributes within RADIUS message be maintained. The constraints of RFC 2865 are therefore NOT sufficient to support the extensions protocol as currently written. As a result if extensions protocol does not explicitly deal with the properties of RFC 2865 the extensions protocol can fail in the narrow case there is interaction with systems not supporting extensions protocol. The failure occurs because there is no restriction on where attributes may be inserted within a RADIUS message in the RFC 2865 protocol. The failure does not apply to implementations supporting extensions protocol. I no longer care what the chance of occurrence is. I only care that this case exists and that I have contributed text to resolve it. I'll let the WG decide what if anything further should be done about it. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Wed Jan 25 00:25:51 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76CB21F869C for ; Wed, 25 Jan 2012 00:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuDLY3m84j3f for ; Wed, 25 Jan 2012 00:25:50 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2C29021F8699 for ; Wed, 25 Jan 2012 00:25:45 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5A073109F6 for ; Wed, 25 Jan 2012 09:25:44 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9] (unknown [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4C8F9106CB for ; Wed, 25 Jan 2012 09:25:44 +0100 (CET) Message-ID: <4F1FBC83.8040304@restena.lu> Date: Wed, 25 Jan 2012 09:25:39 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> <4F1F328F.8010308@deployingradius.com> In-Reply-To: <4F1F328F.8010308@deployingradius.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2599A378DE2E7A2C8FAD838" X-Virus-Scanned: ClamAV Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 08:25:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2599A378DE2E7A2C8FAD838 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, >> Are you able to provide a reference? >=20 > The reference is in the draft. I asked the Eduroam people, and saw > internal eduroam documents. You can ask them, too. All our documents are public. We just like to provide them in PDF format, deeply buried on a website that is not search-engine friendly :-)= For Operator-Name and Chargeable-User-Identity, both of which are IETF-space attributes, not VSAs, see [1], chapter 3.3 "Introduction of Additional RADIUS Attributes into eduroam" Back then we were a bit more enthusiastic than the real world is. Turned out that Microsoft products in particular simply silently discarded incoming requests that contained a perfectly valid Operator-Name attribute. We have since issued an advisory to our Identity Providers how to patch MS IAS/NPS dictionaries (including fiddling in an MS Access database, yay!). The advisory is at [2]. Other servers "helpfully" "fixed" the incoming string and trimmed it to 4 chars because they thought it should be an integer instead (hijacked attribute definitions by private companies). This is a backward compatibility issue just as much as the extended attributes issue is: people who have implemented RADIUS to an older spec which are unaware of newer additional specs might stumble over the newer things. For Operator-Name, silently discarding packets is actually arguably spec-compliant, because RFC2865 states "A RADIUS server MAY ignore Attributes with an unknown Type." The MAY implies: or they may not, and decide to throw it away instead. That is a "great" property: either throw it away or don't, the protocol doesn't mind either way. You are compliant, thumbs up. Ecept that interop goes down the drain. The underlying problem with this is: *We cannot change the past*. We have to live with software deployed in the past which might not do what we would like it to do today. *Nothing* we write in the extended attributes draft is going to change that! The only direction we can be looking is forward: tell those who *do* read the extended attributes spec *today* that they have to be cautious not to insert attributes in the middle, but do so in the end of the packet instead. Yes, there will be incompatibilities with the reality out there. I'm almost sure someone's code will catch the corner case and insert attributes wrongly. Too bad. Our conclusion in eduroam was that we had to introduce active monitoring to see if a RADIUS server in the infrastructure suffers from the problem. For Operator-Name, the process is two-stage: 1) send probing Access-Request with invalid credentials, without O-N 2) send probing Access-Request with invalid credentials, without O-N If 1) is replied to, and 2) isn't, the server has a problem with Operator-Name. If both aren't replied to, the server has a more general problem. If both are replied to, the server is alright. [we didn't encounter 2) is replied to, but 1) not - this would very probably mean the server applies some weird policy of only accepting properly O-N tagged requests] For extended attributes, if they become vital, we will have to think of other tests to include into our compliance testing suite. And/or "name and shame" of the servers which misbehave, so that the vendor might eventually be inconvenienced to change the behaviour. Greetings, Stefan Winter [1] http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-10-30= 4%20DJ3.1.2,1%20%20Roaming%20Developments%2024FEB11.pdf [2] http://www.eduroam.org/downloads/docs/advisory/eduroamOT-admin-advisory-0= 04.pdf >=20 >> Any study that has looked into the issue of behavior of RADIUS >> implementations in detail and current practices of aggregation network= s >> is welcome. I expect we can all appreciate the *real world* encompass= es >> more than the sum of our individual experiences. >=20 > Which is why the draft references Eduroam. Which is why I repeatedly= > referred to real-world experiences. Your last sentence implies that I > haven't done that, and instead have relied on personal experiences. >=20 >> It is not just RADIUS servers acting as proxies but policy systems and= >> intermediate middle boxes that filter process and forward AAA signals = to >> do their jobs. >=20 > That sentence sounds suspiciously like bafflegab to me. "policy > systems" and "intermediate middle boxes"? Really? What's wrong with > just saying "proxy" ? Do proxies not implement "policy systems", and > act as "intermediate middle box"? >=20 >> I previously posted a laundry list of issues that can creep up in an >> "implementation" which does not follow the ordering constraint. Even >> with all three of the mechanisms I proposed working together there wer= e >> still seemingly unlikely loopholes possible as I pointed out in a foll= ow >> up post. >=20 > i.e. systems which don't implement the draft properly will not be > inter-operable. >=20 > Systems which don't implement the draft at all will behave as we've > seen before. Problems have been minimal. We have real-world data, for= > both EAP and Operator-Name. >=20 > You've talked about real-world issues. I'll challenge you to come up= > with ONE real-world system which causes the problems you've noted above= =2E > It must satisfy the following criteria: >=20 > a) NOT implement the draft > b) act as a RADIUS proxy > c) NOT violate 2865 by using unassigned attributes >=20 > You'll be hard-pressed to find that, I think. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA2599A378DE2E7A2C8FAD838 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8fvIgACgkQ+jm90f8eFWYNVgCfZntZYdGfQ37Vx+c+yvRptMMX 5SYAnjeGZ1xNLPcgXfxX8dfQnMnZB5B4 =+b0r -----END PGP SIGNATURE----- --------------enigA2599A378DE2E7A2C8FAD838-- From radext-bounces@ietf.org Wed Jan 25 00:25:53 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A95921F869A; Wed, 25 Jan 2012 00:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327479953; bh=aawF1r43GSsL4dAmHj7CwiwUhHsQwnxbXaMIL21BgTk=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=Hnai2vzbOTrTK7TIoC8yJP/J2uDWtOE0bCBLJ6TXWF++qqw+QunA9md9+x/5Rm8J7 xq/LCqlz+bSQa5yFKMwXKo853BJv8L6b3CSbeuCJVxcsgxRaszlo00xSHhvcgMSQUN AtTAdOVSnuSBfZixlagIjoW7Hj0EQcNwrMj4IREE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76CB21F869C for ; Wed, 25 Jan 2012 00:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuDLY3m84j3f for ; Wed, 25 Jan 2012 00:25:50 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2C29021F8699 for ; Wed, 25 Jan 2012 00:25:45 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5A073109F6 for ; Wed, 25 Jan 2012 09:25:44 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9] (unknown [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4C8F9106CB for ; Wed, 25 Jan 2012 09:25:44 +0100 (CET) Message-ID: <4F1FBC83.8040304@restena.lu> Date: Wed, 25 Jan 2012 09:25:39 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> <4F1F328F.8010308@deployingradius.com> In-Reply-To: <4F1F328F.8010308@deployingradius.com> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2212244712453649242==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2212244712453649242== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA2599A378DE2E7A2C8FAD838" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2599A378DE2E7A2C8FAD838 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, >> Are you able to provide a reference? >=20 > The reference is in the draft. I asked the Eduroam people, and saw > internal eduroam documents. You can ask them, too. All our documents are public. We just like to provide them in PDF format, deeply buried on a website that is not search-engine friendly :-)= For Operator-Name and Chargeable-User-Identity, both of which are IETF-space attributes, not VSAs, see [1], chapter 3.3 "Introduction of Additional RADIUS Attributes into eduroam" Back then we were a bit more enthusiastic than the real world is. Turned out that Microsoft products in particular simply silently discarded incoming requests that contained a perfectly valid Operator-Name attribute. We have since issued an advisory to our Identity Providers how to patch MS IAS/NPS dictionaries (including fiddling in an MS Access database, yay!). The advisory is at [2]. Other servers "helpfully" "fixed" the incoming string and trimmed it to 4 chars because they thought it should be an integer instead (hijacked attribute definitions by private companies). This is a backward compatibility issue just as much as the extended attributes issue is: people who have implemented RADIUS to an older spec which are unaware of newer additional specs might stumble over the newer things. For Operator-Name, silently discarding packets is actually arguably spec-compliant, because RFC2865 states "A RADIUS server MAY ignore Attributes with an unknown Type." The MAY implies: or they may not, and decide to throw it away instead. That is a "great" property: either throw it away or don't, the protocol doesn't mind either way. You are compliant, thumbs up. Ecept that interop goes down the drain. The underlying problem with this is: *We cannot change the past*. We have to live with software deployed in the past which might not do what we would like it to do today. *Nothing* we write in the extended attributes draft is going to change that! The only direction we can be looking is forward: tell those who *do* read the extended attributes spec *today* that they have to be cautious not to insert attributes in the middle, but do so in the end of the packet instead. Yes, there will be incompatibilities with the reality out there. I'm almost sure someone's code will catch the corner case and insert attributes wrongly. Too bad. Our conclusion in eduroam was that we had to introduce active monitoring to see if a RADIUS server in the infrastructure suffers from the problem. For Operator-Name, the process is two-stage: 1) send probing Access-Request with invalid credentials, without O-N 2) send probing Access-Request with invalid credentials, without O-N If 1) is replied to, and 2) isn't, the server has a problem with Operator-Name. If both aren't replied to, the server has a more general problem. If both are replied to, the server is alright. [we didn't encounter 2) is replied to, but 1) not - this would very probably mean the server applies some weird policy of only accepting properly O-N tagged requests] For extended attributes, if they become vital, we will have to think of other tests to include into our compliance testing suite. And/or "name and shame" of the servers which misbehave, so that the vendor might eventually be inconvenienced to change the behaviour. Greetings, Stefan Winter [1] http://www.geant.net/Media_Centre/Media_Library/Media%20Library/GN3-10-30= 4%20DJ3.1.2,1%20%20Roaming%20Developments%2024FEB11.pdf [2] http://www.eduroam.org/downloads/docs/advisory/eduroamOT-admin-advisory-0= 04.pdf >=20 >> Any study that has looked into the issue of behavior of RADIUS >> implementations in detail and current practices of aggregation network= s >> is welcome. I expect we can all appreciate the *real world* encompass= es >> more than the sum of our individual experiences. >=20 > Which is why the draft references Eduroam. Which is why I repeatedly= > referred to real-world experiences. Your last sentence implies that I > haven't done that, and instead have relied on personal experiences. >=20 >> It is not just RADIUS servers acting as proxies but policy systems and= >> intermediate middle boxes that filter process and forward AAA signals = to >> do their jobs. >=20 > That sentence sounds suspiciously like bafflegab to me. "policy > systems" and "intermediate middle boxes"? Really? What's wrong with > just saying "proxy" ? Do proxies not implement "policy systems", and > act as "intermediate middle box"? >=20 >> I previously posted a laundry list of issues that can creep up in an >> "implementation" which does not follow the ordering constraint. Even >> with all three of the mechanisms I proposed working together there wer= e >> still seemingly unlikely loopholes possible as I pointed out in a foll= ow >> up post. >=20 > i.e. systems which don't implement the draft properly will not be > inter-operable. >=20 > Systems which don't implement the draft at all will behave as we've > seen before. Problems have been minimal. We have real-world data, for= > both EAP and Operator-Name. >=20 > You've talked about real-world issues. I'll challenge you to come up= > with ONE real-world system which causes the problems you've noted above= =2E > It must satisfy the following criteria: >=20 > a) NOT implement the draft > b) act as a RADIUS proxy > c) NOT violate 2865 by using unassigned attributes >=20 > You'll be hard-pressed to find that, I think. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA2599A378DE2E7A2C8FAD838 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8fvIgACgkQ+jm90f8eFWYNVgCfZntZYdGfQ37Vx+c+yvRptMMX 5SYAnjeGZ1xNLPcgXfxX8dfQnMnZB5B4 =+b0r -----END PGP SIGNATURE----- --------------enigA2599A378DE2E7A2C8FAD838-- --===============2212244712453649242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============2212244712453649242==-- From stefan.winter@restena.lu Wed Jan 25 02:06:31 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4177521F8603 for ; Wed, 25 Jan 2012 02:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov1QRPX7j38L for ; Wed, 25 Jan 2012 02:06:30 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7801B21F85FB for ; Wed, 25 Jan 2012 02:06:30 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id AF584109F6 for ; Wed, 25 Jan 2012 11:06:29 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9] (unknown [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9]) by smtprelay.restena.lu (Postfix) with ESMTPS id A4E3610584 for ; Wed, 25 Jan 2012 11:06:29 +0100 (CET) Message-ID: <4F1FD420.7000605@restena.lu> Date: Wed, 25 Jan 2012 11:06:24 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig506F482B85EAEDEA522B8CC3" X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: draft-ietf-radext-radsec-10.txt updated by Amanda Baber X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:06:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig506F482B85EAEDEA522B8CC3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, my working copy of the document now contains this text: 7. IANA Considerations No new RADIUS attributes or packet codes are defined. IANA is requested to update the already-assigned TCP port number 2083 in the following ways: o Reference: list the RFC number of this document as the reference o Assignment Notes: add the text "The TCP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC. This early implementation can be configured to be compatible to RADIUS/TLS as specified by the IETF. See RFC (RFC number of this document), Appendix A for details." If there are no objections, this will go into -11 and should address the IANA comment. Greetings, Stefan Winter On 18.01.2012 13:56, Romascanu, Dan (Dan) wrote: > Document editors, >=20 > What is your opinion? At least the text near the port assignment should= > point to the future RFC.=20 >=20 > Dan >=20 >=20 >=20 >=20 > -----Original Message----- > From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org]=20 > Sent: Wednesday, January 18, 2012 4:59 AM > To: Romascanu, Dan (Dan) > Subject: draft-ietf-radext-radsec-10.txt updated by Amanda Baber >=20 >=20 > Please DO NOT reply on this email. >=20 >=20 > I-D: draft-ietf-radext-radsec-10.txt > ID Tracker URL: > https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=3Dview_id&dT= ag=3D > 17332&rfc_flag=3D0 > A new comment added by Amanda Baber >=20 > IANA has a question about this document. >=20 >=20 >=20 > IANA recognizes that previously, TCP port 2083 was already assigned by > IANA for RadSec, an early implementation of RADIUS/TLS. We note that on= e > of the authors is the assignee and contact for that port number. Our > question is: do the authors want to make any changes to the registratio= n > of port 2083 upon approval of this document (description, assignee, > contact, reference)? >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig506F482B85EAEDEA522B8CC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8f1CUACgkQ+jm90f8eFWadPQCfe/k510kjQxoj2YHxaUHVJkzs 7CYAmQEd6Ed2KRuB/rxcbvHip590PYOg =c46p -----END PGP SIGNATURE----- --------------enig506F482B85EAEDEA522B8CC3-- From radext-bounces@ietf.org Wed Jan 25 02:06:33 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435F021F8603; Wed, 25 Jan 2012 02:06:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327485993; bh=f0kNxh8oToq2YPRpu38HwLEsON0gE1nWsN0BC9c6aGQ=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=YvQEydjOdpormq5+lgmPByaEIkQTBehs2ZLV2C2bKZGLSY0Xd5NesgfoJFHjLTVlr 7lY0ErSWnq1J8R6wHYQkCXSwdJST/o88fv7hO30hvHw0jYuDPxBpl0S8/P6lbszvW7 9N7IW096ILFF6ggZ7dT0AU7uAenNduLpbkQTAzPY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4177521F8603 for ; Wed, 25 Jan 2012 02:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov1QRPX7j38L for ; Wed, 25 Jan 2012 02:06:30 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7801B21F85FB for ; Wed, 25 Jan 2012 02:06:30 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id AF584109F6 for ; Wed, 25 Jan 2012 11:06:29 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9] (unknown [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9]) by smtprelay.restena.lu (Postfix) with ESMTPS id A4E3610584 for ; Wed, 25 Jan 2012 11:06:29 +0100 (CET) Message-ID: <4F1FD420.7000605@restena.lu> Date: Wed, 25 Jan 2012 11:06:24 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: draft-ietf-radext-radsec-10.txt updated by Amanda Baber X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8963966074852502788==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8963966074852502788== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig506F482B85EAEDEA522B8CC3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig506F482B85EAEDEA522B8CC3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, my working copy of the document now contains this text: 7. IANA Considerations No new RADIUS attributes or packet codes are defined. IANA is requested to update the already-assigned TCP port number 2083 in the following ways: o Reference: list the RFC number of this document as the reference o Assignment Notes: add the text "The TCP port 2083 was already previously assigned by IANA for "RadSec", an early implementation of RADIUS/TLS, prior to issuance of this RFC. This early implementation can be configured to be compatible to RADIUS/TLS as specified by the IETF. See RFC (RFC number of this document), Appendix A for details." If there are no objections, this will go into -11 and should address the IANA comment. Greetings, Stefan Winter On 18.01.2012 13:56, Romascanu, Dan (Dan) wrote: > Document editors, >=20 > What is your opinion? At least the text near the port assignment should= > point to the future RFC.=20 >=20 > Dan >=20 >=20 >=20 >=20 > -----Original Message----- > From: DraftTracker Mail System [mailto:iesg-secretary@ietf.org]=20 > Sent: Wednesday, January 18, 2012 4:59 AM > To: Romascanu, Dan (Dan) > Subject: draft-ietf-radext-radsec-10.txt updated by Amanda Baber >=20 >=20 > Please DO NOT reply on this email. >=20 >=20 > I-D: draft-ietf-radext-radsec-10.txt > ID Tracker URL: > https://datatracker.ietf.org/cgi-bin/idtracker.cgi?command=3Dview_id&dT= ag=3D > 17332&rfc_flag=3D0 > A new comment added by Amanda Baber >=20 > IANA has a question about this document. >=20 >=20 >=20 > IANA recognizes that previously, TCP port 2083 was already assigned by > IANA for RadSec, an early implementation of RADIUS/TLS. We note that on= e > of the authors is the assignee and contact for that port number. Our > question is: do the authors want to make any changes to the registratio= n > of port 2083 upon approval of this document (description, assignee, > contact, reference)? >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig506F482B85EAEDEA522B8CC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8f1CUACgkQ+jm90f8eFWadPQCfe/k510kjQxoj2YHxaUHVJkzs 7CYAmQEd6Ed2KRuB/rxcbvHip590PYOg =c46p -----END PGP SIGNATURE----- --------------enig506F482B85EAEDEA522B8CC3-- --===============8963966074852502788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============8963966074852502788==-- From stefan.winter@restena.lu Wed Jan 25 02:46:10 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1821F864D for ; Wed, 25 Jan 2012 02:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wc-K2E4fX6r for ; Wed, 25 Jan 2012 02:46:09 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2C18321F864C for ; Wed, 25 Jan 2012 02:46:09 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 63BD5109F6 for ; Wed, 25 Jan 2012 11:46:08 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9] (unknown [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5390D106CB for ; Wed, 25 Jan 2012 11:46:08 +0100 (CET) Message-ID: <4F1FDD6B.2000000@restena.lu> Date: Wed, 25 Jan 2012 11:46:03 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2C87C9BD7419C28DE63E969" X-Virus-Scanned: ClamAV Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:46:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2C87C9BD7419C28DE63E969 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Dan, thanks for these comments. Responses inline... > This is the AD review of draft-ietf-radext-radsec-10. The document is i= n > good shape and I am sending it to IETF Last Call. Please address the > comments below together with the other IETF Last Call comments.=20 >=20 > Technical comments are marked T and Editorial comments are marked E.=20 >=20 > T1. The Intended status of the document is Experimental. I would sugges= t > to add some text to clarify:=20 > - what is the scope of the experiment - any specific features, > behaviors, performance, scalability data that would validate the > experiment and allow for possible migration of the document to Standard= s > Track in the future > - any restrictions in deployment or other operational considerations > that should be known by operators or implementers?=20 My working copy now has this new section 1.3: 1.3. Document Status This document is an Experimental RFC. It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also Section 4). The specification does not fulfill all recommendations on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues. It has yet to be decided whether this approach is to be chosen for standards track. One key aspect to judge whether the approach is usable at large scale is by observing the uptake, usability and operational behaviour of the protocol in large-scale, real-life deployments. One of these deployments could be the eduroam roaming consortium. Does that address your comment? > T2. In Section 4:=20 >=20 >> As a consequence, the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- > bidding attacks on the peer communication. >=20 > This (non-)recommendation is not clear to me. Actually if no other > transport works for a given RADIUS entity or between a client and a > server a fallback to RADIUS/UDP will always happen because this is the > current standard and mandatory-to-implement transport. What is meant > here - I think - is to RECOMMEND that manual administrative interfaces > be made available for configuration of transport and that these > interfaces be used to select the preferred transport between clients an= d > servers.=20 The fallback scenario and this warning apply only for transition phases where the same RADIUS client is moved from RADIUS/UDP to RADIUS/TLS. It goes like: RADIUS Server understands both UDP and TLS. RADIUS client understands only UDP -> client is configured on the server as the tuple (transport UDP, IP, shared secret). Now the RADIUS client is scheduled for an upgrade and can from then on also use RADIUS/TLS. To avoid a flag day, the server is configured to accept incoming requests from that client both via UDP and TLS prior to the client upgrade being done -> RADIUS Server has two tuples: (transport UDP, IP, shared secret) (transport TLS, IP, TLS credential) The client can now be upgraded at convenience to speak TLS. It might also be tempting to configure RADIUS/UDP as a fallback if it cannot establish a connection via TLS. This opens up a bidding-down attack by an attacker sitting between client and server: if it can silently discard TCP SYNs, the (better) TLS encryption will not be used, and the client will send its requests with RADIUS/UDP again. Mitigating this can be done on either side. Either the RADIUS client is configured not to use RADIUS/UDP as a fallback for its outgoing connection attempts; or the RADIUS server can be configured to delete the RADIUS/UDP client from its list of authorized clients. The text you quoted is to make the client end aware that configuring a fallback to RADIUS/UDP is a bad idea. The text for the server side is contained in chapter 6, Security Recommendations, last-but-one paragraph. I guess the text you quoted is misplaced in the document. It would probably be better to consolidate both sides into the Security Considerations section. Would that be okay with you? > E1. Section 2.3 >=20 >> after completing the TCP handshake, immediately negotiate TLS > sessions. The following restrictions apply: according to > [RFC5246] or its predecessor TLS 1.1. The following restriction= s > apply: >=20 >=20 > 'The following restrictions apply' appears twice - drop one of them Fixed in my working copy, thanks! > E2. Add reference to RFC 6421 and link to it from Appendix C. Fixed in my working copy, thanks! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigB2C87C9BD7419C28DE63E969 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8f3XAACgkQ+jm90f8eFWb0ogCfQVijxLF81aV2bi3K+f++7/L4 mCQAn3g8nbCDr0ZrZAwT0BxLjSGXC0lE =Znem -----END PGP SIGNATURE----- --------------enigB2C87C9BD7419C28DE63E969-- From radext-bounces@ietf.org Wed Jan 25 02:46:11 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35921F864D; Wed, 25 Jan 2012 02:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327488371; bh=3b73sCG0UG2WNe+JUg6SYyNesnWgi7MGG8/YtYY8QlU=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=zCMU8NkqzcEtik3TScd88SHRNDhzk2IntPJnKzVorV19HJVP++WDCLm8WHZXCfi4U dtrQDpihqJd01f40jvNHgP3b9MV9eN7LD2I4vP2dkeT9qvILwlxtCNlodR7LwzVrNg X8Q1mSndaLFeTzr/26mCFY3sMuQznI5udzlhgKzs= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD1821F864D for ; Wed, 25 Jan 2012 02:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wc-K2E4fX6r for ; Wed, 25 Jan 2012 02:46:09 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2C18321F864C for ; Wed, 25 Jan 2012 02:46:09 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 63BD5109F6 for ; Wed, 25 Jan 2012 11:46:08 +0100 (CET) Received: from [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9] (unknown [IPv6:2001:a18:1:8:4803:d1c7:f391:5ad9]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5390D106CB for ; Wed, 25 Jan 2012 11:46:08 +0100 (CET) Message-ID: <4F1FDD6B.2000000@restena.lu> Date: Wed, 25 Jan 2012 11:46:03 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341893931771627645==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1341893931771627645== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2C87C9BD7419C28DE63E969" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2C87C9BD7419C28DE63E969 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Dan, thanks for these comments. Responses inline... > This is the AD review of draft-ietf-radext-radsec-10. The document is i= n > good shape and I am sending it to IETF Last Call. Please address the > comments below together with the other IETF Last Call comments.=20 >=20 > Technical comments are marked T and Editorial comments are marked E.=20 >=20 > T1. The Intended status of the document is Experimental. I would sugges= t > to add some text to clarify:=20 > - what is the scope of the experiment - any specific features, > behaviors, performance, scalability data that would validate the > experiment and allow for possible migration of the document to Standard= s > Track in the future > - any restrictions in deployment or other operational considerations > that should be known by operators or implementers?=20 My working copy now has this new section 1.3: 1.3. Document Status This document is an Experimental RFC. It is one out of several approaches to address known cryptographic weaknesses of the RADIUS protocol (see also Section 4). The specification does not fulfill all recommendations on a AAA transport profile as per [RFC3539]; in particular, by being based on TCP as a transport layer, it does not prevent head-of-line blocking issues. It has yet to be decided whether this approach is to be chosen for standards track. One key aspect to judge whether the approach is usable at large scale is by observing the uptake, usability and operational behaviour of the protocol in large-scale, real-life deployments. One of these deployments could be the eduroam roaming consortium. Does that address your comment? > T2. In Section 4:=20 >=20 >> As a consequence, the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- > bidding attacks on the peer communication. >=20 > This (non-)recommendation is not clear to me. Actually if no other > transport works for a given RADIUS entity or between a client and a > server a fallback to RADIUS/UDP will always happen because this is the > current standard and mandatory-to-implement transport. What is meant > here - I think - is to RECOMMEND that manual administrative interfaces > be made available for configuration of transport and that these > interfaces be used to select the preferred transport between clients an= d > servers.=20 The fallback scenario and this warning apply only for transition phases where the same RADIUS client is moved from RADIUS/UDP to RADIUS/TLS. It goes like: RADIUS Server understands both UDP and TLS. RADIUS client understands only UDP -> client is configured on the server as the tuple (transport UDP, IP, shared secret). Now the RADIUS client is scheduled for an upgrade and can from then on also use RADIUS/TLS. To avoid a flag day, the server is configured to accept incoming requests from that client both via UDP and TLS prior to the client upgrade being done -> RADIUS Server has two tuples: (transport UDP, IP, shared secret) (transport TLS, IP, TLS credential) The client can now be upgraded at convenience to speak TLS. It might also be tempting to configure RADIUS/UDP as a fallback if it cannot establish a connection via TLS. This opens up a bidding-down attack by an attacker sitting between client and server: if it can silently discard TCP SYNs, the (better) TLS encryption will not be used, and the client will send its requests with RADIUS/UDP again. Mitigating this can be done on either side. Either the RADIUS client is configured not to use RADIUS/UDP as a fallback for its outgoing connection attempts; or the RADIUS server can be configured to delete the RADIUS/UDP client from its list of authorized clients. The text you quoted is to make the client end aware that configuring a fallback to RADIUS/UDP is a bad idea. The text for the server side is contained in chapter 6, Security Recommendations, last-but-one paragraph. I guess the text you quoted is misplaced in the document. It would probably be better to consolidate both sides into the Security Considerations section. Would that be okay with you? > E1. Section 2.3 >=20 >> after completing the TCP handshake, immediately negotiate TLS > sessions. The following restrictions apply: according to > [RFC5246] or its predecessor TLS 1.1. The following restriction= s > apply: >=20 >=20 > 'The following restrictions apply' appears twice - drop one of them Fixed in my working copy, thanks! > E2. Add reference to RFC 6421 and link to it from Appendix C. Fixed in my working copy, thanks! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigB2C87C9BD7419C28DE63E969 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8f3XAACgkQ+jm90f8eFWb0ogCfQVijxLF81aV2bi3K+f++7/L4 mCQAn3g8nbCDr0ZrZAwT0BxLjSGXC0lE =Znem -----END PGP SIGNATURE----- --------------enigB2C87C9BD7419C28DE63E969-- --===============1341893931771627645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============1341893931771627645==-- From radext-bounces@ietf.org Wed Jan 25 03:43:15 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA26521F85AF; Wed, 25 Jan 2012 03:43:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327491795; bh=zC3VmREd76VtJ6/UsD7P2/zFGtTTGmVOUDIO7W5EunM=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=GbA+KzSjhoWcdzr5ErXPGztbqHSyDgPy1PogVl2V8cK0922LbytcxBvYVT2Cc+ngF DHY+Gt1yq2jd2CXFnVZp1L7ZFnzTzLo+cS0zGIVwdfMexfzWQIkBoLfl7IETl1P192 paE+L0LfjYfFNtxkMhLsM375J3IhJuVVNfYdQuDY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5A321F85AF for ; Wed, 25 Jan 2012 03:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA4SIhJIzx-r for ; Wed, 25 Jan 2012 03:43:13 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id B7E7021F8599 for ; Wed, 25 Jan 2012 03:43:13 -0800 (PST) Message-ID: <4F1FEAB6.90101@deployingradius.com> Date: Wed, 25 Jan 2012 12:42:46 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4F1ED389.8040901@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: radext@ietf.org, "'Sanchez, Mauricio \(HP Networking\)'" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > [BA] The major error of RFC 4282 is its implicit assertion that > internationalization is somehow a function of the NAI itself, rather than > being dictated by the protocol within which the NAI is transmitted. If we > correct this basic error in RFC 422, and fix the ABNF, then we will have > defused the ticking time bomb that is RFC 4282. We can then move on to > another document describing internationalization issues in RADIUS. I understand. OK, I'm in agreement. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Wed Jan 25 03:43:14 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5A321F85AF for ; Wed, 25 Jan 2012 03:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA4SIhJIzx-r for ; Wed, 25 Jan 2012 03:43:13 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id B7E7021F8599 for ; Wed, 25 Jan 2012 03:43:13 -0800 (PST) Message-ID: <4F1FEAB6.90101@deployingradius.com> Date: Wed, 25 Jan 2012 12:42:46 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <4F1ED389.8040901@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, "'Sanchez, Mauricio \(HP Networking\)'" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 11:43:14 -0000 Bernard Aboba wrote: > [BA] The major error of RFC 4282 is its implicit assertion that > internationalization is somehow a function of the NAI itself, rather than > being dictated by the protocol within which the NAI is transmitted. If we > correct this basic error in RFC 422, and fix the ABNF, then we will have > defused the ticking time bomb that is RFC 4282. We can then move on to > another document describing internationalization issues in RADIUS. I understand. OK, I'm in agreement. Alan DeKok. From dromasca@avaya.com Wed Jan 25 06:09:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF52121F86DA for ; Wed, 25 Jan 2012 06:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FysruZMYGCui for ; Wed, 25 Jan 2012 06:09:24 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 58A6021F86CA for ; Wed, 25 Jan 2012 06:09:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJkMIE/GmAcF/2dsb2JhbABDrj6BBYFyAQEBAQIBDAYVCVUEAgEIDQQEAQELBgwLAQYBRQkIAQEEARIIDgMJh1qcZ5tNiS4DIwiCY4EGHIJQYwSIDJMLjFk X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="287991893" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jan 2012 09:09:19 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2012 09:04:09 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jan 2012 15:09:15 +0100 Message-ID: In-Reply-To: <4F1FDD6B.2000000@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] AD Review of draft-ietf-radext-radsec-10 Thread-Index: AczbTpOzgGInTxLFQn+cdUKfPwfN6wAGy02A References: <4F1FDD6B.2000000@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:09:24 -0000 Hi Stefan, See in-line.=20 The LC ends tomorrow, Can you make a new version available immediately = after, so that I can place the document on the agenda of the 2/2 IESG = telechat?=20 Thanks and Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Stefan Winter > Sent: Wednesday, January 25, 2012 12:46 PM > To: radext@ietf.org > Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 >=20 > Hello Dan, >=20 > thanks for these comments. Responses inline... >=20 > > This is the AD review of draft-ietf-radext-radsec-10. The document = is > > in good shape and I am sending it to IETF Last Call. Please address > > the comments below together with the other IETF Last Call comments. > > > > Technical comments are marked T and Editorial comments are marked E. > > > > T1. The Intended status of the document is Experimental. I would > > suggest to add some text to clarify: > > - what is the scope of the experiment - any specific features, > > behaviors, performance, scalability data that would validate the > > experiment and allow for possible migration of the document to > > Standards Track in the future > > - any restrictions in deployment or other operational considerations > > that should be known by operators or implementers? >=20 > My working copy now has this new section 1.3: >=20 > 1.3. Document Status >=20 > This document is an Experimental RFC. >=20 > It is one out of several approaches to address known cryptographic > weaknesses of the RADIUS protocol (see also Section 4). The > specification does not fulfill all recommendations on a AAA > transport > profile as per [RFC3539]; in particular, by being based on TCP as a > transport layer, it does not prevent head-of-line blocking issues. >=20 > It has yet to be decided whether this approach is to be chosen for > standards track. One key aspect to judge whether the approach is > usable at large scale is by observing the uptake, usability and > operational behaviour of the protocol in large-scale, real-life > deployments. One of these deployments could be the eduroam roaming > consortium. >=20 > Does that address your comment? [[DR]] Yes. My only comment would be that I would keep the mention to = the eduroam deployment in a separate paragraph and keep the existing = wording about it:=20 An example for a world-wide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam]. >=20 > > T2. In Section 4: > > > >> As a consequence, the selection of transports to communicate from = a > > client to a server is a manual administrative action. An > automatic > > fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to = down- > > bidding attacks on the peer communication. > > > > This (non-)recommendation is not clear to me. Actually if no other > > transport works for a given RADIUS entity or between a client and a > > server a fallback to RADIUS/UDP will always happen because this is > the > > current standard and mandatory-to-implement transport. What is meant > > here - I think - is to RECOMMEND that manual administrative > interfaces > > be made available for configuration of transport and that these > > interfaces be used to select the preferred transport between clients > > and servers. >=20 > The fallback scenario and this warning apply only for transition = phases > where the same RADIUS client is moved from RADIUS/UDP to RADIUS/TLS. = It > goes like: >=20 > RADIUS Server understands both UDP and TLS. > RADIUS client understands only UDP -> client is configured on the > server as the tuple (transport UDP, IP, shared secret). >=20 > Now the RADIUS client is scheduled for an upgrade and can from then on > also use RADIUS/TLS. To avoid a flag day, the server is configured to > accept incoming requests from that client both via UDP and TLS prior = to > the client upgrade being done > -> RADIUS Server has two tuples: > (transport UDP, IP, shared secret) > (transport TLS, IP, TLS credential) >=20 > The client can now be upgraded at convenience to speak TLS. It might > also be tempting to configure RADIUS/UDP as a fallback if it cannot > establish a connection via TLS. >=20 > This opens up a bidding-down attack by an attacker sitting between > client and server: if it can silently discard TCP SYNs, the (better) > TLS encryption will not be used, and the client will send its requests > with RADIUS/UDP again. >=20 > Mitigating this can be done on either side. Either the RADIUS client = is > configured not to use RADIUS/UDP as a fallback for its outgoing > connection attempts; or the RADIUS server can be configured to delete > the RADIUS/UDP client from its list of authorized clients. >=20 > The text you quoted is to make the client end aware that configuring a > fallback to RADIUS/UDP is a bad idea. >=20 > The text for the server side is contained in chapter 6, Security > Recommendations, last-but-one paragraph. >=20 > I guess the text you quoted is misplaced in the document. It would > probably be better to consolidate both sides into the Security > Considerations section. Would that be okay with you? [[DR]] Yes, this would be easier to follow.=20 >=20 > > E1. Section 2.3 > > > >> after completing the TCP handshake, immediately negotiate TLS > > sessions. The following restrictions apply: according to > > [RFC5246] or its predecessor TLS 1.1. The following > restrictions > > apply: > > > > > > 'The following restrictions apply' appears twice - drop one of them >=20 > Fixed in my working copy, thanks! >=20 > > E2. Add reference to RFC 6421 and link to it from Appendix C. >=20 > Fixed in my working copy, thanks! >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From radext-bounces@ietf.org Wed Jan 25 06:09:26 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D21E21F86DA; Wed, 25 Jan 2012 06:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327500566; bh=vZoY/Loi83SChkG+qlILinWje5E3Z8lgRh3n8evBIZU=; h=MIME-Version:Date:Message-ID:In-Reply-To:References:From:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=oEk0fcaOC96/VVDC91IaOjKJVbZM2vYPWPX1wB4XEnEcfqBEBCXkHli1zJVHB8D1I BEv+YOU3m1fczLlwr1xzD0BeRJlF9zJh94C6+wsB+CD6h+sZw5EbpjfBruj8RLOQiS 0+oPdbUXXDBMGhOG4/5TOAl2ba9s8mEfSOelEHqo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF52121F86DA for ; Wed, 25 Jan 2012 06:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FysruZMYGCui for ; Wed, 25 Jan 2012 06:09:24 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 58A6021F86CA for ; Wed, 25 Jan 2012 06:09:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJkMIE/GmAcF/2dsb2JhbABDrj6BBYFyAQEBAQIBDAYVCVUEAgEIDQQEAQELBgwLAQYBRQkIAQEEARIIDgMJh1qcZ5tNiS4DIwiCY4EGHIJQYwSIDJMLjFk X-IronPort-AV: E=Sophos;i="4.71,568,1320642000"; d="scan'208";a="287991893" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Jan 2012 09:09:19 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2012 09:04:09 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jan 2012 15:09:15 +0100 Message-ID: In-Reply-To: <4F1FDD6B.2000000@restena.lu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [radext] AD Review of draft-ietf-radext-radsec-10 Thread-Index: AczbTpOzgGInTxLFQn+cdUKfPwfN6wAGy02A References: <4F1FDD6B.2000000@restena.lu> From: "Romascanu, Dan (Dan)" To: "Stefan Winter" , Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi Stefan, See in-line. = The LC ends tomorrow, Can you make a new version available immediately afte= r, so that I can place the document on the agenda of the 2/2 IESG telechat? = Thanks and Regards, Dan > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Stefan Winter > Sent: Wednesday, January 25, 2012 12:46 PM > To: radext@ietf.org > Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 > = > Hello Dan, > = > thanks for these comments. Responses inline... > = > > This is the AD review of draft-ietf-radext-radsec-10. The document is > > in good shape and I am sending it to IETF Last Call. Please address > > the comments below together with the other IETF Last Call comments. > > > > Technical comments are marked T and Editorial comments are marked E. > > > > T1. The Intended status of the document is Experimental. I would > > suggest to add some text to clarify: > > - what is the scope of the experiment - any specific features, > > behaviors, performance, scalability data that would validate the > > experiment and allow for possible migration of the document to > > Standards Track in the future > > - any restrictions in deployment or other operational considerations > > that should be known by operators or implementers? > = > My working copy now has this new section 1.3: > = > 1.3. Document Status > = > This document is an Experimental RFC. > = > It is one out of several approaches to address known cryptographic > weaknesses of the RADIUS protocol (see also Section 4). The > specification does not fulfill all recommendations on a AAA > transport > profile as per [RFC3539]; in particular, by being based on TCP as a > transport layer, it does not prevent head-of-line blocking issues. > = > It has yet to be decided whether this approach is to be chosen for > standards track. One key aspect to judge whether the approach is > usable at large scale is by observing the uptake, usability and > operational behaviour of the protocol in large-scale, real-life > deployments. One of these deployments could be the eduroam roaming > consortium. > = > Does that address your comment? [[DR]] Yes. My only comment would be that I would keep the mention to the e= duroam deployment in a separate paragraph and keep the existing wording abo= ut it: = An example for a world-wide roaming environment that uses RADIUS over TLS to secure communication is "eduroam", see [eduroam]. > = > > T2. In Section 4: > > > >> As a consequence, the selection of transports to communicate from a > > client to a server is a manual administrative action. An > automatic > > fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- > > bidding attacks on the peer communication. > > > > This (non-)recommendation is not clear to me. Actually if no other > > transport works for a given RADIUS entity or between a client and a > > server a fallback to RADIUS/UDP will always happen because this is > the > > current standard and mandatory-to-implement transport. What is meant > > here - I think - is to RECOMMEND that manual administrative > interfaces > > be made available for configuration of transport and that these > > interfaces be used to select the preferred transport between clients > > and servers. > = > The fallback scenario and this warning apply only for transition phases > where the same RADIUS client is moved from RADIUS/UDP to RADIUS/TLS. It > goes like: > = > RADIUS Server understands both UDP and TLS. > RADIUS client understands only UDP -> client is configured on the > server as the tuple (transport UDP, IP, shared secret). > = > Now the RADIUS client is scheduled for an upgrade and can from then on > also use RADIUS/TLS. To avoid a flag day, the server is configured to > accept incoming requests from that client both via UDP and TLS prior to > the client upgrade being done > -> RADIUS Server has two tuples: > (transport UDP, IP, shared secret) > (transport TLS, IP, TLS credential) > = > The client can now be upgraded at convenience to speak TLS. It might > also be tempting to configure RADIUS/UDP as a fallback if it cannot > establish a connection via TLS. > = > This opens up a bidding-down attack by an attacker sitting between > client and server: if it can silently discard TCP SYNs, the (better) > TLS encryption will not be used, and the client will send its requests > with RADIUS/UDP again. > = > Mitigating this can be done on either side. Either the RADIUS client is > configured not to use RADIUS/UDP as a fallback for its outgoing > connection attempts; or the RADIUS server can be configured to delete > the RADIUS/UDP client from its list of authorized clients. > = > The text you quoted is to make the client end aware that configuring a > fallback to RADIUS/UDP is a bad idea. > = > The text for the server side is contained in chapter 6, Security > Recommendations, last-but-one paragraph. > = > I guess the text you quoted is misplaced in the document. It would > probably be better to consolidate both sides into the Security > Considerations section. Would that be okay with you? [[DR]] Yes, this would be easier to follow. = > = > > E1. Section 2.3 > > > >> after completing the TCP handshake, immediately negotiate TLS > > sessions. The following restrictions apply: according to > > [RFC5246] or its predecessor TLS 1.1. The following > restrictions > > apply: > > > > > > 'The following restrictions apply' appears twice - drop one of them > = > Fixed in my working copy, thanks! > = > > E2. Add reference to RFC 6421 and link to it from Appendix C. > = > Fixed in my working copy, thanks! > = > Greetings, > = > Stefan Winter > = > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > = > Tel: +352 424409 1 > Fax: +352 422473 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Wed Jan 25 07:44:18 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065F21F8618 for ; Wed, 25 Jan 2012 07:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJSe6nUS0SLu for ; Wed, 25 Jan 2012 07:44:17 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7821F8613 for ; Wed, 25 Jan 2012 07:44:17 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A96B420424; Wed, 25 Jan 2012 10:43:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E14824690; Wed, 25 Jan 2012 10:44:15 -0500 (EST) From: Sam Hartman To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> <4F1F328F.8010308@deployingradius.com> Date: Wed, 25 Jan 2012 10:44:15 -0500 In-Reply-To: (Peter Deacon's message of "Tue, 24 Jan 2012 15:39:26 -0800 (Pacific Standard Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org, Alan DeKok Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:44:18 -0000 For what it's worth. I am not worried if there is an incompatibility between RFC 2865 and extensions under the following narrow case: 1) There is some attribute x assigned by the extensions document. 2) That document was unassigned prior to extensions 3) Things break if a non-extensions aware implementation inserts an instance of attribute x. I think that the issue you are raising falls into this narrow case. If so, I think the risk is acceptable and this is not a significant concern. If your issue is broader than that, you need to explain it more clearly. --Sam From radext-bounces@ietf.org Wed Jan 25 07:44:19 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A481D21F8618; Wed, 25 Jan 2012 07:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327506259; bh=OwLHuXvURGkXTq+gRqkD0LnXH5+KyhjeYzk9+r6nwus=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=c4bE6hzdWZrjcrBJ3gq+xwW/xfmLoZsA3lxfIxqfNMBRSOtq1yiHi3Kv+atEMTCJA ul6aL1j3alsjbiAER/UxbfEO1LT+Ul2fgHjCYUUV8B8jjpIpydR6XZnEKpXdoxEKnQ baN5cVftVSbUBcOpNoe2cMZib5cpqd74BXWrYEI4= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065F21F8618 for ; Wed, 25 Jan 2012 07:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJSe6nUS0SLu for ; Wed, 25 Jan 2012 07:44:17 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA7821F8613 for ; Wed, 25 Jan 2012 07:44:17 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A96B420424; Wed, 25 Jan 2012 10:43:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E14824690; Wed, 25 Jan 2012 10:44:15 -0500 (EST) From: Sam Hartman To: Peter Deacon References: <064.43236a42f17b199f30c6b249161e5808@trac.tools.ietf.org> <079.37092b2ffa342648ab61fa457da375bb@trac.tools.ietf.org> <4F1DD563.2060802@deployingradius.com> <4F1E6646.9090709@deployingradius.com> <4F1EBA5F.8070101@deployingradius.com> <4F1F328F.8010308@deployingradius.com> Date: Wed, 25 Jan 2012 10:44:15 -0500 In-Reply-To: (Peter Deacon's message of "Tue, 24 Jan 2012 15:39:26 -0800 (Pacific Standard Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: radext@ietf.org, draft-ietf-radext-radius-extensions@tools.ietf.org, trac+radext@trac.tools.ietf.org, Alan DeKok Subject: Re: [radext] #103: Long attribute fragmentation constraints X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org For what it's worth. I am not worried if there is an incompatibility between RFC 2865 and extensions under the following narrow case: 1) There is some attribute x assigned by the extensions document. 2) That document was unassigned prior to extensions 3) Things break if a non-extensions aware implementation inserts an instance of attribute x. I think that the issue you are raising falls into this narrow case. If so, I think the risk is acceptable and this is not a significant concern. If your issue is broader than that, you need to explain it more clearly. --Sam _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Wed Jan 25 09:29:46 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5321F85D0 for ; Wed, 25 Jan 2012 09:29: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmcb5GKq89SR for ; Wed, 25 Jan 2012 09:29:45 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9721F85CE for ; Wed, 25 Jan 2012 09:29:45 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 8E56E820D; Wed, 25 Jan 2012 17:29:44 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Jan 2012 17:28:45 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Wed, 25 Jan 2012 17:28:37 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Dave Nelson Date: Wed, 25 Jan 2012 17:28:34 +0000 Thread-Topic: [radext] RADEXT recharter Thread-Index: AczbhsUFFeGXegdsQ8epWEVfiglpVA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 17:29:46 -0000 Removed items noted below in forthcoming 2nd draft. MS From: Dave Nelson > Date: Mon, 23 Jan 2012 22:28:41 +0000 To: Mauricio Sanchez > Cc: "radext@ietf.org" > Subject: Re: [radext] RADEXT recharter Hi Mauricio, I'm a bit confused about a couple of the RADEXT work items that remain in t= he revised charter proposal, specifically" -RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. This has been published as RFC 6158 for "classic" RADIUS atributes, and the= corresponding guidance for "extended" atributes is included in the extende= d attributes ID. -RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. This has been published as RFC 5607. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. This has been published as RFC 6421 . - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. This has been published as RFC 5997. Unless there are new problem statements in any of these areas, I think that= these work items can be removed from teh revised charter. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From radext-bounces@ietf.org Wed Jan 25 09:29:47 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2C021F85E7; Wed, 25 Jan 2012 09:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327512587; bh=lXCacSzXeeaBF45Px4vgjWlY6EIxXdz5jV1eScjjQlQ=; h=From:To:Date:Message-ID:In-Reply-To:MIME-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=RhCTvUwiw96h4vBreNwe4kdeF9xFFY/iYnS+jQi958Tn3nTrbDfaf7VOHGb0f7VWA tuMPOWcMjqfEE4N7Ttt2fsA4QXUbLQ3KUsgO3Wo80/KwRpynFFjjZq3V8ARxniFYuG DBmF7EsNGY9RENdTaQ6gdNFZfcS3FrQO/tMxkecw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5321F85D0 for ; Wed, 25 Jan 2012 09:29: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fmcb5GKq89SR for ; Wed, 25 Jan 2012 09:29:45 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9721F85CE for ; Wed, 25 Jan 2012 09:29:45 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 8E56E820D; Wed, 25 Jan 2012 17:29:44 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Jan 2012 17:28:45 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Wed, 25 Jan 2012 17:28:37 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Dave Nelson Date: Wed, 25 Jan 2012 17:28:34 +0000 Thread-Topic: [radext] RADEXT recharter Thread-Index: AczbhsUFFeGXegdsQ8epWEVfiglpVA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Removed items noted below in forthcoming 2nd draft. MS From: Dave Nelson > Date: Mon, 23 Jan 2012 22:28:41 +0000 To: Mauricio Sanchez > Cc: "radext@ietf.org" > Subject: Re: [radext] RADEXT recharter Hi Mauricio, I'm a bit confused about a couple of the RADEXT work items that remain in the revised charter proposal, specifically" -RADIUS design guidelines. This document will provide guidelines for design of RADIUS attributes. It will specifically consider how complex data types may be introduced in a robust manner, maintaining backwards compatibility with existing RADIUS RFCs, across all the classes of attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it will review RADIUS data types and associated backwards compatibility issues. This has been published as RFC 6158 for "classic" RADIUS atributes, and the corresponding guidance for "extended" atributes is included in the extended attributes ID. -RADIUS Management authorization. This document will define the use of RADIUS for NAS management over IP. This has been published as RFC 5607. -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied on MD5 for both per-packet integrity and authentication as well as attribute confidentiality. Given the increasingly successful attacks being mounted against MD5, the ability to support alternative algorithms is required. This work item will include documentation of RADIUS crypto-agility requirements, as well as development of one or more Experimental RFCs providing support for negotiation of alternative cryptographic algorithms to protect RADIUS. This has been published as RFC 6421 . - Documentation of Status-Server usage. A document describing usage of the Status-Server facility will be developed. This has been published as RFC 5997. Unless there are new problem statements in any of these areas, I think that these work items can be removed from teh revised charter. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jan 25 09:30:02 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17E921F85F0; Wed, 25 Jan 2012 09:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327512602; bh=RYSkr6SvXEIO6pfOaCgNw5zttNJkA085XsfgGLqLxtA=; h=From:To:Date:Message-ID:In-Reply-To:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=jmH6u9vqXHpz8bdPI3ZBE8yg+LEYeOqc0a5VCLsNYeplAlb8tO73LY2I9jrYcXRAZ yURG4nXDgUWBI6lsO19rgjwWdy6Jyzyx+8SIAG2diLmt0NI++G+VYryyXXKD7q3QyG ZAVUbvUV6g4OetpuSBympN4EdpSkl9TqUxBobnic= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE57721F85F0 for ; Wed, 25 Jan 2012 09:30:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkHcCx4bSa18 for ; Wed, 25 Jan 2012 09:29:59 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id C837721F85D0 for ; Wed, 25 Jan 2012 09:29:59 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 6EED886CA; Wed, 25 Jan 2012 17:29:59 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Jan 2012 17:29:12 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Wed, 25 Jan 2012 17:29:12 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Stefan Winter , "radext@ietf.org" Date: Wed, 25 Jan 2012 17:29:09 +0000 Thread-Topic: [radext] RADEXT recharter Thread-Index: Aczbhtm0Bh2D/gATSbuJP1SujlkztQ== Message-ID: In-Reply-To: <4F1E5725.1030205@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Updated delivery date of dynamic discovery to April 2012 in forthcoming 2nd draft. MS On 1/23/12 11:00 PM, "Stefan Winter" wrote: >Hi, > >> Looks good to me. Hasn't the RADIUS over TLS draft already been >> submitted? (it's in IETF LC) > >Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is >sketched as Proposed Standard. The dynamic discovery draft has >RADIUS/TLS as a normative reference. >I'm not entirely sure about the process, but - is it okay for Standards >track to have a normative reference on Experimental? > >Also, Feb 2012 for submission seems a bit too ambitious for me. I will >certainly issue a new rev before Paris, but it will need WGLC etc. so I >don't see how Feb 2012 could be achievable. I'm thinking April at the >earliest. > >(If we aim to approve the new charter by Paris, it will already be >March; seems odd that we will have to discuss dates in the past then) > >Greetings, > >Stefan Winter > >> From: mauricio.sanchez@hp.com >> To: radext@ietf.org >> Date: Mon, 23 Jan 2012 22:11:22 +0000 >> Subject: [radext] RADEXT recharter >> = >> At IETF 82, the RADEXT WG discussed (see notes section 7 >> http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the >> charter to position the WG to be able to embrace several work items that >> the WG believes relevant, as well as recalibrating dates on several >> committed goals. >> = >> Below is the new proposed WG charter that your chairs and AD agreed >>upon. >> Attached are a PDF version of updated milestones and a marked version >> detailing changes introduced from existing charter. At this time the >> chairs would like to open up the list for discussion. Propose your >>changes >> and justify why. >> = >> Our aim is to have this re-chartering discussion completed by next IETF >> meeting. = >> = >> - Mauricio and Jouni >> = >> = >> --------- >> = >> Description of Working Group >> = >> The RADIUS Extensions Working Group will focus on extensions to the >>RADIUS >> protocol required to expand and enrich the standard attribute space, >> address cryptographic algorithm agility, use of new secure transports >>and >> clarify its usage and definition. >> = >> In order to enable interoperation of heterogeneous RADIUS/Diameter >> deployments, all RADEXT WG work items MUST contain a Diameter >> compatibility section, outlining how interoperability with Diameter will >> be maintained. >> Furthermore, to ensure backward compatibility with existing RADIUS >> implementations, as well as compatibility between RADIUS and Diameter, >>the >> following restrictions are imposed on extensions considered by the >>RADEXT >> WG: >> = >> - All documents produced MUST specify means of interoperation with >>legacy >> RADIUS and, if possible, be backward compatible with existing RADIUS >>RFCs, >> including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, >> 5090 and 5176. Transport profiles should, if possible, be compatible >>with >> RFC 3539. >> = >> - All RADIUS work MUST be compatible with equivalent facilities in >> Diameter. Where possible, new attributes should be defined so that the >> same attribute can be used in both RADIUS and Diameter without >> translation. In other cases a translation considerations section should >>be >> included in the specification. >> = >> Work Items >> The immediate goals of the RADEXT working group are to address the >> following issues: >> = >> -RADIUS design guidelines. This document will provide guidelines for >> design of RADIUS attributes. It will specifically consider how complex >> data types may be introduced in a robust manner, maintaining backwards >> compatibility with existing RADIUS RFCs, across all the classes of >> attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it >> will review RADIUS data types and associated backwards compatibility >> issues. >> = >> -RADIUS Management authorization. This document will define the use of >> RADIUS for NAS management over IP. >> = >> -RADIUS attribute space extension. The standard RADIUS attribute space >>is >> currently being depleted. This document will provide additional standard >> attribute space, while maintaining backward compatibility with existing >> attributes. >> = >> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied >> on MD5 for both per-packet integrity and authentication as well as >> attribute confidentiality. Given the increasingly successful attacks >>being >> mounted against MD5, the ability to support alternative algorithms is >> required. This work item will include documentation of RADIUS >> crypto-agility requirements, as well as development of one or more >> Experimental RFCs providing support for negotiation of alternative >> cryptographic algorithms to protect RADIUS. >> = >> -IEEE 802 attributes. New attributes have been proposed to support IEEE >> 802 standards for wired and wireless LANs. This work item will support >> authentication, authorization and accounting attributes needed by IEEE >>802 >> groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> = >> - New RADIUS transports. A reliable transport profile for RADIUS will be >> developed, as well as specifications for Secure transports, including >> TCP/TLS (RADSEC) and UDP/DTLS. >> = >> - Documentation of Status-Server usage. A document describing usage of >>the >> Status-Server facility will be developed. >> = >> - Update and clarification of Network Access Identifiers (RFC4282).This >> work item will correct and clarify egregious issues present with RFC4282 >> in two phases. In first phase, RFC4282bis will be issued to eliminate >> fundamental incompatibilities with RADIUS around character encoding and >> NAI modifications by proxies. In second phase, a fresh review of NAI >> internationalization requirements and behavior will be undertaken with a >> clear goal of maintaining compatibility with RADIUS. >> = >> Goals and Milestones >> Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication >> Done SIP RADIUS authentication draft submitted as a Proposed Standard >>RFC >> Done RFC 2486bis submitted as a Proposed Standard RFC >> Done RFC 3576 MIBs submitted as an Informational RFC >> Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed >> Standard RFC (reduced in scope) >> Done RADIUS Implementation Issues and Fixes draft submitted as an >> Informational RFC >> Done RADIUS Filtering Attributes draft submitted as a Proposed Standard >> RFC (split out from VLAN & Priority draft) >> Done RFC 3576bis submitted as an Informational RFC (split out from >>Issues >> & Fixes draft) >> Done RADIUS Redirection Attributes draft submitted as a Proposed >>Standard >> RFC (split out from VLAN & Priority draft) >> Done RADIUS Design Guidelines submitted as a Best Current Practice RFC >> Done RADIUS Management Authorization I-D submitted as a Proposed >>Standard >> RFC >> Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed >> Standard RFC >> Done Status-Server I-D submitted as a Proposed Standard RFC >> Done RADIUS Crypto-agility Requirements submitted as an Informational >>RFC >> Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental >> RFC >> Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC >> Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC >> Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC >> Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC >> Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC >> Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a >> Proposed Standard RFC >> = >> = >> = >> _______________________________________________ radext mailing list >> radext@ietf.org https://www.ietf.org/mailman/listinfo/radext >> = >> = >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > >-- = >Stefan WINTER >Ingenieur de Recherche >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale= et >de la Recherche >6, rue Richard Coudenhove-Kalergi >L-1359 Luxembourg > >Tel: +352 424409 1 >Fax: +352 422473 > _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From mauricio.sanchez@hp.com Wed Jan 25 09:30:00 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE57721F85F0 for ; Wed, 25 Jan 2012 09:30:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkHcCx4bSa18 for ; Wed, 25 Jan 2012 09:29:59 -0800 (PST) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by ietfa.amsl.com (Postfix) with ESMTP id C837721F85D0 for ; Wed, 25 Jan 2012 09:29:59 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id 6EED886CA; Wed, 25 Jan 2012 17:29:59 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 25 Jan 2012 17:29:12 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Wed, 25 Jan 2012 17:29:12 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Stefan Winter , "radext@ietf.org" Date: Wed, 25 Jan 2012 17:29:09 +0000 Thread-Topic: [radext] RADEXT recharter Thread-Index: Aczbhtm0Bh2D/gATSbuJP1SujlkztQ== Message-ID: In-Reply-To: <4F1E5725.1030205@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 17:30:00 -0000 Updated delivery date of dynamic discovery to April 2012 in forthcoming 2nd draft. MS On 1/23/12 11:00 PM, "Stefan Winter" wrote: >Hi, > >> Looks good to me. Hasn't the RADIUS over TLS draft already been >> submitted? (it's in IETF LC) > >Related: RADIUS/TLS will be Experimental, while Dynamic Discovery is >sketched as Proposed Standard. The dynamic discovery draft has >RADIUS/TLS as a normative reference. >I'm not entirely sure about the process, but - is it okay for Standards >track to have a normative reference on Experimental? > >Also, Feb 2012 for submission seems a bit too ambitious for me. I will >certainly issue a new rev before Paris, but it will need WGLC etc. so I >don't see how Feb 2012 could be achievable. I'm thinking April at the >earliest. > >(If we aim to approve the new charter by Paris, it will already be >March; seems odd that we will have to discuss dates in the past then) > >Greetings, > >Stefan Winter > >> From: mauricio.sanchez@hp.com >> To: radext@ietf.org >> Date: Mon, 23 Jan 2012 22:11:22 +0000 >> Subject: [radext] RADEXT recharter >>=20 >> At IETF 82, the RADEXT WG discussed (see notes section 7 >> http://www.ietf.org/proceedings/82/minutes/radext.txt) updating the >> charter to position the WG to be able to embrace several work items that >> the WG believes relevant, as well as recalibrating dates on several >> committed goals. >> =20 >> Below is the new proposed WG charter that your chairs and AD agreed >>upon. >> Attached are a PDF version of updated milestones and a marked version >> detailing changes introduced from existing charter. At this time the >> chairs would like to open up the list for discussion. Propose your >>changes >> and justify why. >> =20 >> Our aim is to have this re-chartering discussion completed by next IETF >> meeting. =20 >> =20 >> - Mauricio and Jouni >> =09 >> =20 >> --------- >> =20 >> Description of Working Group >> =20 >> The RADIUS Extensions Working Group will focus on extensions to the >>RADIUS >> protocol required to expand and enrich the standard attribute space, >> address cryptographic algorithm agility, use of new secure transports >>and >> clarify its usage and definition. >> =20 >> In order to enable interoperation of heterogeneous RADIUS/Diameter >> deployments, all RADEXT WG work items MUST contain a Diameter >> compatibility section, outlining how interoperability with Diameter will >> be maintained. >> Furthermore, to ensure backward compatibility with existing RADIUS >> implementations, as well as compatibility between RADIUS and Diameter, >>the >> following restrictions are imposed on extensions considered by the >>RADEXT >> WG: >> =20 >> - All documents produced MUST specify means of interoperation with >>legacy >> RADIUS and, if possible, be backward compatible with existing RADIUS >>RFCs, >> including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, >> 5090 and 5176. Transport profiles should, if possible, be compatible >>with >> RFC 3539. >> =20 >> - All RADIUS work MUST be compatible with equivalent facilities in >> Diameter. Where possible, new attributes should be defined so that the >> same attribute can be used in both RADIUS and Diameter without >> translation. In other cases a translation considerations section should >>be >> included in the specification. >> =20 >> Work Items >> The immediate goals of the RADEXT working group are to address the >> following issues: >> =20 >> -RADIUS design guidelines. This document will provide guidelines for >> design of RADIUS attributes. It will specifically consider how complex >> data types may be introduced in a robust manner, maintaining backwards >> compatibility with existing RADIUS RFCs, across all the classes of >> attributes: Standard, Vendor-Specific and SDO-Specific. In addition, it >> will review RADIUS data types and associated backwards compatibility >> issues. >> =20 >> -RADIUS Management authorization. This document will define the use of >> RADIUS for NAS management over IP. >> =20 >> -RADIUS attribute space extension. The standard RADIUS attribute space >>is >> currently being depleted. This document will provide additional standard >> attribute space, while maintaining backward compatibility with existing >> attributes. >> =20 >> -RADIUS Cryptographic Algorithm Agility. RADIUS has traditionally relied >> on MD5 for both per-packet integrity and authentication as well as >> attribute confidentiality. Given the increasingly successful attacks >>being >> mounted against MD5, the ability to support alternative algorithms is >> required. This work item will include documentation of RADIUS >> crypto-agility requirements, as well as development of one or more >> Experimental RFCs providing support for negotiation of alternative >> cryptographic algorithms to protect RADIUS. >> =20 >> -IEEE 802 attributes. New attributes have been proposed to support IEEE >> 802 standards for wired and wireless LANs. This work item will support >> authentication, authorization and accounting attributes needed by IEEE >>802 >> groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. >> =20 >> - New RADIUS transports. A reliable transport profile for RADIUS will be >> developed, as well as specifications for Secure transports, including >> TCP/TLS (RADSEC) and UDP/DTLS. >> =20 >> - Documentation of Status-Server usage. A document describing usage of >>the >> Status-Server facility will be developed. >> =20 >> - Update and clarification of Network Access Identifiers (RFC4282).This >> work item will correct and clarify egregious issues present with RFC4282 >> in two phases. In first phase, RFC4282bis will be issued to eliminate >> fundamental incompatibilities with RADIUS around character encoding and >> NAI modifications by proxies. In second phase, a fresh review of NAI >> internationalization requirements and behavior will be undertaken with a >> clear goal of maintaining compatibility with RADIUS. >> =20 >> Goals and Milestones >> Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication >> Done SIP RADIUS authentication draft submitted as a Proposed Standard >>RFC >> Done RFC 2486bis submitted as a Proposed Standard RFC >> Done RFC 3576 MIBs submitted as an Informational RFC >> Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed >> Standard RFC (reduced in scope) >> Done RADIUS Implementation Issues and Fixes draft submitted as an >> Informational RFC >> Done RADIUS Filtering Attributes draft submitted as a Proposed Standard >> RFC (split out from VLAN & Priority draft) >> Done RFC 3576bis submitted as an Informational RFC (split out from >>Issues >> & Fixes draft) >> Done RADIUS Redirection Attributes draft submitted as a Proposed >>Standard >> RFC (split out from VLAN & Priority draft) >> Done RADIUS Design Guidelines submitted as a Best Current Practice RFC >> Done RADIUS Management Authorization I-D submitted as a Proposed >>Standard >> RFC >> Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed >> Standard RFC >> Done Status-Server I-D submitted as a Proposed Standard RFC >> Done RADIUS Crypto-agility Requirements submitted as an Informational >>RFC >> Jan 2012 RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental >> RFC >> Feb 2012 IPv6 Access I-D submitted as a Proposed Standard RFC >> Feb 2012 Extended Attributes I-D submitted as a Proposed Standard RFC >> Feb 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC >> Mar 2012 RFC 4282bis submitted as a Proposed Standard RFC >> Mar 2012 RADIUS over DTLS I-D submitted as an Experimental RFC >> Apr 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a >> Proposed Standard RFC >> =20 >>=20 >>=20 >> _______________________________________________ radext mailing list >> radext@ietf.org https://www.ietf.org/mailman/listinfo/radext >>=20 >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > >--=20 >Stefan WINTER >Ingenieur de Recherche >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale= et >de la Recherche >6, rue Richard Coudenhove-Kalergi >L-1359 Luxembourg > >Tel: +352 424409 1 >Fax: +352 422473 > From mauricio.sanchez@hp.com Wed Jan 25 09:47:52 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ECE21F85AE for ; Wed, 25 Jan 2012 09:47:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOUV1sw-NOxz for ; Wed, 25 Jan 2012 09:47:49 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id A348B21F84A3 for ; Wed, 25 Jan 2012 09:47:49 -0800 (PST) Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id DF4EAC2BD; Wed, 25 Jan 2012 17:47:48 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 25 Jan 2012 17:46:48 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 25 Jan 2012 17:46:48 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok Date: Wed, 25 Jan 2012 17:46:44 +0000 Thread-Topic: [radext] RADEXT recharter Thread-Index: AczbiU+Sqylexwp9RxePQUBsRGYBsw== Message-ID: In-Reply-To: <4F1ED389.8040901@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 17:47:52 -0000 On 1/24/12 7:51 AM, "Alan DeKok" wrote: >Sanchez, Mauricio (HP Networking) wrote: >> - All documents produced MUST specify means of interoperation with >>legacy >> RADIUS and, if possible, be backward compatible with existing RADIUS >>RFCs, >> including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, >> 5090 and 5176. Transport profiles should, if possible, be compatible >>with >> RFC 3539. > > Add 6158. Done in forthcoming 2nd draft. > >> Work Items >> The immediate goals of the RADEXT working group are to address the >> following issues: > > I agree with Dave's comments here. > >> - Update and clarification of Network Access Identifiers (RFC4282).This >> work item will correct and clarify egregious issues present with RFC4282 >> in two phases. > > While I might like the word "egregious", it might be too strong for >charter text. Removed 'egregious' so as not to ruffle more feathers than necessary in forthcoming 2nd draft. > >> In first phase, RFC4282bis will be issued to eliminate >> fundamental incompatibilities with RADIUS around character encoding and >> NAI modifications by proxies. In second phase, a fresh review of NAI >> internationalization requirements and behavior will be undertaken with a >> clear goal of maintaining compatibility with RADIUS. > > I don't see how the two phases can be separated. A solution to either >phase involves using much of the work from the other phase. At IETF 82 the following proposal was discussed (as noted by the minutes) "-2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP." Does the following text better capture the consensus form IETF 82? "In first phase, RFC4282bis will be issued to deprecate RFC4282 and eliminate the fundamental RADIUS incompatibilities it exhibits.In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS." > >> Goals and Milestones >... >> Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a >> Proposed Standard RFC > > I like that timeframe. But I having a 2 year deadline is more >realistic. The issues were first brought up as important 2-3 years ago, >and little has happened since. Call it illusions of grandeur. -MS=20 From radext-bounces@ietf.org Wed Jan 25 09:47:54 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0642F21F8621; Wed, 25 Jan 2012 09:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327513674; bh=uq4IKxkNDjlVR3QInWrtL3rv8GhgRXbR14d7af4XpXU=; h=From:To:Date:Message-ID:In-Reply-To:MIME-Version:Cc:Subject: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=PmRJiSy+nsrKf59JzJabg/Z/aNgyd5ZeWY5S60TsUuLG4qW1CqSm0Er+japcxUCtk dmAICMOtgQ7dccPIb64xZnWcRtiWd88YfOQm1VdMNHkfJYzqgkRxfBMfI+atwWY0A6 UgrLPVRkZRIFxvhigYQb4IQdTTYK7sVVtM5U3ejA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ECE21F85AE for ; Wed, 25 Jan 2012 09:47:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOUV1sw-NOxz for ; Wed, 25 Jan 2012 09:47:49 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id A348B21F84A3 for ; Wed, 25 Jan 2012 09:47:49 -0800 (PST) Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id DF4EAC2BD; Wed, 25 Jan 2012 17:47:48 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 25 Jan 2012 17:46:48 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 25 Jan 2012 17:46:48 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok Date: Wed, 25 Jan 2012 17:46:44 +0000 Thread-Topic: [radext] RADEXT recharter Thread-Index: AczbiU+Sqylexwp9RxePQUBsRGYBsw== Message-ID: In-Reply-To: <4F1ED389.8040901@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 1/24/12 7:51 AM, "Alan DeKok" wrote: >Sanchez, Mauricio (HP Networking) wrote: >> - All documents produced MUST specify means of interoperation with >>legacy >> RADIUS and, if possible, be backward compatible with existing RADIUS >>RFCs, >> including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, >> 5090 and 5176. Transport profiles should, if possible, be compatible >>with >> RFC 3539. > > Add 6158. Done in forthcoming 2nd draft. > >> Work Items >> The immediate goals of the RADEXT working group are to address the >> following issues: > > I agree with Dave's comments here. > >> - Update and clarification of Network Access Identifiers (RFC4282).This >> work item will correct and clarify egregious issues present with RFC4282 >> in two phases. > > While I might like the word "egregious", it might be too strong for >charter text. Removed 'egregious' so as not to ruffle more feathers than necessary in forthcoming 2nd draft. > >> In first phase, RFC4282bis will be issued to eliminate >> fundamental incompatibilities with RADIUS around character encoding and >> NAI modifications by proxies. In second phase, a fresh review of NAI >> internationalization requirements and behavior will be undertaken with a >> clear goal of maintaining compatibility with RADIUS. > > I don't see how the two phases can be separated. A solution to either >phase involves using much of the work from the other phase. At IETF 82 the following proposal was discussed (as noted by the minutes) "-2 distinct questions - 1 to get rid of what should never have been there in the future. 2 to deal with internationalization questions.in RADIUS. Could get rid of 4282 as a first step, then address internationalization, EAP." Does the following text better capture the consensus form IETF 82? "In first phase, RFC4282bis will be issued to deprecate RFC4282 and eliminate the fundamental RADIUS incompatibilities it exhibits.In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS." > >> Goals and Milestones >... >> Oct 2012 RADIUS support for NAI Internationalization I-D submitted as a >> Proposed Standard RFC > > I like that timeframe. But I having a 2 year deadline is more >realistic. The issues were first brought up as important 2-3 years ago, >and little has happened since. Call it illusions of grandeur. -MS _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jan 25 13:48:48 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E911E80A6; Wed, 25 Jan 2012 13:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327528128; bh=uoeeiLVYsiZr1lWF/ByyVIuIegfXazGQGP6EWP2ilI8=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=K1xYcQgCg1aa/I+h4v00MtUyr2w1BdWg/vTuPdNDjEDiuSjDw/jpl9uFE3QVezLsB T5/u5w3Vs8vbEkZEb6pBlObOhenK7G98h91JRvN9yh+Zr/4o+gxQQVijIzzu+D4074 Ctmd18V7WOi0Kk+BXV9m3M+ZSqefnzbLO6dtDNDc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4211E80A6 for ; Wed, 25 Jan 2012 13:48:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2XxZHUqY8oZ for ; Wed, 25 Jan 2012 13:48:47 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4311E8098 for ; Wed, 25 Jan 2012 13:48:47 -0800 (PST) Received: from [10.33.12.84] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 638397FF9; Wed, 25 Jan 2012 22:48:45 +0100 (CET) Message-ID: <4F2078A8.4060202@venaas.com> Date: Wed, 25 Jan 2012 13:48:24 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4F1E5725.1030205@restena.lu> In-Reply-To: Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 1/24/2012 3:58 AM, Sam Hartman wrote: >>>>>> "Stefan" == Stefan Winter writes: > > Stefan> Hi, > >> Looks good to me. Hasn't the RADIUS over TLS draft already been > >> submitted? (it's in IETF LC) > > Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic > Stefan> Discovery is sketched as Proposed Standard. The dynamic > Stefan> discovery draft has RADIUS/TLS as a normative reference. > Stefan> I'm not entirely sure about the process, but - is it okay > Stefan> for Standards track to have a normative reference on > Stefan> Experimental? > > There is a procedure for doing this, but I don't understand why it is > appropriate in this instance. > In my mind the dynamic discovery stuff is far more experimental than > RADIUS over TLS. I agree. It seems a bit odd the way it is now. I don't remember why RADIUS over TLS was decided to be experimental. Dynamic discovery certainly sounds experimental though. Stig > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stig@venaas.com Wed Jan 25 13:48:47 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4211E80A6 for ; Wed, 25 Jan 2012 13:48:47 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2XxZHUqY8oZ for ; Wed, 25 Jan 2012 13:48:47 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4311E8098 for ; Wed, 25 Jan 2012 13:48:47 -0800 (PST) Received: from [10.33.12.84] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 638397FF9; Wed, 25 Jan 2012 22:48:45 +0100 (CET) Message-ID: <4F2078A8.4060202@venaas.com> Date: Wed, 25 Jan 2012 13:48:24 -0800 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4F1E5725.1030205@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:48:48 -0000 On 1/24/2012 3:58 AM, Sam Hartman wrote: >>>>>> "Stefan" == Stefan Winter writes: > > Stefan> Hi, > >> Looks good to me. Hasn't the RADIUS over TLS draft already been > >> submitted? (it's in IETF LC) > > Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic > Stefan> Discovery is sketched as Proposed Standard. The dynamic > Stefan> discovery draft has RADIUS/TLS as a normative reference. > Stefan> I'm not entirely sure about the process, but - is it okay > Stefan> for Standards track to have a normative reference on > Stefan> Experimental? > > There is a procedure for doing this, but I don't understand why it is > appropriate in this instance. > In my mind the dynamic discovery stuff is far more experimental than > RADIUS over TLS. I agree. It seems a bit odd the way it is now. I don't remember why RADIUS over TLS was decided to be experimental. Dynamic discovery certainly sounds experimental though. Stig > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From radext-bounces@ietf.org Wed Jan 25 13:58:49 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96A11E80A6; Wed, 25 Jan 2012 13:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327528729; bh=RD5w6tya99lAbyRB5ORDloi1/aBLpZUPy44wE6iPgsw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=xe7wr6svzz1Su+Rf4y6MOC1Lc1GFTVmSRYDcaEUZU2wcaETkSA6b+qMOIXbTZKkyb 1Z5z3y3csKrnvoZc60u5neAVDe0oy8XbYW16q/cu3C2NRlY1Ylq/GLQQYLrHvgBsQp EL/cidWqhR4PiLHXf4d17hPDw19T7bkF2FJPhHDY= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3751E11E80A6 for ; Wed, 25 Jan 2012 13:58:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h56VTic2zy7F for ; Wed, 25 Jan 2012 13:58:47 -0800 (PST) Received: from out26-ams.mf.surf.net (out26-ams.mf.surf.net [145.0.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5625811E8098 for ; Wed, 25 Jan 2012 13:58:47 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0PLwjNR003435 for ; Wed, 25 Jan 2012 22:58:45 +0100 Received: from 128-107-239-233.cisco.com ([128.107.239.233] helo=sjc-vpnasa-680.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RqArB-000OM1-8Y for radext@ietf.org; Wed, 25 Jan 2012 22:58:17 +0100 Message-ID: <4F207B13.7010901@wierenga.net> Date: Wed, 25 Jan 2012 22:58:43 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: radext@ietf.org References: <4F1E5725.1030205@restena.lu> <4F2078A8.4060202@venaas.com> In-Reply-To: <4F2078A8.4060202@venaas.com> X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uGpVWJHX - 2feb9039985c - 20120125 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.26 Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On 1/25/12 10:48 PM, Stig Venaas wrote: > On 1/24/2012 3:58 AM, Sam Hartman wrote: >>>>>>> "Stefan" == Stefan Winter writes: >> >> Stefan> Hi, >> >> Looks good to me. Hasn't the RADIUS over TLS draft already been >> >> submitted? (it's in IETF LC) >> >> Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic >> Stefan> Discovery is sketched as Proposed Standard. The dynamic >> Stefan> discovery draft has RADIUS/TLS as a normative reference. >> Stefan> I'm not entirely sure about the process, but - is it okay >> Stefan> for Standards track to have a normative reference on >> Stefan> Experimental? >> >> There is a procedure for doing this, but I don't understand why it is >> appropriate in this instance. >> In my mind the dynamic discovery stuff is far more experimental than >> RADIUS over TLS. > > I agree. It seems a bit odd the way it is now. I don't remember why > RADIUS over TLS was decided to be experimental. Dynamic discovery > certainly sounds experimental though. I agree too. Is there any procedure for reclassifying the draft? Klaas _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From klaas@wierenga.net Wed Jan 25 13:58:48 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3751E11E80A6 for ; Wed, 25 Jan 2012 13:58:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h56VTic2zy7F for ; Wed, 25 Jan 2012 13:58:47 -0800 (PST) Received: from out26-ams.mf.surf.net (out26-ams.mf.surf.net [145.0.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5625811E8098 for ; Wed, 25 Jan 2012 13:58:47 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0PLwjNR003435 for ; Wed, 25 Jan 2012 22:58:45 +0100 Received: from 128-107-239-233.cisco.com ([128.107.239.233] helo=sjc-vpnasa-680.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RqArB-000OM1-8Y for radext@ietf.org; Wed, 25 Jan 2012 22:58:17 +0100 Message-ID: <4F207B13.7010901@wierenga.net> Date: Wed, 25 Jan 2012 22:58:43 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: radext@ietf.org References: <4F1E5725.1030205@restena.lu> <4F2078A8.4060202@venaas.com> In-Reply-To: <4F2078A8.4060202@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uGpVWJHX - 2feb9039985c - 20120125 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.26 Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:58:48 -0000 On 1/25/12 10:48 PM, Stig Venaas wrote: > On 1/24/2012 3:58 AM, Sam Hartman wrote: >>>>>>> "Stefan" == Stefan Winter writes: >> >> Stefan> Hi, >> >> Looks good to me. Hasn't the RADIUS over TLS draft already been >> >> submitted? (it's in IETF LC) >> >> Stefan> Related: RADIUS/TLS will be Experimental, while Dynamic >> Stefan> Discovery is sketched as Proposed Standard. The dynamic >> Stefan> discovery draft has RADIUS/TLS as a normative reference. >> Stefan> I'm not entirely sure about the process, but - is it okay >> Stefan> for Standards track to have a normative reference on >> Stefan> Experimental? >> >> There is a procedure for doing this, but I don't understand why it is >> appropriate in this instance. >> In my mind the dynamic discovery stuff is far more experimental than >> RADIUS over TLS. > > I agree. It seems a bit odd the way it is now. I don't remember why > RADIUS over TLS was decided to be experimental. Dynamic discovery > certainly sounds experimental though. I agree too. Is there any procedure for reclassifying the draft? Klaas From dnelson@elbrys.com Wed Jan 25 14:56:55 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C23721F85A3 for ; Wed, 25 Jan 2012 14:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBSYIm8DGr9Q for ; Wed, 25 Jan 2012 14:56:54 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 77E8C21F85A2 for ; Wed, 25 Jan 2012 14:56:54 -0800 (PST) Received: from mail-vw0-f52.google.com ([209.85.212.52]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTyCItW+e2KeHxKhQcqwhG5YAFmR2DHRJ@postini.com; Wed, 25 Jan 2012 14:56:54 PST Received: by mail-vw0-f52.google.com with SMTP id fp1so2942707vbb.39 for ; Wed, 25 Jan 2012 14:56:53 -0800 (PST) Received: by 10.52.94.148 with SMTP id dc20mr10383058vdb.109.1327532213565; Wed, 25 Jan 2012 14:56:53 -0800 (PST) Received: from [192.168.1.103] (c-24-218-90-45.hsd1.nh.comcast.net. [24.218.90.45]) by mx.google.com with ESMTPS id g13sm2051100vdh.8.2012.01.25.14.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 14:56:53 -0800 (PST) References: <4F1E5725.1030205@restena.lu> <4F2078A8.4060202@venaas.com> <4F207B13.7010901@wierenga.net> In-Reply-To: <4F207B13.7010901@wierenga.net> Mime-Version: 1.0 (1.0) Message-Id: <9881168A-0158-40B3-9F49-2408AF0B8D2A@elbrys.com> X-Mailer: iPad Mail (9A405) From: "David B. Nelson" Date: Wed, 25 Jan 2012 17:56:52 -0500 To: Klaas Wierenga X-Gm-Message-State: ALoCoQllpJL+FqpvkZqDp65mIHbdRPULFTc83TCe76HBEmGtoQAucKRap5QOvcczzhl6iXoBhXkc Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:56:55 -0000 On Jan 25, 2012, at 4:58 PM, Klaas Wierenga wrote: >>> There is a procedure for doing this, but I don't understand why it is >>> appropriate in this instance. >>> In my mind the dynamic discovery stuff is far more experimental than >>> RADIUS over TLS. >>=20 >> I agree. It seems a bit odd the way it is now. I don't remember why >> RADIUS over TLS was decided to be experimental. Dynamic discovery >> certainly sounds experimental though. >=20 > I agree too. Is there any procedure for reclassifying the draft? Perhaps because all RADIUS Crypto-Agility solutions are to be published as e= xperimental until field experience sorts out which should become standards t= rack?= From radext-bounces@ietf.org Wed Jan 25 14:56:56 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4E321F85A3; Wed, 25 Jan 2012 14:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327532216; bh=e2DGLf/C8lLzptCycy4bip5KDknzl3HpIiRpFVbTKic=; h=References:In-Reply-To:Mime-Version:Message-Id:From:Date:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=L89bDKLcZTgY6cT9LwNDQDKqkokLM3Jl4GI6S1/OrEi2sJPd9IUXNsdwrmXEnYURE HgUxh16CzW3b10mAuDgiEm7Tht9RV3wUzuLeQ/twYGa9DU4Nq5kCWfsoW4qPgbDSjl FWQcDi2LWhx8EgFF++e3LzjnLik1km7w8iUZoPhA= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C23721F85A3 for ; Wed, 25 Jan 2012 14:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBSYIm8DGr9Q for ; Wed, 25 Jan 2012 14:56:54 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with SMTP id 77E8C21F85A2 for ; Wed, 25 Jan 2012 14:56:54 -0800 (PST) Received: from mail-vw0-f52.google.com ([209.85.212.52]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTyCItW+e2KeHxKhQcqwhG5YAFmR2DHRJ@postini.com; Wed, 25 Jan 2012 14:56:54 PST Received: by mail-vw0-f52.google.com with SMTP id fp1so2942707vbb.39 for ; Wed, 25 Jan 2012 14:56:53 -0800 (PST) Received: by 10.52.94.148 with SMTP id dc20mr10383058vdb.109.1327532213565; Wed, 25 Jan 2012 14:56:53 -0800 (PST) Received: from [192.168.1.103] (c-24-218-90-45.hsd1.nh.comcast.net. [24.218.90.45]) by mx.google.com with ESMTPS id g13sm2051100vdh.8.2012.01.25.14.56.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 14:56:53 -0800 (PST) References: <4F1E5725.1030205@restena.lu> <4F2078A8.4060202@venaas.com> <4F207B13.7010901@wierenga.net> In-Reply-To: <4F207B13.7010901@wierenga.net> Mime-Version: 1.0 (1.0) Message-Id: <9881168A-0158-40B3-9F49-2408AF0B8D2A@elbrys.com> X-Mailer: iPad Mail (9A405) From: "David B. Nelson" Date: Wed, 25 Jan 2012 17:56:52 -0500 To: Klaas Wierenga X-Gm-Message-State: ALoCoQllpJL+FqpvkZqDp65mIHbdRPULFTc83TCe76HBEmGtoQAucKRap5QOvcczzhl6iXoBhXkc Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org On Jan 25, 2012, at 4:58 PM, Klaas Wierenga wrote: >>> There is a procedure for doing this, but I don't understand why it is >>> appropriate in this instance. >>> In my mind the dynamic discovery stuff is far more experimental than >>> RADIUS over TLS. >> >> I agree. It seems a bit odd the way it is now. I don't remember why >> RADIUS over TLS was decided to be experimental. Dynamic discovery >> certainly sounds experimental though. > > I agree too. Is there any procedure for reclassifying the draft? Perhaps because all RADIUS Crypto-Agility solutions are to be published as experimental until field experience sorts out which should become standards track? _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Wed Jan 25 22:55:24 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482CB11E80CD for ; Wed, 25 Jan 2012 22:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSmakCDYKJYY for ; Wed, 25 Jan 2012 22:55:23 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA2311E8075 for ; Wed, 25 Jan 2012 22:55:23 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 21D01106CB for ; Thu, 26 Jan 2012 07:55:22 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id 10138106C2 for ; Thu, 26 Jan 2012 07:55:22 +0100 (CET) Message-ID: <4F20F8D2.30203@restena.lu> Date: Thu, 26 Jan 2012 07:55:14 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4F1E5725.1030205@restena.lu> <4F2078A8.4060202@venaas.com> <4F207B13.7010901@wierenga.net> <9881168A-0158-40B3-9F49-2408AF0B8D2A@elbrys.com> In-Reply-To: <9881168A-0158-40B3-9F49-2408AF0B8D2A@elbrys.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BA8AE1AF89B064A4F65DAE6" X-Virus-Scanned: ClamAV Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:55:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BA8AE1AF89B064A4F65DAE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Perhaps because all RADIUS Crypto-Agility solutions are to be published= as experimental until field experience sorts out which should become sta= ndards track? Right, that was the reason for making RADIUS/TLS Experimental in the first place. It is also what the new paragraph "Document Status" in the upcoming draft rev states (see my message yesterday). I see Klaas' argument more the other way around: shouldn't we reclassify dynamic discovery to also be Experimental? As time passes by, maybe/hopefully RADIUS/TLS will be selected for staandards track, and then dynamic discovery could follow some time later= =2E Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig3BA8AE1AF89B064A4F65DAE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8g+NkACgkQ+jm90f8eFWZkMQCeO86Dmp3axwoMJk+KqPe5IyWt A6EAn2osgeba2wFZj3Bdg7JruLQKbrbO =H3rn -----END PGP SIGNATURE----- --------------enig3BA8AE1AF89B064A4F65DAE6-- From radext-bounces@ietf.org Wed Jan 25 22:55:27 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5E111E80BB; Wed, 25 Jan 2012 22:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327560926; bh=3FjHtd4Qetiy7hFVdIACgk6DuFngs6PQ/boI/9u0s44=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=DvbPqCUDDxSL3Utc3cnmxpI5G+VC3YbWVqaW/CsZ5rnG1DLnj7ebk8E8C8N0ly+P8 JpApBWr/Y14opM+CjGTHldHukoCSzi6s+qK/siD+f/ajNw6imZgTESLkTTBT8w3FrS QFtNT4GPYDK52UcbOHv4FyTtVADiU0QLf2omvoyo= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482CB11E80CD for ; Wed, 25 Jan 2012 22:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSmakCDYKJYY for ; Wed, 25 Jan 2012 22:55:23 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA2311E8075 for ; Wed, 25 Jan 2012 22:55:23 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 21D01106CB for ; Thu, 26 Jan 2012 07:55:22 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id 10138106C2 for ; Thu, 26 Jan 2012 07:55:22 +0100 (CET) Message-ID: <4F20F8D2.30203@restena.lu> Date: Thu, 26 Jan 2012 07:55:14 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4F1E5725.1030205@restena.lu> <4F2078A8.4060202@venaas.com> <4F207B13.7010901@wierenga.net> <9881168A-0158-40B3-9F49-2408AF0B8D2A@elbrys.com> In-Reply-To: <9881168A-0158-40B3-9F49-2408AF0B8D2A@elbrys.com> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3772768937111310040==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3772768937111310040== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3BA8AE1AF89B064A4F65DAE6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3BA8AE1AF89B064A4F65DAE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Perhaps because all RADIUS Crypto-Agility solutions are to be published= as experimental until field experience sorts out which should become sta= ndards track? Right, that was the reason for making RADIUS/TLS Experimental in the first place. It is also what the new paragraph "Document Status" in the upcoming draft rev states (see my message yesterday). I see Klaas' argument more the other way around: shouldn't we reclassify dynamic discovery to also be Experimental? As time passes by, maybe/hopefully RADIUS/TLS will be selected for staandards track, and then dynamic discovery could follow some time later= =2E Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig3BA8AE1AF89B064A4F65DAE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8g+NkACgkQ+jm90f8eFWZkMQCeO86Dmp3axwoMJk+KqPe5IyWt A6EAn2osgeba2wFZj3Bdg7JruLQKbrbO =H3rn -----END PGP SIGNATURE----- --------------enig3BA8AE1AF89B064A4F65DAE6-- --===============3772768937111310040== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3772768937111310040==-- From stefan.winter@restena.lu Wed Jan 25 23:02:50 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED921F8646 for ; Wed, 25 Jan 2012 23:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9PZDVmCX1ES for ; Wed, 25 Jan 2012 23:02:49 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id EFE4A21F8645 for ; Wed, 25 Jan 2012 23:02:48 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 57745106CB for ; Thu, 26 Jan 2012 08:02:48 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id 48685106C2 for ; Thu, 26 Jan 2012 08:02:48 +0100 (CET) Message-ID: <4F20FA98.2040200@restena.lu> Date: Thu, 26 Jan 2012 08:02:48 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4F1FDD6B.2000000@restena.lu> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44B064358267DF846636B4B1" X-Virus-Scanned: ClamAV Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 07:02:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44B064358267DF846636B4B1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The LC ends tomorrow, Can you make a new version available immediately = after, so that I can place the document on the agenda of the 2/2 IESG tel= echat?=20 Sure thing. If all goes well, -11 should be out tomorrow (Friday). Two things inline. >> 1.3. Document Status >> >> This document is an Experimental RFC. >> >> It is one out of several approaches to address known cryptographic >> weaknesses of the RADIUS protocol (see also Section 4). The >> specification does not fulfill all recommendations on a AAA >> transport >> profile as per [RFC3539]; in particular, by being based on TCP as a= >> transport layer, it does not prevent head-of-line blocking issues. >> >> It has yet to be decided whether this approach is to be chosen for >> standards track. One key aspect to judge whether the approach is >> usable at large scale is by observing the uptake, usability and >> operational behaviour of the protocol in large-scale, real-life >> deployments. One of these deployments could be the eduroam roaming= >> consortium. >> >> Does that address your comment? >=20 >=20 > [[DR]] Yes. My only comment would be that I would keep the mention to t= he eduroam deployment in a separate paragraph and keep the existing wordi= ng about it:=20 >=20 > An example for a world-wide roaming environment that uses RADIUS ove= r > TLS to secure communication is "eduroam", see [eduroam]. Ok, changed in my working copy. >> I guess the text you quoted is misplaced in the document. It would >> probably be better to consolidate both sides into the Security >> Considerations section. Would that be okay with you? >=20 >=20 > [[DR]] Yes, this would be easier to follow.=20 Ok. Bernard also raised an issue about this paragraph in the aaa-doctors review, so I'll change the wording as per his comment and move it all to Security Considerations. Thanks, Stefan >=20 >> >>> E1. Section 2.3 >>> >>>> after completing the TCP handshake, immediately negotiate TLS >>> sessions. The following restrictions apply: according to >>> [RFC5246] or its predecessor TLS 1.1. The following >> restrictions >>> apply: >>> >>> >>> 'The following restrictions apply' appears twice - drop one of them >> >> Fixed in my working copy, thanks! >> >>> E2. Add reference to RFC 6421 and link to it from Appendix C. >> >> Fixed in my working copy, thanks! >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig44B064358267DF846636B4B1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8g+pgACgkQ+jm90f8eFWZABACfbcEQLXhQ/Nr4fkJyHfvJZa3c 2vcAnjCB1Lm5Z2irz7bGkty7Rx/C6x+K =Z/fB -----END PGP SIGNATURE----- --------------enig44B064358267DF846636B4B1-- From radext-bounces@ietf.org Wed Jan 25 23:02:52 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF3721F8634; Wed, 25 Jan 2012 23:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327561372; bh=nuvrtM2FzFn1pmIQLDr/88ulVHkkesWfmommGm4hkpI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=hX7rxU6qeh+hFlqKSrp6sQmhr27YMceGqlx4lQDBfaPa9O6ZjGdZh8SizXdZdHNdZ U7EDU4WaruQUMLSSs/X51E8uMTWXSenZi4lRUofrEJvciLojjTH18NGibj0VPUh8jf V9Kl4Nt9Mn5y55dWNvRXMXMW0LJBEExxAEkMCQoU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EED921F8646 for ; Wed, 25 Jan 2012 23:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9PZDVmCX1ES for ; Wed, 25 Jan 2012 23:02:49 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id EFE4A21F8645 for ; Wed, 25 Jan 2012 23:02:48 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 57745106CB for ; Thu, 26 Jan 2012 08:02:48 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id 48685106C2 for ; Thu, 26 Jan 2012 08:02:48 +0100 (CET) Message-ID: <4F20FA98.2040200@restena.lu> Date: Thu, 26 Jan 2012 08:02:48 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <4F1FDD6B.2000000@restena.lu> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] AD Review of draft-ietf-radext-radsec-10 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7636427777365704385==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7636427777365704385== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44B064358267DF846636B4B1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44B064358267DF846636B4B1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > The LC ends tomorrow, Can you make a new version available immediately = after, so that I can place the document on the agenda of the 2/2 IESG tel= echat?=20 Sure thing. If all goes well, -11 should be out tomorrow (Friday). Two things inline. >> 1.3. Document Status >> >> This document is an Experimental RFC. >> >> It is one out of several approaches to address known cryptographic >> weaknesses of the RADIUS protocol (see also Section 4). The >> specification does not fulfill all recommendations on a AAA >> transport >> profile as per [RFC3539]; in particular, by being based on TCP as a= >> transport layer, it does not prevent head-of-line blocking issues. >> >> It has yet to be decided whether this approach is to be chosen for >> standards track. One key aspect to judge whether the approach is >> usable at large scale is by observing the uptake, usability and >> operational behaviour of the protocol in large-scale, real-life >> deployments. One of these deployments could be the eduroam roaming= >> consortium. >> >> Does that address your comment? >=20 >=20 > [[DR]] Yes. My only comment would be that I would keep the mention to t= he eduroam deployment in a separate paragraph and keep the existing wordi= ng about it:=20 >=20 > An example for a world-wide roaming environment that uses RADIUS ove= r > TLS to secure communication is "eduroam", see [eduroam]. Ok, changed in my working copy. >> I guess the text you quoted is misplaced in the document. It would >> probably be better to consolidate both sides into the Security >> Considerations section. Would that be okay with you? >=20 >=20 > [[DR]] Yes, this would be easier to follow.=20 Ok. Bernard also raised an issue about this paragraph in the aaa-doctors review, so I'll change the wording as per his comment and move it all to Security Considerations. Thanks, Stefan >=20 >> >>> E1. Section 2.3 >>> >>>> after completing the TCP handshake, immediately negotiate TLS >>> sessions. The following restrictions apply: according to >>> [RFC5246] or its predecessor TLS 1.1. The following >> restrictions >>> apply: >>> >>> >>> 'The following restrictions apply' appears twice - drop one of them >> >> Fixed in my working copy, thanks! >> >>> E2. Add reference to RFC 6421 and link to it from Appendix C. >> >> Fixed in my working copy, thanks! >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig44B064358267DF846636B4B1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8g+pgACgkQ+jm90f8eFWZABACfbcEQLXhQ/Nr4fkJyHfvJZa3c 2vcAnjCB1Lm5Z2irz7bGkty7Rx/C6x+K =Z/fB -----END PGP SIGNATURE----- --------------enig44B064358267DF846636B4B1-- --===============7636427777365704385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7636427777365704385==-- From aland@deployingradius.com Wed Jan 25 23:46:23 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9421F8656 for ; Wed, 25 Jan 2012 23:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdJSX1r0TMT9 for ; Wed, 25 Jan 2012 23:46:22 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0921F8655 for ; Wed, 25 Jan 2012 23:46:22 -0800 (PST) Message-ID: <4F2104B3.3030500@deployingradius.com> Date: Thu, 26 Jan 2012 08:45:55 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 07:46:23 -0000 Sanchez, Mauricio (HP Networking) wrote: > Does the following text better capture the consensus form IETF 82? > > "In first phase, RFC4282bis will be issued to deprecate RFC4282 and > eliminate the fundamental RADIUS incompatibilities it exhibits.In second > phase, a fresh review of NAI internationalization requirements and > behavior will be undertaken with a clear goal of maintaining compatibility > with RADIUS." That is clearer to me. Alan DeKok. From radext-bounces@ietf.org Wed Jan 25 23:46:24 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E40621F8656; Wed, 25 Jan 2012 23:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327563984; bh=r7XRUWRGL2+IRcofV1j9ABtagZ+p36+fk1M0dBdgmKY=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=AfzOFOjd2HAhB1PgppuO2KFE1/9KWSqIImg2q151N7zhz3PBT2d3JQrZzvDlxt4qk EW+fa1en0HgWvLKyA83ryfP4V4TZU+I+I6zjK9pi1Uf+TeEOdoDB/UF28LyM4OYaai ISUYaIgajJnj8FoAIGtGH6S9+3h/90B5C4G3FE7c= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9421F8656 for ; Wed, 25 Jan 2012 23:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.344 X-Spam-Level: X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdJSX1r0TMT9 for ; Wed, 25 Jan 2012 23:46:22 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 26D0921F8655 for ; Wed, 25 Jan 2012 23:46:22 -0800 (PST) Message-ID: <4F2104B3.3030500@deployingradius.com> Date: Thu, 26 Jan 2012 08:45:55 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Sanchez, Mauricio (HP Networking) wrote: > Does the following text better capture the consensus form IETF 82? > > "In first phase, RFC4282bis will be issued to deprecate RFC4282 and > eliminate the fundamental RADIUS incompatibilities it exhibits.In second > phase, a fresh review of NAI internationalization requirements and > behavior will be undertaken with a clear goal of maintaining compatibility > with RADIUS." That is clearer to me. Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Thu Jan 26 00:08:39 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BCA11E8075; Thu, 26 Jan 2012 00:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSozpH1+0yZS; Thu, 26 Jan 2012 00:08:37 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A15DB21F8567; Thu, 26 Jan 2012 00:08:29 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D4091106CB; Thu, 26 Jan 2012 09:08:28 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id C14F010691; Thu, 26 Jan 2012 09:08:28 +0100 (CET) Message-ID: <4F2109F8.4060505@restena.lu> Date: Thu, 26 Jan 2012 09:08:24 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ietf@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F474C2ACA5DD7A01FB6B5D2" X-Virus-Scanned: ClamAV Cc: radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 08:08:39 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F474C2ACA5DD7A01FB6B5D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, comments inline. > This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radse= c. >=20 > Overall, this draft was a pleasant to read, and it is clear that a lot > of thought as well as implementation experience has gone into it. >=20 > Kudos to the authors. Thanks :-) > General Issues >=20 > There is a considerable amount of text relating to dynamic discovery in= > this document, yet > there is only an informational reference to it. That's true. As I went through your comments below, I realised that large parts of the texts you quoted should be moved to the dynamic-discovery draft altogether as they are are very specific to that draft. I'm thinking of taking out all the snippets you mentioned below, transfer them to dynamic-discovery and leaving nothing but a small "pointer" paragraph in the RADIUS/TLS document. This actually coincides with what we've experienced in deployment. While in earlier times I considered TLS and dynamic discovery rather intertwined, operations people tell me that these are two very distinct things; most have no problem changing from UDP to TLS, while leaving their servers behind a firewall and opening it only to the same known peers as before; merely changing the transport. They do tend to have more of a problem with opening the port to the world at large and move away from hard-wired configurations of known peer addresses though. So it's indeed best to keep both aspects nicely separated. > Since inserting a normative reference to dynamic discovery could delay > the publication of > this document unnecessarily, my recommendation is to consolidate some o= f > the dynamic > discovery material into a single section in which you can discuss the > implications, while > clearly indicating the status of the dynamic discovery work (e.g. still= > under development, optional to > implement along with RADSEC, etc.). >=20 > For example, you might consider consolidating the following text from > Sections 3.1 and 6 > and placing it prior to the current Section 3.1: >=20 > Section 3.X: Implications of Dynamic Peer Discovery >=20 > One mechanism to discover RADIUS over TLS peers dynamically via DNS > is specified in [I-D.ietf-radext-dynamic-discovery]. While this > mechanism > is still under development and therefore is not a normative dependen= cy of > RADIUS/TLS, the use of dynamic discovery has potential future > implications that are > important to understand. I'll add that to the text. Since the text about dynamic discovery would be externalised to the other draft, how about if I add a sentence: "Readers of this document who are considering the deployment of DNS-based dynamic discovery are thus encouraged to read [I-D.ietf-radext-dynamic-discovery] and follow its future development." ?= Then, those who care can read up on it, while the others just read how to do TLS instead of UDP. > If dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery] is used, peer authentication > alone is not sufficient; the peer must also be authorised to perform= > user authentications. In these cases, the trust fabric cannot depen= d > on peer authentication methods like DNSSEC to identify RADIUS/TLS > nodes. The nodes also need to be properly authorised. Typically, > this can be achieved by adding appropriate authorisation fields into= > a X.509 certificate. Such fields include SRV authority [RFC4985], > subjectAltNames, or a defined list of certificate fingerprints. > Operators of a RADIUS/TLS infrastructure should define their own > authorisation trust model and apply this model to the certificates. > The checks enumerated in Section 2.3 provide sufficient flexibility > for the implementation of authorisation trust models. >=20 > [BA] I think you need to be more prescriptive here. Are there specific= > fields that a RADSEC TLS certificate should contain? Having individual= > implementations/deployments defining their own authorization schemes se= ems > like a bad idea.=20 That text is best moved out to dynamic-discovery anyway. But to address your point: this was discussed numerous times in radext wg meetings. The conclusion in the end was that it is hard to foresee how trust fabrics are created by people in the wild, so it seemed like a bad idea to be too prescriptive. E.g. in eduroam we've already been experimenting with two ( 1) subjectAltName:URI to contain a specific value 2) policyOID to distinguish "authorized eduroam" servers from others Chances are that we might experiment with more, e.g. DNSSEC subtrees with DANE records. This goes together with the current discussion of making dynamic discovery Experimental - then observe how trust models work, and be more concrete if the document makes it to standards track. > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be > able to accept connections from a large, not previously known, group= > of hosts, possibly the whole internet. In this case, the server's > RADIUS/TLS port can not be protected from unauthorised connection > attempts with measures on the network layer, i.e. access lists and > firewalls. This opens more attack vectors for Distributed Denial of= > Service attacks, just like any other service that is supposed to > serve arbitrary clients (like for example web servers). >=20 > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only= > proof of authorisation for a connecting RADIUS/TLS nodes. Special > care needs to be taken that certificates get verified properly > according to the chosen trust model (particularly: consulting CRLs, > checking critical extensions, checking subjectAltNames etc.) to > prevent unauthorised connections. Both of these security considerations apply only to deployers of dynamic-discovery; so they should be moved to dynamic-discovery. >=20 > Other comments >=20 > Section 1 >=20 > One mechanism to discover RADIUS over TLS peers with DNS is specifie= d in > [I-D.ietf-radext-dynamic-discovery]. >=20 > [BA] Recommend moving this to a section devoted to dynamic discovery. Done in my working copy, by using your text above. >=20 > Section 2.1 >=20 > See > section Section 3.3 (4) and (5) for considerations regarding > separation of authentication, accounting and dynauth traffic. >=20 > [BA] Recommend changing to: >=20 > "See Section 3.3 for considerations regarding separation of > authentication, accounting and dynamic authorisation traffic." Done in my working copy. >=20 > Section 2.3 >=20 > 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The= > shared secret to compute the (obsolete) MD5 integrity checks and= > attribute encryption MUST be "radsec" (see Section 3.3 (2) ). >=20 > Section 3.1 >=20 > (3) If dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery] is used, peer authentication > alone is not sufficient; the peer must also be authorised to perform= > user authentications. In these cases, the trust fabric cannot depen= d > on peer authentication methods like DNSSEC to identify RADIUS/TLS > nodes. The nodes also need to be properly authorised. Typically, > this can be achieved by adding appropriate authorisation fields into= > a X.509 certificate. Such fields include SRV authority [RFC4985], > subjectAltNames, or a defined list of certificate fingerprints. > Operators of a RADIUS/TLS infrastructure should define their own > authorisation trust model and apply this model to the certificates. > The checks enumerated in Section 2.3 provide sufficient flexibility > for the implementation of authorisation trust models. >=20 > As noted above, I'd suggest removing this material from Section 3.1 and= > consolidating it with other dynamic-discovery material. =20 Moved out to dynamic-discovery. >=20 > Section 3.3 >=20 > Note well: it is not required for an implementation > to actually process these packet types. It is sufficient that upon > receiving such a packet, an unconditional NAK is sent back to > indicate that the action is not supported. >=20 > [BA] What Error-Cause attribute value should be included within the NAK= > to make it > clear that the action is not supported? Error 406 "Unsupported Extensi= on"? > That is what RFC 5176 Section 3.5 seems to indicate. Indeed. I'll update the text to that end. Note though that adding Error-Cause is a MAY only in 5176, so it may very well be that an implementation which doesn't support dynauth would still send only a "naked" NAK, ignoring the MAY. I've put the following text into my working copy: (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. The NAK MAY contain an attribute Error-Cause with the value 406 ("Unsupported Extension"); see [RFC5176] for details. > There > is no RADIUS datagram to signal an Accounting NAK. Clients may be > misconfigured to send Accounting packets to a RADIUS/TLS server whic= h > does not wish to process their Accounting packet. The server will > need to silently drop the packet. The client will need to deduce > from the absence of replies that it is misconfigured; no negative > ICMP response will reveal this. >=20 > [BA] This seems like a bad idea. How about requiring implementations n= ot > supporting Accounting to respond with an Accounting-Response containing= > Error-Cause attribute value 406? Implementations receiving an > Accounting-Response > with this Error-Cause can be required to treat this like an ICMP respon= se. I'm slightly confused here. To my best knowledge, Error-cause is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurence table in 5176. I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics. And to be honest, I would even be rather against such a change, and introduce a proper Accounting-NAK packet type instead; but that's a different story. The non-ability to indicate "No accounting please" has been discussed in a radext wg meetint. The conclusion was that auth and acct are two separate, unrelated items. RADIUS Accounting needs to be configured differently and explicitly; so there is little risk that accounting packets are sent "by chance" anyway. If they are sent to the wrong place, that is an administrative error: misconfigured on the sender-side.= > Section 4 >=20 > As a consequence, the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- > bidding attacks on the peer communication. >=20 > [BA] If a fixed shared secret "radsec" is used alongside fallback to > RADIUS/UDP, > that seems more like a MUST NOT!! That paragraph was also brought up in the AD review. It was not meant in the way you perceived it; please see the thread of the AD review of this document for an extensive explanation how it was really meant. In any case, I take the point that the text is confusing for readers. While resolving the AD comments, I agreed with Dan Romascanu to reformulate this whole paragraph and move it to Security Considerations instead. I'll follow up with the new text later today. > Section 6 >=20 > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be > able to accept connections from a large, not previously known, group= > of hosts, possibly the whole internet. In this case, the server's > RADIUS/TLS port can not be protected from unauthorised connection > attempts with measures on the network layer, i.e. access lists and > firewalls. This opens more attack vectors for Distributed Denial of= > Service attacks, just like any other service that is supposed to > serve arbitrary clients (like for example web servers). >=20 > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only= > proof of authorisation for a connecting RADIUS/TLS nodes. Special > care needs to be taken that certificates get verified properly > according to the chosen trust model (particularly: consulting CRLs, > checking critical extensions, checking subjectAltNames etc.) to > prevent unauthorised connections. >=20 >=20 > [BA] I'd recommend collecting this and other dynamic-discovery related > material > into a separate section prior to 3.1. Moved out of the document, to go into dynamic-discovery. > Appendix C. Assessment of Crypto-Agility Requirements >=20 >=20 > The RADIUS Crypto-Agility Requirements (link to RFC once issued here= ) > defines numerous classification criteria for protocols that strive t= o > enhance the security of RADIUS. It contains mandatory (M) and > recommended (R) criteria which crypto-agile protocols have to > fulfill. The authors believe that the following assessment about th= e > crypto-agility properties of RADIUS/TLS are true. >=20 > [BA] The Crypto-Agility RFC is now published so you should reference th= at. Done now in my working copy. Thanks for this extensive review, much appreciated! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig3F474C2ACA5DD7A01FB6B5D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8hCfwACgkQ+jm90f8eFWaZoACdFwkftP0j3ufU99CrE+ZgtMSC bTAAn2UNJ2T0Tmd4a5FHuVpLDQkcYkIb =DETq -----END PGP SIGNATURE----- --------------enig3F474C2ACA5DD7A01FB6B5D2-- From radext-bounces@ietf.org Thu Jan 26 00:08:42 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5997811E80B0; Thu, 26 Jan 2012 00:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327565322; bh=7PUYfyOOUiSAfqS8K5R9JQiljJM76rswSxhSzDoSAts=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=x16x+2XxNxIgtwH/q3eDlF2dnYCs4BhHDQxqjk6BCgl97bjorPVVA7MATRPcmb/3o Vsqc6+EUh2C2ofiGw4jkVyZKitMjGqbGF+a1YvVReuE88OgKBTQSu0jjDcFEXHCexU O/feoq4b8QPEkrLulG3U0Zlu+GKGYoNLyou2GOTs= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BCA11E8075; Thu, 26 Jan 2012 00:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSozpH1+0yZS; Thu, 26 Jan 2012 00:08:37 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A15DB21F8567; Thu, 26 Jan 2012 00:08:29 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D4091106CB; Thu, 26 Jan 2012 09:08:28 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id C14F010691; Thu, 26 Jan 2012 09:08:28 +0100 (CET) Message-ID: <4F2109F8.4060505@restena.lu> Date: Thu, 26 Jan 2012 09:08:24 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ietf@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Cc: radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7498722088318706418==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7498722088318706418== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F474C2ACA5DD7A01FB6B5D2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3F474C2ACA5DD7A01FB6B5D2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, comments inline. > This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radse= c. >=20 > Overall, this draft was a pleasant to read, and it is clear that a lot > of thought as well as implementation experience has gone into it. >=20 > Kudos to the authors. Thanks :-) > General Issues >=20 > There is a considerable amount of text relating to dynamic discovery in= > this document, yet > there is only an informational reference to it. That's true. As I went through your comments below, I realised that large parts of the texts you quoted should be moved to the dynamic-discovery draft altogether as they are are very specific to that draft. I'm thinking of taking out all the snippets you mentioned below, transfer them to dynamic-discovery and leaving nothing but a small "pointer" paragraph in the RADIUS/TLS document. This actually coincides with what we've experienced in deployment. While in earlier times I considered TLS and dynamic discovery rather intertwined, operations people tell me that these are two very distinct things; most have no problem changing from UDP to TLS, while leaving their servers behind a firewall and opening it only to the same known peers as before; merely changing the transport. They do tend to have more of a problem with opening the port to the world at large and move away from hard-wired configurations of known peer addresses though. So it's indeed best to keep both aspects nicely separated. > Since inserting a normative reference to dynamic discovery could delay > the publication of > this document unnecessarily, my recommendation is to consolidate some o= f > the dynamic > discovery material into a single section in which you can discuss the > implications, while > clearly indicating the status of the dynamic discovery work (e.g. still= > under development, optional to > implement along with RADSEC, etc.). >=20 > For example, you might consider consolidating the following text from > Sections 3.1 and 6 > and placing it prior to the current Section 3.1: >=20 > Section 3.X: Implications of Dynamic Peer Discovery >=20 > One mechanism to discover RADIUS over TLS peers dynamically via DNS > is specified in [I-D.ietf-radext-dynamic-discovery]. While this > mechanism > is still under development and therefore is not a normative dependen= cy of > RADIUS/TLS, the use of dynamic discovery has potential future > implications that are > important to understand. I'll add that to the text. Since the text about dynamic discovery would be externalised to the other draft, how about if I add a sentence: "Readers of this document who are considering the deployment of DNS-based dynamic discovery are thus encouraged to read [I-D.ietf-radext-dynamic-discovery] and follow its future development." ?= Then, those who care can read up on it, while the others just read how to do TLS instead of UDP. > If dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery] is used, peer authentication > alone is not sufficient; the peer must also be authorised to perform= > user authentications. In these cases, the trust fabric cannot depen= d > on peer authentication methods like DNSSEC to identify RADIUS/TLS > nodes. The nodes also need to be properly authorised. Typically, > this can be achieved by adding appropriate authorisation fields into= > a X.509 certificate. Such fields include SRV authority [RFC4985], > subjectAltNames, or a defined list of certificate fingerprints. > Operators of a RADIUS/TLS infrastructure should define their own > authorisation trust model and apply this model to the certificates. > The checks enumerated in Section 2.3 provide sufficient flexibility > for the implementation of authorisation trust models. >=20 > [BA] I think you need to be more prescriptive here. Are there specific= > fields that a RADSEC TLS certificate should contain? Having individual= > implementations/deployments defining their own authorization schemes se= ems > like a bad idea.=20 That text is best moved out to dynamic-discovery anyway. But to address your point: this was discussed numerous times in radext wg meetings. The conclusion in the end was that it is hard to foresee how trust fabrics are created by people in the wild, so it seemed like a bad idea to be too prescriptive. E.g. in eduroam we've already been experimenting with two ( 1) subjectAltName:URI to contain a specific value 2) policyOID to distinguish "authorized eduroam" servers from others Chances are that we might experiment with more, e.g. DNSSEC subtrees with DANE records. This goes together with the current discussion of making dynamic discovery Experimental - then observe how trust models work, and be more concrete if the document makes it to standards track. > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be > able to accept connections from a large, not previously known, group= > of hosts, possibly the whole internet. In this case, the server's > RADIUS/TLS port can not be protected from unauthorised connection > attempts with measures on the network layer, i.e. access lists and > firewalls. This opens more attack vectors for Distributed Denial of= > Service attacks, just like any other service that is supposed to > serve arbitrary clients (like for example web servers). >=20 > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only= > proof of authorisation for a connecting RADIUS/TLS nodes. Special > care needs to be taken that certificates get verified properly > according to the chosen trust model (particularly: consulting CRLs, > checking critical extensions, checking subjectAltNames etc.) to > prevent unauthorised connections. Both of these security considerations apply only to deployers of dynamic-discovery; so they should be moved to dynamic-discovery. >=20 > Other comments >=20 > Section 1 >=20 > One mechanism to discover RADIUS over TLS peers with DNS is specifie= d in > [I-D.ietf-radext-dynamic-discovery]. >=20 > [BA] Recommend moving this to a section devoted to dynamic discovery. Done in my working copy, by using your text above. >=20 > Section 2.1 >=20 > See > section Section 3.3 (4) and (5) for considerations regarding > separation of authentication, accounting and dynauth traffic. >=20 > [BA] Recommend changing to: >=20 > "See Section 3.3 for considerations regarding separation of > authentication, accounting and dynamic authorisation traffic." Done in my working copy. >=20 > Section 2.3 >=20 > 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The= > shared secret to compute the (obsolete) MD5 integrity checks and= > attribute encryption MUST be "radsec" (see Section 3.3 (2) ). >=20 > Section 3.1 >=20 > (3) If dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery] is used, peer authentication > alone is not sufficient; the peer must also be authorised to perform= > user authentications. In these cases, the trust fabric cannot depen= d > on peer authentication methods like DNSSEC to identify RADIUS/TLS > nodes. The nodes also need to be properly authorised. Typically, > this can be achieved by adding appropriate authorisation fields into= > a X.509 certificate. Such fields include SRV authority [RFC4985], > subjectAltNames, or a defined list of certificate fingerprints. > Operators of a RADIUS/TLS infrastructure should define their own > authorisation trust model and apply this model to the certificates. > The checks enumerated in Section 2.3 provide sufficient flexibility > for the implementation of authorisation trust models. >=20 > As noted above, I'd suggest removing this material from Section 3.1 and= > consolidating it with other dynamic-discovery material. =20 Moved out to dynamic-discovery. >=20 > Section 3.3 >=20 > Note well: it is not required for an implementation > to actually process these packet types. It is sufficient that upon > receiving such a packet, an unconditional NAK is sent back to > indicate that the action is not supported. >=20 > [BA] What Error-Cause attribute value should be included within the NAK= > to make it > clear that the action is not supported? Error 406 "Unsupported Extensi= on"? > That is what RFC 5176 Section 3.5 seems to indicate. Indeed. I'll update the text to that end. Note though that adding Error-Cause is a MAY only in 5176, so it may very well be that an implementation which doesn't support dynauth would still send only a "naked" NAK, ignoring the MAY. I've put the following text into my working copy: (4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. The NAK MAY contain an attribute Error-Cause with the value 406 ("Unsupported Extension"); see [RFC5176] for details. > There > is no RADIUS datagram to signal an Accounting NAK. Clients may be > misconfigured to send Accounting packets to a RADIUS/TLS server whic= h > does not wish to process their Accounting packet. The server will > need to silently drop the packet. The client will need to deduce > from the absence of replies that it is misconfigured; no negative > ICMP response will reveal this. >=20 > [BA] This seems like a bad idea. How about requiring implementations n= ot > supporting Accounting to respond with an Accounting-Response containing= > Error-Cause attribute value 406? Implementations receiving an > Accounting-Response > with this Error-Cause can be required to treat this like an ICMP respon= se. I'm slightly confused here. To my best knowledge, Error-cause is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurence table in 5176. I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics. And to be honest, I would even be rather against such a change, and introduce a proper Accounting-NAK packet type instead; but that's a different story. The non-ability to indicate "No accounting please" has been discussed in a radext wg meetint. The conclusion was that auth and acct are two separate, unrelated items. RADIUS Accounting needs to be configured differently and explicitly; so there is little risk that accounting packets are sent "by chance" anyway. If they are sent to the wrong place, that is an administrative error: misconfigured on the sender-side.= > Section 4 >=20 > As a consequence, the selection of transports to communicate from a > client to a server is a manual administrative action. An automatic > fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- > bidding attacks on the peer communication. >=20 > [BA] If a fixed shared secret "radsec" is used alongside fallback to > RADIUS/UDP, > that seems more like a MUST NOT!! That paragraph was also brought up in the AD review. It was not meant in the way you perceived it; please see the thread of the AD review of this document for an extensive explanation how it was really meant. In any case, I take the point that the text is confusing for readers. While resolving the AD comments, I agreed with Dan Romascanu to reformulate this whole paragraph and move it to Security Considerations instead. I'll follow up with the new text later today. > Section 6 >=20 > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be > able to accept connections from a large, not previously known, group= > of hosts, possibly the whole internet. In this case, the server's > RADIUS/TLS port can not be protected from unauthorised connection > attempts with measures on the network layer, i.e. access lists and > firewalls. This opens more attack vectors for Distributed Denial of= > Service attacks, just like any other service that is supposed to > serve arbitrary clients (like for example web servers). >=20 > In the case of dynamic peer discovery as per > [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only= > proof of authorisation for a connecting RADIUS/TLS nodes. Special > care needs to be taken that certificates get verified properly > according to the chosen trust model (particularly: consulting CRLs, > checking critical extensions, checking subjectAltNames etc.) to > prevent unauthorised connections. >=20 >=20 > [BA] I'd recommend collecting this and other dynamic-discovery related > material > into a separate section prior to 3.1. Moved out of the document, to go into dynamic-discovery. > Appendix C. Assessment of Crypto-Agility Requirements >=20 >=20 > The RADIUS Crypto-Agility Requirements (link to RFC once issued here= ) > defines numerous classification criteria for protocols that strive t= o > enhance the security of RADIUS. It contains mandatory (M) and > recommended (R) criteria which crypto-agile protocols have to > fulfill. The authors believe that the following assessment about th= e > crypto-agility properties of RADIUS/TLS are true. >=20 > [BA] The Crypto-Agility RFC is now published so you should reference th= at. Done now in my working copy. Thanks for this extensive review, much appreciated! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig3F474C2ACA5DD7A01FB6B5D2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8hCfwACgkQ+jm90f8eFWaZoACdFwkftP0j3ufU99CrE+ZgtMSC bTAAn2UNJ2T0Tmd4a5FHuVpLDQkcYkIb =DETq -----END PGP SIGNATURE----- --------------enig3F474C2ACA5DD7A01FB6B5D2-- --===============7498722088318706418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7498722088318706418==-- From stefan.winter@restena.lu Thu Jan 26 04:36:02 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A261E21F8663; Thu, 26 Jan 2012 04:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khy7vEnOksBj; Thu, 26 Jan 2012 04:36:02 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B48E421F8659; Thu, 26 Jan 2012 04:36:01 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1325F106CB; Thu, 26 Jan 2012 13:36:01 +0100 (CET) Received: from [IPv6:2001:a18:1:8:d0e6:a4f2:93f:2654] (unknown [IPv6:2001:a18:1:8:d0e6:a4f2:93f:2654]) by smtprelay.restena.lu (Postfix) with ESMTPS id F1F2C106C2; Thu, 26 Jan 2012 13:36:00 +0100 (CET) Message-ID: <4F2148AC.7080108@restena.lu> Date: Thu, 26 Jan 2012 13:35:56 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ietf@ietf.org, radext@ietf.org References: <4F2109F8.4060505@restena.lu> In-Reply-To: <4F2109F8.4060505@restena.lu> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE1D151C91639983533087B96" X-Virus-Scanned: ClamAV Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:36:02 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1D151C91639983533087B96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, >> As a consequence, the selection of transports to communicate from a= >> client to a server is a manual administrative action. An automatic= >> fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- >> bidding attacks on the peer communication. >> >> [BA] If a fixed shared secret "radsec" is used alongside fallback to >> RADIUS/UDP, >> that seems more like a MUST NOT!! >=20 > That paragraph was also brought up in the AD review. It was not meant i= n > the way you perceived it; please see the thread of the AD review of thi= s > document for an extensive explanation how it was really meant. My working copy has the following text in Security Considerations now: If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security),and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down- bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients I hope that makes my intended statement clearer. If I'm not mistaken, IETF LC period is now over. I plan to produce a new -11 revision tomorrow to prepare the IESG review phase. It would be nice if you could let me know whether the changes I did in the document satisfactorily address your concerns. Greetings, Stefan Winter >=20 > In any case, I take the point that the text is confusing for readers. >=20 > While resolving the AD comments, I agreed with Dan Romascanu to > reformulate this whole paragraph and move it to Security Considerations= > instead. I'll follow up with the new text later today. >=20 >> Section 6 >> >> In the case of dynamic peer discovery as per >> [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be >> able to accept connections from a large, not previously known, grou= p >> of hosts, possibly the whole internet. In this case, the server's >> RADIUS/TLS port can not be protected from unauthorised connection >> attempts with measures on the network layer, i.e. access lists and >> firewalls. This opens more attack vectors for Distributed Denial o= f >> Service attacks, just like any other service that is supposed to >> serve arbitrary clients (like for example web servers). >> >> In the case of dynamic peer discovery as per >> [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the onl= y >> proof of authorisation for a connecting RADIUS/TLS nodes. Special >> care needs to be taken that certificates get verified properly >> according to the chosen trust model (particularly: consulting CRLs,= >> checking critical extensions, checking subjectAltNames etc.) to >> prevent unauthorised connections. >> >> >> [BA] I'd recommend collecting this and other dynamic-discovery related= >> material >> into a separate section prior to 3.1. >=20 > Moved out of the document, to go into dynamic-discovery. >=20 >> Appendix C. Assessment of Crypto-Agility Requirements >> >> >> The RADIUS Crypto-Agility Requirements (link to RFC once issued her= e) >> defines numerous classification criteria for protocols that strive = to >> enhance the security of RADIUS. It contains mandatory (M) and >> recommended (R) criteria which crypto-agile protocols have to >> fulfill. The authors believe that the following assessment about t= he >> crypto-agility properties of RADIUS/TLS are true. >> >> [BA] The Crypto-Agility RFC is now published so you should reference t= hat. >=20 > Done now in my working copy. >=20 > Thanks for this extensive review, much appreciated! >=20 > Greetings, >=20 > Stefan Winter >=20 >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE1D151C91639983533087B96 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8hSLAACgkQ+jm90f8eFWbFogCePqLVbDTi2lvg2/OpXcjSiKgK 5VIAn36jH/wlxEnPUALXPOIaJ8pMR2lh =/83G -----END PGP SIGNATURE----- --------------enigE1D151C91639983533087B96-- From radext-bounces@ietf.org Thu Jan 26 04:36:07 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461D421F8700; Thu, 26 Jan 2012 04:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327581367; bh=S92ubw9+I+aQel7EKXWL9Kf/+rMi1kxT1GOf4V1nPRc=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=VO11UZAfRVWv84KdGuBgdCAPzMkUgiZnpW+OQiDdQEYS18ybW9NsQaG6zkdmpEKqZ GxMlR3Sezkia8mU3U7CzqpIzbBqpzmKE2cQS0ZpLSBRfR3PzUFm5m/OuDWHBgRvjOL I8L78ahIPCgJt+IwAvEowFFFaPJGM/i01FMm+14I= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A261E21F8663; Thu, 26 Jan 2012 04:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Khy7vEnOksBj; Thu, 26 Jan 2012 04:36:02 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B48E421F8659; Thu, 26 Jan 2012 04:36:01 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1325F106CB; Thu, 26 Jan 2012 13:36:01 +0100 (CET) Received: from [IPv6:2001:a18:1:8:d0e6:a4f2:93f:2654] (unknown [IPv6:2001:a18:1:8:d0e6:a4f2:93f:2654]) by smtprelay.restena.lu (Postfix) with ESMTPS id F1F2C106C2; Thu, 26 Jan 2012 13:36:00 +0100 (CET) Message-ID: <4F2148AC.7080108@restena.lu> Date: Thu, 26 Jan 2012 13:35:56 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: ietf@ietf.org, radext@ietf.org References: <4F2109F8.4060505@restena.lu> In-Reply-To: <4F2109F8.4060505@restena.lu> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0175561161893941674==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0175561161893941674== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE1D151C91639983533087B96" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE1D151C91639983533087B96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi again, >> As a consequence, the selection of transports to communicate from a= >> client to a server is a manual administrative action. An automatic= >> fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down- >> bidding attacks on the peer communication. >> >> [BA] If a fixed shared secret "radsec" is used alongside fallback to >> RADIUS/UDP, >> that seems more like a MUST NOT!! >=20 > That paragraph was also brought up in the AD review. It was not meant i= n > the way you perceived it; please see the thread of the AD review of thi= s > document for an extensive explanation how it was really meant. My working copy has the following text in Security Considerations now: If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security),and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down- bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup, the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: o Client side: de-configure the failover setup, leaving RADIUS/TLS as the only communication option o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients I hope that makes my intended statement clearer. If I'm not mistaken, IETF LC period is now over. I plan to produce a new -11 revision tomorrow to prepare the IESG review phase. It would be nice if you could let me know whether the changes I did in the document satisfactorily address your concerns. Greetings, Stefan Winter >=20 > In any case, I take the point that the text is confusing for readers. >=20 > While resolving the AD comments, I agreed with Dan Romascanu to > reformulate this whole paragraph and move it to Security Considerations= > instead. I'll follow up with the new text later today. >=20 >> Section 6 >> >> In the case of dynamic peer discovery as per >> [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be >> able to accept connections from a large, not previously known, grou= p >> of hosts, possibly the whole internet. In this case, the server's >> RADIUS/TLS port can not be protected from unauthorised connection >> attempts with measures on the network layer, i.e. access lists and >> firewalls. This opens more attack vectors for Distributed Denial o= f >> Service attacks, just like any other service that is supposed to >> serve arbitrary clients (like for example web servers). >> >> In the case of dynamic peer discovery as per >> [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the onl= y >> proof of authorisation for a connecting RADIUS/TLS nodes. Special >> care needs to be taken that certificates get verified properly >> according to the chosen trust model (particularly: consulting CRLs,= >> checking critical extensions, checking subjectAltNames etc.) to >> prevent unauthorised connections. >> >> >> [BA] I'd recommend collecting this and other dynamic-discovery related= >> material >> into a separate section prior to 3.1. >=20 > Moved out of the document, to go into dynamic-discovery. >=20 >> Appendix C. Assessment of Crypto-Agility Requirements >> >> >> The RADIUS Crypto-Agility Requirements (link to RFC once issued her= e) >> defines numerous classification criteria for protocols that strive = to >> enhance the security of RADIUS. It contains mandatory (M) and >> recommended (R) criteria which crypto-agile protocols have to >> fulfill. The authors believe that the following assessment about t= he >> crypto-agility properties of RADIUS/TLS are true. >> >> [BA] The Crypto-Agility RFC is now published so you should reference t= hat. >=20 > Done now in my working copy. >=20 > Thanks for this extensive review, much appreciated! >=20 > Greetings, >=20 > Stefan Winter >=20 >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigE1D151C91639983533087B96 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8hSLAACgkQ+jm90f8eFWbFogCePqLVbDTi2lvg2/OpXcjSiKgK 5VIAn36jH/wlxEnPUALXPOIaJ8pMR2lh =/83G -----END PGP SIGNATURE----- --------------enigE1D151C91639983533087B96-- --===============0175561161893941674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0175561161893941674==-- From bernard_aboba@hotmail.com Thu Jan 26 21:16:05 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B92721F86FD; Thu, 26 Jan 2012 21:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1aRwIJ1R0Lm; Thu, 26 Jan 2012 21:16:04 -0800 (PST) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7E21F86F0; Thu, 26 Jan 2012 21:16:04 -0800 (PST) Received: from BLU152-W4 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 21:16:03 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_579e820c-7f0a-464a-b50e-bbd6c7acd75b_" X-Originating-IP: [75.94.72.66] From: Bernard Aboba To: Stefan Winter , , Date: Thu, 26 Jan 2012 21:16:02 -0800 Importance: Normal In-Reply-To: <4F2148AC.7080108@restena.lu> References: , <4F2109F8.4060505@restena.lu>, <4F2148AC.7080108@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 05:16:03.0398 (UTC) FILETIME=[C3C9E660:01CCDCB2] Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 05:16:05 -0000 --_579e820c-7f0a-464a-b50e-bbd6c7acd75b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: =20 My working copy has the following text in Security Considerations now: =20 If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security)=2Cand where the RADIUS/UDP transport is the failover option if the TLS session cannot be established=2C a down- bidding attack can occur if an adversary can maliciously close the TCP connection=2C or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup=2C the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: =20 o Client side: de-configure the failover setup=2C leaving RADIUS/TLS as the only communication option =20 o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients =20 I hope that makes my intended statement clearer. =20 [BA] My issue is the use of a "well known" shared secret with RADIUS/UDP.=20 This could be fixed by requiring that a server supporting RADIUS/TLS MUST check for a RADIUS/TLS connection before allowing use of the "well known" shared secret.=20 = --_579e820c-7f0a-464a-b50e-bbd6c7acd75b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
 
My working copy has the following text in Se=
curity Considerations now:
 
   If peer communication between two dev=
ices is configured for both
   RADIUS/TLS transport (using TLS security)=
 and RADIUS/UDP (using
   shared secret security)=2Cand where the RADIUS=
/UDP transport is the
   failover option if the TLS session cannot be es=
tablished=2C a down-
   bidding attack can occur if an adversary can mal=
iciously close the
   TCP connection=2C or prevent it from being establi=
shed.  Situations
   where clients are configured in such a way are like=
ly to occur during
   a migration phase from RADIUS/UDP to RADIUS/TLS.  =
By preventing the
   TLS session setup=2C the attacker can reduce the se=
curity of the packet
   payload from the selected TLS cipher suite packe=
t encryption to the
   classic MD5 per-attribute encryption.  The situat=
ion should be
   avoided by disabling the weaker RADIUS/UDP transport as=
 soon as the
   new RADIUS/TLS transport is established and tested.  Dis=
abling can
   happen at either the RADIUS client or server side:
    o  Client side: de-configure the failover setup=2C leaving RADIUS/TLS      as the only communication option
 
   o  Server side: de-conf=
igure the RADIUS/UDP client from the list of
      valid RADIUS clients<=
br> 
I hope that makes my intended statement clearer.
 
[BA] My is=
sue is the use of a "well known" shared secret with RADIUS/UDP. 
This co=
uld be fixed by requiring that a server supporting RADIUS/TLS MUST
check=
 for a RADIUS/TLS connection before allowing use of the "well known"
sha=
red secret.
= --_579e820c-7f0a-464a-b50e-bbd6c7acd75b_-- From radext-bounces@ietf.org Thu Jan 26 21:16:10 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3E21F8730; Thu, 26 Jan 2012 21:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327641370; bh=MtGq5nKwhuAKIPsLZNpLTS0uyH5irl9OHFtZptIZ5js=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=zH8tKxYovQFkUpYbXeM2DCe1eoaytgGsPPUN2WaJbOMkCEvkhLOs/HBGmo8Z2ZoY/ pUUyxn/Vw2juOOQIPozDrkmmGy8raE43fSqb2URL7xukVL4DeCgn/HkM5wJJWbAQa5 CbPw0PyO7un5oKR5oYZ6OgZvMU4nOxnYVIIJHeco= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B92721F86FD; Thu, 26 Jan 2012 21:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1aRwIJ1R0Lm; Thu, 26 Jan 2012 21:16:04 -0800 (PST) Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7E21F86F0; Thu, 26 Jan 2012 21:16:04 -0800 (PST) Received: from BLU152-W4 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 21:16:03 -0800 Message-ID: X-Originating-IP: [75.94.72.66] From: Bernard Aboba To: Stefan Winter , , Date: Thu, 26 Jan 2012 21:16:02 -0800 Importance: Normal In-Reply-To: <4F2148AC.7080108@restena.lu> References: , <4F2109F8.4060505@restena.lu>, <4F2148AC.7080108@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 05:16:03.0398 (UTC) FILETIME=[C3C9E660:01CCDCB2] Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6203478852000293768==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============6203478852000293768== Content-Type: multipart/alternative; boundary="_579e820c-7f0a-464a-b50e-bbd6c7acd75b_" --_579e820c-7f0a-464a-b50e-bbd6c7acd75b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: =20 My working copy has the following text in Security Considerations now: =20 If peer communication between two devices is configured for both RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using shared secret security)=2Cand where the RADIUS/UDP transport is the failover option if the TLS session cannot be established=2C a down- bidding attack can occur if an adversary can maliciously close the TCP connection=2C or prevent it from being established. Situations where clients are configured in such a way are likely to occur during a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS session setup=2C the attacker can reduce the security of the packet payload from the selected TLS cipher suite packet encryption to the classic MD5 per-attribute encryption. The situation should be avoided by disabling the weaker RADIUS/UDP transport as soon as the new RADIUS/TLS transport is established and tested. Disabling can happen at either the RADIUS client or server side: =20 o Client side: de-configure the failover setup=2C leaving RADIUS/TLS as the only communication option =20 o Server side: de-configure the RADIUS/UDP client from the list of valid RADIUS clients =20 I hope that makes my intended statement clearer. =20 [BA] My issue is the use of a "well known" shared secret with RADIUS/UDP.=20 This could be fixed by requiring that a server supporting RADIUS/TLS MUST check for a RADIUS/TLS connection before allowing use of the "well known" shared secret.=20 = --_579e820c-7f0a-464a-b50e-bbd6c7acd75b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
 
My working copy has the following text in Se=
curity Considerations now:
 
   If peer communication between two dev=
ices is configured for both
   RADIUS/TLS transport (using TLS security)=
 and RADIUS/UDP (using
   shared secret security)=2Cand where the RADIUS=
/UDP transport is the
   failover option if the TLS session cannot be es=
tablished=2C a down-
   bidding attack can occur if an adversary can mal=
iciously close the
   TCP connection=2C or prevent it from being establi=
shed.  Situations
   where clients are configured in such a way are like=
ly to occur during
   a migration phase from RADIUS/UDP to RADIUS/TLS.  =
By preventing the
   TLS session setup=2C the attacker can reduce the se=
curity of the packet
   payload from the selected TLS cipher suite packe=
t encryption to the
   classic MD5 per-attribute encryption.  The situat=
ion should be
   avoided by disabling the weaker RADIUS/UDP transport as=
 soon as the
   new RADIUS/TLS transport is established and tested.  Dis=
abling can
   happen at either the RADIUS client or server side:
    o  Client side: de-configure the failover setup=2C leaving RADIUS/TLS      as the only communication option
 
   o  Server side: de-conf=
igure the RADIUS/UDP client from the list of
      valid RADIUS clients<=
br> 
I hope that makes my intended statement clearer.
 
[BA] My is=
sue is the use of a "well known" shared secret with RADIUS/UDP. 
This co=
uld be fixed by requiring that a server supporting RADIUS/TLS MUST
check=
 for a RADIUS/TLS connection before allowing use of the "well known"
sha=
red secret.
= --_579e820c-7f0a-464a-b50e-bbd6c7acd75b_-- --===============6203478852000293768== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============6203478852000293768==-- From bernard_aboba@hotmail.com Thu Jan 26 21:51:07 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20121F85AC; Thu, 26 Jan 2012 21:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny6tte1Xz1Kx; Thu, 26 Jan 2012 21:51:06 -0800 (PST) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2921F85AA; Thu, 26 Jan 2012 21:51:06 -0800 (PST) Received: from BLU152-W62 ([65.55.116.72]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 21:51:05 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d841b3fe-0081-4ebf-9a21-d3131e52919f_" X-Originating-IP: [75.94.72.66] From: Bernard Aboba To: Stefan Winter , Date: Thu, 26 Jan 2012 21:51:05 -0800 Importance: Normal In-Reply-To: <4F2109F8.4060505@restena.lu> References: , <4F2109F8.4060505@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 05:51:05.0834 (UTC) FILETIME=[A8F02CA0:01CCDCB7] Cc: radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 05:51:07 -0000 --_d841b3fe-0081-4ebf-9a21-d3131e52919f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: "That's true. As I went through your comments below=2C I realised that large parts of the texts you quoted should be moved to the dynamic-discovery draft altogether as they are are very specific to that draft. =20 I'm thinking of taking out all the snippets you mentioned below=2C transfer them to dynamic-discovery and leaving nothing but a small "pointer" paragraph in the RADIUS/TLS document." [BA] That's a great idea.=20 =20 Stefan said: "Indeed. I'll update the text to that end. Note though that adding Error-Cause is a MAY only in 5176=2C so it may very well be that an implementation which doesn't support dynauth would still send only a "naked" NAK=2C ignoring the MAY." [BA] It's a MAY in RFC 5176 because existing implementations didn't support Error-Cause at all. However=2C in this particular case=2C since you're requiring that RADIUS/TLS implementations support NAK in the first place=2C you can also say that they SHOULD send an Error-Cause attribute. So I'd suggest that the MAY be stronger=2C so as to remove a potential ambiguity about the meaning of the NAK. =20 It is sufficient that upon receiving such a packet=2C an unconditional NAK is sent back to indicate that the action is not supported. =20 [BA] The problem is that a NAK does NOT mean that the action is unsupported according to RFC 5176=2C unless there is an Error-Cause attribute present that indicates that.=20 =20 Stefan said: =20 "I'm slightly confused here. To my best knowledge=2C Error-cause is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurrence table in 5176." [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authorizati= on it can also be used in other contexts. For example=2C Error-Cause is refer= enced in the following other RFCs: RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see Secti= on 3.3) RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1) Stefan said: "I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics." [BA] Apparently=2C Error-Cause is being sent in Accounting-Request packets= =2C see: http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.ht= ml With respect to Accounting-Response=2C RFC 2866 does prohibit inclusion of= =20 attributes relating to a service=2C but not attributes like Proxy-State or = Vendor-Specific. So I'd argue that Error-Cause fits within the category of attributes that w= ould be permissible -- an Informational attribute that can be ignored without da= mage. Stefan said: "The non-ability to indicate "No accounting please" has been discussed in a radext wg meeting. The conclusion was that auth and acct are two separate=2C unrelated items. RADIUS Accounting needs to be configured differently and explicitly=3B so there is little risk that accounting packets are sent "by chance" anyway. If they are sent to the wrong place=2C that is an administrative error: misconfigured on the sender-side.= " [BA] If a RADIUS over UDP packet is sent to the wrong place=2C an ICMP message will result that the RADIUS Accounting client can act on=2C such as by logging the error. =20 In this case=2C you are mandating that the RADIUS over TLS server ignore the request=2C resulting in continuing connection attempts and retransmissi= ons by the RADIUS over TLS client=2C who doesn't receive evidence of the miscon= figuration. So I'd argue that RADIUS over TLS is creating a new problem.=20 = --_d841b3fe-0081-4ebf-9a21-d3131e52919f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
"That's true. As I went through your comments bel=
ow=2C I realised that
large parts of the texts you quoted should be move=
d to the
dynamic-discovery draft altogether as they are are very specifi=
c to that
draft.
 
I'm thinking of taking out all the snippets you=
 mentioned below=2C
transfer them to dynamic-discovery and leaving nothi=
ng but a small
"pointer" paragraph in the RADIUS/TLS document."

[=
BA] That's a great idea. 
 
Stefan said:

"Indeed. I'll update =
the text to that end. Note though that adding
Error-Cause is a MAY only =
in 5176=2C so it may very well be that an
implementation which doesn't s=
upport dynauth would still send only a
"naked" NAK=2C ignoring the MAY."=


[BA] It's a MAY in RFC 5176 because existing implementations didn't=

support Error-Cause at all.  However=2C in this particular case=2C sinc=
e
you're requiring that RADIUS/TLS implementations support NAK in thefirst place=2C you can also say that they SHOULD send an Error-Cause
at=
tribute.  So I'd suggest that the MAY be stronger=2C so as to remove
a p=
otential ambiguity about the meaning of the NAK.  

   It is sufficie=
nt that upon
   receiving such a packet=2C an unconditional NAK is sent =
back to
   indicate that the action is not supported.  

[BA] The =
problem is that a NAK does NOT mean that the action is
unsupported accor=
ding to RFC 5176=2C unless there is an Error-Cause
attribute present tha=
t indicates that. 

 
Stefan said:
 
"I'm slightly confused =
here. To my best knowledge=2C Error-cause is only
specified in the conte=
xt of DynAuth (RFC5176). That attribute is listed
as only allowed in a N=
AK as per the attribute occurrence table in 5176."

[BA] While RFC 51=
76 only mentions use of Error-Cause in dynamic authorization
it can also=
 be used in other contexts.  For example=2C Error-Cause is referenced
in=
 the following other RFCs:

RFC 3579:  Error-Cause use in Access-Chal=
lenge and Access-Reject (see Section 3.3)
RFC 5080:  Error-Cause in Acce=
ss-Reject (See Section 2.6.1)

Stefan said:

"I would be hesita=
nt to use Error-Cause in RADIUS Accounting packets -
unless the correspo=
nding RFCs get updated to specify that this attribute
is now also to be =
used in Accounting semantics."

[BA] Apparently=2C Error-Cause is bei=
ng sent in Accounting-Request packets=2C see:
http://lists.cistron.nl/pi=
permail/freeradius-users/2011-January/msg00255.html

With respect to =
Accounting-Response=2C RFC 2866 does prohibit inclusion of 
attributes r=
elating to a service=2C but not attributes like Proxy-State or Vendor-Speci=
fic.
So I'd argue that Error-Cause fits within the category of attribute=
s that would
be permissible -- an Informational attribute that can be ig=
nored without damage.

Stefan said:

"The non-ability to indica=
te "No accounting please" has been discussed in
a radext wg meeting. The=
 conclusion was that auth and acct are two
separate=2C unrelated items. =
RADIUS Accounting needs to be configured
differently and explicitly=3B s=
o there is little risk that accounting
packets are sent "by chance" anyw=
ay. If they are sent to the wrong
place=2C that is an administrative err=
or: misconfigured on the sender-side."

[BA] If a RADIUS over UDP pac=
ket is sent to the wrong place=2C an ICMP
message will result that the R=
ADIUS Accounting client can act on=2C such
as by logging the error.  
In this case=2C you are mandating that the RADIUS over TLS server igno=
re
the request=2C resulting in continuing connection attempts and retran=
smissions
by the RADIUS over TLS client=2C who doesn't receive evidence =
of the misconfiguration.
So I'd argue that RADIUS over TLS is creating a=
 new problem.


= --_d841b3fe-0081-4ebf-9a21-d3131e52919f_-- From radext-bounces@ietf.org Thu Jan 26 21:51:12 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0A121F862A; Thu, 26 Jan 2012 21:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327643472; bh=izzUju7bZVNDx3/ZOEBPMGiMPHuPQzSlwspk9MZ1coQ=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=PX44Bd9B0GSi9zNaDoN8No7zyRW59jaCEa8Il6uyDzEXRK3Fzok0n/ovFjXxTXIHA W069BPUXO5v4G45PfKn8+fhaHyYMMtPDPc0gjGi0WId990RXW96DPtulY2EZdJeS03 H8lM/XAeFMqT51mI06TuOoV3SZN2CeQoJ9owqH/c= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20121F85AC; Thu, 26 Jan 2012 21:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny6tte1Xz1Kx; Thu, 26 Jan 2012 21:51:06 -0800 (PST) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2921F85AA; Thu, 26 Jan 2012 21:51:06 -0800 (PST) Received: from BLU152-W62 ([65.55.116.72]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jan 2012 21:51:05 -0800 Message-ID: X-Originating-IP: [75.94.72.66] From: Bernard Aboba To: Stefan Winter , Date: Thu, 26 Jan 2012 21:51:05 -0800 Importance: Normal In-Reply-To: <4F2109F8.4060505@restena.lu> References: , <4F2109F8.4060505@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 05:51:05.0834 (UTC) FILETIME=[A8F02CA0:01CCDCB7] Cc: radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0734283231733121376==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============0734283231733121376== Content-Type: multipart/alternative; boundary="_d841b3fe-0081-4ebf-9a21-d3131e52919f_" --_d841b3fe-0081-4ebf-9a21-d3131e52919f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: "That's true. As I went through your comments below=2C I realised that large parts of the texts you quoted should be moved to the dynamic-discovery draft altogether as they are are very specific to that draft. =20 I'm thinking of taking out all the snippets you mentioned below=2C transfer them to dynamic-discovery and leaving nothing but a small "pointer" paragraph in the RADIUS/TLS document." [BA] That's a great idea.=20 =20 Stefan said: "Indeed. I'll update the text to that end. Note though that adding Error-Cause is a MAY only in 5176=2C so it may very well be that an implementation which doesn't support dynauth would still send only a "naked" NAK=2C ignoring the MAY." [BA] It's a MAY in RFC 5176 because existing implementations didn't support Error-Cause at all. However=2C in this particular case=2C since you're requiring that RADIUS/TLS implementations support NAK in the first place=2C you can also say that they SHOULD send an Error-Cause attribute. So I'd suggest that the MAY be stronger=2C so as to remove a potential ambiguity about the meaning of the NAK. =20 It is sufficient that upon receiving such a packet=2C an unconditional NAK is sent back to indicate that the action is not supported. =20 [BA] The problem is that a NAK does NOT mean that the action is unsupported according to RFC 5176=2C unless there is an Error-Cause attribute present that indicates that.=20 =20 Stefan said: =20 "I'm slightly confused here. To my best knowledge=2C Error-cause is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurrence table in 5176." [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authorizati= on it can also be used in other contexts. For example=2C Error-Cause is refer= enced in the following other RFCs: RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see Secti= on 3.3) RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1) Stefan said: "I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics." [BA] Apparently=2C Error-Cause is being sent in Accounting-Request packets= =2C see: http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.ht= ml With respect to Accounting-Response=2C RFC 2866 does prohibit inclusion of= =20 attributes relating to a service=2C but not attributes like Proxy-State or = Vendor-Specific. So I'd argue that Error-Cause fits within the category of attributes that w= ould be permissible -- an Informational attribute that can be ignored without da= mage. Stefan said: "The non-ability to indicate "No accounting please" has been discussed in a radext wg meeting. The conclusion was that auth and acct are two separate=2C unrelated items. RADIUS Accounting needs to be configured differently and explicitly=3B so there is little risk that accounting packets are sent "by chance" anyway. If they are sent to the wrong place=2C that is an administrative error: misconfigured on the sender-side.= " [BA] If a RADIUS over UDP packet is sent to the wrong place=2C an ICMP message will result that the RADIUS Accounting client can act on=2C such as by logging the error. =20 In this case=2C you are mandating that the RADIUS over TLS server ignore the request=2C resulting in continuing connection attempts and retransmissi= ons by the RADIUS over TLS client=2C who doesn't receive evidence of the miscon= figuration. So I'd argue that RADIUS over TLS is creating a new problem.=20 = --_d841b3fe-0081-4ebf-9a21-d3131e52919f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
"That's true. As I went through your comments bel=
ow=2C I realised that
large parts of the texts you quoted should be move=
d to the
dynamic-discovery draft altogether as they are are very specifi=
c to that
draft.
 
I'm thinking of taking out all the snippets you=
 mentioned below=2C
transfer them to dynamic-discovery and leaving nothi=
ng but a small
"pointer" paragraph in the RADIUS/TLS document."

[=
BA] That's a great idea. 
 
Stefan said:

"Indeed. I'll update =
the text to that end. Note though that adding
Error-Cause is a MAY only =
in 5176=2C so it may very well be that an
implementation which doesn't s=
upport dynauth would still send only a
"naked" NAK=2C ignoring the MAY."=


[BA] It's a MAY in RFC 5176 because existing implementations didn't=

support Error-Cause at all.  However=2C in this particular case=2C sinc=
e
you're requiring that RADIUS/TLS implementations support NAK in thefirst place=2C you can also say that they SHOULD send an Error-Cause
at=
tribute.  So I'd suggest that the MAY be stronger=2C so as to remove
a p=
otential ambiguity about the meaning of the NAK.  

   It is sufficie=
nt that upon
   receiving such a packet=2C an unconditional NAK is sent =
back to
   indicate that the action is not supported.  

[BA] The =
problem is that a NAK does NOT mean that the action is
unsupported accor=
ding to RFC 5176=2C unless there is an Error-Cause
attribute present tha=
t indicates that. 

 
Stefan said:
 
"I'm slightly confused =
here. To my best knowledge=2C Error-cause is only
specified in the conte=
xt of DynAuth (RFC5176). That attribute is listed
as only allowed in a N=
AK as per the attribute occurrence table in 5176."

[BA] While RFC 51=
76 only mentions use of Error-Cause in dynamic authorization
it can also=
 be used in other contexts.  For example=2C Error-Cause is referenced
in=
 the following other RFCs:

RFC 3579:  Error-Cause use in Access-Chal=
lenge and Access-Reject (see Section 3.3)
RFC 5080:  Error-Cause in Acce=
ss-Reject (See Section 2.6.1)

Stefan said:

"I would be hesita=
nt to use Error-Cause in RADIUS Accounting packets -
unless the correspo=
nding RFCs get updated to specify that this attribute
is now also to be =
used in Accounting semantics."

[BA] Apparently=2C Error-Cause is bei=
ng sent in Accounting-Request packets=2C see:
http://lists.cistron.nl/pi=
permail/freeradius-users/2011-January/msg00255.html

With respect to =
Accounting-Response=2C RFC 2866 does prohibit inclusion of 
attributes r=
elating to a service=2C but not attributes like Proxy-State or Vendor-Speci=
fic.
So I'd argue that Error-Cause fits within the category of attribute=
s that would
be permissible -- an Informational attribute that can be ig=
nored without damage.

Stefan said:

"The non-ability to indica=
te "No accounting please" has been discussed in
a radext wg meeting. The=
 conclusion was that auth and acct are two
separate=2C unrelated items. =
RADIUS Accounting needs to be configured
differently and explicitly=3B s=
o there is little risk that accounting
packets are sent "by chance" anyw=
ay. If they are sent to the wrong
place=2C that is an administrative err=
or: misconfigured on the sender-side."

[BA] If a RADIUS over UDP pac=
ket is sent to the wrong place=2C an ICMP
message will result that the R=
ADIUS Accounting client can act on=2C such
as by logging the error.  
In this case=2C you are mandating that the RADIUS over TLS server igno=
re
the request=2C resulting in continuing connection attempts and retran=
smissions
by the RADIUS over TLS client=2C who doesn't receive evidence =
of the misconfiguration.
So I'd argue that RADIUS over TLS is creating a=
 new problem.


= --_d841b3fe-0081-4ebf-9a21-d3131e52919f_-- --===============0734283231733121376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0734283231733121376==-- From stefan.winter@restena.lu Thu Jan 26 23:16:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5EF21F856D; Thu, 26 Jan 2012 23:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TukzruuH303X; Thu, 26 Jan 2012 23:16:19 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7A21F853B; Thu, 26 Jan 2012 23:16:18 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8860C106CB; Fri, 27 Jan 2012 08:16:17 +0100 (CET) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7819E10691; Fri, 27 Jan 2012 08:16:17 +0100 (CET) Message-ID: <4F224F36.9000102@restena.lu> Date: Fri, 27 Jan 2012 08:16:06 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org, 'IETF Discussion Mailing List' References: , <4F2109F8.4060505@restena.lu>, <4F2148AC.7080108@restena.lu> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig40BDD5C13E24490DC67072D3" X-Virus-Scanned: ClamAV Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 07:16:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig40BDD5C13E24490DC67072D3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > If peer communication between two devices is configured for both > RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using > shared secret security),and where the RADIUS/UDP transport is the > failover option if the TLS session cannot be established, a down- > bidding attack can occur if an adversary can maliciously close the > TCP connection, or prevent it from being established. Situations > where clients are configured in such a way are likely to occur durin= g > a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the > TLS session setup, the attacker can reduce the security of the packe= t > payload from the selected TLS cipher suite packet encryption to the > classic MD5 per-attribute encryption. The situation should be > avoided by disabling the weaker RADIUS/UDP transport as soon as the > new RADIUS/TLS transport is established and tested. Disabling can > happen at either the RADIUS client or server side: > =20 > o Client side: de-configure the failover setup, leaving RADIUS/TLS > as the only communication option > =20 > o Server side: de-configure the RADIUS/UDP client from the list of > valid RADIUS clients > =20 > I hope that makes my intended statement clearer. > =20 > [BA] My issue is the use of a "well known" shared secret with RADIUS/UD= P.=20 > This could be fixed by requiring that a server supporting RADIUS/TLS MU= ST > check for a RADIUS/TLS connection before allowing use of the "well know= n" > shared secret.=20 Ah, I see. The spec does not mandate a fixed well-known shared secret for RADIUS/UDP at all. It only specifies that when TLS transport is used, security is provided on the transport layer, so the shared secret that used to protect the RADIUS payload is useless is set to this fixed term. When using RADIUS/UDP, the shared secret is still chosen by the administrator by configuration. Would it help to clarify the first lines to read: If peer communication between two devices is configured for both RADIUS/TLS transport (i.e. TLS security on the transport layer, shared secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security with a secret manually configured by the administrator), and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down-bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Just to make sure people realise that RADIUS/UDP security is untouched by this spec? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig40BDD5C13E24490DC67072D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8iTz8ACgkQ+jm90f8eFWbBfwCfcoBFq372k+Q7Yo14ZtuQvCyO 1nwAnjf8ICourZ1qKvAmNVRr2IzhId47 =aHu1 -----END PGP SIGNATURE----- --------------enig40BDD5C13E24490DC67072D3-- From radext-bounces@ietf.org Thu Jan 26 23:16:24 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28F821F8592; Thu, 26 Jan 2012 23:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327648583; bh=JEZR06ZXD0Pqwm17jUzIqo9MDCw6lrNNcvGAsupnvws=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=tI/9raXooH52VXzkTmI2759IrI2UiVW2IFQUN3SH8O94aer4uiKD7MOcfVTdIUEdY LQOimEZ1o+xxPt4eNpVFbK/gcyp8PRpuK7UGFR7o7SyNNzCEp+Qunx3JgwUhf5v1h1 nyjECKTO9bgKMzNJvNqyvzD8rTouAK1Nz0NBakVw= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5EF21F856D; Thu, 26 Jan 2012 23:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TukzruuH303X; Thu, 26 Jan 2012 23:16:19 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7A21F853B; Thu, 26 Jan 2012 23:16:18 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8860C106CB; Fri, 27 Jan 2012 08:16:17 +0100 (CET) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7819E10691; Fri, 27 Jan 2012 08:16:17 +0100 (CET) Message-ID: <4F224F36.9000102@restena.lu> Date: Fri, 27 Jan 2012 08:16:06 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org, 'IETF Discussion Mailing List' References: , <4F2109F8.4060505@restena.lu>, <4F2148AC.7080108@restena.lu> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0856815243424158860==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0856815243424158860== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig40BDD5C13E24490DC67072D3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig40BDD5C13E24490DC67072D3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > If peer communication between two devices is configured for both > RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using > shared secret security),and where the RADIUS/UDP transport is the > failover option if the TLS session cannot be established, a down- > bidding attack can occur if an adversary can maliciously close the > TCP connection, or prevent it from being established. Situations > where clients are configured in such a way are likely to occur durin= g > a migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the > TLS session setup, the attacker can reduce the security of the packe= t > payload from the selected TLS cipher suite packet encryption to the > classic MD5 per-attribute encryption. The situation should be > avoided by disabling the weaker RADIUS/UDP transport as soon as the > new RADIUS/TLS transport is established and tested. Disabling can > happen at either the RADIUS client or server side: > =20 > o Client side: de-configure the failover setup, leaving RADIUS/TLS > as the only communication option > =20 > o Server side: de-configure the RADIUS/UDP client from the list of > valid RADIUS clients > =20 > I hope that makes my intended statement clearer. > =20 > [BA] My issue is the use of a "well known" shared secret with RADIUS/UD= P.=20 > This could be fixed by requiring that a server supporting RADIUS/TLS MU= ST > check for a RADIUS/TLS connection before allowing use of the "well know= n" > shared secret.=20 Ah, I see. The spec does not mandate a fixed well-known shared secret for RADIUS/UDP at all. It only specifies that when TLS transport is used, security is provided on the transport layer, so the shared secret that used to protect the RADIUS payload is useless is set to this fixed term. When using RADIUS/UDP, the shared secret is still chosen by the administrator by configuration. Would it help to clarify the first lines to read: If peer communication between two devices is configured for both RADIUS/TLS transport (i.e. TLS security on the transport layer, shared secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret security with a secret manually configured by the administrator), and where the RADIUS/UDP transport is the failover option if the TLS session cannot be established, a down-bidding attack can occur if an adversary can maliciously close the TCP connection, or prevent it from being established. Just to make sure people realise that RADIUS/UDP security is untouched by this spec? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig40BDD5C13E24490DC67072D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8iTz8ACgkQ+jm90f8eFWbBfwCfcoBFq372k+Q7Yo14ZtuQvCyO 1nwAnjf8ICourZ1qKvAmNVRr2IzhId47 =aHu1 -----END PGP SIGNATURE----- --------------enig40BDD5C13E24490DC67072D3-- --===============0856815243424158860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============0856815243424158860==-- From stefan.winter@restena.lu Thu Jan 26 23:55:58 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ED421F854C; Thu, 26 Jan 2012 23:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZGrmZgSnW5h; Thu, 26 Jan 2012 23:55:57 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7427221F854B; Thu, 26 Jan 2012 23:55:57 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id CCAC8106CB; Fri, 27 Jan 2012 08:55:56 +0100 (CET) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id BED76106C2; Fri, 27 Jan 2012 08:55:56 +0100 (CET) Message-ID: <4F225888.9050601@restena.lu> Date: Fri, 27 Jan 2012 08:55:52 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org, 'IETF Discussion Mailing List' References: , <4F2109F8.4060505@restena.lu> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8755B2B111B3152A1D96D22A" X-Virus-Scanned: ClamAV Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 07:55:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8755B2B111B3152A1D96D22A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, comments inline. > "Indeed. I'll update the text to that end. Note though that adding > Error-Cause is a MAY only in 5176, so it may very well be that an > implementation which doesn't support dynauth would still send only a > "naked" NAK, ignoring the MAY." >=20 > [BA] It's a MAY in RFC 5176 because existing implementations didn't > support Error-Cause at all. However, in this particular case, since > you're requiring that RADIUS/TLS implementations support NAK in the > first place, you can also say that they SHOULD send an Error-Cause > attribute. So I'd suggest that the MAY be stronger, so as to remove > a potential ambiguity about the meaning of the NAK. =20 >=20 > It is sufficient that upon > receiving such a packet, an unconditional NAK is sent back to > indicate that the action is not supported. =20 >=20 > [BA] The problem is that a NAK does NOT mean that the action is > unsupported according to RFC 5176, unless there is an Error-Cause > attribute present that indicates that.=20 Okay, the argument for a SHOULD sunds very reasonable. I have updated my working copy to that end. > Stefan said: > =20 > "I'm slightly confused here. To my best knowledge, Error-cause is only > specified in the context of DynAuth (RFC5176). That attribute is listed= > as only allowed in a NAK as per the attribute occurrence table in 5176.= " >=20 > [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authori= zation > it can also be used in other contexts. For example, Error-Cause is ref= erenced > in the following other RFCs: >=20 > RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see S= ection 3.3) > RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1) Ok... 3579 defines it to be that way, simply pointing to dynauth; my draft could do so, too, of course. 5080 lists that it is done elsewhere but doesn't reference a particular RFC; looks to me like it could refer to RFC3579. > Stefan said: >=20 > "I would be hesitant to use Error-Cause in RADIUS Accounting packets - > unless the corresponding RFCs get updated to specify that this attribut= e > is now also to be used in Accounting semantics." >=20 > [BA] Apparently, Error-Cause is being sent in Accounting-Request packet= s, see: > http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg0025= 5.html Interesting use. I don't recall "Error-Cause =3D Invite" being specified anywhere; it's not in the list of enumerated Error-Cause reasons in the IANA registry anyway. And it's one message on the list that was never replied to. Looks to me like it's one particular NAS sending weird things out-of-spec. I don't really like that as an example to be honest. > With respect to Accounting-Response, RFC 2866 does prohibit inclusion o= f=20 > attributes relating to a service, but not attributes like Proxy-State o= r Vendor-Specific. > So I'd argue that Error-Cause fits within the category of attributes th= at would > be permissible -- an Informational attribute that can be ignored withou= t damage. >=20 > Stefan said: >=20 > "The non-ability to indicate "No accounting please" has been discussed = in > a radext wg meeting. The conclusion was that auth and acct are two > separate, unrelated items. RADIUS Accounting needs to be configured > differently and explicitly; so there is little risk that accounting > packets are sent "by chance" anyway. If they are sent to the wrong > place, that is an administrative error: misconfigured on the sender-sid= e." >=20 > [BA] If a RADIUS over UDP packet is sent to the wrong place, an ICMP > message will result that the RADIUS Accounting client can act on, such > as by logging the error. =20 >=20 > In this case, you are mandating that the RADIUS over TLS server ignore > the request, resulting in continuing connection attempts and retransmis= sions > by the RADIUS over TLS client, who doesn't receive evidence of the misc= onfiguration. > So I'd argue that RADIUS over TLS is creating a new problem.=20 I take your point only partially. It's true that NASes could act on receipt of ICMP Port Unreachable, and they can't as per this spec. I would like to note however that ICMP Port Unreachable is a *very* coarse-grained way of NAKing accounting that is of little use anyway. Consider classic RADIUS, and a proxy environment where a server provides accounting services for some clients, but not for others (or even more fine-grained: for some realms, but not for others - even if they arrive via the same RADIUS client): a UDP port is either open or closed; it is an entirely binary way of signalling whether a server processes accounting for a given client or not. It is not possible to signal to the misconfigured peer that *his* (or only some of his) packets are unwanted, while others are. That is the situation in classic RADIUS, and makes ICMP Port Unreachable a very poor way of signalling this condition. That's why I don't have any scruple sacrificing it. (That, and that the wg discussion also was rather unimpressed about the consequences of this). That being said, I can change the spec to "patch" the situation with your suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. In the long run though, I think this solution is inadequate; if Accounting-NAK signalling is to be fixed, it should be fixed properly (i.e. on a per-packet basis) for all transports, not just this one. Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by adding an Accounting-NAK packet type, analogous to the dynauth NAKs. It is definitely a useful thing to work on; but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now; this might be worthwhile to include...) Please let me know if you'd prefer the Error-Cause "patch" to be in this spec; I'll do as you say :-) I promised my AD to publish the -11 revision for IESG review later today; if our conversation didn't converge until then, there can always be a -12. Probably necessary after the IESG review anyway :-) Greetings, Stefan Winter >=20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8755B2B111B3152A1D96D22A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8iWIwACgkQ+jm90f8eFWY1MwCeNAZpoZ/HOEQI/r6gC9VOwPfy L6QAnis1pH43I8zIg/G5fEW7aLXey/gL =Q7gL -----END PGP SIGNATURE----- --------------enig8755B2B111B3152A1D96D22A-- From radext-bounces@ietf.org Thu Jan 26 23:56:00 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698EC21F854C; Thu, 26 Jan 2012 23:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327650960; bh=wW4NVITnJUukzvTMqM8vlf7RtUf1TIWLYHgk1KbBxsI=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=vkVNf1E3s8EgsoyLol0IBUyBTg4cJgxLovD3vEPSzfXgmUBv/zYWOSA3OpyxiISmt cyRimKf3EoBDeuhIN51/PtDdJy72NQYo6JlpCZu+dmQkSiKbPc6DkxhKQr9MGj7T9Z RZeAD9cqIIyqD9S7ceK+V2ORWz6DyKP7dVLA/730= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ED421F854C; Thu, 26 Jan 2012 23:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZGrmZgSnW5h; Thu, 26 Jan 2012 23:55:57 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7427221F854B; Thu, 26 Jan 2012 23:55:57 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id CCAC8106CB; Fri, 27 Jan 2012 08:55:56 +0100 (CET) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id BED76106C2; Fri, 27 Jan 2012 08:55:56 +0100 (CET) Message-ID: <4F225888.9050601@restena.lu> Date: Fri, 27 Jan 2012 08:55:52 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org, 'IETF Discussion Mailing List' References: , <4F2109F8.4060505@restena.lu> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8679384323243734368==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8679384323243734368== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8755B2B111B3152A1D96D22A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8755B2B111B3152A1D96D22A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, comments inline. > "Indeed. I'll update the text to that end. Note though that adding > Error-Cause is a MAY only in 5176, so it may very well be that an > implementation which doesn't support dynauth would still send only a > "naked" NAK, ignoring the MAY." >=20 > [BA] It's a MAY in RFC 5176 because existing implementations didn't > support Error-Cause at all. However, in this particular case, since > you're requiring that RADIUS/TLS implementations support NAK in the > first place, you can also say that they SHOULD send an Error-Cause > attribute. So I'd suggest that the MAY be stronger, so as to remove > a potential ambiguity about the meaning of the NAK. =20 >=20 > It is sufficient that upon > receiving such a packet, an unconditional NAK is sent back to > indicate that the action is not supported. =20 >=20 > [BA] The problem is that a NAK does NOT mean that the action is > unsupported according to RFC 5176, unless there is an Error-Cause > attribute present that indicates that.=20 Okay, the argument for a SHOULD sunds very reasonable. I have updated my working copy to that end. > Stefan said: > =20 > "I'm slightly confused here. To my best knowledge, Error-cause is only > specified in the context of DynAuth (RFC5176). That attribute is listed= > as only allowed in a NAK as per the attribute occurrence table in 5176.= " >=20 > [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authori= zation > it can also be used in other contexts. For example, Error-Cause is ref= erenced > in the following other RFCs: >=20 > RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see S= ection 3.3) > RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1) Ok... 3579 defines it to be that way, simply pointing to dynauth; my draft could do so, too, of course. 5080 lists that it is done elsewhere but doesn't reference a particular RFC; looks to me like it could refer to RFC3579. > Stefan said: >=20 > "I would be hesitant to use Error-Cause in RADIUS Accounting packets - > unless the corresponding RFCs get updated to specify that this attribut= e > is now also to be used in Accounting semantics." >=20 > [BA] Apparently, Error-Cause is being sent in Accounting-Request packet= s, see: > http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg0025= 5.html Interesting use. I don't recall "Error-Cause =3D Invite" being specified anywhere; it's not in the list of enumerated Error-Cause reasons in the IANA registry anyway. And it's one message on the list that was never replied to. Looks to me like it's one particular NAS sending weird things out-of-spec. I don't really like that as an example to be honest. > With respect to Accounting-Response, RFC 2866 does prohibit inclusion o= f=20 > attributes relating to a service, but not attributes like Proxy-State o= r Vendor-Specific. > So I'd argue that Error-Cause fits within the category of attributes th= at would > be permissible -- an Informational attribute that can be ignored withou= t damage. >=20 > Stefan said: >=20 > "The non-ability to indicate "No accounting please" has been discussed = in > a radext wg meeting. The conclusion was that auth and acct are two > separate, unrelated items. RADIUS Accounting needs to be configured > differently and explicitly; so there is little risk that accounting > packets are sent "by chance" anyway. If they are sent to the wrong > place, that is an administrative error: misconfigured on the sender-sid= e." >=20 > [BA] If a RADIUS over UDP packet is sent to the wrong place, an ICMP > message will result that the RADIUS Accounting client can act on, such > as by logging the error. =20 >=20 > In this case, you are mandating that the RADIUS over TLS server ignore > the request, resulting in continuing connection attempts and retransmis= sions > by the RADIUS over TLS client, who doesn't receive evidence of the misc= onfiguration. > So I'd argue that RADIUS over TLS is creating a new problem.=20 I take your point only partially. It's true that NASes could act on receipt of ICMP Port Unreachable, and they can't as per this spec. I would like to note however that ICMP Port Unreachable is a *very* coarse-grained way of NAKing accounting that is of little use anyway. Consider classic RADIUS, and a proxy environment where a server provides accounting services for some clients, but not for others (or even more fine-grained: for some realms, but not for others - even if they arrive via the same RADIUS client): a UDP port is either open or closed; it is an entirely binary way of signalling whether a server processes accounting for a given client or not. It is not possible to signal to the misconfigured peer that *his* (or only some of his) packets are unwanted, while others are. That is the situation in classic RADIUS, and makes ICMP Port Unreachable a very poor way of signalling this condition. That's why I don't have any scruple sacrificing it. (That, and that the wg discussion also was rather unimpressed about the consequences of this). That being said, I can change the spec to "patch" the situation with your suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. In the long run though, I think this solution is inadequate; if Accounting-NAK signalling is to be fixed, it should be fixed properly (i.e. on a per-packet basis) for all transports, not just this one. Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by adding an Accounting-NAK packet type, analogous to the dynauth NAKs. It is definitely a useful thing to work on; but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now; this might be worthwhile to include...) Please let me know if you'd prefer the Error-Cause "patch" to be in this spec; I'll do as you say :-) I promised my AD to publish the -11 revision for IESG review later today; if our conversation didn't converge until then, there can always be a -12. Probably necessary after the IESG review anyway :-) Greetings, Stefan Winter >=20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8755B2B111B3152A1D96D22A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8iWIwACgkQ+jm90f8eFWY1MwCeNAZpoZ/HOEQI/r6gC9VOwPfy L6QAnis1pH43I8zIg/G5fEW7aLXey/gL =Q7gL -----END PGP SIGNATURE----- --------------enig8755B2B111B3152A1D96D22A-- --===============8679384323243734368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============8679384323243734368==-- From internet-drafts@ietf.org Fri Jan 27 06:48:39 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5C21F85C3; Fri, 27 Jan 2012 06:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYERvsrBV5iu; Fri, 27 Jan 2012 06:48:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6021F8516; Fri, 27 Jan 2012 06:48:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120127144839.11692.74419.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 06:48:39 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radsec-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 14:48:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. Title : TLS encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-11.txt Pages : 21 Date : 2012-01-27 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-11.txt From radext-bounces@ietf.org Fri Jan 27 06:48:42 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFD821F8537; Fri, 27 Jan 2012 06:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327675721; bh=gd5Vs+rOVBMVXNQ/gQ8MHzwKq/IVRB62bEimYEos2bc=; h=MIME-Version:From:To:Message-ID:Date:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=LHWSawnbpT1w9/7QWDVneiYZMS4K1LAxsMq4KGvphz6aSmLJNoOJKXJZSu5LfVLUX SD7EWtNciZH5dkCjIOh648e4beJioIxRcIIlXhsXxcQCjrWeJ1Nu0KEhZA3tGXqJgt UliG7KfhaFAmEOAPb10C+gfK6mKL58N4nGGTArZU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5C21F85C3; Fri, 27 Jan 2012 06:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYERvsrBV5iu; Fri, 27 Jan 2012 06:48:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E6021F8516; Fri, 27 Jan 2012 06:48:39 -0800 (PST) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120127144839.11692.74419.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 06:48:39 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radsec-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : TLS encryption for RADIUS Author(s) : Stefan Winter Mike McCauley Stig Venaas Klaas Wierenga Filename : draft-ietf-radext-radsec-11.txt Pages : 21 Date : 2012-01-27 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radext-radsec-11.txt _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Fri Jan 27 06:53:00 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB521F84F6 for ; Fri, 27 Jan 2012 06:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZRqozBxjh12 for ; Fri, 27 Jan 2012 06:52:59 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C121D21F84F3 for ; Fri, 27 Jan 2012 06:52:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2B929106CB for ; Fri, 27 Jan 2012 15:52:59 +0100 (CET) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1A57B10691 for ; Fri, 27 Jan 2012 15:52:59 +0100 (CET) Message-ID: <4F22BA46.8080009@restena.lu> Date: Fri, 27 Jan 2012 15:52:54 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120127144839.11692.74419.idtracker@ietfa.amsl.com> In-Reply-To: <20120127144839.11692.74419.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig946E522BF0123657D5D6094E" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 14:53:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig946E522BF0123657D5D6094E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. >=20 > Title : TLS encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-11.txt > Pages : 21 > Date : 2012-01-27 >=20 > This document specifies security on the transport layer (TLS) for th= e > RADIUS protocol when transmitted over TCP. This enables dynamic > trust relationships between RADIUS servers. This new version takes all the IETF LC comments into account. One comment from Bernard Aboba is not entirely resolved yet (Accounting "NAK" handling). Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig946E522BF0123657D5D6094E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8iuksACgkQ+jm90f8eFWbzSACeIuyzEuGYdXhVxYmioZ0/r/O6 6RYAn3hTvKBvGZflmdDDM2so6FwHE5o9 =p9Lq -----END PGP SIGNATURE----- --------------enig946E522BF0123657D5D6094E-- From radext-bounces@ietf.org Fri Jan 27 06:53:01 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF9921F84F6; Fri, 27 Jan 2012 06:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327675981; bh=JSZHv3AZTjL37YOE7hCMImuHf40MdpXmwqpgkelhXxQ=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=fGT4CDxgpzTgAiA1MyvsSDVChsvBnECZgmQ114EDo7KseSW0JHDRPFTaRlbI0P9gg HsE5PynMoK5k/GgUs1pRf17NxrPpnbHE5/x6LHh5epxBf+pPVa1gIDYScM8Vlytbw1 0TpSIVstH71YGlRbSKWCkNMwgCrVEWJ7LDG5SuXE= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB521F84F6 for ; Fri, 27 Jan 2012 06:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZRqozBxjh12 for ; Fri, 27 Jan 2012 06:52:59 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C121D21F84F3 for ; Fri, 27 Jan 2012 06:52:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2B929106CB for ; Fri, 27 Jan 2012 15:52:59 +0100 (CET) Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1A57B10691 for ; Fri, 27 Jan 2012 15:52:59 +0100 (CET) Message-ID: <4F22BA46.8080009@restena.lu> Date: Fri, 27 Jan 2012 15:52:54 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: <20120127144839.11692.74419.idtracker@ietfa.amsl.com> In-Reply-To: <20120127144839.11692.74419.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-radsec-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9198838592355590977==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============9198838592355590977== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig946E522BF0123657D5D6094E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig946E522BF0123657D5D6094E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the RADIUS EXTensions Working Group= of the IETF. >=20 > Title : TLS encryption for RADIUS > Author(s) : Stefan Winter > Mike McCauley > Stig Venaas > Klaas Wierenga > Filename : draft-ietf-radext-radsec-11.txt > Pages : 21 > Date : 2012-01-27 >=20 > This document specifies security on the transport layer (TLS) for th= e > RADIUS protocol when transmitted over TCP. This enables dynamic > trust relationships between RADIUS servers. This new version takes all the IETF LC comments into account. One comment from Bernard Aboba is not entirely resolved yet (Accounting "NAK" handling). Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig946E522BF0123657D5D6094E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8iuksACgkQ+jm90f8eFWbzSACeIuyzEuGYdXhVxYmioZ0/r/O6 6RYAn3hTvKBvGZflmdDDM2so6FwHE5o9 =p9Lq -----END PGP SIGNATURE----- --------------enig946E522BF0123657D5D6094E-- --===============9198838592355590977== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============9198838592355590977==-- From hartmans@painless-security.com Fri Jan 27 11:47:50 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564921F85F3; Fri, 27 Jan 2012 11:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5kCoMQNpC+L; Fri, 27 Jan 2012 11:47:49 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AB21F8510; Fri, 27 Jan 2012 11:47:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A9B42204AF; Fri, 27 Jan 2012 14:46:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 528A74690; Fri, 27 Jan 2012 14:47:42 -0500 (EST) From: Sam Hartman To: radext@ietf.org,secdir@ietf.org,ietf@ietf.org Date: Fri, 27 Jan 2012 14:47:42 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [radext] Security review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:47:50 -0000 Hi. I'm not the secdir reviewer assigned to this draft, but felt that this draft needed additional security review, so I decided to perform a secdir-like review. Overall, I think this is a much-needed specification and believe it is mostly ready for publication as an experimental RFC. I'd say a bit more clarity would be required if we wanted to move this to the standards track. General issues: 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions prior to 1.1. The concern I have is that RADSEC has long-lived TLS connections under which an attacker could potentially observe ciphertext generated from some plaintext before sending additional plaintext. TLS 1.1 includes explicit IVs that prevent various attacks that may happen against earlier versions of TLS. There are implementation work arounds that can also prevent these attacks. However since all RADSEC implementations are required to support TLS 1.1, I'd prefer to add a requirement that RADSEC implementations MUST NOT negotiate TLS versions prior to 1.1 in order to avoid this issue. 2) Section 2.3 implies that you need to do cert validation all the time, even when you have a certificate fingerprint. I think it could more clearly indicate that multiple ways of figuring out if you have the right public key are provided. It's also not clear to me from section 2.3 whether there is a mandatory-to-implement strategy. You SHOULD support cert fingerprints. You MUST support cert path validation, but is there a required name form to support? There are discussions of several name forms but none seem mandatory. I see no discussion of RFC 6125, which I would have expected to see here. However, most of this is OK for an experimental spec. This is the big area where I'd expect to see more clarity before this could move to the standards track. From radext-bounces@ietf.org Fri Jan 27 11:47:51 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE7E21F85F3; Fri, 27 Jan 2012 11:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327693671; bh=SdqFSJpuUj4hqjd+6huW6uG3Ht/RtHAtQVrcy3Rkxy0=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=kYNvoKIFjsLKoj6aqLgaqavYGcDrXyUH7Yh/BfsW9bm8JdaIs8ZpwUxrM2PIwm9bW JztQOL28bnqVzBFr1mOMbxR7ds/j1Kd/AjSvtpHm9gkKR3MksTQNHPi3GGJe9WhkhY GK62zlYcrGUGJ1SWPq+6BS6vd5VQQ3Er3VXvltKc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564921F85F3; Fri, 27 Jan 2012 11:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5kCoMQNpC+L; Fri, 27 Jan 2012 11:47:49 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AB21F8510; Fri, 27 Jan 2012 11:47:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A9B42204AF; Fri, 27 Jan 2012 14:46:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 528A74690; Fri, 27 Jan 2012 14:47:42 -0500 (EST) From: Sam Hartman To: radext@ietf.org,secdir@ietf.org,ietf@ietf.org Date: Fri, 27 Jan 2012 14:47:42 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Subject: [radext] Security review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Hi. I'm not the secdir reviewer assigned to this draft, but felt that this draft needed additional security review, so I decided to perform a secdir-like review. Overall, I think this is a much-needed specification and believe it is mostly ready for publication as an experimental RFC. I'd say a bit more clarity would be required if we wanted to move this to the standards track. General issues: 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions prior to 1.1. The concern I have is that RADSEC has long-lived TLS connections under which an attacker could potentially observe ciphertext generated from some plaintext before sending additional plaintext. TLS 1.1 includes explicit IVs that prevent various attacks that may happen against earlier versions of TLS. There are implementation work arounds that can also prevent these attacks. However since all RADSEC implementations are required to support TLS 1.1, I'd prefer to add a requirement that RADSEC implementations MUST NOT negotiate TLS versions prior to 1.1 in order to avoid this issue. 2) Section 2.3 implies that you need to do cert validation all the time, even when you have a certificate fingerprint. I think it could more clearly indicate that multiple ways of figuring out if you have the right public key are provided. It's also not clear to me from section 2.3 whether there is a mandatory-to-implement strategy. You SHOULD support cert fingerprints. You MUST support cert path validation, but is there a required name form to support? There are discussions of several name forms but none seem mandatory. I see no discussion of RFC 6125, which I would have expected to see here. However, most of this is OK for an experimental spec. This is the big area where I'd expect to see more clarity before this could move to the standards track. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Fri Jan 27 15:55:50 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50B21F85C7; Fri, 27 Jan 2012 15:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+gOmhJXlr7s; Fri, 27 Jan 2012 15:55:49 -0800 (PST) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6121F85D2; Fri, 27 Jan 2012 15:55:48 -0800 (PST) Received: from BLU152-W47 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 15:55:47 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_951639fe-3bc0-49ed-a414-debe6639e541_" X-Originating-IP: [131.107.0.118] From: Bernard Aboba To: Stefan Winter , , Date: Fri, 27 Jan 2012 15:55:47 -0800 Importance: Normal In-Reply-To: <4F225888.9050601@restena.lu> References: , , <4F2109F8.4060505@restena.lu>, , <4F225888.9050601@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 23:55:47.0939 (UTC) FILETIME=[30E54B30:01CCDD4F] Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:55:50 -0000 --_951639fe-3bc0-49ed-a414-debe6639e541_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: =20 "Ok... 3579 defines it to be that way=2C simply pointing to dynauth=3B my draft could do so=2C too=2C of course. 5080 lists that it is done elsewhere but doesn't reference a particular RFC=3B looks to me like it could refer to RFC3579." [BA] Yes.=20 =20 Stefan also said: =20 "Interesting use. I don't recall "Error-Cause =3D Invite" being specified anywhere=3B it's not in the list of enumerated Error-Cause reasons in the IANA registry anyway. =20 And it's one message on the list that was never replied to. Looks to me like it's one particular NAS sending weird things out-of-spec." [BA] Since the message was posted on the FreeRADIUS list=2C I was hoping that Alan could enlighten us. The meaning of "Error-Cause=3DInvite" wasn't obvious to me (e.g. it didn't look like there was an error involved)=2C=20 and as you mentioned=2C "Invite" isn't in the list of enumerated Error-Caus= e values.=20 =20 Stefan said:=20 =20 "I would like to note however that ICMP Port Unreachable is a *very* coarse-grained way of NAKing accounting that is of little use anyway... That being said=2C I can change the spec to "patch" the situation with your suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. [BA] I agree that an ICMP Port Unreachable is not a useful way for a RADIUS server to tell a RADIUS client that it can't process a particular Accounting-Request. However=2C it does allow the destination to indicate that RADIUS accounting is not supported at all=2C in a way that can be distinguished from a server or network failure. That's the functionality missing in RADIUS over TLS.=20 Stefan said: =20 "In the long run though=2C I think this solution is inadequate=3B if Accounting-NAK signalling is to be fixed=2C it should be fixed properly (i.e. on a per-packet basis) for all transports=2C not just this one. Maybe by updating 2866 with a consistent use of Error-Cause=2C or maybe by adding an Accounting-NAK packet type=2C analogous to the dynauth NAKs. It is definitely a useful thing to work on=3B but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now=3B this might be worthwhile to include...)" [BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS is not a solution to the other problems you mention. Stefan said: "Please let me know if you'd prefer the Error-Cause "patch" to be in this spec=3B I'll do as you say =3B) [BA] Here is suggested text: (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets.=20 Since RADIUS/TLS does not utilize a separate port for Accounting packets=2C this mechanism is not available. In the event that a=20 client is misconfigured to send Accounting-Request packets to a RADIUS/TLS server which does not support accounting=2C the=20 RADIUS/TLS server SHOULD reply with an Accounting-Response=20 containing an Error-Cause attribute with value 406=20 "Unsupported Extension". A RADIUS/TLS accounting client=20 receiving such an Accounting-Response SHOULD log the error. =20 =20 = --_951639fe-3bc0-49ed-a414-debe6639e541_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
 
"Ok... 3579 defines it to be that way=2C sim=
ply pointing to dynauth=3B my
draft could do so=2C too=2C of course.
=
5080 lists that it is done elsewhere but doesn't reference a particular
=
RFC=3B looks to me like it could refer to RFC3579."

[BA] Yes. 
 <=
br>Stefan also said:
 =3B
"Interesting use. I don't recall "Error=
-Cause =3D Invite" being specified
anywhere=3B it's not in the list of e=
numerated Error-Cause reasons in the
IANA registry anyway.
 
And i=
t's one message on the list that was never replied to. Looks to me
like =
it's one particular NAS sending weird things out-of-spec."

[BA] Sinc=
e the message was posted on the FreeRADIUS list=2C I was hoping
that Ala=
n could enlighten us.  The meaning of "Error-Cause=3DInvite" wasn't
obvi=
ous to me (e.g. it didn't look like there was an error involved)=2C 
and=
 as you mentioned=2C "Invite" isn't in the list of enumerated Error-Causevalues. 
 
Stefan said: 
 
"I would like to note however that=
 ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounti=
ng that is of little use anyway...

That being said=2C I can change t=
he spec to "patch" the situation with
your suggestion of using Accountin=
g-Response + Error-Cause. It may be
the adequate thing to do since this =
specification is going for
Experimental only.

[BA] I agree that a=
n ICMP Port Unreachable is not a useful way for a
RADIUS server to tell =
a RADIUS client that it can't process a particular
Accounting-Request.  =
However=2C it does allow the destination to indicate
that RADIUS account=
ing is not supported at all=2C in a way that can be
distinguished from a=
 server or network failure.  That's the functionality
missing in RADIUS =
over TLS. 

Stefan said:
 
"In the long run though=2C I think t=
his solution is inadequate=3B if
Accounting-NAK signalling is to be fixe=
d=2C it should be fixed properly
(i.e. on a per-packet basis) for all tr=
ansports=2C not just this one.
Maybe by updating 2866 with a consistent =
use of Error-Cause=2C or maybe by
adding an Accounting-NAK packet type=
=2C analogous to the dynauth NAKs.

It is definitely a useful thing t=
o work on=3B but it's not for the
RAIDUS/TLS draft to decide. That would=
 need a wg chartered item (luckily
radext is discussing rechartering rig=
ht now=3B this might be worthwhile to
include...)"

[BA] I agree t=
hat ICMP Port Unreachable or an equivalent in RADIUS/TLS
is not a soluti=
on to the other problems you mention.

Stefan said:

"Please le=
t me know if you'd prefer the Error-Cause "patch" to be in this
spec=3B =
I'll do as you say =3B)

[BA] Here is suggested text:

   (5) R=
ADIUS/UDP [RFC2865] u=
ses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of RADIUS Accounting packets. 
   Si=
nce RADIUS/TLS does not utilize a separate port for Accounting
   packet=
s=2C this mechanism is not available.  In the event that a 
   client is=
 misconfigured to send Accounting-Request packets to
   a RADIUS/TLS ser=
ver which does not support accounting=2C the 
   RADIUS/TLS server SHOUL=
D reply with an Accounting-Response 
   containing an Error-Cause attrib=
ute with value 406 
   "Unsupported Extension".  A RADIUS/TLS accounting=
 client 
   receiving such an Accounting-Response SHOULD log the error. =
= --_951639fe-3bc0-49ed-a414-debe6639e541_-- From radext-bounces@ietf.org Fri Jan 27 15:55:54 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A721F862A; Fri, 27 Jan 2012 15:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327708554; bh=5/uVPKv3eTgK58SHMIOgaCgXSBxT5QDdgu/Jcd8STfI=; h=Message-ID:From:To:Date:In-Reply-To:References:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=WVU8MgYfBgujRT9jPTACTSwSIulf00tywphF8abGdFstZ6WcB3jHXJFjUXdRErb+Y 9C94pQvtSpSggWb778NTajYd0851IPvwkfdCnQ++FtXPC2XpIce8m3HYhfvTC93p0I wANXObvlkDhojpFHovrn8x5uxlinRjLOC7ilvA/0= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50B21F85C7; Fri, 27 Jan 2012 15:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.18 X-Spam-Level: X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+gOmhJXlr7s; Fri, 27 Jan 2012 15:55:49 -0800 (PST) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6121F85D2; Fri, 27 Jan 2012 15:55:48 -0800 (PST) Received: from BLU152-W47 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 15:55:47 -0800 Message-ID: X-Originating-IP: [131.107.0.118] From: Bernard Aboba To: Stefan Winter , , Date: Fri, 27 Jan 2012 15:55:47 -0800 Importance: Normal In-Reply-To: <4F225888.9050601@restena.lu> References: , , <4F2109F8.4060505@restena.lu>, , <4F225888.9050601@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 23:55:47.0939 (UTC) FILETIME=[30E54B30:01CCDD4F] Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5468481998317880573==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org --===============5468481998317880573== Content-Type: multipart/alternative; boundary="_951639fe-3bc0-49ed-a414-debe6639e541_" --_951639fe-3bc0-49ed-a414-debe6639e541_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stefan said: =20 "Ok... 3579 defines it to be that way=2C simply pointing to dynauth=3B my draft could do so=2C too=2C of course. 5080 lists that it is done elsewhere but doesn't reference a particular RFC=3B looks to me like it could refer to RFC3579." [BA] Yes.=20 =20 Stefan also said: =20 "Interesting use. I don't recall "Error-Cause =3D Invite" being specified anywhere=3B it's not in the list of enumerated Error-Cause reasons in the IANA registry anyway. =20 And it's one message on the list that was never replied to. Looks to me like it's one particular NAS sending weird things out-of-spec." [BA] Since the message was posted on the FreeRADIUS list=2C I was hoping that Alan could enlighten us. The meaning of "Error-Cause=3DInvite" wasn't obvious to me (e.g. it didn't look like there was an error involved)=2C=20 and as you mentioned=2C "Invite" isn't in the list of enumerated Error-Caus= e values.=20 =20 Stefan said:=20 =20 "I would like to note however that ICMP Port Unreachable is a *very* coarse-grained way of NAKing accounting that is of little use anyway... That being said=2C I can change the spec to "patch" the situation with your suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. [BA] I agree that an ICMP Port Unreachable is not a useful way for a RADIUS server to tell a RADIUS client that it can't process a particular Accounting-Request. However=2C it does allow the destination to indicate that RADIUS accounting is not supported at all=2C in a way that can be distinguished from a server or network failure. That's the functionality missing in RADIUS over TLS.=20 Stefan said: =20 "In the long run though=2C I think this solution is inadequate=3B if Accounting-NAK signalling is to be fixed=2C it should be fixed properly (i.e. on a per-packet basis) for all transports=2C not just this one. Maybe by updating 2866 with a consistent use of Error-Cause=2C or maybe by adding an Accounting-NAK packet type=2C analogous to the dynauth NAKs. It is definitely a useful thing to work on=3B but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now=3B this might be worthwhile to include...)" [BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS is not a solution to the other problems you mention. Stefan said: "Please let me know if you'd prefer the Error-Cause "patch" to be in this spec=3B I'll do as you say =3B) [BA] Here is suggested text: (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets.=20 Since RADIUS/TLS does not utilize a separate port for Accounting packets=2C this mechanism is not available. In the event that a=20 client is misconfigured to send Accounting-Request packets to a RADIUS/TLS server which does not support accounting=2C the=20 RADIUS/TLS server SHOULD reply with an Accounting-Response=20 containing an Error-Cause attribute with value 406=20 "Unsupported Extension". A RADIUS/TLS accounting client=20 receiving such an Accounting-Response SHOULD log the error. =20 =20 = --_951639fe-3bc0-49ed-a414-debe6639e541_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Stefan said:
 
"Ok... 3579 defines it to be that way=2C sim=
ply pointing to dynauth=3B my
draft could do so=2C too=2C of course.
=
5080 lists that it is done elsewhere but doesn't reference a particular
=
RFC=3B looks to me like it could refer to RFC3579."

[BA] Yes. 
 <=
br>Stefan also said:
 =3B
"Interesting use. I don't recall "Error=
-Cause =3D Invite" being specified
anywhere=3B it's not in the list of e=
numerated Error-Cause reasons in the
IANA registry anyway.
 
And i=
t's one message on the list that was never replied to. Looks to me
like =
it's one particular NAS sending weird things out-of-spec."

[BA] Sinc=
e the message was posted on the FreeRADIUS list=2C I was hoping
that Ala=
n could enlighten us.  The meaning of "Error-Cause=3DInvite" wasn't
obvi=
ous to me (e.g. it didn't look like there was an error involved)=2C 
and=
 as you mentioned=2C "Invite" isn't in the list of enumerated Error-Causevalues. 
 
Stefan said: 
 
"I would like to note however that=
 ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounti=
ng that is of little use anyway...

That being said=2C I can change t=
he spec to "patch" the situation with
your suggestion of using Accountin=
g-Response + Error-Cause. It may be
the adequate thing to do since this =
specification is going for
Experimental only.

[BA] I agree that a=
n ICMP Port Unreachable is not a useful way for a
RADIUS server to tell =
a RADIUS client that it can't process a particular
Accounting-Request.  =
However=2C it does allow the destination to indicate
that RADIUS account=
ing is not supported at all=2C in a way that can be
distinguished from a=
 server or network failure.  That's the functionality
missing in RADIUS =
over TLS. 

Stefan said:
 
"In the long run though=2C I think t=
his solution is inadequate=3B if
Accounting-NAK signalling is to be fixe=
d=2C it should be fixed properly
(i.e. on a per-packet basis) for all tr=
ansports=2C not just this one.
Maybe by updating 2866 with a consistent =
use of Error-Cause=2C or maybe by
adding an Accounting-NAK packet type=
=2C analogous to the dynauth NAKs.

It is definitely a useful thing t=
o work on=3B but it's not for the
RAIDUS/TLS draft to decide. That would=
 need a wg chartered item (luckily
radext is discussing rechartering rig=
ht now=3B this might be worthwhile to
include...)"

[BA] I agree t=
hat ICMP Port Unreachable or an equivalent in RADIUS/TLS
is not a soluti=
on to the other problems you mention.

Stefan said:

"Please le=
t me know if you'd prefer the Error-Cause "patch" to be in this
spec=3B =
I'll do as you say =3B)

[BA] Here is suggested text:

   (5) R=
ADIUS/UDP [RFC2865] u=
ses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of RADIUS Accounting packets. 
   Si=
nce RADIUS/TLS does not utilize a separate port for Accounting
   packet=
s=2C this mechanism is not available.  In the event that a 
   client is=
 misconfigured to send Accounting-Request packets to
   a RADIUS/TLS ser=
ver which does not support accounting=2C the 
   RADIUS/TLS server SHOUL=
D reply with an Accounting-Response 
   containing an Error-Cause attrib=
ute with value 406 
   "Unsupported Extension".  A RADIUS/TLS accounting=
 client 
   receiving such an Accounting-Response SHOULD log the error. =
= --_951639fe-3bc0-49ed-a414-debe6639e541_-- --===============5468481998317880573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============5468481998317880573==-- From aland@deployingradius.com Sat Jan 28 00:40:36 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BE721F84F6 for ; Sat, 28 Jan 2012 00:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm+Gsov58wsu for ; Sat, 28 Jan 2012 00:40:35 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5452C21F84F3 for ; Sat, 28 Jan 2012 00:40:35 -0800 (PST) Message-ID: <4F23B466.2070102@deployingradius.com> Date: Sat, 28 Jan 2012 09:40:06 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , , <4F2109F8.4060505@restena.lu>, , <4F225888.9050601@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 08:40:36 -0000 Bernard Aboba wrote: > [BA] Since the message was posted on the FreeRADIUS list, I was hoping > that Alan could enlighten us. The meaning of "Error-Cause=Invite" wasn't > obvious to me (e.g. it didn't look like there was an error involved), > and as you mentioned, "Invite" isn't in the list of enumerated Error-Cause > values. It's not. This is another instance of a vendor abusing the standard space. The OpenSER project has defined their own dictionary, which is included by NOT referenced in FreeRADIUS: https://github.com/alandekok/freeradius-server/blob/master/share/dictionary.openser That dictionary has the following comment at the top: # This dictionary is NOT included by default, because it conflicts # with attributes defined in the RADIUS standard. Vendors SHOULD # be using a VSA space to assign attributes. # # Be aware that if you DO include this dictionary in the main # dictionary file, other parts of your configuration may break! The user has edited the system to use this dictionary, in violation of the above recommendations. The result is that the "SIP-Method" attribute has the same value and data type as Error-Cause. When a packet is received with attribute 101, the Error-Cause name is printed. However, the name of the VALUE is taken from SIP-Method. The reason is that FreeRADIUS assumes the dictionaries are in a "flat" namespace. So when there are conflicts, they are implicitly resolved by whatever the code happens to do. There doesn't appear to be much need to change that behavior, to allow multiple conflicting dictionaries. The vendors who do this have mostly learned it's bad behavior. > [BA] Here is suggested text: > > (5) RADIUS/UDP [RFC2865 ] uses negative ICMP responses to a newly > allocated UDP port to signal that a peer RADIUS server does not > support reception and processing of RADIUS Accounting packets. > Since RADIUS/TLS does not utilize a separate port for Accounting > packets, this mechanism is not available. In the event that a > client is misconfigured to send Accounting-Request packets to > a RADIUS/TLS server which does not support accounting, the > RADIUS/TLS server SHOULD reply with an Accounting-Response > containing an Error-Cause attribute with value 406 > "Unsupported Extension". A RADIUS/TLS accounting client > receiving such an Accounting-Response SHOULD log the error. Also STOP SENDING ACCOUNTING PACKETS! Alan DeKok. From radext-bounces@ietf.org Sat Jan 28 00:40:38 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CBE21F84F6; Sat, 28 Jan 2012 00:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327740037; bh=aUeQZuXhIYzN5S+nwvaOOWChvvhjYFDtydGmQEF/TDg=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=BsceRVDXtBhuR1VhR2v4FASHCHcPsN/WC+yZofNnjp0n8v96gzwGxIADw3cjnYI8/ E7oQf24X9oShvC4QEmzXJ5lW5+8NnE9M/K6DbKVzWAIwbMdkjpVilpHxg/ibPmKLQD syXQD3oCg+Hp1jZFQGcqTOYq/iy2gG7JbyWRX2ns= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BE721F84F6 for ; Sat, 28 Jan 2012 00:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm+Gsov58wsu for ; Sat, 28 Jan 2012 00:40:35 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 5452C21F84F3 for ; Sat, 28 Jan 2012 00:40:35 -0800 (PST) Message-ID: <4F23B466.2070102@deployingradius.com> Date: Sat, 28 Jan 2012 09:40:06 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , , <4F2109F8.4060505@restena.lu>, , <4F225888.9050601@restena.lu> In-Reply-To: X-Enigmail-Version: 0.96.0 Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Bernard Aboba wrote: > [BA] Since the message was posted on the FreeRADIUS list, I was hoping > that Alan could enlighten us. The meaning of "Error-Cause=Invite" wasn't > obvious to me (e.g. it didn't look like there was an error involved), > and as you mentioned, "Invite" isn't in the list of enumerated Error-Cause > values. It's not. This is another instance of a vendor abusing the standard space. The OpenSER project has defined their own dictionary, which is included by NOT referenced in FreeRADIUS: https://github.com/alandekok/freeradius-server/blob/master/share/dictionary.openser That dictionary has the following comment at the top: # This dictionary is NOT included by default, because it conflicts # with attributes defined in the RADIUS standard. Vendors SHOULD # be using a VSA space to assign attributes. # # Be aware that if you DO include this dictionary in the main # dictionary file, other parts of your configuration may break! The user has edited the system to use this dictionary, in violation of the above recommendations. The result is that the "SIP-Method" attribute has the same value and data type as Error-Cause. When a packet is received with attribute 101, the Error-Cause name is printed. However, the name of the VALUE is taken from SIP-Method. The reason is that FreeRADIUS assumes the dictionaries are in a "flat" namespace. So when there are conflicts, they are implicitly resolved by whatever the code happens to do. There doesn't appear to be much need to change that behavior, to allow multiple conflicting dictionaries. The vendors who do this have mostly learned it's bad behavior. > [BA] Here is suggested text: > > (5) RADIUS/UDP [RFC2865 ] uses negative ICMP responses to a newly > allocated UDP port to signal that a peer RADIUS server does not > support reception and processing of RADIUS Accounting packets. > Since RADIUS/TLS does not utilize a separate port for Accounting > packets, this mechanism is not available. In the event that a > client is misconfigured to send Accounting-Request packets to > a RADIUS/TLS server which does not support accounting, the > RADIUS/TLS server SHOULD reply with an Accounting-Response > containing an Error-Cause attribute with value 406 > "Unsupported Extension". A RADIUS/TLS accounting client > receiving such an Accounting-Response SHOULD log the error. Also STOP SENDING ACCOUNTING PACKETS! Alan DeKok. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Sat Jan 28 07:39:00 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588C321F84F2 for ; Sat, 28 Jan 2012 07:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdoUFyfdLwoX for ; Sat, 28 Jan 2012 07:39:00 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1621F84D6 for ; Sat, 28 Jan 2012 07:38:59 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 017D720424; Sat, 28 Jan 2012 10:38:04 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DB7884690; Sat, 28 Jan 2012 10:38:50 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4F2109F8.4060505@restena.lu> <4F225888.9050601@restena.lu> <4F23B466.2070102@deployingradius.com> Date: Sat, 28 Jan 2012 10:38:50 -0500 In-Reply-To: <4F23B466.2070102@deployingradius.com> (Alan DeKok's message of "Sat, 28 Jan 2012 09:40:06 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bernard Aboba , Stefan Winter , radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 15:39:00 -0000 I'm fine with Bernard's error text, although I note that section 3 is non-normative and you're adding normative advice to it. From radext-bounces@ietf.org Sat Jan 28 07:39:03 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA6B21F84F2; Sat, 28 Jan 2012 07:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327765143; bh=MaKEeuJ7zRJe+KMpXHUDHPHZbtRHGoxIk4bKfJ9zGcE=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=L/MdA0QaOi5bXUBc0jhvvO65hwTdKNQJoN0yWhFikuvCBbu8fbzb3qk00a5XaBQtQ mg5aGKzyJDUeWGSKwqjQllh0tISy9uPYgk2M1j6PFM3lJEXpDkiME6Ffb8Qtm+j6e8 VELVsnwfu97xBK5iWNT3ZHkcCvBmPvjQPWdHjV+Q= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588C321F84F2 for ; Sat, 28 Jan 2012 07:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdoUFyfdLwoX for ; Sat, 28 Jan 2012 07:39:00 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BFF1621F84D6 for ; Sat, 28 Jan 2012 07:38:59 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 017D720424; Sat, 28 Jan 2012 10:38:04 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DB7884690; Sat, 28 Jan 2012 10:38:50 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4F2109F8.4060505@restena.lu> <4F225888.9050601@restena.lu> <4F23B466.2070102@deployingradius.com> Date: Sat, 28 Jan 2012 10:38:50 -0500 In-Reply-To: <4F23B466.2070102@deployingradius.com> (Alan DeKok's message of "Sat, 28 Jan 2012 09:40:06 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: Bernard Aboba , Stefan Winter , radext@ietf.org Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org I'm fine with Bernard's error text, although I note that section 3 is non-normative and you're adding normative advice to it. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dromasca@avaya.com Sun Jan 29 08:45:36 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D53521F8554 for ; Sun, 29 Jan 2012 08:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRIvGQLD6geq for ; Sun, 29 Jan 2012 08:45:35 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46521F84EC for ; Sun, 29 Jan 2012 08:45:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA12JU/GmAcF/2dsb2JhbAA8Bq5XgQWBcgEBAQEDEh4KSwYBCA0EBAEBCwYMCwEHRQcBAQUEAQQTCBqgT4QXmliIHx0qAwSDPgkfgS0BgktjBJsSjFo X-IronPort-AV: E=Sophos;i="4.71,588,1320642000"; d="scan'208";a="229093561" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Jan 2012 11:45:34 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jan 2012 11:40:10 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Jan 2012 17:45:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECDIR review of draft-ietf-radext-radsec-11 Thread-Index: AczdOsLYiZJG3oXYSMqP1t9jkSw5PwBapsGQ From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: SECDIR review of draft-ietf-radext-radsec-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 16:45:36 -0000 -----Original Message----- From: Matt Lepinski [mailto:mlepinski@bbn.com]=20 Sent: Friday, January 27, 2012 11:29 PM To: secdir@ietf.org; draft-ietf-radext-radsec.all@tools.ietf.org Subject: SECDIR review of draft-ietf-radext-radsec-11 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. This document specifies a TLS transport for the RADIUS protocol. It is=20 an experimental specification that is one of several approaches to=20 address security shortcomings in RADIUS (for example, the reliance of=20 RADIUS upon MD5). I believe this document presents a reasonable approach to providing=20 integrity and confidentiality protection to RADIUS packets as well as=20 cipher suite agility. The principal security concern is that when=20 deploying RADIUS/TLS, the system will be vulnerable to bid-down attacks=20 to RADIUS/UDP until either the RADIUS client or the RADIUS server=20 disables support for RADIUS/UDP. This type of bid-down attack seems to=20 be unavoidable and is well-documented in the security considerations. I have a small number of additional comments below: -- I would strongly advise changing all instances of the phrase=20 "acceptable Certification Authority" to "trusted Certification=20 Authority" in order to be consistent with terminology in TLS 1.2 (RFC=20 5246). (I found instances of the phrase "acceptable Certification=20 Authority" on the bottom of page 5 and the top of page 6.) I would also=20 change "acceptable certificate" to "trusted certificate" in the=20 fingerprint bullet on page 6. -- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9=20 seem to be redundant. Furthermore, I find it unusual to have a normative mandate that compliant implementations MUST NOT negotiate ciphersuites=20 that do not provide confidentiality protection. (It is very common when=20 discussing ciphersuite negotiation to mandate that implementations=20 support certain ciphersuites offer confidentiality protection, but=20 saying that a user MUST NOT be able to configure the implementation to=20 use a NULL-encryption cipher suite is quite unusual.) After reading the=20 security considerations section, I believe that the reason you have this normative requirement is because RADIUS packets include user-passwords=20 which always require confidentiality protection. However, because the=20 normative requirement is unusual, I would either add a sentence to 2.3=20 explaining the requirement or else put a forward reference to Section 6=20 (Security Considerations) for explanation. -- I found the fingerprint bullet on page 6 to be a bit confusing. My=20 understanding (after reading it several times) is that you are=20 specifying a particular ASCII encoding for certificate fingerprints. In=20 particular, you are mandating that each of the 20 bytes of the=20 certificate fingerprint be encoded as a pair of hexadecimal digits and=20 that the encoding for the fingerprint is the string "sha-1:" followed by the encodings of these 20 bytes separated by colons. I am not sure what=20 the clearest way is to get across this meaning. However, the first time=20 I read I read the current text it was not clear to me that the document=20 was mandating a particular ASCII encoding of certificate fingerprints.=20 (Question: Is there an interoperability failure if two RADIUS devices do not agree on the encoding of a certificate fingerprint? If the=20 fingerprint is just something that is configured, calculated and used=20 locally then it doesn't seem to matter whether one implementation uses=20 the ASCII string: "sha-1:E1:2D:53 ... 9D" and another implementation=20 uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".) From radext-bounces@ietf.org Sun Jan 29 08:45:38 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346C421F8554; Sun, 29 Jan 2012 08:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327855538; bh=Dng7Yp15zTT6EZ/niCh9WEw43zWflsfKusaMMYcmpEc=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=LOsQB4EHwjOgcGpjxXZ09v7LqW1Ly1xl/BtHM4YECX+163WNqAwepgMq4HdR3b1Yn 4HUpsJW3ovA2FA2gZTicVwYtpUycu0wqlTEQ4PE6WtYE+Y0ZqH3nim8GJ4Oq34Ii1Z 9Ro8RANKlnLOdZpaLamaZs0xh6yWko0Tr/I1d9Y8= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D53521F8554 for ; Sun, 29 Jan 2012 08:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRIvGQLD6geq for ; Sun, 29 Jan 2012 08:45:35 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5A46521F84EC for ; Sun, 29 Jan 2012 08:45:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA12JU/GmAcF/2dsb2JhbAA8Bq5XgQWBcgEBAQEDEh4KSwYBCA0EBAEBCwYMCwEHRQcBAQUEAQQTCBqgT4QXmliIHx0qAwSDPgkfgS0BgktjBJsSjFo X-IronPort-AV: E=Sophos;i="4.71,588,1320642000"; d="scan'208";a="229093561" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Jan 2012 11:45:34 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jan 2012 11:40:10 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 29 Jan 2012 17:45:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECDIR review of draft-ietf-radext-radsec-11 Thread-Index: AczdOsLYiZJG3oXYSMqP1t9jkSw5PwBapsGQ From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: SECDIR review of draft-ietf-radext-radsec-11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org -----Original Message----- From: Matt Lepinski [mailto:mlepinski@bbn.com] Sent: Friday, January 27, 2012 11:29 PM To: secdir@ietf.org; draft-ietf-radext-radsec.all@tools.ietf.org Subject: SECDIR review of draft-ietf-radext-radsec-11 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 specifies a TLS transport for the RADIUS protocol. It is an experimental specification that is one of several approaches to address security shortcomings in RADIUS (for example, the reliance of RADIUS upon MD5). I believe this document presents a reasonable approach to providing integrity and confidentiality protection to RADIUS packets as well as cipher suite agility. The principal security concern is that when deploying RADIUS/TLS, the system will be vulnerable to bid-down attacks to RADIUS/UDP until either the RADIUS client or the RADIUS server disables support for RADIUS/UDP. This type of bid-down attack seems to be unavoidable and is well-documented in the security considerations. I have a small number of additional comments below: -- I would strongly advise changing all instances of the phrase "acceptable Certification Authority" to "trusted Certification Authority" in order to be consistent with terminology in TLS 1.2 (RFC 5246). (I found instances of the phrase "acceptable Certification Authority" on the bottom of page 5 and the top of page 6.) I would also change "acceptable certificate" to "trusted certificate" in the fingerprint bullet on page 6. -- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9 seem to be redundant. Furthermore, I find it unusual to have a normative mandate that compliant implementations MUST NOT negotiate ciphersuites that do not provide confidentiality protection. (It is very common when discussing ciphersuite negotiation to mandate that implementations support certain ciphersuites offer confidentiality protection, but saying that a user MUST NOT be able to configure the implementation to use a NULL-encryption cipher suite is quite unusual.) After reading the security considerations section, I believe that the reason you have this normative requirement is because RADIUS packets include user-passwords which always require confidentiality protection. However, because the normative requirement is unusual, I would either add a sentence to 2.3 explaining the requirement or else put a forward reference to Section 6 (Security Considerations) for explanation. -- I found the fingerprint bullet on page 6 to be a bit confusing. My understanding (after reading it several times) is that you are specifying a particular ASCII encoding for certificate fingerprints. In particular, you are mandating that each of the 20 bytes of the certificate fingerprint be encoded as a pair of hexadecimal digits and that the encoding for the fingerprint is the string "sha-1:" followed by the encodings of these 20 bytes separated by colons. I am not sure what the clearest way is to get across this meaning. However, the first time I read I read the current text it was not clear to me that the document was mandating a particular ASCII encoding of certificate fingerprints. (Question: Is there an interoperability failure if two RADIUS devices do not agree on the encoding of a certificate fingerprint? If the fingerprint is just something that is configured, calculated and used locally then it doesn't seem to matter whether one implementation uses the ASCII string: "sha-1:E1:2D:53 ... 9D" and another implementation uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".) _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Sun Jan 29 23:16:52 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987B21F8559 for ; Sun, 29 Jan 2012 23:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQJ8QEGfH7Kt for ; Sun, 29 Jan 2012 23:16:51 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE1F21F859B for ; Sun, 29 Jan 2012 23:16:51 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C5536106CB; Mon, 30 Jan 2012 08:16:36 +0100 (CET) Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id B3020106C2; Mon, 30 Jan 2012 08:16:36 +0100 (CET) Message-ID: <4F2643D0.6080007@restena.lu> Date: Mon, 30 Jan 2012 08:16:32 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Sam Hartman References: <4F2109F8.4060505@restena.lu> <4F225888.9050601@restena.lu> <4F23B466.2070102@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig797CE479E6902FC090F8D13F" X-Virus-Scanned: ClamAV Cc: Bernard Aboba , radext@ietf.org, Alan DeKok Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 07:16:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig797CE479E6902FC090F8D13F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all, > I'm fine with Bernard's error text, although I note that section 3 is > non-normative and you're adding normative advice to it. Thanks for the inputs and text suggestions. I took Bernard's text, Alan's addition, and re-shuffled the text into section 2 so that it is in the normative part now. In my working copy (to be -12), this currently reads: 2.5 RADIUS datagrams [... snip ...] Due to the use of one single TCP port for all packet types, it is required for a RADIUS/TLS server to signal to a connecting peer which types of packets are supported on a server. See also section Section 3.4 for a discussion of signaling. o When receiving an unwanted packet of type 'CoA-Request' or 'Disconnect-Request', it needs to be replied to with a 'CoA-NAK' or 'Disconnect-NAK' respectively. The NAK SHOULD contain an attribute Error-Cause with the value 406 ("Unsupported Extension"); see [RFC5176] for details. o When receiving an unwanted packet of type 'Accounting-Request', the RADIUS/TLS server SHOULD reply with an Accounting-Response containing an Error-Cause attribute with value 406 "Unsupported Extension" as defined in [RFC5176]. A RADIUS/TLS accounting client receiving such an Accounting-Response SHOULD log the error and stop sending Accounting-Request packets. I reckon that the text is still "needs to be replied to" which could also be a "MUST reply with". For Accouning, I took Bernard's text with a "SHOULD reply with" - however, for consistency with CoA I could also imagine cranking it up to MUST. I wonder what your opinion here is. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig797CE479E6902FC090F8D13F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mQ9QACgkQ+jm90f8eFWYn1wCeMXAGCMO+7g9zZ1RDqrfvSWJB 3NsAnjucae5U/bFAsltccfeEa5l5nXTt =iMiA -----END PGP SIGNATURE----- --------------enig797CE479E6902FC090F8D13F-- From radext-bounces@ietf.org Sun Jan 29 23:16:56 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3780F21F85AE; Sun, 29 Jan 2012 23:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327907816; bh=ZU8q/riFYHpjeAxtyDIj4RoKUlu5AgeZhlvR0Zx4PRU=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=zLF1x67eWeRt+xSlFRADqOx1bFuxUnSsKvhTLQyVbc3zizC0tvW7BGt5P6EI0J2+L f1is3Kb+yCCWHtgAgwpqZCvq9wKTzl3jmw3DmE0O78ZjKDXXGWDy1SVmHB84qfNaH6 HrVOH3HLT4R/jXn/O47DMyv1G33usTnrFI80GQ2k= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987B21F8559 for ; Sun, 29 Jan 2012 23:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQJ8QEGfH7Kt for ; Sun, 29 Jan 2012 23:16:51 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE1F21F859B for ; Sun, 29 Jan 2012 23:16:51 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C5536106CB; Mon, 30 Jan 2012 08:16:36 +0100 (CET) Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id B3020106C2; Mon, 30 Jan 2012 08:16:36 +0100 (CET) Message-ID: <4F2643D0.6080007@restena.lu> Date: Mon, 30 Jan 2012 08:16:32 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Sam Hartman References: <4F2109F8.4060505@restena.lu> <4F225888.9050601@restena.lu> <4F23B466.2070102@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.3.5 X-Virus-Scanned: ClamAV Cc: Bernard Aboba , radext@ietf.org, Alan DeKok Subject: Re: [radext] Review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7145116469313007480==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============7145116469313007480== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig797CE479E6902FC090F8D13F" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig797CE479E6902FC090F8D13F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all, > I'm fine with Bernard's error text, although I note that section 3 is > non-normative and you're adding normative advice to it. Thanks for the inputs and text suggestions. I took Bernard's text, Alan's addition, and re-shuffled the text into section 2 so that it is in the normative part now. In my working copy (to be -12), this currently reads: 2.5 RADIUS datagrams [... snip ...] Due to the use of one single TCP port for all packet types, it is required for a RADIUS/TLS server to signal to a connecting peer which types of packets are supported on a server. See also section Section 3.4 for a discussion of signaling. o When receiving an unwanted packet of type 'CoA-Request' or 'Disconnect-Request', it needs to be replied to with a 'CoA-NAK' or 'Disconnect-NAK' respectively. The NAK SHOULD contain an attribute Error-Cause with the value 406 ("Unsupported Extension"); see [RFC5176] for details. o When receiving an unwanted packet of type 'Accounting-Request', the RADIUS/TLS server SHOULD reply with an Accounting-Response containing an Error-Cause attribute with value 406 "Unsupported Extension" as defined in [RFC5176]. A RADIUS/TLS accounting client receiving such an Accounting-Response SHOULD log the error and stop sending Accounting-Request packets. I reckon that the text is still "needs to be replied to" which could also be a "MUST reply with". For Accouning, I took Bernard's text with a "SHOULD reply with" - however, for consistency with CoA I could also imagine cranking it up to MUST. I wonder what your opinion here is. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig797CE479E6902FC090F8D13F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mQ9QACgkQ+jm90f8eFWYn1wCeMXAGCMO+7g9zZ1RDqrfvSWJB 3NsAnjucae5U/bFAsltccfeEa5l5nXTt =iMiA -----END PGP SIGNATURE----- --------------enig797CE479E6902FC090F8D13F-- --===============7145116469313007480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============7145116469313007480==-- From radext-bounces@ietf.org Mon Jan 30 00:16:21 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22AE21F860B; Mon, 30 Jan 2012 00:16:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327911380; bh=1QtJp2I+DBk8lOh5ULLlG/8OVv1sS+JedlgqcfjM6lc=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=LC9NiXunwAwKtyyx2NE2OghSidWVniGqtdPheg+P3fbednBe5SjejhVyJ8FD2tHa4 to/1Bkv8ly4Pcwyo9e2S4BIR1/U2ylK7nIR6KZjXS0oXh35XWqHAA8+hnqkByIqzwO 1A9/a89w8EPpCR56bJIXY8UfFt+4Fr/71d1JzYgc= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD621F860B; Mon, 30 Jan 2012 00:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8svGZ6h37oH; Mon, 30 Jan 2012 00:16:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53121F85B4; Mon, 30 Jan 2012 00:16:17 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 920F710584; Mon, 30 Jan 2012 09:16:16 +0100 (CET) Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8766410581; Mon, 30 Jan 2012 09:16:16 +0100 (CET) Message-ID: <4F2651CC.2030406@restena.lu> Date: Mon, 30 Jan 2012 09:16:12 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 X-Virus-Scanned: ClamAV Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [radext] Security review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3224487472715197026==" Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3224487472715197026== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA734C262E16C49F78C0C72F7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA734C262E16C49F78C0C72F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Hi. I'm not the secdir reviewer assigned to this draft, but felt that > this draft needed additional security review, so I decided to perform a= > secdir-like review. >=20 > Overall, I think this is a much-needed specification and believe it is > mostly ready for publication as an experimental RFC. I'd say a bit more= > clarity would be required if we wanted to move this to the standards > track. Thanks for the review! > General issues: >=20 > 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions > prior to 1.1. The concern I have is that RADSEC has long-lived TLS > connections under which an attacker could potentially observe ciphertex= t > generated from some plaintext before sending additional plaintext. TLS= > 1.1 includes explicit IVs that prevent various attacks that may happen= > against earlier versions of TLS. > There are implementation work arounds that can also prevent these > attacks. However since all RADSEC implementations are required to > support TLS 1.1, I'd prefer to add a requirement that RADSEC > implementations MUST NOT negotiate TLS versions prior to 1.1 in order t= o > avoid this issue. That's a very useful comment, thanks! TLS 1.1 was marked as minimum-required to prevent these attacks (IIRC). But of course it might happen that even though both sides *support* TLS 1.1, they don't actually negotiate it. I've added corresponding text in my working copy, which will become -12 soon: * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 [RFC5246] ]) is REQUIRED. To prevent known attacks on TLS versions prior to 1.1, implementations MUST NOT negotiate TLS versions prior to 1.1. > 2) Section 2.3 implies that you need to do cert validation all the time= , > even when you have a certificate fingerprint. I think it could more > clearly indicate that multiple ways of figuring out if you have the > right public key are provided. It's also not clear to me from section > 2.3 whether there is a mandatory-to-implement strategy. You SHOULD > support cert fingerprints. You MUST support cert path validation, but i= s > there a required name form to support? There are discussions of several= > name forms but none seem mandatory. I see no discussion of RFC 6125, > which I would have expected to see here. However, most of this is OK > for an experimental spec. This is the big area where I'd expect to see= > more clarity before this could move to the standards track. Agreed that there's a bit of an option bloat in the cert validation sections, and that there should be more guidance for standards track if the spec gets there. There's one thing I'd like to fix for the current document though. It was not really my intention to enforce e.g. 5280 checks when fingerprint-based operation is in place. My role-model existing deployment of fingerprint-based validation is SAML2 metadata. There, an entity can get identified by its fingerprint alone; regardless of other properties of the certificate (e.g. it doesn't matter whether the certificate is expired, or what CA it comes from - so lang as the configured fingerprint matches the incoming cert's fingerprint, it's fine= ). In the SAML world, that mode of operation seems to be popular; I wouldn't want to preclude that same model of operation here. I'll reformulate that section to make clearer that PKIX-style cert validation is one thing, and that manually configured fingerprints is another (and TLS-PSK is yet another thing, of course). How about this: 3. Peer authentication can be performed in any of the following three operation models: * TLS with X.509 certificates using PKIX trust models (this model is mandatory to implement): + Implementations MUST allow to configure a list of trusted Certification Authorities for incoming connections. + Certificate validation MUST include the verification rules as per [RFC5280]. + Implementations SHOULD indicate their trusted Certification Authorities as per section 7.4.4 (server side) and x.y.z ["Trusted CA Indication"] (client side) of [RFC5246] (see Section 3.2) + Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN. + Implementations SHOULD allow to configure a set of acceptable values for subjectAltName:URI. * TLS with X.509 certificates using certificate fingerprints (this model is optional to implement): Implementations SHOULD allow to configure a list of trusted certificates, identified via certificate fingerprint. Implementations MUST support SHA-1 as the hash algorithm. * TLS using TLS-PSK (this model is optional to implement) (note that some changed to this text might occur due to pending DISCUSSes and COMMENTs in the IESG review). Greetings, Stefan Winter >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA734C262E16C49F78C0C72F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mUdAACgkQ+jm90f8eFWbIVQCeOrY9k9ajivBwl1gnMPhfTvcQ FfkAn11WQGdvc6IVg02OSqIbO1/OeoXR =XtZR -----END PGP SIGNATURE----- --------------enigA734C262E16C49F78C0C72F7-- --===============3224487472715197026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --===============3224487472715197026==-- From stefan.winter@restena.lu Mon Jan 30 00:16:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD621F860B; Mon, 30 Jan 2012 00:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8svGZ6h37oH; Mon, 30 Jan 2012 00:16:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53121F85B4; Mon, 30 Jan 2012 00:16:17 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 920F710584; Mon, 30 Jan 2012 09:16:16 +0100 (CET) Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8766410581; Mon, 30 Jan 2012 09:16:16 +0100 (CET) Message-ID: <4F2651CC.2030406@restena.lu> Date: Mon, 30 Jan 2012 09:16:12 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA734C262E16C49F78C0C72F7" X-Virus-Scanned: ClamAV Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [radext] Security review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 08:16:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA734C262E16C49F78C0C72F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Hi. I'm not the secdir reviewer assigned to this draft, but felt that > this draft needed additional security review, so I decided to perform a= > secdir-like review. >=20 > Overall, I think this is a much-needed specification and believe it is > mostly ready for publication as an experimental RFC. I'd say a bit more= > clarity would be required if we wanted to move this to the standards > track. Thanks for the review! > General issues: >=20 > 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions > prior to 1.1. The concern I have is that RADSEC has long-lived TLS > connections under which an attacker could potentially observe ciphertex= t > generated from some plaintext before sending additional plaintext. TLS= > 1.1 includes explicit IVs that prevent various attacks that may happen= > against earlier versions of TLS. > There are implementation work arounds that can also prevent these > attacks. However since all RADSEC implementations are required to > support TLS 1.1, I'd prefer to add a requirement that RADSEC > implementations MUST NOT negotiate TLS versions prior to 1.1 in order t= o > avoid this issue. That's a very useful comment, thanks! TLS 1.1 was marked as minimum-required to prevent these attacks (IIRC). But of course it might happen that even though both sides *support* TLS 1.1, they don't actually negotiate it. I've added corresponding text in my working copy, which will become -12 soon: * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 [RFC5246] ]) is REQUIRED. To prevent known attacks on TLS versions prior to 1.1, implementations MUST NOT negotiate TLS versions prior to 1.1. > 2) Section 2.3 implies that you need to do cert validation all the time= , > even when you have a certificate fingerprint. I think it could more > clearly indicate that multiple ways of figuring out if you have the > right public key are provided. It's also not clear to me from section > 2.3 whether there is a mandatory-to-implement strategy. You SHOULD > support cert fingerprints. You MUST support cert path validation, but i= s > there a required name form to support? There are discussions of several= > name forms but none seem mandatory. I see no discussion of RFC 6125, > which I would have expected to see here. However, most of this is OK > for an experimental spec. This is the big area where I'd expect to see= > more clarity before this could move to the standards track. Agreed that there's a bit of an option bloat in the cert validation sections, and that there should be more guidance for standards track if the spec gets there. There's one thing I'd like to fix for the current document though. It was not really my intention to enforce e.g. 5280 checks when fingerprint-based operation is in place. My role-model existing deployment of fingerprint-based validation is SAML2 metadata. There, an entity can get identified by its fingerprint alone; regardless of other properties of the certificate (e.g. it doesn't matter whether the certificate is expired, or what CA it comes from - so lang as the configured fingerprint matches the incoming cert's fingerprint, it's fine= ). In the SAML world, that mode of operation seems to be popular; I wouldn't want to preclude that same model of operation here. I'll reformulate that section to make clearer that PKIX-style cert validation is one thing, and that manually configured fingerprints is another (and TLS-PSK is yet another thing, of course). How about this: 3. Peer authentication can be performed in any of the following three operation models: * TLS with X.509 certificates using PKIX trust models (this model is mandatory to implement): + Implementations MUST allow to configure a list of trusted Certification Authorities for incoming connections. + Certificate validation MUST include the verification rules as per [RFC5280]. + Implementations SHOULD indicate their trusted Certification Authorities as per section 7.4.4 (server side) and x.y.z ["Trusted CA Indication"] (client side) of [RFC5246] (see Section 3.2) + Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN. + Implementations SHOULD allow to configure a set of acceptable values for subjectAltName:URI. * TLS with X.509 certificates using certificate fingerprints (this model is optional to implement): Implementations SHOULD allow to configure a list of trusted certificates, identified via certificate fingerprint. Implementations MUST support SHA-1 as the hash algorithm. * TLS using TLS-PSK (this model is optional to implement) (note that some changed to this text might occur due to pending DISCUSSes and COMMENTs in the IESG review). Greetings, Stefan Winter >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA734C262E16C49F78C0C72F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mUdAACgkQ+jm90f8eFWbIVQCeOrY9k9ajivBwl1gnMPhfTvcQ FfkAn11WQGdvc6IVg02OSqIbO1/OeoXR =XtZR -----END PGP SIGNATURE----- --------------enigA734C262E16C49F78C0C72F7-- From hartmans@painless-security.com Mon Jan 30 03:42:19 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228C021F8559; Mon, 30 Jan 2012 03:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twGvAVNqPUsF; Mon, 30 Jan 2012 03:42:18 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AF59421F84EB; Mon, 30 Jan 2012 03:42:18 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1C92203C0; Mon, 30 Jan 2012 06:41:21 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A60A4690; Mon, 30 Jan 2012 06:42:05 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <4F2651CC.2030406@restena.lu> Date: Mon, 30 Jan 2012 06:42:05 -0500 In-Reply-To: <4F2651CC.2030406@restena.lu> (Stefan Winter's message of "Mon, 30 Jan 2012 09:16:12 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [radext] Security review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:42:19 -0000 Your proposed direction for trust validation semes like a major improvement to me. From radext-bounces@ietf.org Mon Jan 30 03:42:21 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2621F8576; Mon, 30 Jan 2012 03:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327923740; bh=5oYpxBJiTdqKO2ZjcgP9i3aGVleGsl9N2vlyGGIqhEA=; h=From:To:References:Date:In-Reply-To:Message-ID:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=xXvZ7rZD7mu/z5PbIvb+Wg59ztjuxevYqLp2AiA5mb/KKPEjlBM+/do4ItfxthsrB 9ld8W/IsFNu0G3/6PnosZMtD5C8kmUpb7NM/mvYaOSQusBs4A+oHYhvU7zuTacNZTw FT/rEQ1EG98pH8wkXGa4OuZF5wbEEU63T1gEkskU= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228C021F8559; Mon, 30 Jan 2012 03:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twGvAVNqPUsF; Mon, 30 Jan 2012 03:42:18 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AF59421F84EB; Mon, 30 Jan 2012 03:42:18 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1C92203C0; Mon, 30 Jan 2012 06:41:21 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A60A4690; Mon, 30 Jan 2012 06:42:05 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <4F2651CC.2030406@restena.lu> Date: Mon, 30 Jan 2012 06:42:05 -0500 In-Reply-To: <4F2651CC.2030406@restena.lu> (Stefan Winter's message of "Mon, 30 Jan 2012 09:16:12 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Cc: radext@ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [radext] Security review of draft-ietf-radext-radsec X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org Your proposed direction for trust validation semes like a major improvement to me. _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From dromasca@avaya.com Tue Jan 31 04:54:07 2012 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0C921F84E0 for ; Tue, 31 Jan 2012 04:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB4Peb-38Uev for ; Tue, 31 Jan 2012 04:54:06 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAE21F84D9 for ; Tue, 31 Jan 2012 04:54:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEjkJ0/GmAcF/2dsb2JhbABEhQuoZm+BBYFyAQEBAQMSEQ0EUQYBCA0EBAEBAwIGBgwLAQICAwFEBwEBBQQBBBMIARmHY5h0hBeJdJF3gS+JWAUBAQEDASkGAYNmAYEGJgEVggYzYwSbGYxc X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="327406246" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Jan 2012 07:54:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Jan 2012 07:48:31 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 31 Jan 2012 13:53:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Russ Housley's Discuss on draft-ietf-radext-radsec-11: (with DISCUSSand COMMENT) Thread-Index: AczgF0+mW0w2BH3xQWa/GJaKwpgW2gAABA0g From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: Russ Housley's Discuss on draft-ietf-radext-radsec-11: (with DISCUSSand COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 12:54:07 -0000 DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUnVzcyBI b3VzbGV5DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDEyIDI6NTMgUE0NClRvOiBUaGUg SUVTRw0KQ2M6IFBldGUgTWNDYW5uOyBkcmFmdC1pZXRmLXJhZGV4dC1yYWRzZWNAdG9vbHMuaWV0 Zi5vcmc7IHJhZGV4dC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJ1c3MgSG91c2xl eSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1yYWRleHQtcmFkc2VjLTExOiAod2l0aCBESVNDVVNT YW5kIENPTU1FTlQpDQoNClJ1c3MgSG91c2xleSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtcmFkZXh0LXJhZHNlYy0xMTogRGlzY3Vzcw0K DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwNCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBo b3dldmVyLikNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K RElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQogIFRoZSBHZW4tQVJUIFJldmlldyBieSBQZXRl ciBNY0Nhbm4gb24gMzAtSmFuLTIwMTIgcmFpc2VkIHR3bw0KICBjb25jZXJucy4gIFBsZWFzZSBy ZXNwb25kIHRvIGVhY2ggb2YgdGhlbS4NCg0KICAoMSkgU2VjdGlvbiAyLjQ6DQogICAgICAgSW4g VExTLVguNTA5IHdpdGggUEtJIGluZnJhc3RydWN0dXJlLCBhIGNsaWVudCBpcyB1bmlxdWVseQ0K ICAgICAgIGlkZW50aWZpZWQgYnkgdGhlIHNlcmlhbCBudW1iZXIgb2YgdGhlIHR1cGxlIChwcmVz ZW50ZWQgY2xpZW50DQogICAgICAgY2VydGlmaWNhdGU7SXNzdWVyKS4NCiAgICAgIFNIT1VMRCBC RToNCiAgICAgICBJbiBUTFMtWC41MDkgd2l0aCBQS0kgaW5mcmFzdHJ1Y3R1cmUsIGEgY2xpZW50 IGlzIHVuaXF1ZWx5DQogICAgICAgaWRlbnRpZmllZCBieSB0aGUgdHVwbGUgKHNlcmlhbCBudW1i ZXIgb2YgcHJlc2VudGVkIGNsaWVudA0KICAgICAgIGNlcnRpZmljYXRlO0lzc3VlcikuDQoNCiAg KDIpIEJlY2F1c2UgUkFESVVTIHN1cHBvcnRzIHRoZSBEaXNjb25uZWN0IFJlcXVlc3QgKHNlcnZl ci10by1jbGllbnQpDQogICAgICBtZXNzYWdlLCBpdCBzZWVtcyB0aGF0IHRoZXJlIGlzIHNvbWUg cmVxdWlyZW1lbnQgdG8ga2VlcCB0aGUgVExTDQogICAgICBzZXNzaW9uIG9wZW4gZm9yIHRoZSBk dXJhdGlvbiBvZiB0aGUgYWNjZXNzIHRoYXQgd2FzIGF1dGhvcml6ZWQuDQogICAgICBPdGhlcndp c2UsIHRoZSBzZXJ2ZXIgd291bGQgbm90IGJlIGFibGUgdG8gc2VuZCBzdWNoIGEgcGFja2V0IHRv DQogICAgICB0aGUgY2xpZW50IHdpdGhvdXQgaW5pdGlhdGluZyBpdHMgb3duIFRMUyBjb25uZWN0 aW9uIHdoaWNoIG1heSBub3QNCiAgICAgIGJlIHBvc3NpYmxlIG9yIGRlc2lyYWJsZS4gIElzIHRo aXMgYXNwZWN0IG9mIHRoZSBzcGVjaWZpY2F0aW9uDQogICAgICBpbmhlcml0ZWQgZnJvbSB0aGUg cmVmZXJlbmNlZCBUQ1Agc3BlY2lmaWNhdGlvbj8gIEl0IG1heSBiZQ0KICAgICAgaGVscGZ1bCB0 byBhZGQgYSBwYXJhZ3JhcGggYWJvdXQgdGhpcyBpc3N1ZS4NCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpD T01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAgVGhlIEdlbi1BUlQgUmV2aWV3IGJ5IFBldGVy IE1jQ2FubiBvbiAzMC1KYW4tMjAxMiByYWlzZWQgdHdvIGVkaXRvcmlhbA0KICBpc3N1ZXMuICBQ bGVhc2UgY29uc2lkZXIgdGhlbS4NCg0KICAoMSkgU2VjdGlvbiAyLjM6DQogICAgICAgeC55LnoN CiAgICAgIERpZCB5b3UgbWVhbiB0byBmaWxsIGluIGEgcmVhbCBzZWN0aW9uIG51bWJlciBoZXJl Pw0KDQogICgyKSBOb3RlIFNlY3Rpb24gMy40ICgxKSApDQogICAgICBNaXNzaW5nIG9wZW4gcGFy ZW4/DQoNCg0K From radext-bounces@ietf.org Tue Jan 31 04:54:07 2012 Return-Path: X-Original-To: radext-archive-IeZ9sae2@lists.ietf.org Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937FA21F84E0; Tue, 31 Jan 2012 04:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1328014447; bh=uOrQuepgtQfFPiSJtZAUpULQxbUCpGJ+JyoJ5atSuZ4=; h=MIME-Version:Date:Message-ID:From:To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=JVXx97NUQM1P8H7XX8ijo/O8QrB3RhtwxhnhvdZrRtTxLLUipzyqqKxi29twx2n4g bNcGFbloPicldBOv79vifpEhR56gC80LaqfEnLKDkrX1Nt1Yie4TAbTquTH0z1PUdO tXAxPIvG4vAMlYeK+Mo+xCwVgk6iPlOdbWsCJFnk= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0C921F84E0 for ; Tue, 31 Jan 2012 04:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB4Peb-38Uev for ; Tue, 31 Jan 2012 04:54:06 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAE21F84D9 for ; Tue, 31 Jan 2012 04:54:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEjkJ0/GmAcF/2dsb2JhbABEhQuoZm+BBYFyAQEBAQMSEQ0EUQYBCA0EBAEBAwIGBgwLAQICAwFEBwEBBQQBBBMIARmHY5h0hBeJdJF3gS+JWAUBAQEDASkGAYNmAYEGJgEVggYzYwSbGYxc X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="327406246" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Jan 2012 07:54:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Jan 2012 07:48:31 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 31 Jan 2012 13:53:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Russ Housley's Discuss on draft-ietf-radext-radsec-11: (with DISCUSSand COMMENT) Thread-Index: AczgF0+mW0w2BH3xQWa/GJaKwpgW2gAABA0g From: "Romascanu, Dan (Dan)" To: Subject: [radext] FW: Russ Housley's Discuss on draft-ietf-radext-radsec-11: (with DISCUSSand COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, January 31, 2012 2:53 PM To: The IESG Cc: Pete McCann; draft-ietf-radext-radsec@tools.ietf.org; radext-chairs@tools.ietf.org Subject: Russ Housley's Discuss on draft-ietf-radext-radsec-11: (with DISCUSSand COMMENT) Russ Housley has entered the following ballot position for draft-ietf-radext-radsec-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two concerns. Please respond to each of them. (1) Section 2.4: In TLS-X.509 with PKI infrastructure, a client is uniquely identified by the serial number of the tuple (presented client certificate;Issuer). SHOULD BE: In TLS-X.509 with PKI infrastructure, a client is uniquely identified by the tuple (serial number of presented client certificate;Issuer). (2) Because RADIUS supports the Disconnect Request (server-to-client) message, it seems that there is some requirement to keep the TLS session open for the duration of the access that was authorized. Otherwise, the server would not be able to send such a packet to the client without initiating its own TLS connection which may not be possible or desirable. Is this aspect of the specification inherited from the referenced TCP specification? It may be helpful to add a paragraph about this issue. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Gen-ART Review by Peter McCann on 30-Jan-2012 raised two editorial issues. Please consider them. (1) Section 2.3: x.y.z Did you mean to fill in a real section number here? (2) Note Section 3.4 (1) ) Missing open paren? _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext