From ietf@augustcellars.com Mon Jul 1 13:32:55 2013 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 E1FFD11E8279 for ; Mon, 1 Jul 2013 13:32:55 -0700 (PDT) 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 zH1xLV4WyTrV for ; Mon, 1 Jul 2013 13:32:49 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 835AB11E8254 for ; Mon, 1 Jul 2013 13:32:49 -0700 (PDT) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 775072CA22; Mon, 1 Jul 2013 13:32:48 -0700 (PDT) From: "Jim Schaad" To: , , References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <080.a349ae9f35fd5ba78c6dfd60a52a8535@trac.tools.ietf.org> In-Reply-To: <080.a349ae9f35fd5ba78c6dfd60a52a8535@trac.tools.ietf.org> Date: Mon, 1 Jul 2013 13:31:51 -0700 Message-ID: <011401ce769a$050f8f30$0f2ead90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG6BiECksJl4xbIhvfkRt9hc11tPgCYwaGXmXRcQgA= Content-Language: en-us Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad 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, 01 Jul 2013 20:32:56 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of radext issue tracker > Sent: Wednesday, June 26, 2013 6:16 AM > To: draft-ietf-radext-dynamic-discovery@tools.ietf.org; > stefan.winter@restena.lu > Cc: radext@ietf.org > Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad > > #148: Review of dynamic-discovery by Jim Schaad > > > Comment (by stefan.winter@restena.lu): > > > 1) In section 2.3.3, step 4 - what is to be considered an error at this point. > For example, there are a number of odd conditions that can be returned > from DNSSEC, specifically the "indeterminate" state. > > I've added text in my working copy which white-lists two sorts of replies as > good, and everything else as an error. Hope that is adequate and removes > all ambiguity: > > "2.3.3. Definitions > > Where the algorithm states "name resolution returns with an error", > this shall mean that either the DNS request timed out, or every > response except a) the RR queried for and b) the positive > acknowledgement that the record queried for does not exist (i.e. > status: NXDOMAIN)." I wish I knew enough DNSSEC to say for sure, however this is a good step in the right direction. > > > 2) In section 2.3.4 - Given that the above algorithm does not return a TTL > value in the event of an empty set or define how to know the TTL value > - what is the TTL value to be used in in paragraph 2 "negative TTL"? > > I'll have to modify the return value to be a tuple with the second element > being the place to put a negative TTL into (either as learned from an > NXDOMAIN reply or configured in case of an absence of any reply). I'll keep > this TRAC ticket open for this sub-issue. > > > 3) In section 2.3.5 - Does it make sense to return a result, but to continue > the algorithm and store the result after the timeouts for later use? > > We discussed this in the last meeting. It's generally a bad idea (end- users > can enter bogus DNS data and DoS the server by trying to login with > corresponding realms). An implementation could be brave and do that > anyway, so I've added text to Security Considerations explaining the issues > with it. Implementations can then do a judgment call whether they want to > take this risk. The text is: > > " The algorithm has a fixed completion time-out of three seconds. > Implementations might be tempted to continue their attempt to resolve > DNS records even after the timeout has passed; a subsequent request > for the same realm might benefit from retrieving the results anyway. > Doing so exposes the server to a Denial-of-Service risk: an attacker > might intentionally craft bogus DNS zones which take a very long time > to reply (e.g. due to a particularly byzantine tree structure, or > artificial delays in responses). If an attacker generates enough > Access-Requests for a number of such zones, it may deplete server > sockets or other server resources." I am not sure that the DOS risk would be significantly larger between a 3 and a 6 second time out. It would just require half as many requests. A better way of addressing the specific problem you have shown here would involve black-listing of DNS queries and I don't see anything in this text or the algorithm which talks about doing black listing of any type. > > > 4) I find the security considerations to be completely inadequate for this > document. > > Use of a certificate is only going to be valid if the original realm name > that is the input the validation routine is what is found and matched in the > certificate. In this case I would not know where in the name or alt name > fields of the certificate it would be found. You cannot validate to the final > DNS name as that is now an untrusted value. > > We discussed on the list that an MTI validation mechanism which works in > the absence of DNSSEC is needed (sigh!). I'll work on corresponding text > soon. I'll keep this TRAC ticket open until the text is ready. > > > The suggestion of out-of-band validation methods ignores the existence > of DANE. > > > > The NAI document suggests that the RADIUS peer is pre-configured with > information about certificates or TLS validation data. The suggested text > works in the case that the table says do dynamic lookup and here is the TLS > configuration data. But in other cases it is completely unclear how a TLS- > PSK would be found for a dynamic lookup. > > These were both discussed on the list; DANE is clumsy/not usable in its > current state; TLS-PSK is not in scope for this document. Great - please state this in the introduction material Jim > > Greetings, > > Stefan Winter > > -- > -------------------------------------+---------------------------------- > -------------------------------------+--- > Reporter: | Owner: draft-ietf-radext- > stefan.winter@restena.lu | dynamic-discovery@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 > Component: dynamic-discovery | Version: 1.0 > Severity: - | Resolution: > Keywords: | > -------------------------------------+---------------------------------- > -------------------------------------+--- > > Ticket URL: > > radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From ietf@augustcellars.com Mon Jul 1 13:37:05 2013 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 33B3B11E826E for ; Mon, 1 Jul 2013 13:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, 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 OkTCxgvWKTI2 for ; Mon, 1 Jul 2013 13:36:59 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 53A3211E8254 for ; Mon, 1 Jul 2013 13:36:59 -0700 (PDT) Received: from Philemon (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 1D1C338EF1; Mon, 1 Jul 2013 13:36:59 -0700 (PDT) From: "Jim Schaad" To: "'Stefan Winter'" , "'Sam Hartman'" References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <51CAF86E.30504@restena.lu> In-Reply-To: <51CAF86E.30504@restena.lu> Date: Mon, 1 Jul 2013 13:36:02 -0700 Message-ID: <011501ce769a$9a695ac0$cf3c1040$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG6BiECksJl4xbIhvfkRt9hc11tPgGl6Lx2Aj/W81YB2RkCxADlQHzqAcEQuuGZNf8TkA== Content-Language: en-us Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad 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, 01 Jul 2013 20:37:05 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On = Behalf > Of Stefan Winter > Sent: Wednesday, June 26, 2013 7:19 AM > To: Sam Hartman > Cc: radext@ietf.org > Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad >=20 > Hi, >=20 > > I strongly favor the first. I agree that it means that you need to > > have a field in the cert that contains the realm's name. > > There are fairly obvious ways this can be done in a SAN. > > RFc 4985 is an example of how microsoft does this. > > My concern with the dnssec approach is that while it's easy to > > specify, > > > > I'm concerned that dnssec APIs are not widely available enough at > > userspace levels outside the resolver that I'd have confidence > > radsecproxy or freeradius or other radsec implementations could > > actually implement dnssec validation in the radius proxy right now. >=20 > My current working copy defines NAIRealm as a new otherName. At least = I > hope that's what it does; I mostly copy&pasted from RFC 4985 and = replaced > the strings. >=20 > I had to pick an integer for the object identifier; but couldn't find = the registry > which holds all the assigned values. So I had to guess - I picked { = id-on 9 }. > Beat me with a club if I stole someone's ID. Does the usage of this pobject > ID need to be registered with IANA? If so, let me know and I'll add a = note to > IANA considerations. >=20 > I also copied the 1993 ASN syntax (assuming that we really don't have = to > bother the 1988 one?) into an appendix A. >=20 > The text now reads: >=20 > "2.3. Definition of the X.509 certificate property > SubjectAltName:otherName:NAIRealm >=20 > This specification retrieves IP addresses and port numbers from the > Domain Name System which are subsequently used to authenticate = users > via the RADIUS/TLS protocol. Since the Domain Name System is not > necessarily trustworthy (e.g. if DNSSEC is not deployed for the > queried domain name), it is important to verify that the server = which > was contacted is authorized to service requests for the user which > triggered the discovery process. >=20 > The input to the algorithm is a NAI realm as specified in the next > section. As a consequence, the X.509 certificate of the server = which > is ultimately contacted for user authentication needs to be able to > express that it is authorized to handle requests for that realm. >=20 > Current subjectAltName fields do not semantically allow to express = an > NAI realm; the field subjectAltName:dNSName is syntactically a good > match but would inappropriately conflate DNS names and NAI realm > names. Thus, this specification defines a new subjectAltName field > to hold either a single NAI realm name or a wildcard name matching = a > set of NAI realms. >=20 > This section defines the NAIRealm name as a form of otherName from > the GeneralName structure in SubjectAltName defined in [RFC5280]. >=20 > id-on-nai OBJECT IDENTIFIER ::=3D { id-on 9 } >=20 > NAIRealm ::=3D IA5String (SIZE (1..MAX)) Are you sure you want NAIRealms to be IA5String and not UTF8String? = This is an I18N question. >=20 > The NAIRealm, if present, MUST contain an NAI realm as defined in > TODO: the new NAI document. It may substitute labels on all dot- > separated parts of the NAI with the character "*" to indicate a > wildcard match for "all labels in this part". This text would appear to say that foo.*.bar is a legal wildcard NAI = realm. Is that what you want? >=20 > Appendix A contains the ASN.1 definition of the above objects." >=20 > And that appendix is: >=20 > "Appendix A. Appendix A: ASN.1 Syntax of NAIRealm >=20 >=20 >=20 > PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-dns-srv-name-93(40) } >=20 > DEFINITIONS EXPLICIT TAGS ::=3D >=20 > BEGIN >=20 > -- EXPORTS ALL -- >=20 > IMPORTS >=20 > id-pkix > FROM PKIX1Explicit88 { iso(1) = identified-organization(3) > dod(6) internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } ; > -- from RFC 3280 [N2] >=20 >=20 > -- In the GeneralName definition using the 1993 ASN.1 syntax > -- includes: >=20 > OTHER-NAME ::=3D TYPE-IDENTIFIER >=20 > -- Service Name Object Identifier >=20 > id-on OBJECT IDENTIFIER ::=3D { id-pkix 8 } >=20 > id-on-nai OBJECT IDENTIFIER ::=3D { id-on 9 } >=20 > -- Service Name >=20 > naiRealm OTHER-NAME ::=3D { NAIRealm IDENTIFIED BY { id-on-nai = }} >=20 > NAIRealm ::=3D IA5String (SIZE (1..MAX)) >=20 > END" >=20 > The text specifying that checking for this name is MTI is not written = yet; > please wait for day++. >=20 > Stefan >=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 alex@um.es Mon Jul 1 23:56:39 2013 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 4E74111E82F3; Mon, 1 Jul 2013 23:56:39 -0700 (PDT) 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 OHTDJUyKAJSe; Mon, 1 Jul 2013 23:56:33 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 35E0511E82F0; Mon, 1 Jul 2013 23:56:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 1240453CF2; Tue, 2 Jul 2013 08:56:31 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dWhweECjRvBE; Tue, 2 Jul 2013 08:56:30 +0200 (CEST) Received: from [192.168.1.102] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id A6A3153715; Tue, 2 Jul 2013 08:56:28 +0200 (CEST) Message-ID: <51D2799C.8060205@um.es> Date: Tue, 02 Jul 2013 08:56:28 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: "radext@ietf.org" , "abfab@ietf.org" References: <20130702064711.29981.10301.idtracker@ietfa.amsl.com> In-Reply-To: <20130702064711.29981.10301.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130702064711.29981.10301.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090901070802060201020005" Subject: [radext] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-06.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, 02 Jul 2013 06:56:39 -0000 This is a multi-part message in MIME format. --------------090901070802060201020005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, we have updated our RADIUS fragmentation draft. This new version addresses comments from Bernard, as well as it re-introduces the possibility to send large amounts of authorization data before authentication. Regards, Alejandro -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-06.txt Fecha: Mon, 01 Jul 2013 23:47:11 -0700 De: internet-drafts@ietf.org Para: Alejandro Perez-Mendez , Rafael Lopez , Fernando Pereniguez-Garcia , Rafa Marin-Lopez , Gabriel Lopez-Millan , Diego R. Lopez , Alan DeKok A new version of I-D, draft-perez-radext-radius-fragmentation-06.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 06 Title: Support of fragmentation of RADIUS packets Creation date: 2013-07-02 Group: Individual Submission Number of pages: 25 URL: http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-06.txt Status: http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation Htmlized: http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-06 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy clients and servers. The IETF Secretariat --------------090901070802060201020005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

we have updated our RADIUS fragmentation draft. This new version addresses comments from Bernard, as well as it re-introduces the possibility to send large amounts of authorization data before authentication.

Regards,
Alejandro


-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-06.txt
Fecha: Mon, 01 Jul 2013 23:47:11 -0700
De: internet-drafts@ietf.org
Para: Alejandro Perez-Mendez <alex@um.es>, Rafael Lopez <rafa@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es>, Rafa Marin-Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Diego R. Lopez <diego@tid.es>, Alan DeKok <aland@networkradius.com> 


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

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 06
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-07-02
Group:		 Individual Submission
Number of pages: 25
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-06.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-06
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-06

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy clients and servers.

                                                                                  


The IETF Secretariat


--------------090901070802060201020005-- From alex@um.es Tue Jul 2 00:04:40 2013 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 3662311E82F0 for ; Tue, 2 Jul 2013 00:04:40 -0700 (PDT) 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 b9GS9wtiv5Pf for ; Tue, 2 Jul 2013 00:04:35 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id B0C7121F9D6F for ; Tue, 2 Jul 2013 00:04:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 033B453CEF for ; Tue, 2 Jul 2013 09:04:19 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iI9Ls0qOek+G for ; Tue, 2 Jul 2013 09:04:17 +0200 (CEST) Received: from [192.168.1.102] (84.124.135.236.dyn.user.ono.com [84.124.135.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 762FE53CED for ; Tue, 2 Jul 2013 09:04:16 +0200 (CEST) Message-ID: <51D27B71.9030702@um.es> Date: Tue, 02 Jul 2013 09:04:17 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> In-Reply-To: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting 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, 02 Jul 2013 07:04:40 -0000 Hello Jouni, we would need a 15 minute slot to discuss aspects of the new version of the RADIUS fragmentation draft. We will also ask for its adoption, as we consider this new version solves all the raised concerns. Best regards, Alejandro > Folks, > > We have requested for one and half hour meeting slot. If you feel > like presenting your work (be that in the current charter or not), > send a request to the co-chairs. Obviously, chartered items will > be prioritized over other topics. > > - Jouni & Mauricio > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From diego@tid.es Tue Jul 2 00:05:45 2013 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 C507E11E835E for ; Tue, 2 Jul 2013 00:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxrGAqefMtk9 for ; Tue, 2 Jul 2013 00:05:41 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0A11E82F0 for ; Tue, 2 Jul 2013 00:05:41 -0700 (PDT) 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 <0MPA00A8IRPDZI@tid.hi.inet> for radext@ietf.org; Tue, 02 Jul 2013 09:05:37 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 2F.79.03142.1CB72D15; Tue, 02 Jul 2013 09:05:37 +0200 (CEST) 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 ESMTP id <0MPA00A8CRPDZI@tid.hi.inet> for radext@ietf.org; Tue, 02 Jul 2013 09:05:37 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Tue, 02 Jul 2013 09:04:28 +0200 Date: Tue, 02 Jul 2013 07:04:27 +0000 From: "Diego R. Lopez" In-reply-to: <11FAD0B4-6888-4A93-A5B2-0B9821A5E44F@gmail.com> X-Originating-IP: [10.95.64.115] To: Jouni Korhonen Message-id: Content-id: <1E74FB07EDE151408D76FF69D14550C7@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [radext] Call for agenda items for IETF#87 Berlin meeting Thread-index: AQHOWibyJy0Ua/OBOESmvMMD1NBlTJk7GXKAgABu+wCAAB0kAIAA8hUAgBR3nAA= X-AuditID: 0a5f4068-b7f128e000000c46-5d-51d27bc1d3e0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lhinfg0j1YfSnQYPdCaYuWVzPZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XXfPtaCOyIVF37eZW1gfCjQxcjJISFgInHw4QpGCFtM4sK9 9WxdjFwcQgIbGSVmbetkhnB+MkrMP7caKjONUaLx4xkmkBYWAVWJxxNOgbWzAdmPmn+zg9jC Am4S064cZgGxOQVsJe7dnc4CsUJB4s+5x0A2B4eIgLbE8g1iIGFmgQOMEtuXuIHYvALeEuuP XmCFiJtJHOlaxgwRF5T4MfkeC0RcR6L3+zdmCFtcorn1JlRcW+LJO4heRgFZiXfz54PZIgLu Eus/bmWDsP0kbt9+zQxxjoDEkj3noWxRiZeP/7FC/PiPUWLylX2ME4CBgOSOWUjumIXkjllI 7piF5I4FjKyrGMWKk4oy0zNKchMzc9INDPUyMvUy81JLNjFCIi9jB+PynSqHGAU4GJV4eBXm XQwUYk0sK67MPcQowcGsJMJ70xsoxJuSWFmVWpQfX1Sak1p8iJGJg1OqgVF7vxIfo/atTStP LhZSFtHYUh8RcizL7dOlJMGv3GcuPVtTKvJmVxqbgldcSkAH358TO/awJR66qhhrH3Clo8n7 q/sS5dxD17f8evKEYadORsKjLbYrmiuPPJFcvatsUvyVyM36TR8OzFMuXqrVHzmt8GYbR5fN swAe55xZmj/tK95PjU7qnKnEUpyRaKjFXFScCAAHoeK2mgIAAA== References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> <4198A764-0ADB-43B1-82B1-B9B208B05BCC@gmail.com> <11FAD0B4-6888-4A93-A5B2-0B9821A5E44F@gmail.com> Cc: Sam Hartman , Jouni Korhonen , "" , "" Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting 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, 02 Jul 2013 07:05:45 -0000 Hi, Alejandro just uploaded -06, in which we address all the comments received = so far in what we hope will be a satisfactory version for WG adoption. Coul= d you book a short slot to make a brief intro of the changes? Be goode, On 19 Jun 2013, at 08:32 , Jouni Korhonen wrote: > > Speaking of updates I hope we can see one quickly. The -05 revision left = the situation into a bit floating state and I hope the new revision address= es the issues Bernard and Sam had. > > - Jouni > > > On Jun 18, 2013, at 7:04 PM, Diego R. Lopez wrote: > >> Hi Sam, >> >> Good you mention it. Alan, yours truly and the other authors are prepari= ng a plan for making a new submission in the line of what we discussed in O= rlando... >> >> Be goode, >> >> On 18 Jun 2013, at 16:21 , Sam Hartman wrote: >> >>> I think it's fairly important that we spend enough time on the radius >>> fragmentation issue that we can move forward and avoid continuing to >>> block ABFAB documents. >>> >>> --Sam >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> 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=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el = enlace situado m=E1s 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 > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ 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 stefan.winter@restena.lu Tue Jul 2 05:55:42 2013 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 DDDE421F9298 for ; Tue, 2 Jul 2013 05:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.840, 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 eDue7PTNOPjw for ; Tue, 2 Jul 2013 05:55:42 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9914B21F9F5F for ; Tue, 2 Jul 2013 05:55:40 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8A81A10581 for ; Tue, 2 Jul 2013 14:55:38 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 799FB10580 for ; Tue, 2 Jul 2013 14:55:38 +0200 (CEST) Message-ID: <51D2CDCA.9020400@restena.lu> Date: Tue, 02 Jul 2013 14:55:38 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org References: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> In-Reply-To: <48059112-8694-43E2-994F-14382BED4AD9@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NCHQSMNXGIHHOKKTVVEG" X-Virus-Scanned: ClamAV Subject: Re: [radext] Call for agenda items for IETF#87 Berlin meeting 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, 02 Jul 2013 12:55:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NCHQSMNXGIHHOKKTVVEG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I would like to talk about dynamic discovery. I'm about to finalise an -07 draft with notable changes; if time allows, I'd appreciate ten minutes to talk about it. I'll be there in person. Stefan On 26.05.2013 17:38, Jouni wrote: > Folks, >=20 > We have requested for one and half hour meeting slot. If you feel > like presenting your work (be that in the current charter or not), > send a request to the co-chairs. Obviously, chartered items will > be prioritized over other topics. >=20 > - Jouni & Mauricio >=20 > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2NCHQSMNXGIHHOKKTVVEG 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHSzcoACgkQ+jm90f8eFWbwpQCfY9zFBeriZZUy8HdXEdA/YNl7 OSsAn23/QI+MIYlbmjmx/Vzbe3ZnOeWn =3g4q -----END PGP SIGNATURE----- ------enig2NCHQSMNXGIHHOKKTVVEG-- From stefan.winter@restena.lu Wed Jul 3 06:33:00 2013 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 6849E11E8145 for ; Wed, 3 Jul 2013 06:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_LWSHORTT=1.24] 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 0iekOrhB1gVv for ; Wed, 3 Jul 2013 06:32:59 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 73D4221F9CA7 for ; Wed, 3 Jul 2013 06:32:57 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4387E10581; Wed, 3 Jul 2013 15:32:56 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3168410580; Wed, 3 Jul 2013 15:32:56 +0200 (CEST) Message-ID: <51D42803.3030507@restena.lu> Date: Wed, 03 Jul 2013 15:32:51 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org, Brian Julin References: <88ACDECA21EE5B438CA26316163BC14C25D0E891@BASS.ad.clarku.edu> <51CDAEF6.4080302@restena.lu> In-Reply-To: <51CDAEF6.4080302@restena.lu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2DVOUTGCWWMQIOXAIXQCL" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 03 Jul 2013 13:33:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2DVOUTGCWWMQIOXAIXQCL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> This would be a whitelist of stuff we want, and everything is else is >> declared bad. Would that address your concern? >=20 > One case not covered that I know of: NXDOMAIN is not returned when an o= wner > has records of type other than the type you query. What you get is a > NOERROR response without any of the requested type of RRs, and > usually an authority SOA record, and maybe some additional section RRs.= > Try a dig for NAPTRs for ieee.org for example. >=20 > I'd suggest defining NXDOMAIN/NSEC/NSEC3 and the above case as a > "negative result" instead, and just say in step 4 to proceed to > step 9 on a credible negative result, step 5 if credible NAPTR RRs > were retrieved, and otherwise O =3D { empty set } and terminate. Okay, I've modified the text to be more explicit: 3.2. Configuration Variables The algorithm contains various variables for timeouts. These variables are named here and reasonable default values are provided. Implementations wishing to deviate from these defaults should make they understand the implications of changes. DNS_TIMEOUT: maximum amount of time to wait for the complete set of all DNS queries to complete: Default =3D 3 seconds MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default =3D 60 seconds BACKOFF_TIME: if no conclusive DNS response was retrieved after DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME has elapsed. Default =3D 600 seconds 3.3. Definitions Positive DNS response: a response which contains the RR that was queried for. Negative DNS response: a response which does not contain the RR that was queried for, but contains an SOA record along with a TTL indicating cache duration for this negative result. DNS Error: Where the algorithm states "name resolution returns with an error", this shall mean that either the DNS request timed out, or a DNS response which is neither a positive nor a negative response (e.g. SERVFAIL). Effective TTL: The validity period for discovered RADIUS/TLS target hosts. Calculated as: Effective TTL (set of DNS TTL values) =3D max {= MIN_EFF_TTL, min { DNS TTL values } } (the last definition helps streamlining the formulations about the minimum TTLs later on; stay tuned for the final -07 draft. > I think this point would benefit from the attention of a jaded^Wexperie= nced > DNS developer, which I am not. There could easily be other modes which= I've > not seen. Anyone reading the radext ML is invited to comment; in any case, sloppy formulations on the radext side would be caught in IETF last call or AD reviews. > Minor quibble -- it's presented in steps, but 8 is really happening dur= ing 7 > and functioning as a break condition. Yes... formulations aren't totally final yet. I'm happy if the meaning of things gets across (which I believe does). >> 9. O' =3D (set of {hostname; port; order/preference; min{all TTLs= >> that led to this result} } for all lookup results). Keep note= >> of the remaining TTL of each of the discovered records (e.g. S= RV >> and AAAA). >=20 >> I.e. you either get a final result for all the records, or the discove= ry >> has failed. >=20 >> Would that address your concern? >=20 > It still needs work. What's a "complete set of hostnames"? This is th= e > area where I'm probably going to try your patience :-). I'm not sure how to formulate this cleanly... the idea is: in each DNS query, there may be several RRs. All of these RRs again lead to more queries which can have multiple RRs; effectively creating a tree of DNS replies, where hostnames are penultimate to the leafs, and A and AAAA records are the leafs. A "final result" here is one where all branches have been explored and have all yielded hostnames. (the ultimate A and AAAA resolution comes in a later step, as it's common for both the NAPTR and the fallback SRV resolution; and it is a host prefence which protocol to try in the end. Actually, the following text hopefully captures that: " 9. If these name resolutions return an error for any of the subsequent lookups (e.g. an SRV target which does not exist), or for other reasons does not yield a complete set of hostnames (i.e. where all branches of NAPTR and possibly their follow-up SRV RRs have been evaluated) before DNS_TIMEOUT has elapsed, O =3D= { empty set } and terminate." (it has become step 9 meanwhile) > The words "perform SRV lookup" could mean to just launch a SRV query, > as intended, or could be taken as "follow the rules for using SRV recor= ds > in the RFC that defines them." I don't think not mentioning 2782 gets > the draft off the hook here, because once SRV is mentioned as something= that > is a known quantity, the reasonable recourse for an un-annotated extern= al > reference is to consult relevant RFCs. >=20 > As an aside, when dealing with "s" flags, 3958 explicitly states "norma= l > SRV processing is applied" (2.2.3). Were it not for the explicit provi= sion > in 2.2.4. about declaring failure, I would take this to mean that the > Usage Rules in 2782 are supposed to be followed. >=20 > It could perhaps be rephrased "look up RRs of type SRV." I've defined my use of "SRV lookups" now in the new Definitions section. It reads: " SRV lookup: for the purpose of this specification, SRV lookup procedures are defined as per [RFC2782], but excluding that RFCs "A" fallback as defined in its section "Usage Rules", final "else" clause." >> The ports are merely default ports. If someone runs a RADIUS/TLS serve= r >> on 1812 instead of 2083, then that's fine and he can announce that fac= t >> in DNS if he so likes. >=20 > I'm satisfied with that answer, and it was the one I expected. Do > note, the language in 6613 for port 1812 in particular is a bit stronge= r > than merely defining a default port, but that could plausibly be a > shortcoming > in 6613's phrasing. That may be as it likes; I don't think it warrants changes to the dynamic discovery I-D. >> Regarding 3.1.3, I'll need to think more about it, and need another re= v >> of the document before it manifests. >=20 > Likewise, it will be some time until I can thoroughly investigate this.= Actually, I now have text for that; stay tuned for -07. > Some of these vectors will exist whether or not the implementation stop= s at > three seconds. Also the 3 second value is for the benefit of RADIUS > protocol > fallback needs and should probably not be conflated with a secure value= for > abating DoS attacks. Implementations could use an arbitrary value here= > that is > more than 3 seconds but still reasonably finite. What administrators > will want > instinctively is for the resolution to continue for their usual client > retry interval, > and continue thereafter if refreshed by a retry. I've now moved that integer to an explicit configuration variable with a (sane?) default of 3 seconds. > In some vectors three seconds is more than enough time to cause > a lot of hurt, repeated bursts of three seconds moreso. At the very > least the DNS caches will be subject to loading under these scenarios. > Note that RADIUS servers are likely to be exempt from many of the > safeguards applied to client machines on the DNS server side, and > they are likely to have nice fast 1G or 10G links direct to the DNS > servers with a very low RTT. A lot of queries can happen under those > conditions in 3 seconds if the terminal records are aimed at NX records= > in a locally authoritative domain. >=20 > Most mature implementations will likely opt to place arbitrary limits > on the following quantities, per realm, tunable either at compile or > runtime so that resource use can be matched to reasonable expections > within the particular federation(s) involved: >=20 > 1) total number of backtracks since the last TTL expiry or > well-known-rule instigation > 2) number of NAPTR records for which (summarized) TTL information is > tracked. >=20 > The width/depth of NAPTR trees will be limited by 2). The rate of > queries for bogus domains will be limited by 1). > > In addition implementations will likely limit the number of ongoing or > cached DDDS discoveries, in a FIFO fashion, failing and/or expunging > the oldest queries when new ones arrive and the cap is exceeded. As > long as this cap is kept high enough that legitimate queries have > time to complete before they get expunged to make room for a bogus > query, RADIUS service itself is not in jeopardy. If the rate of > these queries is large enough to spin that FIFO too fast, then the > server has bigger problems on its hands that need to be addressed at > a general DoS mitigation level. > > I would suggest generalizing that language to simply advise > implementations to set sensible limits to prevent over-stacking of > pending DDDS discoveries. That is some form of rate-limiting and has also been suggested by others on the list. I'm sympathetic with adding text towards rate-limiting; I am against being prescrptive towards implementations how they should do that. I'm adding this sentence to the corresponding section in Security Considerations: "Note that even a timeout of three seconds may wreak havoc when being attacked large-scale; implementations are advised to consider rate-limiting either their amount of new executions of the dynamic discovery algorithm as a whole, or the amount of intermediate responses to track, or at least the number of pending DNS queries." > If discussions have come up with an advised default value that is > coincidentally > also 3 seconds, distinguish this value from the limit on individual > queries and > present solid rationale as to why 10 to 30 seconds (typical for retries= ) > is too > long whereas 3 seconds is not. The three seconds are explained earlier in the draft (needs to be below 5 due to RADIUS clients usually giving up after that amount of time). Now that the value is configurable, implementations might tune that down to smaller values if they see fit. > Note that caching DDDS results for later use is required by the > draft and also a vector for resource DoS, though not for sockets. >=20 >>> 3) The concerns in 2) may also be mitigated substantially if the draf= t >>> were to put normative limits on how small NAPTR and SRV TTL value= s >>> may be in compliant DDNS database entries. Allowing small TTLs i= n >>> these records leaves open the possibility that "relied upon" RRs >>> will expire before negative results return from DNS servers, the >>> algorithm will backtrack, and if those negative results also have= >>> a short TTL or are not well cached, this process could repeat >>> itself for as long as the discovery algorithm is allowed to run. >>> The draft would do well to permit compliant implementations to >>> apply a reasonable minimum TTL value to all NAPTR and SRV records= >>> received, something on the order of 60 seconds, and to advise >>> database creators to keep NAPTR and SRV record TTLs even much >>> higher than that. One source of advice on this matter is an >>> expired draft, draft-ietf-speermint-srv-naptr-use. >=20 >> Answering your point 3) first. >=20 >> I believe there is a misconception on the TTLs here. Of course the >> maintainers of a DNS zone should define their entries with reasonably >> high TTLs to avoid thrashing. That's a normal consideration for any DN= S >> label and RR though, I don't think we need to engage in the business o= f >> handholding or explain "DNS domain administration 101". >=20 >> Also keep in mind that changes in the network infrastructure sometimes= >> REQUIRE low TTLs, e.g. when trying to change a hostname to A mapping >> in-place. >=20 >> The reason why I wrote misconception though is that these are not the >> TTLs the algorithm gets (I tried to construct a pun involving "these a= re >> not the TTLs you are looking for" but didn't manage :-) ). The name >> resolution library on the server which does dynamic discovery is very >> unlikely to get fresh entries from the respective authoritative DNS >> server with the full TTL of that authoritative server. It will much mo= re >> likely get a cached reply from its resolver. And resolvers keep track = of >> how long *they* should cache answers received from upstream. I.e. they= >> will take the initial TTL from the authoritative server, and will >> decrement it on their cached entry. When queried, they will reply with= >> their own copy's (lower) TTL. >=20 >> No matter how large the TTL on the authoritative server is, it can at >> any time happen that a resolver will reply in the last second of its o= wn >> cache lifetime and will rightfully state that the entry is TTLed with = a >> 1 second duration. >=20 >> So, no amount of advice towards DNS administrators will make your issu= e >> go away. >=20 > This is understood. Do note that if a DNS server provides a lingering > record with an extremely low TTL that expires, and the authoritative TT= L > is set reasonably, the re-query is only going to happen once in the > short term, as opposed to when the authoritative TTL is e.g. zero. >=20 > (Think of what happens when a sports team tour bus or two of 50 or so > eduroamers from the same institution arrives at your school and their > NAPTR TTLs are 1, then they proceed to hop repeatedly around > several autonomous access points without fast-reauth enabled.) >=20 > Advice to DNS administrators does not technically solve the issue, thou= gh, > you are correct. It just serves (if followed) to reduce the occurence = of > instances where the implementation might need to disobey the TTL -- TTL= s > would more often expire in the interstices between RADIUS requests and > be refreshed with values that would endure the full DDDS discovery. >=20 > It also sets reasonable expectations on the part of DNS administrators = and > federation policy makers as to how DDDS implementations are likely to > behave. > If the guidance suggests a minimum TTL, they'll be duly warned that > implementation behavior might not be reliable if they elect to do other= wise. They can read a book about DNS zone administration; TTL thrashing is a well-understood problem. > Your point about the scope of the specification is well taken, though. >=20 >>> 2) It is not clear as to how to proceed if TTLs, either positive or >>> negative, expire during the execution of the algorithm due to DNS= >>> delays; Section 2.3.4 only specifies that they apply when conside= ring >>> the re-use of results for additional user sessions. RFC3403 Sect= ion 3 >>> does specify that records that are "relied upon" will cause a res= tart >>> of the algorithm if their TTL has expired during a "backtrack", b= ut >>> says nothing of what to do during the descent. >=20 >> Picking up your point from 3), it sounds like an interesting idea to >> specify that any TTL < 60 seconds (or an arguable other integer) shoul= d >> be considered as TTL =3D 60 seconds; thereby overriding the DNS cachin= g >> rules. Then your concerns would probably be mitigated. >=20 > Entirely mitigated, yes. Another option is to say that results are sti= cky > during descent. From an implementation standpoint the former is easier= > since we have to keep the TTL as state anyway. I've added the notion of "Effective TTL, which is either the DNS TTL or the configuration parameter MIN_EFF_TTL, whichever is higher. >> I like that, and would put that in the draft. But I believe it should = be >> discussed on the mailing list first; I could imagine DNS people to be >> disenchanted by an override of their data ("Why do you think you know >> better than the DNS admin himself?!?!"). >=20 >>> Also, it is not >>> explicitly stated in RFC3403 Section 3 that a negative result whi= ch >>> has caused a previous skip of a branch of the NAPTR tree is "reli= ed >>> upon", so that may be worth explicit mention. >=20 >> If also all negative results would get at least a 60s survival time, >> then this becomes a non-issue, right? >=20 > Partially: it solves it for descent, but not for backtrack which can > happen much later. > This is more a technicality than an issue -- the right thing to do > (maintain a summarized > "negative" TTL for each skipped NAPTR RR which is the minimum of all > positive/negative > TTLs involved in the decision to backtrack past the RR in question, and= then > check it when re-using the data) was comprehensible to me, but it isn't= > stated outright and might be unfathomable to some implementers. I prob= ably > should not have lumped this point into 2) as it does not just apply to > initial descent. Also it is really RFC3403s problem -- whether patchin= g it > up in the application definition is appropriate I leave to the standard= s > gurus :-) Well, there is one open question to it (but it is so minor that the answer to it may not matter very much). Imagine a realm without dynamic discovery targets, neither NAPTR nor SRV labels. The NAPTR query will yield a negative TTL X; the subsequent SRV fallback query will yield its own negative TTL Y. How long should the caller of the algorithm be told to back off? I think min { X,Y } is the answer; if any one of the two has elapsed, either a new NAPTR might show up -> worth re-executing the algorithm; or it may not, but a new SRV might come up -> again worth re-executing. I've changed the algorithm to take this into account. Greetings, Stefan Winter >=20 > -- > Brian S. Julin >=20 >=20 >=20 >=20 > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2DVOUTGCWWMQIOXAIXQCL 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHUKAcACgkQ+jm90f8eFWYhOwCfVo/2HALIAVCM4/7FpzEk3yQq os8An00aUn84UlIc3Skzl3HtqFikdyOv =VPm5 -----END PGP SIGNATURE----- ------enig2DVOUTGCWWMQIOXAIXQCL-- From stefan.winter@restena.lu Wed Jul 3 07:07:55 2013 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 C2F6F21F9CC0 for ; Wed, 3 Jul 2013 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6] 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 ZxLQRy5rq-Qu for ; Wed, 3 Jul 2013 07:07:55 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C021F8E70 for ; Wed, 3 Jul 2013 07:07:54 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2B0FA10581 for ; Wed, 3 Jul 2013 16:07:54 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 14F6910580 for ; Wed, 3 Jul 2013 16:07:54 +0200 (CEST) Message-ID: <51D43036.4080900@restena.lu> Date: Wed, 03 Jul 2013 16:07:50 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <080.a349ae9f35fd5ba78c6dfd60a52a8535@trac.tools.ietf.org> <011401ce769a$050f8f30$0f2ead90$@augustcellars.com> In-Reply-To: <011401ce769a$050f8f30$0f2ead90$@augustcellars.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MLGGNPFBMVSDHMNWMMPC" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad 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, 03 Jul 2013 14:07:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MLGGNPFBMVSDHMNWMMPC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I wish I knew enough DNSSEC to say for sure, however this is a good ste= p in > the right direction. After more feedback in anothe thread, I've refined the text even more. I believe we are getting somewhere now :-) >> " The algorithm has a fixed completion time-out of three seconds. >> Implementations might be tempted to continue their attempt to reso= lve >> DNS records even after the timeout has passed; a subsequent reques= t >> for the same realm might benefit from retrieving the results anywa= y. >> Doing so exposes the server to a Denial-of-Service risk: an attack= er >> might intentionally craft bogus DNS zones which take a very long t= ime >> to reply (e.g. due to a particularly byzantine tree structure, or >> artificial delays in responses). If an attacker generates enough >> Access-Requests for a number of such zones, it may deplete server >> sockets or other server resources." >=20 > I am not sure that the DOS risk would be significantly larger between a= 3 > and a 6 second time out. It would just require half as many requests. = A > better way of addressing the specific problem you have shown here would= > involve black-listing of DNS queries and I don't see anything in this t= ext > or the algorithm which talks about doing black listing of any type. I've added more text which suggests rate-limiting (but want to leave the details to implementations). >> These were both discussed on the list; DANE is clumsy/not usable in i= ts >> current state; TLS-PSK is not in scope for this document. >=20 > Great - please state this in the introduction material There's actually a better place for this: the S-NAPTR RFC requires me to wreite a section on "Server Identification and Handshake" anyway. My current working copy has text to explain why TLS-PSK is bad, suggests the NAIRealm certificate property (MTI), and has a non-MTI explanation of what we do in eduroam. As I thought more about DANE, I think we were actually a bit unfair: the algorithm discovers a /server/. The identification and handshake therefore only need to deal with server identification. It's true that the contacted RADIUS server at some point also has to make a determination whether it wants to talk to the RADIUS client, but this doesn't have to be determined on the same grounds as the server-side identification. That's actually the same as with NAIRealm: this (MTI!) mechanism only takes one through the server-side identification, the client auth is left unspec'ed. In that light, I think it's fair to add DNSSEC+DANE as one of the mechanisms. I've added stub text about it; if there is sufficient interest in the topic then this can be expanded. I've added a remark that the discovery spec only concerns itself with the server-side identification. Greetings, Stefan Winter >=20 > Jim >=20 >> >> Greetings, >> >> Stefan Winter >> >> -- >> -------------------------------------+--------------------------------= -- >> -------------------------------------+--- >> Reporter: | Owner: draft-ietf-radext= - >> stefan.winter@restena.lu | dynamic-discovery@tools.ietf.o= rg >> Type: defect | Status: new >> Priority: major | Milestone: milestone1 >> Component: dynamic-discovery | Version: 1.0 >> Severity: - | Resolution: >> Keywords: | >> -------------------------------------+--------------------------------= -- >> -------------------------------------+--- >> >> Ticket URL: >> >> radext >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2MLGGNPFBMVSDHMNWMMPC 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHUMDkACgkQ+jm90f8eFWY5DACfXNlqIKYg8VX0mEjLnbzJlcg+ 3nUAniWP8O7VqYlVKCKOtNmGlePuXZ9m =albV -----END PGP SIGNATURE----- ------enig2MLGGNPFBMVSDHMNWMMPC-- From trac+radext@trac.tools.ietf.org Wed Jul 3 07:12:20 2013 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 BB85321F9A83 for ; Wed, 3 Jul 2013 07:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCLWkm10xYrS for ; Wed, 3 Jul 2013 07:12:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0DC21F9B5C for ; Wed, 3 Jul 2013 07:12:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:34101 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UuNn6-00076j-9Y; Wed, 03 Jul 2013 16:12:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 03 Jul 2013 14:12:16 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/148#comment:2 Message-ID: <080.e8f185e21900dfba6ff273660484c83f@trac.tools.ietf.org> References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 148 In-Reply-To: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mikem@open.com.au, stefan.winter@restena.lu Resent-Message-Id: <20130703141219.8C0DC21F9B5C@ietfa.amsl.com> Resent-Date: Wed, 3 Jul 2013 07:12:19 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad 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: Wed, 03 Jul 2013 14:12:20 -0000 #148: Review of dynamic-discovery by Jim Schaad Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: My working copy now also contains text for the two remaining sub-issues above. I'll submit -07 probably by tomorrow; now closing this TRAC item as resolved fixed. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | dynamic-discovery@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From stefan.winter@restena.lu Wed Jul 3 07:19:16 2013 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 5B2DD21F8F24 for ; Wed, 3 Jul 2013 07:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.749, 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 QOwbcnUlwf57 for ; Wed, 3 Jul 2013 07:19:15 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E3EEA21F84F2 for ; Wed, 3 Jul 2013 07:19:14 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4D45710581 for ; Wed, 3 Jul 2013 16:19:09 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3F82610580 for ; Wed, 3 Jul 2013 16:19:09 +0200 (CEST) Message-ID: <51D432D9.2070902@restena.lu> Date: Wed, 03 Jul 2013 16:19:05 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org References: <029601ce1575$a21b0600$e6511200$@augustcellars.com> In-Reply-To: <029601ce1575$a21b0600$e6511200$@augustcellars.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2LBJMGAAQBGJGCUNNNARM" X-Virus-Scanned: ClamAV Subject: Re: [radext] Comments on draft-ietf-radext-dynamic-discovery-06 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, 03 Jul 2013 14:19:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2LBJMGAAQBGJGCUNNNARM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > 1. Should there be a potential privacy concern noted in this document= > surrounding the question of what information can leak based on the doma= in(s) > being queried? I am not sure that there is any usable information leak= ing > here but this is not even close to my forte. >=20 > 2. In section 2.3.3 - May want to be a bit more detailed here about t= he > subsequent lookup steps. Presumably this is not starting with step 8 b= ut I > could be wrong. I.e. do we take the set of result names and go back to= step > 4 with new values of R? I'm adding these two to a new TRAC ticket, almost lost them in my ML history. > 3. In section 2.3.3 - Please provide some text somewhere about the > reasoning behind step 15. I can understand removing a single record fr= om > the record set but all of them? The current working copy of -07-to-be describes this. > 4. In section 2.3.3 - Step 12 does not specify where the negative TTL = comes > from. ( referenced as something significant in 2.3.4) The current working copy of -07-to-be describes this (either from a SOA TTL, or from local config if there was no reply at all). 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 ------enig2LBJMGAAQBGJGCUNNNARM 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHUMt0ACgkQ+jm90f8eFWY9qACfSlXodCGhTgWIKzYsLI7YcxhG ICwAnApDHibb7fQbpDpg5HW1FR/mRWwf =6sge -----END PGP SIGNATURE----- ------enig2LBJMGAAQBGJGCUNNNARM-- From trac+radext@trac.tools.ietf.org Wed Jul 3 07:20:41 2013 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 16A2E21F9BCF for ; Wed, 3 Jul 2013 07:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lPuvkp3QnN8 for ; Wed, 3 Jul 2013 07:20:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8021F9C19 for ; Wed, 3 Jul 2013 07:20:22 -0700 (PDT) Received: from localhost ([127.0.0.1]:34927 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UuNuu-0006UR-WB; Wed, 03 Jul 2013 16:20:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Wed, 03 Jul 2013 14:20:20 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/168 Message-ID: <065.8e3b593ce94ff54b06f468a19aa3f87e@trac.tools.ietf.org> X-Trac-Ticket-ID: 168 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mikem@open.com.au, stefan.winter@restena.lu Resent-Message-Id: <20130703142022.5FD8021F9C19@ietfa.amsl.com> Resent-Date: Wed, 3 Jul 2013 07:20:22 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #168: Remaining issues for dynamic-discovery draft 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: Wed, 03 Jul 2013 14:20:41 -0000 #168: Remaining issues for dynamic-discovery draft This ticket captures the remaining comments on the ML that need to be worked on: 1) NAIRealm certificate extension 1.1 allocation of an OID is pending 1.2 Comment by JS: "Are you sure you want NAIRealms to be IA5String and not UTF8String? This is an I18N question." 1.3 Comment by JS: "This text would appear to say that foo.*.bar is a legal wildcard NAI realm. Is that what you want?" 2) Privacy (JS) "Should there be a potential privacy concern noted in this document surrounding the question of what information can leak based on the domain(s) being queried? I am not sure that there is any usable information leaking here but this is not even close to my forte." 3) subsequent lookup steps (JS) "In section 2.3.3 - May want to be a bit more detailed here about the subsequent lookup steps. Presumably this is not starting with step 8 but I could be wrong. I.e. do we take the set of result names and go back to step 4 with new values of R?" These will be dealt with after -07 is out. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | dynamic-discovery@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: dynamic-discovery | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Thu Jul 4 05:37:52 2013 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 3B3F221F9FAA; Thu, 4 Jul 2013 05:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, NO_RELAYS=-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 UI-2Wwr0uJqa; Thu, 4 Jul 2013 05:37:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 535A021F9FBB; Thu, 4 Jul 2013 05:37:38 -0700 (PDT) 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: 4.51.p2 Message-ID: <20130704123738.26098.28703.idtracker@ietfa.amsl.com> Date: Thu, 04 Jul 2013 05:37:38 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-07.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, 04 Jul 2013 12:37:52 -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 the IE= TF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-07.txt Pages : 22 Date : 2013-07-04 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan.winter@restena.lu Thu Jul 4 05:42:50 2013 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 A480521F9FD9 for ; Thu, 4 Jul 2013 05:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.634, 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 5Pig-gHoh++V for ; Thu, 4 Jul 2013 05:42:50 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1438D21F9F87 for ; Thu, 4 Jul 2013 05:42:50 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EE5F210581 for ; Thu, 4 Jul 2013 14:42:48 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D6E6610580 for ; Thu, 4 Jul 2013 14:42:48 +0200 (CEST) Message-ID: <51D56DC4.8060009@restena.lu> Date: Thu, 04 Jul 2013 14:42:44 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org References: <20130704123738.26098.28703.idtracker@ietfa.amsl.com> In-Reply-To: <20130704123738.26098.28703.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FNRRKENBJUOWLBBMFDXW" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-07.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, 04 Jul 2013 12:42:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FNRRKENBJUOWLBBMFDXW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, this new version addresses all issues except those in TRAC #168. There is another follow-up mail from an implementer; forwarding soon. His comments are also addressed. Beware: even though the core algorithm isunchanged, the diff is big and probably a bit unreadable. Please consider taking a fresh look. This draft is obviously not yet ready for WGLC; I first need to get TRAC #168 addressed. I hope to be able to push out an -08 with these in before the cut-off. Greetings, Stefan Winter On 04.07.2013 14:37, 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 th= e IETF. >=20 > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and = RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-07.txt > Pages : 22 > Date : 2013-07-04 >=20 > Abstract: > This document specifies a means to find authoritative RADIUS servers= > for a given realm. It is used in conjunction with either RADIUS/TLS= > and RADIUS/DTLS. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-= 07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2FNRRKENBJUOWLBBMFDXW 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHVbcgACgkQ+jm90f8eFWadVACfQ9Wo6rTMrTOZ6TVf8xBAHYnV v7UAn3VKDTYT+H5yC1PSCDf+upCcIlF9 =35E1 -----END PGP SIGNATURE----- ------enig2FNRRKENBJUOWLBBMFDXW-- From stefan.winter@restena.lu Thu Jul 4 05:43:19 2013 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 5105921F9FDF for ; Thu, 4 Jul 2013 05:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.589, 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 Ghkl2donVYhZ for ; Thu, 4 Jul 2013 05:43:18 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3E50A21F9FDC for ; Thu, 4 Jul 2013 05:43:18 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9B4E510581 for ; Thu, 4 Jul 2013 14:43:17 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9021E10580 for ; Thu, 4 Jul 2013 14:43:17 +0200 (CEST) Message-ID: <51D56DE5.3040507@restena.lu> Date: Thu, 04 Jul 2013 14:43:17 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "radext@ietf.org" References: <88ACDECA21EE5B438CA26316163BC14C25D2E88E@BASS.ad.clarku.edu> In-Reply-To: <88ACDECA21EE5B438CA26316163BC14C25D2E88E@BASS.ad.clarku.edu> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <88ACDECA21EE5B438CA26316163BC14C25D2E88E@BASS.ad.clarku.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2EWQNCLVBNKJAELDCUIQS" X-Virus-Scanned: ClamAV Subject: [radext] Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 04 Jul 2013 12:43:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EWQNCLVBNKJAELDCUIQS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Follow-up from the implementer... -------- Original Message -------- Subject: RE: [radext] Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery Date: Wed, 3 Jul 2013 16:16:21 +0000 From: Brian Julin To: Stefan Winter Stefan, Thanks again for your responses. Most of the issues seem to be addressed= or will be address in the next draft, so I'll wait for that and offer mor= e comments then (and in the meantime adapt the code I'm working on.) A couple things still seem worth wrangling trough: > A "final result" here is one where all branches have been explored and > have all yielded hostnames. (the ultimate A and AAAA resolution comes i= n > a later step, as it's common for both the NAPTR and the fallback SRV > resolution; and it is a host prefence which protocol to try in the end.= Well, one is only supposed to explore the tree up to the point where one terminal NAPTR and its subsequent child lookup yields usable results,= stop there and use those results, so that's not "all branches" really. Then the implementation is expected to either continue exploring or resta= rt exploring (depending on TTLs) whenever those results are deemed to no longer be usable. So "final result" is probably not good nomenclature. = I'd suggest "terminal result" to tie it to the single parent NAPTR. My question is really what to do when you have sets of either NAPTR RRs or SRV RRs all of which match your tag, but a few of which are obviously invalid (pointing to bogons, owned by "." or "", etc.). The two good answers I see are "throw out the whole set and move on at the next higher level" = and "ignore the bad ones and use the good ones" and I don't have much advice to offer as to which is best. > > Some of these vectors will exist whether or not the implementation st= ops > at > > three seconds. Also the 3 second value is for the benefit of RADIUS > > protocol > > fallback needs and should probably not be conflated with a secure val= ue for > > abating DoS attacks. Implementations could use an arbitrary value he= re > > that is > > more than 3 seconds but still reasonably finite. What administrators= > > will want > > instinctively is for the resolution to continue for their usual clien= t > > retry interval, > > and continue thereafter if refreshed by a retry. >=20 > I've now moved that integer to an explicit configuration variable with = a > (sane?) default of 3 seconds. [... snipped and rearranged the order a bit here] > > If discussions have come up with an advised default value that is > > coincidentally > > also 3 seconds, distinguish this value from the limit on individual > > queries and > > present solid rationale as to why 10 to 30 seconds (typical for retri= es) > > is too > > long whereas 3 seconds is not. >=20 > The three seconds are explained earlier in the draft (needs to be below= > 5 due to RADIUS clients usually giving up after that amount of time). > Now that the value is configurable, implementations might tune that dow= n > to smaller values if they see fit. OK, I see the DNS_TIMEOUT, but I don't think we are quite yet on the same= page here. I agree that the 3 seconds value is correct for the amount of time after which a RADIUS request should be routed through the default (non-DD= DS) path. I don't think the amount of time that the DNS lookup may proceed (independent of the fate of the RADIUS request) needs to be related to th= is number, and I don't see a rationale presented for the default for THAT be= ing 3 seconds, though I do see the need for it to be quite strictly limited for DoS prevention. My instinct tells me that the longest you would want to keep scratching a= t DNS in the hopes of resolving the lookup before a failing client retries = is near the typical client retry interval, but in most cases that will be overkill and a lower value based on actual "worst-but-not-pathological-case" real-world expected DNS performance would be better as a default value. [ snip ] > That is some form of rate-limiting and has also been suggested by other= s > on the list. I'm sympathetic with adding text towards rate-limiting; I > am against being prescrptive towards implementations how they should do= > that. I'm adding this sentence to the corresponding section in Security= > Considerations: >=20 > "Note that even a timeout of three seconds may wreak havoc > when being attacked large-scale; implementations are advised to > consider rate-limiting either their amount of new executions of the > dynamic discovery algorithm as a whole, or the amount of intermediat= e > responses to track, or at least the number of pending DNS queries." I think this is fine. Rate limiting is a very complex subject and the proper approach varies with details of the implementation, especially since you can easily thereby open the additional DoS vector of soaking the rate= limit to deny service to legitimate requests. [snip] > Imagine a realm without dynamic discovery targets, neither NAPTR nor SR= V > labels. >=20 > The NAPTR query will yield a negative TTL X; the subsequent SRV fallbac= k > query will yield its own negative TTL Y. >=20 > How long should the caller of the algorithm be told to back off? >=20 > I think min { X,Y } is the answer; if any one of the two has elapsed, > either a new NAPTR might show up -> worth re-executing the algorithm; o= r > it may not, but a new SRV might come up -> again worth re-executing. This sounds like TRTTD. With MIN_EFF_TTL mixed in I assume. -- Brian S. Julin ------enig2EWQNCLVBNKJAELDCUIQS 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHVbeUACgkQ+jm90f8eFWbv/gCfRDYOjqm3MTopD7ctVd4XtfFd U9AAmwZP5gisJO1ThC5t//KWuBGnPTGv =1VjW -----END PGP SIGNATURE----- ------enig2EWQNCLVBNKJAELDCUIQS-- From stefan.winter@restena.lu Thu Jul 4 06:01:00 2013 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 AB7DA21F9FDA for ; Thu, 4 Jul 2013 06:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, 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 MdSYGdC3ohGL for ; Thu, 4 Jul 2013 06:01:00 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9880421F9FD9 for ; Thu, 4 Jul 2013 06:00:59 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id F361010581; Thu, 4 Jul 2013 15:00:58 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id E834D10580; Thu, 4 Jul 2013 15:00:58 +0200 (CEST) Message-ID: <51D57207.802@restena.lu> Date: Thu, 04 Jul 2013 15:00:55 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org, Brian Julin References: <88ACDECA21EE5B438CA26316163BC14C25D2E88E@BASS.ad.clarku.edu> <51D56DE5.3040507@restena.lu> In-Reply-To: <51D56DE5.3040507@restena.lu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TWFGHXHBLSCTPQNKNJJE" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 04 Jul 2013 13:01:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TWFGHXHBLSCTPQNKNJJE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> A "final result" here is one where all branches have been explored and= >> have all yielded hostnames. (the ultimate A and AAAA resolution comes = in >> a later step, as it's common for both the NAPTR and the fallback SRV >> resolution; and it is a host prefence which protocol to try in the end= =2E >=20 > Well, one is only supposed to explore the tree up to the point where > one terminal NAPTR and its subsequent child lookup yields usable result= s, > stop there and use those results, so that's not "all branches" really. >=20 > Then the implementation is expected to either continue exploring or res= tart > exploring (depending on TTLs) whenever those results are deemed to no > longer be usable. So "final result" is probably not good nomenclature.= I'd > suggest "terminal result" to tie it to the single parent NAPTR. >=20 > My question is really what to do when you have sets of either NAPTR RRs= > or SRV RRs all of which match your tag, but a few of which are obviousl= y > invalid (pointing to bogons, owned by "." or "", etc.). The two good > answers > I see are "throw out the whole set and move on at the next higher level= " and > "ignore the bad ones and use the good ones" and I don't have much advic= e > to offer as to which is best. Okay... RFC3958 speaks of "Successive Resolution" and "terminal lookup". I've changed the draft -07 to use that nomenclature. Indeed, that same RFC suggests an (IMHO: odd) mixture of the descendence of NAPTR -> SRV/A/AAAA lookups and the connection phase to a server; it's in a way a greedy search which advises an implementation to proceed to connection setup with the top-priority discovered host as soon as it's discovered. If that top-priority host turns out not to be acceptable or doesn't respond, you are supposed to come back to discovery and try the remaining options. I don't like this approach; it is incompatible with the loop detection - the querying server needs to find out whether it itself is in the set of results; which requires the set to be complete. I believe it also makes implementations harder; they've got to temporarily break out of the algorithm, do their connection attempt, and come back later if needed. I prefer having a strict two-phase approach: do all DNS lookups for all branches; then take the resulting set and try the servers in order of preference. That also nicely solves your backtracking question for bogus DNS entries: RFC3958 declares these as "failure", which in its context means return to backtracking immediately. Since my draft now doesn't need backtracking, it merely needs to descend on all branches and ignore those which are bogus. Either at least one branch yielded at least one hostname, which means discovery worked and this set of hostnames is used - or all entries were bogus, which means discovery did NOT work and we need to back off for BACKOFF_TIME to wait for better days. I've made a last-minute change to the draft to that effect. The step in the algorithm now reads: 9. For the extracted NAPTRs, perform successive resolution as defined in [RFC3958], section 2.2.4, with the additional reservation that all records are to be immediately pursued through terminal lookup, i.e. have resulted in hostnames. Failure to achieve terminal lookup for individual records is non-fatal. 10. If the set of hostnames is empty, O-1 =3D { empty set }, O-2 =3D BACKOFF_TIME and terminate. >> The three seconds are explained earlier in the draft (needs to be belo= w >> 5 due to RADIUS clients usually giving up after that amount of time). >> Now that the value is configurable, implementations might tune that do= wn >> to smaller values if they see fit. >=20 > OK, I see the DNS_TIMEOUT, but I don't think we are quite yet on the sa= me > page here. I agree that the 3 seconds value is correct for the amount > of time > after which a RADIUS request should be routed through the default (non-= DDDS) > path. I don't think the amount of time that the DNS lookup may proceed= > (independent of the fate of the RADIUS request) needs to be related to = this > number, and I don't see a rationale presented for the default for THAT = being > 3 seconds, though I do see the need for it to be quite strictly limited= > for DoS > prevention. >=20 > My instinct tells me that the longest you would want to keep scratching= at > DNS in the hopes of resolving the lookup before a failing client retrie= s is > near the typical client retry interval, but in most cases that will be > overkill > and a lower value based on actual "worst-but-not-pathological-case" > real-world > expected DNS performance would be better as a default value. I've modified the Security Considerations text to make sure that it's understood that DNS_TIMEOUT is one thing (for ops reasons), and the waiting time for DNS to finish is another thing, implementation choice and its duration is out of scope. In any case, DNS_TIMOUT <=3D DoS-preventing waiting time. If you're only willing to wait less time, then you effectively lower DNS_TIMEOUT implicitly. > I think this is fine. Rate limiting is a very complex subject and the > proper > approach varies with details of the implementation, especially since > you can easily thereby open the additional DoS vector of soaking the ra= te > limit to deny service to legitimate requests. Great. >> I think min { X,Y } is the answer; if any one of the two has elapsed, >> either a new NAPTR might show up -> worth re-executing the algorithm; = or >> it may not, but a new SRV might come up -> again worth re-executing. >=20 > This sounds like TRTTD. With MIN_EFF_TTL mixed in I assume. Correct; I'm using the Effective TTL ( ) function throughout the algorithm, also for the negative TTL result from SOAs. 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 ------enig2TWFGHXHBLSCTPQNKNJJE 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHVcgoACgkQ+jm90f8eFWbtOwCeK01PgFnYVSoAHj5lccm8GJ+t jF4An30AYT1WglnjeRi2Y+rhvqgQpZZJ =ZOVV -----END PGP SIGNATURE----- ------enig2TWFGHXHBLSCTPQNKNJJE-- From stefan.winter@restena.lu Thu Jul 4 06:34:49 2013 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 CC39B21F9F71 for ; Thu, 4 Jul 2013 06:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 49YrQvW7Wofo for ; Thu, 4 Jul 2013 06:34:49 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 0485C21F9F58 for ; Thu, 4 Jul 2013 06:34:48 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 17ADE10581 for ; Thu, 4 Jul 2013 15:34:46 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 031DD1057E for ; Thu, 4 Jul 2013 15:34:46 +0200 (CEST) Message-ID: <51D579F1.20905@restena.lu> Date: Thu, 04 Jul 2013 15:34:41 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: radext@ietf.org References: <065.8e3b593ce94ff54b06f468a19aa3f87e@trac.tools.ietf.org> In-Reply-To: <065.8e3b593ce94ff54b06f468a19aa3f87e@trac.tools.ietf.org> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2HKAEKBNPBJKNPTGAQOSP" X-Virus-Scanned: ClamAV Subject: Re: [radext] #168: Remaining issues for dynamic-discovery draft 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, 04 Jul 2013 13:34:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2HKAEKBNPBJKNPTGAQOSP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > This ticket captures the remaining comments on the ML that need to be > worked on: >=20 > 1) NAIRealm certificate extension >=20 > 1.1 allocation of an OID is pending I'll send a notification about -07 to the pkix list to keep the ball rolling. > 1.2 Comment by JS: "Are you sure you want NAIRealms to be IA5String an= d > not UTF8String? This is an I18N question." I didn't think much during copy&paste - which was probably a mistake :-) I want things to be aligned with the new NAI document. After all, the purpose of the certificate extension is to compare it to the original NAI of a user request; they should naturally be in the same format. Since the NAI document allows UTF-8 input which is not restricted to the ASCII subset, the certificate extension should allow that, too. Just before submitting -07 I realised that, so -07 now speaks of UTF8Stri= ng. > 1.3 Comment by JS: "This text would appear to say that foo.*.bar is a > legal wildcard NAI realm. Is that what you want?" It is what I wanted. But I have to say that this area is not my preferred; I keep hearing from DNS people that wildcard names are generally evil and that they should either be forbidden (but I think they are necessary in our case to allow for proxy operation) or lobotomised as much as possible. If there is consensus on lobotomising the wildcard names so that left of a star component is either another star component or nothing - preventing the foo.*.example construct - , then I'm fine with changing it that way. > 2) Privacy (JS) >=20 > "Should there be a potential privacy concern noted in this document > surrounding the question of what information can leak based on the > domain(s) > being queried? I am not sure that there is any usable information lea= king > here but this is not even close to my forte." I can't think of any (and in eduroam we are traditionally extremely excited about privacy preservation, so not being able to think of privacy concerns for an eduroamer means something :-) ). The algorithm only processes a domain name; anything left of the @ is stripped before the first query. Also, the domain name is not vetted in any way. If someone were to observe the DNS traffic coming out of the RADIUS forwarding server which executes the algorithm, he could only deduce "someone who claims to belong to domain x.y wants to authenticate". On the other end of the DNS queries, a DNS operator will see that queries come in from a particular source, and will be able to conclude "someone who claims to belong to my domain is near that querying server".= I find none of those two very exciting information; but this is of course subject to discussion. > 3) subsequent lookup steps (JS) >=20 > "In section 2.3.3 - May want to be a bit more detailed here about the > subsequent lookup steps. Presumably this is not starting with step 8 = but > I > could be wrong. I.e. do we take the set of result names and go back t= o > step > 4 with new values of R?" In -07 I am now referring directly to the S-NAPTR RFC, which has more detailed provisions for the lookup steps. I believe you were aiming at non-terminal lookups (empty FLAG field)? These yield a new label to lookup NAPTR for, that's true. This is not "going back" to a previous step though, it's just part of the normal descendence on a NAPTR -> SRV/A/AAAA branch. I.e. the next query will then be another NAPTR query for the new label, which will either be yet another non-terminal (more NAPTRs to follow), or a "S" or a "A" NAPTR. The initial value of R always needs to be retained for the server identity and handshake verification. Or maybe I mis-understood your comment. 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 ------enig2HKAEKBNPBJKNPTGAQOSP 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHVefUACgkQ+jm90f8eFWbDDQCdFBluZjWOAPeylHwm42w1a7Fe bCAAnRGqHRAa8PEJiwgu7/YmIJIaXItR =vZrx -----END PGP SIGNATURE----- ------enig2HKAEKBNPBJKNPTGAQOSP-- From hartmans@painless-security.com Sun Jul 7 19:29:35 2013 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 A5D7C21F91B0 for ; Sun, 7 Jul 2013 19:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 GEvZuP0Po1F7 for ; Sun, 7 Jul 2013 19:29:29 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A5C3821F8EB2 for ; Sun, 7 Jul 2013 19:29:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0D34220181 for ; Sun, 7 Jul 2013 22:24:50 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulTOq61IRouX for ; Sun, 7 Jul 2013 22:24:49 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Sun, 7 Jul 2013 22:24:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F404F88414; Sun, 7 Jul 2013 22:28:43 -0400 (EDT) From: Sam Hartman To: radext@ietf.org Date: Sun, 07 Jul 2013 22:28:43 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [radext] Short draft on using larger packets for TLS fragmentation 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, 08 Jul 2013 02:29:35 -0000 There seems to be consensus on the idea that TCP level fragmentation is the right way to fragment TLS when you can afford to change the proxies. In fact, we may even have consensus that since RADSEC is experimental that it's reasonable to assume that people who need fragmentation and RADSEC can upgrade their proxies. I'm tempted to write a short draft that revises RADSEC, permits larger RADIUS messages and introduces a mechanism for saying that you cannot respond to a request without being able to send a larger fragment. This does not provide negotiation nor does it provide support for the proxy unmodified case. However at least as I've been reading the WG discussion, we all seem to agree this is the best approach when it is possible. Also, such a draft would not preclude using a future negotiation mechanism and could work well along-side Alex's draft. I'd kind of like to get to noises of support soon if I'm going to put this together. I understand the 00 deadline has been removed but I'd rather publish sooner than later. If this is published I'd like this to be consider as part of the fragmentation discussion. It's been brought up a number of times. From peterd@iea-software.com Mon Jul 8 08:46:49 2013 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 63C1821F9CB9 for ; Mon, 8 Jul 2013 08:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw4S5VH-A2KK for ; Mon, 8 Jul 2013 08:46:44 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4621F9C56 for ; Mon, 8 Jul 2013 08:46:43 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 8 Jul 2013 08:46:43 -0700 Date: Mon, 8 Jul 2013 08:46:23 -0700 (Pacific Daylight Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: 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 Subject: Re: [radext] Short draft on using larger packets for TLS fragmentation 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, 08 Jul 2013 15:46:49 -0000 On Sun, 7 Jul 2013, Sam Hartman wrote: > There seems to be consensus on the idea that TCP level fragmentation is > the right way to fragment TLS when you can afford to change the proxies. > In fact, we may even have consensus that since RADSEC is experimental > that it's reasonable to assume that people who need fragmentation and > RADSEC can upgrade their proxies. > I'm tempted to write a short draft that revises RADSEC, permits larger > RADIUS messages and introduces a mechanism for saying that you cannot > respond to a request without being able to send a larger fragment. Only concern with this approach UDP compatibility is lost. > This does not provide negotiation nor does it provide support for the > proxy unmodified case. However at least as I've been reading the WG > discussion, we all seem to agree this is the best approach when it is > possible. Also, such a draft would not preclude using a future > negotiation mechanism and could work well along-side Alex's draft. My draft addresses TCP limits (4.2) while concurrently providing for UDP interop (4.1) should it be desired. Those who see no value in UDP interop can elect not to implement Section 4.1. Section 4.2 provides for larger messages via TCP and communicating message limits. It's not even necessary to support 4.2 command code and attributes to communicate message limits. Support for large messages is allowed to be an administrative option provided it is not enabled by default. regards, Peter From hartmans@painless-security.com Mon Jul 8 09:25:21 2013 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 8BEDB21F938E for ; Mon, 8 Jul 2013 09:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB39JbhWN2P2 for ; Mon, 8 Jul 2013 09:25:14 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 37C0221F8925 for ; Mon, 8 Jul 2013 09:25:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id E4C6320181; Mon, 8 Jul 2013 12:20:32 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiDyD2qCjHgz; Mon, 8 Jul 2013 12:20:31 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 8 Jul 2013 12:20:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6DE3188420; Mon, 8 Jul 2013 12:24:28 -0400 (EDT) From: Sam Hartman To: Peter Deacon References: Date: Mon, 08 Jul 2013 12:24:28 -0400 In-Reply-To: (Peter Deacon's message of "Mon, 8 Jul 2013 08:46:23 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] Short draft on using larger packets for TLS fragmentation 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, 08 Jul 2013 16:25:21 -0000 >>>>> "Peter" == Peter Deacon writes: Peter> On Sun, 7 Jul 2013, Sam Hartman wrote: Peter> Section 4.2 provides for larger messages via TCP and Peter> communicating message limits. It's not even necessary to Peter> support 4.2 command code and attributes to communicate Peter> message limits. Support for large messages is allowed to be Peter> an administrative option provided it is not enabled by Peter> default. Yeah, I was taking 4.2 out of your draft as inspiration. I agree my approach does not of itself give UDP interop. However, this approach works well either with your approach or Alex's approach, but seems to be close enough to WG agreement that we might be able to move on it this year. Once we get consensus on a broader solution I think it can fit in. I don't promise to use the same framing as your section 4.2, but your contributions to this discussion particularly in that section are very much on my mind in terms of what we're trying to accomplish. I'm trying to separate out what we seem to have agreement on so that I can start shipping code. From stefan.winter@restena.lu Wed Jul 10 05:41:48 2013 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 6B5B821F9F02 for ; Wed, 10 Jul 2013 05:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.513, 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 XL1JBt3fa5Ly for ; Wed, 10 Jul 2013 05:41:47 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E361D21F9EF1 for ; Wed, 10 Jul 2013 05:41:46 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id F07A710583 for ; Wed, 10 Jul 2013 14:41:43 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id E1A6810581 for ; Wed, 10 Jul 2013 14:41:43 +0200 (CEST) Message-ID: <51DD5683.3070202@restena.lu> Date: Wed, 10 Jul 2013 14:41:39 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "radext@ietf.org" References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> In-Reply-To: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2RMPPRJRXBEJIDUEGMRWM" X-Virus-Scanned: ClamAV Subject: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 10 Jul 2013 12:41:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RMPPRJRXBEJIDUEGMRWM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Brian did a VERY thorough analysis of one particular feature of the draft: loop prevention. See the forward below. I believe it's worth discussing the question in Berlin (again). My point so far is: loops can occur, so we should do all we can to detect and prevent them. This requires all NAPTR -> SRV -> A/AAAA lookups to be done, and look for inconsistencies in the resulting set. Brian's counter-point is: loops can happen also outside dynamic discovery, too; and will fix themselves by busting RADIUS packet boundaries. In the interest of speed, let's be less thorough in finding them and take shortcuts in DNS response evaluation wherever possible. Greetings, Stefan Winter -------- Original Message -------- Subject: RE: [radext] Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext= -dynamic-discovery Date: Tue, 9 Jul 2013 19:00:36 +0000 From: Brian Julin To: Stefan Winter Stefan, Having read through the new version of the draft, I now understand what the draft is trying to achieve WRT loop detection. Here are my comments on that: The motivation for performing this loop detection seems to be predominant= ly aimed at dealing with mis-configured edge RADIUS proxies which are handli= ng local realms as though they were remote. First let us consider the scenario where there are no failures in DNS and= no failures encountered when connecting to servers selected via the DDDS algorithm. In this case, only the highest matching order/preference/prio= rity will be used. The possible conditions under which a loop might occur in = this scenario are as follows: 1) The DDDS algorithm selects a listening address of the same RADIUS serv= er. This can be detected by a safeguard to prevent tight loops performed when= inidividual connections are initiated and/or received, and does not requi= re examination of any of the other DDDS results. 2) The next hop is an arrangement of statically routed servers which have= a static route back to a listening address of the initiating server. In this case= there is no clue present in any of the DDDS results that a loop has occurred. Thi= s could happen both on backbone federation servers, or within an institution wher= e different RADIUS instances perform different roles. 3) A terminal A record with multiple RRs is selected, one of which is a l= istening address on the initiating server. Since the A lookup needed to be perfor= med anyway, all addresses are already available for a sanity check. 4) A SRV contains multiple RRs of the same priority, one of which is a li= stening address on the initiating server. Since all A records in a SRV are not c= ustomarily looked up, only those selected for transit, this scenario could result in= loops around a load-balancing pool, if said pool was not configured to refuse c= onnections from itself and other members of the pool. 5) The result of DDDS otherwise forwards the packet to another server tha= t also performs DDDS for the same service/protocol. This will always result in = a loop, since DDDS for a given service/protocol must only be performed once. (Wh= at was said about doing the same thing multiple times and expecting differen= t results?) For the scenario that a backup SRV priority or a backtracked NAPTR order/= preference is selected, or a connection failure, the situations are the same as abov= e, with the addition that in any of the above situations the results of DDDS could di= ffer in any servers involved in the loop. This could even be done intentionally or a= ccidentally with a split horizon DNS server. There is also the specter of transient = results during DNS changes. None of these are actual problems: if any of that ever matt= ers, the root problem is that DDDS is being performed a second time for the same service/protocol during the routing of the same packet, when that should = never be the case. Note that if a non-fatal DNS failure prevents a RADIUS server from seeing= its own listening address/port in the DDDS results, this can render a san= ity check ineffective. Also note (per 2 above) that there are several scenarios where the list o= f addresses/ports against which the DDDS result would need to be checked to correctly break= loops is not the same as the list of listening sockets on the server performing DDDS -= - i.e. any arrangement of multiple autonomous RADIUS servers that forwards packets i= nternally. When a RADIUS routing loop occurs, there is no formally defined mechanism= for breaking loops. However, implementations have worked in some duplica= te detection for performance reasons (e.g. not sending the retransmits neede= d in an unreliable UDP-based environment into a reliable TCP-based environm= ent) and to deal with network topologies that might generate duplicate UDP tra= ffic. In FreeRADIUS the duplicate detection relies on the authentication vector= and size of the packet as well as the src/dst ip/port. This would cut short = most naturally occurring loops after a finite number of iterations -- the exce= ption being scenarios where hops modify transiting requests in a way that is not eventually idempotent, without also creating a packet that exceeds any RADIUS packet format limitations, or implementations that change their so= urce ports frequently. RADIUS administrators should be advised not to disable= duplicate checking on incoming TCP connections when DDDS is in use. Other possible safeguards for implementors to consider could include per-realm rate limiting on transit hops, with violations leading to a pur= ge of all requests from that realm for a short period of time and log messag= es to that effect. General loop detection in RADIUS is an issue beyond the scope of the draf= t -- albeit one which does deserve some attention. While it is a helpful safeguard to prevent a server from trying to connec= t to itself, the scenarios sketched out above are likely to be rare enough = that a balance needs to be struck between the performance of the normal, funct= ional, case and the efficacy of safeguards, which cannot be perfect as DDDS cann= ot in and of itself solve the problem. Given the expense of performing a fu= ll enumeration of the DDDS tree, I suggest that line should be drawn somewha= t short of that measure. with implementations given the option to be more thorough where they deem fit. I'd suggest that servers SHOULD lookup and= loop-guard all A/AAAA records for RRs of an active SRV priority, with a h= ard failure if even one matches, and SHOULD likewise loop-guard against all A/AAAA addresses retrieved when multiple A/AAAA RRs respond to the same owner, and of course MUST never try to forward to the same listening addr= ess upon which the original request was received. I might further offer that implementations MAY shut down all attempts to = connect to a realm if they ever are asked to connect to themselves for that realm= in a manner that generates noisy complaints in logs and requires manual interv= ention to clear. In general these problems are of the type that will not self-h= eal and/or they indicate a security incident which merits notification of an adminis= trator. Most implementations will probably elect not to permanently poison a real= m for fear that a single spoofed DNS result could use this as a DoS. They shou= ld be at least encouraged to log such episodes as security events. Regards, Brian S. Julin ------enig2RMPPRJRXBEJIDUEGMRWM 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHdVocACgkQ+jm90f8eFWb0UACePJWw60rP1uTyE5qQPXNVnjHG /h4An1mdmPyOjHmHSsIr85j45wG8X+GJ =BnfZ -----END PGP SIGNATURE----- ------enig2RMPPRJRXBEJIDUEGMRWM-- From aland@deployingradius.com Wed Jul 10 23:57:54 2013 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 B07CA21F9D21 for ; Wed, 10 Jul 2013 23:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ylAmaaWc6bC for ; Wed, 10 Jul 2013 23:57:48 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7150321F9D1E for ; Wed, 10 Jul 2013 23:57:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7E454224011E; Thu, 11 Jul 2013 08:56:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlbpTJ9-D9Wn; Thu, 11 Jul 2013 08:56:47 +0200 (CEST) Received: from pc24.home (AAnnecy-157-1-133-15.w86-209.abo.wanadoo.fr [86.209.28.15]) by power.freeradius.org (Postfix) with ESMTPSA id DE5F822400AB; Thu, 11 Jul 2013 08:56:43 +0200 (CEST) Message-ID: <51DE5730.4080008@deployingradius.com> Date: Thu, 11 Jul 2013 08:56:48 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> In-Reply-To: <51DD5683.3070202@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 11 Jul 2013 06:57:54 -0000 Stefan Winter wrote: > My point so far is: loops can occur, so we should do all we can to > detect and prevent them. This requires all NAPTR -> SRV -> A/AAAA > lookups to be done, and look for inconsistencies in the resulting set. > > Brian's counter-point is: loops can happen also outside dynamic > discovery, too; and will fix themselves by busting RADIUS packet > boundaries. In the interest of speed, let's be less thorough in finding > them and take shortcuts in DNS response evaluation wherever possible. Sounds good to me. Some notes on Brian's text: > In FreeRADIUS the duplicate detection relies on the authentication vector and > size of the packet as well as the src/dst ip/port. This would cut short most > naturally occurring loops after a finite number of iterations It won't. The duplicate detection is the RFC 5080 mechanism. It detects a NAS retransmitting the identical packet. It doesn't affect (or help with) loop detection. > -- the exception being > scenarios where hops modify transiting requests in a way that is not > eventually idempotent, All proxies modify the RADIUS packet. The ID field changes (usually), and the shared secret is different, so the authentication vector field changes, too. > without also creating a packet that exceeds any > RADIUS packet format limitations, or implementations that change their source > ports frequently. RADIUS administrators should be advised not to disable > duplicate checking on incoming TCP connections when DDDS is in use. I think this advice is wrong. RFC 6613 Section 2.6.1 forbids retransmission of duplicate packets over TCP. So any packet in a loop will look different the second time around. Or if it's the same, then it MUST NOT be transmitted the second time, and the loop is broken. > General loop detection in RADIUS is an issue beyond the scope of the draft -- > albeit one which does deserve some attention. That's very true. > While it is a helpful safeguard to prevent a server from trying to connect > to itself, the scenarios sketched out above are likely to be rare enough that > a balance needs to be struck between the performance of the normal, functional, > case and the efficacy of safeguards, which cannot be perfect as DDDS cannot > in and of itself solve the problem. Given the expense of performing a full > enumeration of the DDDS tree, I suggest that line should be drawn somewhat > short of that measure. with implementations given the option to be more > thorough where they deem fit. I'd suggest that servers SHOULD lookup and > loop-guard all A/AAAA records for RRs of an active SRV priority, with a hard > failure if even one matches, and SHOULD likewise loop-guard against all > A/AAAA addresses retrieved when multiple A/AAAA RRs respond to the same > owner, and of course MUST never try to forward to the same listening address > upon which the original request was received. That analysis presumes the *outgoing* address of the server is the same as it's *incoming* address. Which doesn't have to be the case. It may be worth updating the draft to suggest that servers using dynamic discovery either: (1) use the same address for incoming and outgoing packets (2) publish a different DNS record indicating their outgoing address The SMTP world has had similar issues for a long time. Solutions like SPF may be applicable here. > I might further offer that implementations MAY shut down all attempts to connect > to a realm if they ever are asked to connect to themselves for that realm in a > manner that generates noisy complaints in logs and requires manual intervention > to clear. I agree. This also brings up issues of authenticating the DNS records. It may be useful to have reverse IP records, which serve as a cross-check. e.g. if looking up "example.net" gets you 192.12.6.10, then doing a reverse IP lookup on that IP should get you "example.com" (among others). The document doesn't discuss reverse IP records or lookups. > In general these problems are of the type that will not self-heal and/or > they indicate a security incident which merits notification of an administrator. > Most implementations will probably elect not to permanently poison a realm for > fear that a single spoofed DNS result could use this as a DoS. They should be > at least encouraged to log such episodes as security events. Having a reverse IP lookup can help with this situation. If the forward and reverse records don't match, then that can be discovered automatically. And before the proxy starts a secure connection to the home server. Alan DeKok. From xueli@huawei.com Thu Jul 11 20:23:03 2013 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 8D23C11E80E9 for ; Thu, 11 Jul 2013 20:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJgo1IrT8N0O for ; Thu, 11 Jul 2013 20:22:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 01E2E11E80F2 for ; Thu, 11 Jul 2013 20:22:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ10460; Fri, 12 Jul 2013 03:22:39 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 04:21:59 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 04:22:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 11:22:33 +0800 From: Xueli To: "radext@ietf.org" Thread-Topic: New Version Notification for draft-xue-radext-key-management-01.txt Thread-Index: AQHOfq43n3NX8Dvj3EugYrrolDG+ZZlgXy/Q Date: Fri, 12 Jul 2013 03:22:32 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448525BE5@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.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, 12 Jul 2013 03:23:03 -0000 SGksDQoNClRoZXJlIGlzIGEgbmV3IHZlcnNpb24gZm9yIFJBRElVUyBFeHRlbnNpb25zIGZvciBL ZXkgTWFuYWdlbWVudCBpbiBXTEFOIG5ldHdvcmsuDQoNCg0KSXQgaXMgYSBnZW5lcmFsIGNhc2Ug dGhhdCBhdXRoZW50aWNhdG9yIGlzIGRlcGxveWVkIG9uIGdhdGV3YXkgaW5zdGVhZCBvZiBBQy4g U28gSW4gdGhpcyBzY2VuYXJpbywgDQp0aGUgZW5jcnlwdGlvbi9kZWNyeXB0aW9uIG5vZGUgIGNh bid0IG9idGFpbiBQYWlyd2lzZSBNYXN0ZXIgS2V5IChQTUspIGluZm9ybWF0aW9uIGR1cmluZyBF eHRlbnNpYmxlDQpBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBwcm9jZWR1cmUsIGl0IGlz IG5vdCBzdWZmaWNpZW50IHRvDQphY2hpZXZlIHRyYWZmaWMgZW5jcnlwdGlvbi9kZWNyeXB0aW9u IHJlcXVpcmVtZW50IGluIFdpcmVsZXNzIExvY2FsIEFyZWEgTmV0d29yayAoV0xBTikgbmV0d29y ay4NCg0KVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgcmVxdWlyZW1lbnQgYW5kIGlzc3VlIGZv ciBrZXkgbWFuYWdlbWVudA0KdGhhdCBoYXMgYXJpc2VuIHNvIGZhciBkdXJpbmcgYXV0aGVudGlj YXRpb24gcHJvY2VzcyBpbiBXTEFOIG5ldHdvcmsuDQpNZWFud2hpbGUsIHRoZSBjb250cm9sIG1l c3NhZ2VzIGZvciBrZXkgbWFuYWdlbWVudCBhcmUgZGVmaW5lZC4NCg0KVGhpcyBkcmF0IGlzIHVw ZGF0ZWQgd2l0aCBDaGluYS10ZWxlY29tIGFzIGNvLWF1dGhvci4NCllvdXIgY29tbWVudHMgYXJl IGFwcHJlY2lhdGVkLiANCg0KQlINCkxpDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10NCj5TZW50OiBGcmlkYXksIEp1bHkgMTIsIDIwMTMgMTE6MTYgQU0NCj5UbzogWHVl bGk7IEJvIEdhbw0KPlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt eHVlLXJhZGV4dC1rZXktbWFuYWdlbWVudC0wMS50eHQNCj4NCj4NCj5BIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQteHVlLXJhZGV4dC1rZXktbWFuYWdlbWVudC0wMS50eHQNCj5oYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExpIFh1ZSBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYg cmVwb3NpdG9yeS4NCj4NCj5GaWxlbmFtZToJIGRyYWZ0LXh1ZS1yYWRleHQta2V5LW1hbmFnZW1l bnQNCj5SZXZpc2lvbjoJIDAxDQo+VGl0bGU6CQkgUkFESVVTIEV4dGVuc2lvbnMgZm9yIEtleSBN YW5hZ2VtZW50IGluIFdMQU4gbmV0d29yaw0KPkNyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTEyDQo+ R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+TnVtYmVyIG9mIHBhZ2VzOiAxMg0KPlVS TDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dWUtcmFkZXh0 LWtleS1tYW5hZ2VtZW50LTAxLnR4dA0KPlN0YXR1czoNCj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXh1ZS1yYWRleHQta2V5LW1hbmFnZW1lbnQNCj5IdG1saXplZDoNCj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dWUtcmFkZXh0LWtleS1tYW5hZ2VtZW50 LTAxDQo+RGlmZjoNCj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC14dWUt cmFkZXh0LWtleS1tYW5hZ2VtZW50LTAxDQo+DQo+QWJzdHJhY3Q6DQo+ICAgSXQgaXMgYSBnZW5l cmFsIGNhc2UgaW4gb3BlcmF0b3JzIG5ldHdvcmtzIHRoYXQgQXV0aGVudGljYXRvciBpcw0KPiAg IGRlcGxveWVkIG9uIFNlcnZpY2UgR2F0ZXdheSAoU0dXKSB0byBhdm9pZCBvdmVybG9hZCBvbiB0 aGUgQWNjZXNzDQo+ICAgQ29udHJvbGxlciAoQUMpLiAgSW4gdGhpcyBzY2VuYXJpbywgdGhlIGVu Y3J5cHRpb24vZGVjcnlwdGlvbiBub2RlDQo+ICAgY2FuJ3Qgb2J0YWluIFBhaXJ3aXNlIE1hc3Rl ciBLZXkgKFBNSykgaW5mb3JtYXRpb24gZHVyaW5nIEV4dGVuc2libGUNCj4gICBBdXRoZW50aWNh dGlvbiBQcm90b2NvbCAoRUFQKSBwcm9jZWR1cmUsIGl0IGlzIG5vdCBzdWZmaWNlbnQgdG8NCj4g ICBhY2hpZXZlIHRyYWZmaWMgZW5jcnlwdGlvbi9kZWNyeXB0aW9uIHJlcXVpcmVtZW50IGluIFdp cmVsZXNzIExvY2FsDQo+ICAgQXJlYSBOZXR3b3JrIChXTEFOKSBuZXR3b3JrLg0KPg0KPiAgIFRo aXMgZG9jdW1lbnQgYW5hbHl6ZXMgdGhlIHJlcXVpcmVtZW50IGFuZCBpc3N1ZSBmb3Iga2V5IG1h bmFnZW1lbnQNCj4gICB0aGF0IGhhcyBhcmlzZW4gc28gZmFyIGR1cmluZyBhdXRoZW50aWNhdGlv biBwcm9jZXNzIGluIFdMQU4gbmV0d29yay4NCj4gICBNZWFud2hpbGUsIHRoZSBjb250cm9sIG1l c3NhZ2VzIGZvciBrZXkgbWFuYWdlbWVudCBhcmUgZGVmaW5lZC4NCj4NCj4NCj4NCj4NCj5UaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From stefan.winter@restena.lu Thu Jul 11 23:39:23 2013 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 B8F3C21F9CBD for ; Thu, 11 Jul 2013 23:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=0.487, 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 zLCa60MrkLE3 for ; Thu, 11 Jul 2013 23:39:23 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D2A4921F9C74 for ; Thu, 11 Jul 2013 23:39:22 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9895B10580 for ; Fri, 12 Jul 2013 08:39:20 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 867B41057D for ; Fri, 12 Jul 2013 08:39:20 +0200 (CEST) Message-ID: <51DFA493.5000005@restena.lu> Date: Fri, 12 Jul 2013 08:39:15 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <01FE63842C181246BBE4CF183BD159B448525BE5@NKGEML512-MBS.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B448525BE5@NKGEML512-MBS.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2XFADBWDFNFSLLLEUKKTS" X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.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, 12 Jul 2013 06:39:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2XFADBWDFNFSLLLEUKKTS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, > There is a new version for RADIUS Extensions for Key Management in WLAN= network. >=20 >=20 > It is a general case that authenticator is deployed on gateway instead = of AC. So In this scenario,=20 > the encryption/decryption node can't obtain Pairwise Master Key (PMK) = information during Extensible > Authentication Protocol (EAP) procedure, it is not sufficient to > achieve traffic encryption/decryption requirement in Wireless Local Are= a Network (WLAN) network. >=20 > This document analyzes the requirement and issue for key management > that has arisen so far during authentication process in WLAN network. > Meanwhile, the control messages for key management are defined. >=20 > This drat is updated with China-telecom as co-author. > Your comments are appreciated.=20 When you submitted -00, you got substantial criticism as per the use cases for this document; the approach taken to offload the authenticator function to the SGW was seen as a rather odd move. Now, in -01, you don't really react to this; the only statement in that direction I see is that you repeatedly make the assertion that "It is a general case in operators networks". I simply doubt that this is generally true; merely making an unbacked assertion that it is so doesn't make it true. I also can't help but notice that many of your normative references are old and obsolete. * For key exchange, you reference an unapproved draft of IEEE-802.11i! All of the features from that draft are meanwhile part of IEEE 802.11-2012 (and I hope you don't implement an old draft version in your products!). * The next reference is the IEEE 802.1X version from 2001 - it has two successors meanwhile. * RFC3576 is obsoleted by RFC5176. You mention both in the normative references; the main text uses the Authenticator field from 3576, but the type definition from 5176. That's probably an oversight; the calculation of Authenticator hasn't changed between the two revs. Your security considerations are very inadequate. You simply state that the link between SGW and AC must be secure. From my (skimming) understanding of the draft, these two entities are not typically located inside the same premises, right? If they aren't, simply assuming securtiy on the link blindly is an extremely bad idea. IMHO, not protecting the keys and sending them in the clear is a no-go. In the same section, you state roughly "Oh, if you need security, use IPSec!" - which is too superficial a statement to be useful; you should at least discuss how the IPSec endpoints are supposed to negotiate IPSec keying material to be able to communicate confidentially. BTW, if I recall correctly your draft was motivated by the "fact" (or so you presented it) that changing the AC to take over the authenticator role is too costly in terms of implementation or computing power. Now in security considerations, you generously recommend to implement the entire IPSec stack on the AC. I would argue that it's easier to implement the authenticator function of IEEE 802.1X than it is to implement IPSec. The same section also suggests MD5 encryption/decryption. Here I am completely lost. The KoA and KoA ACK/NAK messages are RADIUS packets, right? As such they are always making use of the MD5 shared secret for integrity checks; if you want to protect the 802.11 keying material then you could use encrypted attributes with the same shared secret (that's the way how User-Password gets encrypted). With little to no additional implementation cost. If that's what you want - don't put a half-sentence into security considerations. *Write in the spec itself that the attribute is to be encrypted*. BTW, even if you do write that in the spec, you'd still get a beating for suggesting MD5 RADIUS crypto in 2013. This encryption method is not contemporary. 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 ------enig2XFADBWDFNFSLLLEUKKTS 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHfpJgACgkQ+jm90f8eFWav/QCfa7sOY625ErMV4ZYv1TgIxwEJ YNkAnjw/BpTm9T1UPO77bZ6zsx5Wv54a =6T0n -----END PGP SIGNATURE----- ------enig2XFADBWDFNFSLLLEUKKTS-- From xueli@huawei.com Fri Jul 12 03:17:36 2013 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 387AB21F9C06 for ; Fri, 12 Jul 2013 03:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yix05G8R44IO for ; Fri, 12 Jul 2013 03:17:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4355621F9B97 for ; Fri, 12 Jul 2013 03:17:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATJ40707; Fri, 12 Jul 2013 10:17:29 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 11:16:49 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 11:17:27 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 18:17:22 +0800 From: Xueli To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.txt Thread-Index: AQHOfsqT7bHIAJnAqE6vK9PcjJUA95lg1EWw Date: Fri, 12 Jul 2013 10:17:21 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B448525CC5@NKGEML512-MBS.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B448525BE5@NKGEML512-MBS.china.huawei.com> <51DFA493.5000005@restena.lu> In-Reply-To: <51DFA493.5000005@restena.lu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: gaobo Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.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, 12 Jul 2013 10:17:36 -0000 Hi, Stefan Thanks for your comments.. And please see my reply in line. BR Li=20 >-----Original Message----- >From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On=20 >Behalf Of Stefan Winter >Sent: Friday, July 12, 2013 2:39 PM >To: radext@ietf.org >Subject: Re: [radext] FW: New Version Notification for=20 >draft-xue-radext-key-management-01.txt > >Hello, > >> There is a new version for RADIUS Extensions for Key Management in=20 >> WLAN >network. >> >> >> It is a general case that authenticator is deployed on gateway=20 >> instead of AC. So In this scenario, the encryption/decryption node =20 >> can't obtain Pairwise Master Key (PMK) information during Extensible=20 >> Authentication Protocol (EAP) procedure, it is not sufficient to=20 >> achieve traffic >encryption/decryption requirement in Wireless Local Area Network (WLAN)=20 >network. >> >> This document analyzes the requirement and issue for key management=20 >> that has arisen so far during authentication process in WLAN network. >> Meanwhile, the control messages for key management are defined. >> >> This drat is updated with China-telecom as co-author. >> Your comments are appreciated. > >When you submitted -00, you got substantial criticism as per the use=20 >cases for this document; the approach taken to offload the=20 >authenticator function to the SGW was seen as a rather odd move. >Now, in -01, you don't really react to this; the only statement in that=20 >direction I see is that you repeatedly make the assertion that "It is a=20 >general case in operators networks". >I simply doubt that this is generally true; merely making an unbacked=20 >assertion that it is so doesn't make it true. [xueli] I appreciated the comments to scenario to offload the authenticator= function to SGW. There are two reasons, which I clarified the scenario in the document versi= on 01 as : "In EAP framework, SGW could act as the Authenticator instead of AC because of several reasons. First of all, a powerful AC that aggregates the Authenticator function is not a appreciated choice for some operators. There are large numbers of AC devices in the operators existing network. The Authentication Server (AS) will overload the comm= unication with large numbers of AC devices if ACs acts as the Authenticator. On the other hand, SGW MUST support the RADIUS proxy function when AC acts as the Authenticator in EAP framework. In this scenario, both SGW and AC should be responsible for authentication procedure. For operators, it is cost in large-scale upgraded deployment." Meanwhile, this requirement is also mentioned in the draft " http://tools.i= etf.org/html/draft-cao-capwap-eap-00" It is described as "AR acts as authenticator in the EAP framework. After authentication, the = AR receives the EAP keying message for the session. But AC is supposed to delieve these keying messages to the AP, and AR has no standard interface to ship them to the AP or the AC. This is unacceptable in the scenario of EAP-based auto-authentication. " AR is the access router.=20 >I also can't help but notice that many of your normative references are=20 >old and obsolete. >* For key exchange, you reference an unapproved draft of IEEE-802.11i! >All of the features from that draft are meanwhile part of IEEE >802.11-2012 (and I hope you don't implement an old draft version in=20 >your products!). >* The next reference is the IEEE 802.1X version from 2001 - it has two=20 >successors meanwhile. >* RFC3576 is obsoleted by RFC5176. You mention both in the normative=20 >references; the main text uses the Authenticator field from 3576, but=20 >the type definition from 5176. That's probably an oversight; the=20 >calculation of Authenticator hasn't changed between the two revs. [xueli] thanks a lot.=20 802.11i is already approved in 2004. I am not sure why you say it is an una= pproved draft. For other references, I will update.=20 >Your security considerations are very inadequate. You simply state that=20 >the link between SGW and AC must be secure. From my (skimming)=20 >understanding of the draft, these two entities are not typically=20 >located inside the same premises, right? If they aren't, simply=20 >assuming securtiy on the link blindly is an extremely bad idea. IMHO,=20 >not protecting the keys and sending them in the clear is a no-go. [xueli] I don't think I mentioned that the link between AC and SGW is secur= e.=20 I have already recognized the key transported in the link must be encrypted= .=20 > >In the same section, you state roughly "Oh, if you need security, use=20 >IPSec!" - which is too superficial a statement to be useful; you should=20 >at least discuss how the IPSec endpoints are supposed to negotiate=20 >IPSec keying material to be able to communicate confidentially. [xueli] I totally agree with you and this part of work will be presented in= the next version.=20 > >BTW, if I recall correctly your draft was motivated by the "fact" (or=20 >so you presented it) that changing the AC to take over the=20 >authenticator role is too costly in terms of implementation or=20 >computing power. Now in security considerations, you generously=20 >recommend to implement the entire IPSec stack on the AC. I would argue=20 >that it's easier to implement the authenticator function of IEEE 802.1X th= an it is to implement IPSec. [xueli] I see. I just give a possible solution to address the security prob= lem. I agree that there could be more optimal solutions.=20 I would like to mention during the meeting and collect comments from the se= curity guys. Is that fair enough? > >The same section also suggests MD5 encryption/decryption. Here I am=20 >completely lost. The KoA and KoA ACK/NAK messages are RADIUS packets,=20 >right? As such they are always making use of the MD5 shared secret for=20 >integrity checks; if you want to protect the 802.11 keying material=20 >then you could use encrypted attributes with the same shared secret=20 >(that's the way how User-Password gets encrypted). With little to no=20 >additional implementation cost. If that's what you want - don't put a=20 >half-sentence into security considerations. *Write in the spec itself=20 >that the attribute is to be encrypted*. > [xueli] Yes, that is what I want to do.. I will clarify it. >BTW, even if you do write that in the spec, you'd still get a beating=20 >for suggesting MD5 RADIUS crypto in 2013. This encryption method is not=20 >contemporary. [xueli] Thank you for your advice.=20 Security is important part of this work.=20 It is my plan to go into technique details and give a more concrete securit= y solution by the next IETF meeting.=20 >Greetings, > >Stefan Winter > >-- >Stefan WINTER >Ingenieur de Recherche >Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale= et=20 >de la Recherche 6, rue Richard Coudenhove-Kalergi >L-1359 Luxembourg > >Tel: +352 424409 1 >Fax: +352 422473 From stefan.winter@restena.lu Fri Jul 12 04:31:28 2013 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 1472D21F9D80 for ; Fri, 12 Jul 2013 04:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 lZmSBjsDyCKX for ; Fri, 12 Jul 2013 04:31:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A612921F9D71 for ; Fri, 12 Jul 2013 04:31:26 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 060ED10581; Fri, 12 Jul 2013 13:31:25 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id EE0F61057F; Fri, 12 Jul 2013 13:31:24 +0200 (CEST) Message-ID: <51DFE908.9020008@restena.lu> Date: Fri, 12 Jul 2013 13:31:20 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Xueli References: <01FE63842C181246BBE4CF183BD159B448525BE5@NKGEML512-MBS.china.huawei.com> <51DFA493.5000005@restena.lu> <01FE63842C181246BBE4CF183BD159B448525CC5@NKGEML512-MBS.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B448525CC5@NKGEML512-MBS.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FPUGBUVXLAALGATCUUNM" X-Virus-Scanned: ClamAV Cc: "radext@ietf.org" , gaobo Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.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, 12 Jul 2013 11:31:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FPUGBUVXLAALGATCUUNM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> When you submitted -00, you got substantial criticism as per the use=20 >> cases for this document; the approach taken to offload the=20 >> authenticator function to the SGW was seen as a rather odd move. >> Now, in -01, you don't really react to this; the only statement in tha= t=20 >> direction I see is that you repeatedly make the assertion that "It is = a=20 >> general case in operators networks". >=20 >> I simply doubt that this is generally true; merely making an unbacked = >> assertion that it is so doesn't make it true. >=20 > [xueli] I appreciated the comments to scenario to offload the authentic= ator function to SGW. > There are two reasons, which I clarified the scenario in the document v= ersion 01 as : > "In EAP framework, SGW could act as the Authenticator instead of AC > because of several reasons. First of all, a powerful AC that > aggregates the Authenticator function is not a appreciated choice fo= r > some operators. There are large numbers of AC devices in the operato= rs > existing network. The Authentication Server (AS) will overload the = communication with large > numbers of AC devices if ACs acts as the Authenticator. This is the point where you lost me. Why is it "not appreciated" by operators? Sometimes you need to add new functionality to a device; the vendor writes code and provides firmware updates for these devices. Deployers apply the firmware update. That is a normal part of day-to-day operations in a network. I don't understand why you go out of your way to define an entire new *protocol* just for the convenience of saving a firmware update in a fleet of equipment. (And not even that is true, see below) At other places you write that it's difficult to implement in the authenticators and more convenient to do it in a central place. My only reply to this: yes, it's work and it needs to be done. Get over it. I don't see how the hassle of defining a new protocol - which also needs to get implemented, and firmware updated to support it - is in any way easier or more useful. I also don't buy that the AC authentication traffic will "overload the communication". AAA traffic is only an insignificant portion of traffic of an edge network - the payload generated by the user after authenticating is many orders of magnitude higher. If you are concerned about AAA packets getting lost if the link gets full, use traffic priorisation, i.e. put the AAA traffic in a separate queue which has priority over normal IP payloads. That's how "everyone else" does it as well. > On the other > hand, SGW MUST support the RADIUS proxy function when AC acts as the= > Authenticator in EAP framework. In this scenario, both SGW and AC > should be responsible for authentication procedure. I also don't see why the SGW needs to be a RADIUS proxy. If the authenticators are implemented correctly, they implement the RADIUS client side and can be configured to contact any RADIUS server they want. If traffic is administratively *wanted* to flow by the SGW, then yes, the SGW must also implement the RADIUS protocol. If not, the authenticators can talk to the real target, the authentication server, on their own. So this is not a protocol problem, it is just a deployment choice. > For operators, > it is cost in large-scale upgraded deployment." Your KoA is also new code that both the ACs and the SGW need to understand. An upgrade is necessary either way; so your argument is null.= > Meanwhile, this requirement is also mentioned in the draft " http://too= ls.ietf.org/html/draft-cao-capwap-eap-00" >=20 > It is described as > "AR acts as authenticator in the EAP framework. After authentication, = the AR > receives the EAP keying message for the session. But AC is supposed= > to delieve these keying messages to the AP, and AR has no standard > interface to ship them to the AP or the AC. This is unacceptable in= > the scenario of EAP-based auto-authentication. > " AR is the access router.=20 >=20 >=20 >> I also can't help but notice that many of your normative references ar= e=20 >> old and obsolete. >> * For key exchange, you reference an unapproved draft of IEEE-802.11i!= >> All of the features from that draft are meanwhile part of IEEE >> 802.11-2012 (and I hope you don't implement an old draft version in=20 >> your products!). >> * The next reference is the IEEE 802.1X version from 2001 - it has two= =20 >> successors meanwhile. >> * RFC3576 is obsoleted by RFC5176. You mention both in the normative=20 >> references; the main text uses the Authenticator field from 3576, but = >> the type definition from 5176. That's probably an oversight; the=20 >> calculation of Authenticator hasn't changed between the two revs. >=20 > [xueli] thanks a lot.=20 > 802.11i is already approved in 2004. I am not sure why you say it is an= unapproved draft. You should read your own draft again. I *quoted* you with the word Unapproved. If I may *quote* your Normative References section: [IEEE-802.11i] , "Institute of Electrical and Electronics Engineers, "Unapproved Draft Supplement to Standard for Telecommunications and Information Exchange Between Systems-LAN/MAN Specific Requirements -Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security" "", September 2004. If you don't want to talk about an unapproved draft from 2004, then ... don't. Just update your text. >> Your security considerations are very inadequate. You simply state tha= t=20 >> the link between SGW and AC must be secure. From my (skimming)=20 >> understanding of the draft, these two entities are not typically=20 >> located inside the same premises, right? If they aren't, simply=20 >> assuming securtiy on the link blindly is an extremely bad idea. IMHO, = >> not protecting the keys and sending them in the clear is a no-go. > [xueli] I don't think I mentioned that the link between AC and SGW is s= ecure.=20 > I have already recognized the key transported in the link must be encry= pted.=20 You write that security must be guaranteed. Then you state that "if there is a security requirement". Why the "if"? - security *is* a requirement, you are transporting secrets. The first sentence of the section says that itself. You don't say anything about a MUST encryption. You hide it behind an "if" conditional. I understood this such as that there are cases where the if isn't true; which means there is no encryption on the wire. If you still guarantee security in that case, that can only be because the link in itself is for some unexplained reason secure. I suggest you fix your wording and be *much* more verbose. >> In the same section, you state roughly "Oh, if you need security, use = >> IPSec!" - which is too superficial a statement to be useful; you shoul= d=20 >> at least discuss how the IPSec endpoints are supposed to negotiate=20 >> IPSec keying material to be able to communicate confidentially. >=20 > [xueli] I totally agree with you and this part of work will be presente= d in the next version.=20 >> >> BTW, if I recall correctly your draft was motivated by the "fact" (or = >> so you presented it) that changing the AC to take over the=20 >> authenticator role is too costly in terms of implementation or=20 >> computing power. Now in security considerations, you generously=20 >> recommend to implement the entire IPSec stack on the AC. I would argue= =20 >> that it's easier to implement the authenticator function of IEEE 802.1= X than it is to implement IPSec. >=20 > [xueli] I see. I just give a possible solution to address the security = problem. I agree that there could be more optimal solutions.=20 > I would like to mention during the meeting and collect comments from th= e security guys. Is that fair enough? >=20 >> >> The same section also suggests MD5 encryption/decryption. Here I am=20 >> completely lost. The KoA and KoA ACK/NAK messages are RADIUS packets, = >> right? As such they are always making use of the MD5 shared secret for= =20 >> integrity checks; if you want to protect the 802.11 keying material=20 >> then you could use encrypted attributes with the same shared secret=20 >> (that's the way how User-Password gets encrypted). With little to no=20 >> additional implementation cost. If that's what you want - don't put a = >> half-sentence into security considerations. *Write in the spec itself = >> that the attribute is to be encrypted*. >> > [xueli] Yes, that is what I want to do.. I will clarify it. >=20 >> BTW, even if you do write that in the spec, you'd still get a beating = >> for suggesting MD5 RADIUS crypto in 2013. This encryption method is no= t=20 >> contemporary. >=20 > [xueli] Thank you for your advice.=20 > Security is important part of this work.=20 > It is my plan to go into technique details and give a more concrete sec= urity solution by the next IETF meeting.=20 It is up to the chairs to distribute speaking time. I for one would welcome if we could first clear up the very first topic area: what is the *use* of your designed protocol. As I wrote earlier in my mail I see many reasons why your thinking that the authenticator function should be split and put into the SGW is flawed in the first place. If it is, there is no need to further discuss technical details of the draft. Greetings, Stefan Winter >=20 >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et=20 >> 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 --=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 ------enig2FPUGBUVXLAALGATCUUNM 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHf6QwACgkQ+jm90f8eFWb3WACfbsk7oPGSutmEcDCYSOLalRHy jeYAn32oDdSubSv6Z42leJwTGGop8qpW =JAvY -----END PGP SIGNATURE----- ------enig2FPUGBUVXLAALGATCUUNM-- From internet-drafts@ietf.org Fri Jul 12 05:17:56 2013 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 6472B21E808F; Fri, 12 Jul 2013 05:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-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 mAxxO3u7LyCd; Fri, 12 Jul 2013 05:17:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA1821E8093; Fri, 12 Jul 2013 05:17:54 -0700 (PDT) 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: 4.51.p2 Message-ID: <20130712121754.29674.6842.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 05:17:54 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-06.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, 12 Jul 2013 12:17:56 -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 the IE= TF. Title : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-06.txt Pages : 22 Date : 2013-07-12 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dtls-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gaobo@sttri.com.cn Fri Jul 12 07:17:48 2013 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 B0A9821F9A1B for ; Fri, 12 Jul 2013 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.494 X-Spam-Level: X-Spam-Status: No, score=0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, SARE_SUB_ENC_UTF8=0.152] 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 qHyCdvqq2pNy for ; Fri, 12 Jul 2013 07:17:44 -0700 (PDT) Received: from corp.21cn.com (corp.forptr.21cn.com [121.14.129.40]) by ietfa.amsl.com (Postfix) with ESMTP id A643A21F9BEB for ; Fri, 12 Jul 2013 07:17:41 -0700 (PDT) HMM_SOURCE_IP: 10.27.101.9:38719.1200190524 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from gaobo-nb (unknown [10.27.101.9]) by corp.21cn.com (HERMES) with ESMTP id C63E31A481A; Fri, 12 Jul 2013 22:17:33 +0800 (CST) Received: from gaobo-nb ([114.91.154.127]) by 21CN-entas9(MEDUSA 10.27.101.9) with ESMTP id 1373638651.22773 for xueli@huawei.com ; Fri Jul 12 22:17:39 2013 0/X-Total-Score: 0: 2/X-Total-Score: -120: 3/X-Brightmail-Tracker: AAAAAA== X-FILTER-SCORE: to=<9996868d8a6189968298868a4f84908e94958687828f4f988a8f9586936193869495868f824f8d96938285869995618a8695874f909388>, score=<1373638659AgAXrg9UYQdKAAAAAXAArAMa6lM+wHbt4aaaaa6aalaa> X-REAL-FROM: gaobo@sttri.com.cn X-Receive-IP: 114.91.154.127 gaobo@sttri.com.cn Date: Fri, 12 Jul 2013 22:17:35 +0800 From: "=?utf-8?B?Z2FvYm8=?=" To: "=?utf-8?B?WHVlbGk=?=" , "=?utf-8?B?U3RlZmFuIFdpbnRlcg==?=" , "=?utf-8?B?cmFkZXh0QGlldGYub3Jn?=" References: <01FE63842C181246BBE4CF183BD159B448525BE5@NKGEML512-MBS.china.huawei.com>, <51DFA493.5000005@restena.lu> Message-ID: <201307122217319377026@sttri.com.cn> X-mailer: Foxmail 6, 15, 201, 21 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon573820155088_=====" X-Mailman-Approved-At: Sun, 14 Jul 2013 13:19:00 -0700 Subject: Re: [radext] =?utf-8?q?FW=3A_New_Version_Notification_fordraft-xue-ra?= =?utf-8?q?dext-key-management-01=2Etxt?= 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, 13 Jul 2013 01:12:01 -0000 This is a multi-part message in MIME format. --=====003_Dragon573820155088_===== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAgSSBzdXBwbGVtZW50IG15IHZpZXcgYXMgZm9sbG93czoNCkZvciB0aGUgdHJhZGl0aW9uYWwg b3BlcmF0b3JzLCBXTEFOIG5ldHdvcmsgaXMgc3RhY2tlZCBpbiB0aGUgZXhpc3RpbmcgYnJvYWRi YW5kIG5ldHdvcmsuIFNHVyBpcyByZXNwb25zaWJsZSBmb3IgdGhlIGJyb2FkYmFuZCB1c2VyIGF1 dGhlbnRpY2F0aW9uLCBhZGRyZXNzIGFzc2lnbm1lbnQsIHVzZXIgbWFuYWdlbWVudCBhbmQgb3Ro ZXIgZnVuY3Rpb25zLiBJbiB0aGUgV0xBTiBESENQK1BvcnRhbCB1c2VyIGF1dGhlbnRpY2F0aW9u LCBTR1cgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBhbGxvY2F0aW9uIG9mIFdMQU4gYWRkcmVzcywg dXNlciBhdXRoZW50aWNhdGlvbiBhbmQgdXNlciBtYW5hZ2VtZW50LCBhbmQgQUMgaXMgb25seSBy ZXNwb25zaWJsZSBmb3IgcmFkaW8gcmVzb3VyY2UgbWFuYWdlbWVudCBhbmQgQVAgbWFuYWdlbWVu dC4gRm9yIEVBUCBhdXRoZW50aWNhdGlvbiwgQUMgYXMgdGhlIGF1dGhlbnRpY2F0aW9uIHBvaW50 LCBTR1cgYWN0cyBhcyBSYWRpdXMgUHJveHkuIEF0IHRoZSBzYW1lIHRpbWUsIFNHVyBpcyByZXNw b25zaWJsZSBmb3IgdGhlIHVzZXIgRUFQIGFkZHJlc3MgYWxsb2NhdGlvbiBhbmQgdXNlciBtYW5h Z2VtZW50LiBUaGlzIGNvbmZpZ3VyYXRpb24gZW5hYmxlcyB0aGUgbmV0d29yayBjb21wbGV4LCBh bmQgbWFpbnRlbmFuY2Ugb2YgbmV0d29yayBtYW5hZ2VtZW50IGJlY29tZXMgY29tcGxleC4gSWYg dGhlIFNHVyBhY3RzIGFzIEVBUCBhdXRoZW50aWNhdGlvbiwgdGhlIG5ldHdvcmsgYmVjb21lcyBz aW1wbGUsIGJ1dCB3ZSBuZWVkIHRvIHNvbHZlIHRoZSBQTUsgZXhjaGFuZ2UgYmV0d2VlbiBTR1cg YW5kIEFDLg0KQnkgdGhlIHdheSwgU0dXIGFjdHMgYXMgdGhlIEVBUCBhdXRoZW50aWNhdGlvbiwg Zm9yIHRoZSBvcGVyYXRvcnMgbW9yZSB0aGFuIG9uZSBvcHRpb24uDQpUaGFua3MhDQogICANCiAg IEJvIEdhbw0KICAgQ2hpbmEgVGVsZWNvbQ0KICAgTm8uIDE4MzUsIFNvdXRoIFB1ZG9uZyBSb2Fk DQogICBTaGFuZ2hhaSAgMjAwMTIyDQogICBDaGluYQ0KDQogDQoNCg0KDQrlj5Hku7bkurrvvJog WHVlbGkgDQrlj5HpgIHml7bpl7TvvJogMjAxMy0wNy0xMiAgMTg6MTc6MzIgDQrmlLbku7bkurrv vJogU3RlZmFuIFdpbnRlcjsgcmFkZXh0QGlldGYub3JnIA0K5oqE6YCB77yaIGdhb2JvIA0K5Li7 6aKY77yaIFJFOiBbcmFkZXh0XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0 LXh1ZS1yYWRleHQta2V5LW1hbmFnZW1lbnQtMDEudHh0IA0KIA0KSGksIFN0ZWZhbg0KVGhhbmtz IGZvciB5b3VyIGNvbW1lbnRzLi4NCkFuZCBwbGVhc2Ugc2VlIG15IHJlcGx5IGluIGxpbmUuDQpC Ug0KTGkgDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiByYWRleHQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj5CZWhhbGYg T2YgU3RlZmFuIFdpbnRlcg0KPlNlbnQ6IEZyaWRheSwgSnVseSAxMiwgMjAxMyAyOjM5IFBNDQo+ VG86IHJhZGV4dEBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciANCj5kcmFmdC14dWUtcmFkZXh0LWtleS1tYW5hZ2VtZW50LTAx LnR4dA0KPg0KPkhlbGxvLA0KPg0KPj4gVGhlcmUgaXMgYSBuZXcgdmVyc2lvbiBmb3IgUkFESVVT IEV4dGVuc2lvbnMgZm9yIEtleSBNYW5hZ2VtZW50IGluIA0KPj4gV0xBTg0KPm5ldHdvcmsuDQo+ Pg0KPj4NCj4+IEl0IGlzIGEgZ2VuZXJhbCBjYXNlIHRoYXQgYXV0aGVudGljYXRvciBpcyBkZXBs b3llZCBvbiBnYXRld2F5IA0KPj4gaW5zdGVhZCBvZiBBQy4gU28gSW4gdGhpcyBzY2VuYXJpbywg dGhlIGVuY3J5cHRpb24vZGVjcnlwdGlvbiBub2RlICANCj4+IGNhbid0IG9idGFpbiBQYWlyd2lz ZSBNYXN0ZXIgS2V5IChQTUspIGluZm9ybWF0aW9uIGR1cmluZyBFeHRlbnNpYmxlIA0KPj4gQXV0 aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkgcHJvY2VkdXJlLCBpdCBpcyBub3Qgc3VmZmljaWVu dCB0byANCj4+IGFjaGlldmUgdHJhZmZpYw0KPmVuY3J5cHRpb24vZGVjcnlwdGlvbiByZXF1aXJl bWVudCBpbiBXaXJlbGVzcyBMb2NhbCBBcmVhIE5ldHdvcmsgKFdMQU4pIA0KPm5ldHdvcmsuDQo+ Pg0KPj4gVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgcmVxdWlyZW1lbnQgYW5kIGlzc3VlIGZv ciBrZXkgbWFuYWdlbWVudCANCj4+IHRoYXQgaGFzIGFyaXNlbiBzbyBmYXIgZHVyaW5nIGF1dGhl bnRpY2F0aW9uIHByb2Nlc3MgaW4gV0xBTiBuZXR3b3JrLg0KPj4gTWVhbndoaWxlLCB0aGUgY29u dHJvbCBtZXNzYWdlcyBmb3Iga2V5IG1hbmFnZW1lbnQgYXJlIGRlZmluZWQuDQo+Pg0KPj4gVGhp cyBkcmF0IGlzIHVwZGF0ZWQgd2l0aCBDaGluYS10ZWxlY29tIGFzIGNvLWF1dGhvci4NCj4+IFlv dXIgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVkLg0KPg0KPldoZW4geW91IHN1Ym1pdHRlZCAtMDAs IHlvdSBnb3Qgc3Vic3RhbnRpYWwgY3JpdGljaXNtIGFzIHBlciB0aGUgdXNlIA0KPmNhc2VzIGZv ciB0aGlzIGRvY3VtZW50OyB0aGUgYXBwcm9hY2ggdGFrZW4gdG8gb2ZmbG9hZCB0aGUgDQo+YXV0 aGVudGljYXRvciBmdW5jdGlvbiB0byB0aGUgU0dXIHdhcyBzZWVuIGFzIGEgcmF0aGVyIG9kZCBt b3ZlLg0KPk5vdywgaW4gLTAxLCB5b3UgZG9uJ3QgcmVhbGx5IHJlYWN0IHRvIHRoaXM7IHRoZSBv bmx5IHN0YXRlbWVudCBpbiB0aGF0IA0KPmRpcmVjdGlvbiBJIHNlZSBpcyB0aGF0IHlvdSByZXBl YXRlZGx5IG1ha2UgdGhlIGFzc2VydGlvbiB0aGF0ICJJdCBpcyBhIA0KPmdlbmVyYWwgY2FzZSBp biBvcGVyYXRvcnMgbmV0d29ya3MiLg0KPkkgc2ltcGx5IGRvdWJ0IHRoYXQgdGhpcyBpcyBnZW5l cmFsbHkgdHJ1ZTsgbWVyZWx5IG1ha2luZyBhbiB1bmJhY2tlZCANCj5hc3NlcnRpb24gdGhhdCBp dCBpcyBzbyBkb2Vzbid0IG1ha2UgaXQgdHJ1ZS4NClt4dWVsaV0gSSBhcHByZWNpYXRlZCB0aGUg Y29tbWVudHMgdG8gc2NlbmFyaW8gdG8gb2ZmbG9hZCB0aGUgYXV0aGVudGljYXRvciBmdW5jdGlv biB0byBTR1cuDQpUaGVyZSBhcmUgdHdvIHJlYXNvbnMsIHdoaWNoIEkgY2xhcmlmaWVkIHRoZSBz Y2VuYXJpbyBpbiB0aGUgZG9jdW1lbnQgdmVyc2lvbiAwMSBhcyA6DQogICAiSW4gRUFQIGZyYW1l d29yaywgU0dXIGNvdWxkIGFjdCBhcyB0aGUgQXV0aGVudGljYXRvciBpbnN0ZWFkIG9mIEFDDQog ICBiZWNhdXNlIG9mIHNldmVyYWwgcmVhc29ucy4gIEZpcnN0IG9mIGFsbCwgYSBwb3dlcmZ1bCBB QyB0aGF0DQogICBhZ2dyZWdhdGVzIHRoZSBBdXRoZW50aWNhdG9yIGZ1bmN0aW9uIGlzIG5vdCBh IGFwcHJlY2lhdGVkIGNob2ljZSBmb3INCiAgIHNvbWUgb3BlcmF0b3JzLiBUaGVyZSBhcmUgbGFy Z2UgbnVtYmVycyBvZiBBQyBkZXZpY2VzIGluIHRoZSBvcGVyYXRvcnMNCiAgIGV4aXN0aW5nIG5l dHdvcmsuICBUaGUgQXV0aGVudGljYXRpb24gU2VydmVyIChBUykgd2lsbCBvdmVybG9hZCB0aGUg Y29tbXVuaWNhdGlvbiB3aXRoIGxhcmdlDQogICBudW1iZXJzIG9mIEFDIGRldmljZXMgaWYgQUNz IGFjdHMgYXMgdGhlIEF1dGhlbnRpY2F0b3IuICBPbiB0aGUgb3RoZXINCiAgIGhhbmQsIFNHVyBN VVNUIHN1cHBvcnQgdGhlIFJBRElVUyBwcm94eSBmdW5jdGlvbiB3aGVuIEFDIGFjdHMgYXMgdGhl DQogICBBdXRoZW50aWNhdG9yIGluIEVBUCBmcmFtZXdvcmsuICBJbiB0aGlzIHNjZW5hcmlvLCBi b3RoIFNHVyBhbmQgQUMNCiAgIHNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgYXV0aGVudGljYXRp b24gcHJvY2VkdXJlLiAgRm9yIG9wZXJhdG9ycywNCiAgIGl0IGlzIGNvc3QgaW4gbGFyZ2Utc2Nh bGUgdXBncmFkZWQgZGVwbG95bWVudC4iDQpNZWFud2hpbGUsIHRoaXMgcmVxdWlyZW1lbnQgaXMg YWxzbyBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0ICIgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtY2FvLWNhcHdhcC1lYXAtMDAiDQpJdCBpcyBkZXNjcmliZWQgYXMNCiJBUiBhY3RzIGFz IGF1dGhlbnRpY2F0b3IgaW4gdGhlIEVBUCBmcmFtZXdvcmsuICBBZnRlciBhdXRoZW50aWNhdGlv biwgdGhlIEFSDQogICByZWNlaXZlcyB0aGUgRUFQIGtleWluZyBtZXNzYWdlIGZvciB0aGUgc2Vz c2lvbi4gIEJ1dCBBQyBpcyBzdXBwb3NlZA0KICAgdG8gZGVsaWV2ZSB0aGVzZSBrZXlpbmcgbWVz c2FnZXMgdG8gdGhlIEFQLCBhbmQgQVIgaGFzIG5vIHN0YW5kYXJkDQogICBpbnRlcmZhY2UgdG8g c2hpcCB0aGVtIHRvIHRoZSBBUCBvciB0aGUgQUMuICBUaGlzIGlzIHVuYWNjZXB0YWJsZSBpbg0K ICAgdGhlIHNjZW5hcmlvIG9mIEVBUC1iYXNlZCBhdXRvLWF1dGhlbnRpY2F0aW9uLg0KIiBBUiBp cyB0aGUgYWNjZXNzIHJvdXRlci4gDQo+SSBhbHNvIGNhbid0IGhlbHAgYnV0IG5vdGljZSB0aGF0 IG1hbnkgb2YgeW91ciBub3JtYXRpdmUgcmVmZXJlbmNlcyBhcmUgDQo+b2xkIGFuZCBvYnNvbGV0 ZS4NCj4qIEZvciBrZXkgZXhjaGFuZ2UsIHlvdSByZWZlcmVuY2UgYW4gdW5hcHByb3ZlZCBkcmFm dCBvZiBJRUVFLTgwMi4xMWkhDQo+QWxsIG9mIHRoZSBmZWF0dXJlcyBmcm9tIHRoYXQgZHJhZnQg YXJlIG1lYW53aGlsZSBwYXJ0IG9mIElFRUUNCj44MDIuMTEtMjAxMiAoYW5kIEkgaG9wZSB5b3Ug ZG9uJ3QgaW1wbGVtZW50IGFuIG9sZCBkcmFmdCB2ZXJzaW9uIGluIA0KPnlvdXIgcHJvZHVjdHMh KS4NCj4qIFRoZSBuZXh0IHJlZmVyZW5jZSBpcyB0aGUgSUVFRSA4MDIuMVggdmVyc2lvbiBmcm9t IDIwMDEgLSBpdCBoYXMgdHdvIA0KPnN1Y2Nlc3NvcnMgbWVhbndoaWxlLg0KPiogUkZDMzU3NiBp cyBvYnNvbGV0ZWQgYnkgUkZDNTE3Ni4gWW91IG1lbnRpb24gYm90aCBpbiB0aGUgbm9ybWF0aXZl IA0KPnJlZmVyZW5jZXM7IHRoZSBtYWluIHRleHQgdXNlcyB0aGUgQXV0aGVudGljYXRvciBmaWVs ZCBmcm9tIDM1NzYsIGJ1dCANCj50aGUgdHlwZSBkZWZpbml0aW9uIGZyb20gNTE3Ni4gVGhhdCdz IHByb2JhYmx5IGFuIG92ZXJzaWdodDsgdGhlIA0KPmNhbGN1bGF0aW9uIG9mIEF1dGhlbnRpY2F0 b3IgaGFzbid0IGNoYW5nZWQgYmV0d2VlbiB0aGUgdHdvIHJldnMuDQpbeHVlbGldIHRoYW5rcyBh IGxvdC4gDQo4MDIuMTFpIGlzIGFscmVhZHkgYXBwcm92ZWQgaW4gMjAwNC4gSSBhbSBub3Qgc3Vy ZSB3aHkgeW91IHNheSBpdCBpcyBhbiB1bmFwcHJvdmVkIGRyYWZ0Lg0KRm9yIG90aGVyIHJlZmVy ZW5jZXMsIEkgd2lsbCB1cGRhdGUuIA0KPllvdXIgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJl IHZlcnkgaW5hZGVxdWF0ZS4gWW91IHNpbXBseSBzdGF0ZSB0aGF0IA0KPnRoZSBsaW5rIGJldHdl ZW4gU0dXIGFuZCBBQyBtdXN0IGJlIHNlY3VyZS4gRnJvbSBteSAoc2tpbW1pbmcpIA0KPnVuZGVy c3RhbmRpbmcgb2YgdGhlIGRyYWZ0LCB0aGVzZSB0d28gZW50aXRpZXMgYXJlIG5vdCB0eXBpY2Fs bHkgDQo+bG9jYXRlZCBpbnNpZGUgdGhlIHNhbWUgcHJlbWlzZXMsIHJpZ2h0PyBJZiB0aGV5IGFy ZW4ndCwgc2ltcGx5IA0KPmFzc3VtaW5nIHNlY3VydGl5IG9uIHRoZSBsaW5rIGJsaW5kbHkgaXMg YW4gZXh0cmVtZWx5IGJhZCBpZGVhLiBJTUhPLCANCj5ub3QgcHJvdGVjdGluZyB0aGUga2V5cyBh bmQgc2VuZGluZyB0aGVtIGluIHRoZSBjbGVhciBpcyBhIG5vLWdvLg0KW3h1ZWxpXSBJIGRvbid0 IHRoaW5rIEkgbWVudGlvbmVkIHRoYXQgdGhlIGxpbmsgYmV0d2VlbiBBQyBhbmQgU0dXIGlzIHNl Y3VyZS4gDQpJIGhhdmUgYWxyZWFkeSByZWNvZ25pemVkIHRoZSBrZXkgdHJhbnNwb3J0ZWQgaW4g dGhlIGxpbmsgbXVzdCBiZSBlbmNyeXB0ZWQuIA0KPg0KPkluIHRoZSBzYW1lIHNlY3Rpb24sIHlv dSBzdGF0ZSByb3VnaGx5ICJPaCwgaWYgeW91IG5lZWQgc2VjdXJpdHksIHVzZSANCj5JUFNlYyEi IC0gd2hpY2ggaXMgdG9vIHN1cGVyZmljaWFsIGEgc3RhdGVtZW50IHRvIGJlIHVzZWZ1bDsgeW91 IHNob3VsZCANCj5hdCBsZWFzdCBkaXNjdXNzIGhvdyB0aGUgSVBTZWMgZW5kcG9pbnRzIGFyZSBz dXBwb3NlZCB0byBuZWdvdGlhdGUgDQo+SVBTZWMga2V5aW5nIG1hdGVyaWFsIHRvIGJlIGFibGUg dG8gY29tbXVuaWNhdGUgY29uZmlkZW50aWFsbHkuDQpbeHVlbGldIEkgdG90YWxseSBhZ3JlZSB3 aXRoIHlvdSBhbmQgdGhpcyBwYXJ0IG9mIHdvcmsgd2lsbCBiZSBwcmVzZW50ZWQgaW4gdGhlIG5l eHQgdmVyc2lvbi4gDQo+DQo+QlRXLCBpZiBJIHJlY2FsbCBjb3JyZWN0bHkgeW91ciBkcmFmdCB3 YXMgbW90aXZhdGVkIGJ5IHRoZSAiZmFjdCIgKG9yIA0KPnNvIHlvdSBwcmVzZW50ZWQgaXQpIHRo YXQgY2hhbmdpbmcgdGhlIEFDIHRvIHRha2Ugb3ZlciB0aGUgDQo+YXV0aGVudGljYXRvciByb2xl IGlzIHRvbyBjb3N0bHkgaW4gdGVybXMgb2YgaW1wbGVtZW50YXRpb24gb3IgDQo+Y29tcHV0aW5n IHBvd2VyLiBOb3cgaW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHlvdSBnZW5lcm91c2x5IA0K PnJlY29tbWVuZCB0byBpbXBsZW1lbnQgdGhlIGVudGlyZSBJUFNlYyBzdGFjayBvbiB0aGUgQUMu IEkgd291bGQgYXJndWUgDQo+dGhhdCBpdCdzIGVhc2llciB0byBpbXBsZW1lbnQgdGhlIGF1dGhl bnRpY2F0b3IgZnVuY3Rpb24gb2YgSUVFRSA4MDIuMVggdGhhbiBpdCBpcyB0byBpbXBsZW1lbnQg SVBTZWMuDQpbeHVlbGldIEkgc2VlLiBJIGp1c3QgZ2l2ZSBhIHBvc3NpYmxlIHNvbHV0aW9uIHRv IGFkZHJlc3MgdGhlIHNlY3VyaXR5IHByb2JsZW0uIEkgYWdyZWUgdGhhdCB0aGVyZSBjb3VsZCBi ZSBtb3JlIG9wdGltYWwgc29sdXRpb25zLiANCkkgd291bGQgbGlrZSB0byBtZW50aW9uIGR1cmlu ZyB0aGUgbWVldGluZyBhbmQgY29sbGVjdCBjb21tZW50cyBmcm9tIHRoZSBzZWN1cml0eSBndXlz LiBJcyB0aGF0IGZhaXIgZW5vdWdoPw0KPg0KPlRoZSBzYW1lIHNlY3Rpb24gYWxzbyBzdWdnZXN0 cyBNRDUgZW5jcnlwdGlvbi9kZWNyeXB0aW9uLiBIZXJlIEkgYW0gDQo+Y29tcGxldGVseSBsb3N0 LiBUaGUgS29BIGFuZCBLb0EgQUNLL05BSyBtZXNzYWdlcyBhcmUgUkFESVVTIHBhY2tldHMsIA0K PnJpZ2h0PyBBcyBzdWNoIHRoZXkgYXJlIGFsd2F5cyBtYWtpbmcgdXNlIG9mIHRoZSBNRDUgc2hh cmVkIHNlY3JldCBmb3IgDQo+aW50ZWdyaXR5IGNoZWNrczsgaWYgeW91IHdhbnQgdG8gcHJvdGVj dCB0aGUgODAyLjExIGtleWluZyBtYXRlcmlhbCANCj50aGVuIHlvdSBjb3VsZCB1c2UgZW5jcnlw dGVkIGF0dHJpYnV0ZXMgd2l0aCB0aGUgc2FtZSBzaGFyZWQgc2VjcmV0IA0KPih0aGF0J3MgdGhl IHdheSBob3cgVXNlci1QYXNzd29yZCBnZXRzIGVuY3J5cHRlZCkuIFdpdGggbGl0dGxlIHRvIG5v IA0KPmFkZGl0aW9uYWwgaW1wbGVtZW50YXRpb24gY29zdC4gSWYgdGhhdCdzIHdoYXQgeW91IHdh bnQgLSBkb24ndCBwdXQgYSANCj5oYWxmLXNlbnRlbmNlIGludG8gc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMuICpXcml0ZSBpbiB0aGUgc3BlYyBpdHNlbGYgDQo+dGhhdCB0aGUgYXR0cmlidXRlIGlz IHRvIGJlIGVuY3J5cHRlZCouDQo+DQpbeHVlbGldIFllcywgdGhhdCBpcyB3aGF0IEkgd2FudCB0 byBkby4uIEkgd2lsbCBjbGFyaWZ5IGl0Lg0KPkJUVywgZXZlbiBpZiB5b3UgZG8gd3JpdGUgdGhh dCBpbiB0aGUgc3BlYywgeW91J2Qgc3RpbGwgZ2V0IGEgYmVhdGluZyANCj5mb3Igc3VnZ2VzdGlu ZyBNRDUgUkFESVVTIGNyeXB0byBpbiAyMDEzLiBUaGlzIGVuY3J5cHRpb24gbWV0aG9kIGlzIG5v dCANCj5jb250ZW1wb3JhcnkuDQpbeHVlbGldIFRoYW5rIHlvdSBmb3IgeW91ciBhZHZpY2UuIA0K U2VjdXJpdHkgaXMgaW1wb3J0YW50IHBhcnQgb2YgdGhpcyB3b3JrLiANCkl0IGlzIG15IHBsYW4g dG8gZ28gaW50byB0ZWNobmlxdWUgZGV0YWlscyBhbmQgZ2l2ZSBhIG1vcmUgY29uY3JldGUgc2Vj dXJpdHkgc29sdXRpb24gYnkgdGhlIG5leHQgSUVURiBtZWV0aW5nLiANCj5HcmVldGluZ3MsDQo+ DQo+U3RlZmFuIFdpbnRlcg0KPg0KPi0tDQo+U3RlZmFuIFdJTlRFUg0KPkluZ2VuaWV1ciBkZSBS ZWNoZXJjaGUNCj5Gb25kYXRpb24gUkVTVEVOQSAtIFLDqXNlYXUgVMOpbMOpaW5mb3JtYXRpcXVl IGRlIGwnRWR1Y2F0aW9uIE5hdGlvbmFsZSBldCANCj5kZSBsYSBSZWNoZXJjaGUgNiwgcnVlIFJp Y2hhcmQgQ291ZGVuaG92ZS1LYWxlcmdpDQo+TC0xMzU5IEx1eGVtYm91cmcNCj4NCj5UZWw6ICsz NTIgNDI0NDA5IDENCj5GYXg6ICszNTIgNDIyNDczDQo= --=====003_Dragon573820155088_===== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjYwMDAuMjEzNDIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZv bnQtZmFtaWx5OiDlrovkvZM7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVmVyZGFu YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBA5a6L5L2TOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpV U1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBj bSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlm eQ0KfQ0KTEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9O VC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMg TmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVY VC1KVVNUSUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBj bSAwY20gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1 c3RpZnkNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lDQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElP TjogdW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JB VElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjog cHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcg ew0KCUZPTlQtV0VJR0hUOiBub3JtYWw7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBu b3JtYWw7IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1z dHlsZS10eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNl Y3Rpb24xDQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0K CU1BUkdJTi1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9 DQpPTCB7DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglN QVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTjogMTBweDsgRk9OVC1GQU1JTFk6 IHZlcmRhbmEiPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+ DQo8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IExJTkUtSEVJ R0hUOiAxMnB0Ij48Rk9OVCANCmNvbG9yPSMwMDAwMDA+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxl PSJGT05ULUZBTUlMWTog5a6L5L2TOyBtc28tYmlkaS1mb250LXNpemU6IDEwLjVwdDsgbXNvLWJp ZGktZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZvbnQta2VybmluZzogMHB0Ij4mbmJzcDsmbmJz cDsgDQpJIHN1cHBsZW1lbnQgbXk8L1NQQU4+PFNQQU4gbGVmdC1wb3M9Ijl8MTIiIHJpZ2h0LXBv cz0iOXwxMiIgc3BhY2U9IjB8ICI+IHZpZXcgDQphcyBmb2xsb3dzOjwvU1BBTj48P3htbDpuYW1l c3BhY2UgcHJlZml4ID0gbyBucyA9IA0KInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl Om9mZmljZSIgLz48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFAgY2xhc3M9b3JkaW5h cnktb3V0cHV0dGFyZ2V0LW91dHB1dCANCnN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsgTUFSR0lO OiBhdXRvIDBjbTsgVEVYVC1JTkRFTlQ6IDguOXB0OyBtc28tY2hhci1pbmRlbnQtY291bnQ6IC44 NSI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1T SVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9u dC1zaXplOiAxMi4wcHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDlrovkvZMiPkZvciANCnRoZSB0 cmFkaXRpb25hbCBvcGVyYXRvcnMsPC9TUEFOPjwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPjxGT05U IGZhY2U95a6L5L2TIHNpemU9Mz4gDQo8L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJyI+PEZPTlQgDQpzaXplPTM+V0xBTiBu ZXR3b3JrIGlzPC9GT05UPjwvU1BBTj48Rk9OVCBmYWNlPeWui+S9kz48U1BBTiBsZWZ0LXBvcz0i MTN8MyIgDQpyaWdodC1wb3M9IjEzfDMiIHNwYWNlPSIwfCAiPjxGT05UIHNpemU9Mz4gc3RhY2tl ZDwvRk9OVD48L1NQQU4+PFNQQU4gDQpsZWZ0LXBvcz0iMTZ8OSIgcmlnaHQtcG9zPSIxNnw5IiBz cGFjZT0iMHwgIj48Rk9OVCBzaXplPTM+IA0KaTwvRk9OVD48L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1TSVpFOiAxMC41cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1zaXplOiAxMi4wcHQ7IG1zby1iaWRpLWZvbnQtZmFt aWx5OiDlrovkvZMiPm4gDQp0aGUgZXhpc3Rpbmc8L1NQQU4+PEZPTlQgZmFjZT3lrovkvZM+PEZP TlQgc2l6ZT0zPjxTUEFOIGxlZnQtcG9zPSIyNXw2IiANCnJpZ2h0LXBvcz0iMjV8NiIgc3BhY2U9 IjB8ICI+IGJyb2FkYmFuZDwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMzF8OSIgDQpyaWdodC1wb3M9 IjMxfDkiIHNwYWNlPSIwfCAiPiBuZXR3b3JrLiBTR1cgaXMgcmVzcG9uc2libGUgZm9yIHRoZTwv U1BBTj48U1BBTiANCmxlZnQtcG9zPSI5fDYiIHJpZ2h0LXBvcz0iOXw2IiBzcGFjZT0iMHwgIj4g YnJvYWRiYW5kPC9TUEFOPjxTUEFOIA0KbGVmdC1wb3M9IjE1fDE1IiByaWdodC1wb3M9IjE1fDE1 IiBzcGFjZT0iMHwgIj4gdXNlciBhdXRoZW50aWNhdGlvbjwvU1BBTj48U1BBTiANCmxlZnQtcG9z PSIzMHwzIiByaWdodC1wb3M9IjMwfDMiIHNwYWNlPSIiPiw8L1NQQU4+PFNQQU4gbGVmdC1wb3M9 IjMzfDEyIiANCnJpZ2h0LXBvcz0iMzN8MTIiIHNwYWNlPSIwfCAiPiBhZGRyZXNzIGFzc2lnbm1l bnQ8L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjQ1fDMiIA0KcmlnaHQtcG9zPSI0NXwzIiBzcGFjZT0i Ij4sPC9TUEFOPjxTUEFOIGxlZnQtcG9zPSI0OHwyMSIgcmlnaHQtcG9zPSI0OHwyMSIgDQpzcGFj ZT0iMHwgIj4gdXNlciBtYW5hZ2VtZW50IGFuZCBvdGhlciBmdW5jdGlvbnM8L1NQQU4+LiBJbiB0 aGUgV0xBTiBESENQK1BvcnRhbCANCnVzZXI8L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjI3fDYiIHJp Z2h0LXBvcz0iMjd8NiIgc3BhY2U9IjB8ICI+IA0KYXV0aGVudGljYXRpb248L1NQQU4+PFNQQU4g bGVmdC1wb3M9IjMzfDYiIHJpZ2h0LXBvcz0iMzN8NiIgc3BhY2U9IiI+LDwvU1BBTj4gDQpTR1cg aXMgcmVzcG9uc2libGUgZm9yIHRoZSBhbGxvY2F0aW9uPC9TUEFOPjxTUEFOIGxlZnQtcG9zPSI0 MHwzIiANCnJpZ2h0LXBvcz0iNDB8MyIgc3BhY2U9IjB8ICI+IG9mPC9TUEFOPjxTUEFOIGxlZnQt cG9zPSIxMnwzIiByaWdodC1wb3M9IjEyfDMiIA0Kc3BhY2U9IjB8ICI+IFdMQU48L1NQQU4+PFNQ QU4gbGVmdC1wb3M9IjI1fDMiIHJpZ2h0LXBvcz0iMjV8MyIgc3BhY2U9IjB8ICI+IA0KYWRkcmVz czwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMzR8NiIgcmlnaHQtcG9zPSIzNHw2IiBzcGFjZT0iIj4s PC9TUEFOPjxTUEFOIA0KbGVmdC1wb3M9IjE1fDQiIHJpZ2h0LXBvcz0iMTV8NCIgc3BhY2U9IjB8 ICI+IHVzZXI8L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjE5fDYiIA0KcmlnaHQtcG9zPSIxOXw2IiBz cGFjZT0iMHwgIj4gYXV0aGVudGljYXRpb24gYW5kPC9TUEFOPjxTUEFOIGxlZnQtcG9zPSI1Mnwx MiIgDQpyaWdodC1wb3M9IjUyfDEyIiBzcGFjZT0iMHwgIj4gdXNlciBtYW5hZ2VtZW50PC9TUEFO PiwgYW5kIEFDIGlzIA0Kb25seTwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iNXw2IiByaWdodC1wb3M9 IjV8NiIgc3BhY2U9IjB8ICI+IHJlc3BvbnNpYmxlIA0KZm9yPC9TUEFOPjxTUEFOIGxlZnQtcG9z PSIxMXwxMiIgcmlnaHQtcG9zPSIxMXwxMiIgc3BhY2U9IjB8ICI+IHJhZGlvIA0KcmVzb3VyY2U8 L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjIzfDE3IiByaWdodC1wb3M9IjIzfDE3IiBzcGFjZT0iMHwg Ij4gbWFuYWdlbWVudCANCmFuZCBBUCBtYW5hZ2VtZW50PC9TUEFOPi4gRm9yIEVBUCBhdXRoZW50 aWNhdGlvbjwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMzB8MyIgDQpyaWdodC1wb3M9IjMwfDMiIHNw YWNlPSIiPiwgQUMgYXMgdGhlPC9TUEFOPjxTUEFOIGxlZnQtcG9zPSI4fDkiIHJpZ2h0LXBvcz0i OHw5IiANCnNwYWNlPSIwfCAiPiBhdXRoZW50aWNhdGlvbiBwb2ludDwvU1BBTj4sIFNHVyBhY3Rz IGFzIFJhZGl1cyBQcm94eS4gQXQgdGhlIHNhbWUgDQp0aW1lLDwvU1BBTj48U1BBTiBsZWZ0LXBv cz0iNnwxMiIgcmlnaHQtcG9zPSI2fDEyIiBzcGFjZT0iMHwgIj4gU0dXIGlzIA0KcmVzcG9uc2li bGUgZm9yIHRoZTwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMTh8OSIgcmlnaHQtcG9zPSIxOHw5IiBz cGFjZT0iMHwgIj4gDQp1c2VyIEVBUDwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMjd8MTUiIHJpZ2h0 LXBvcz0iMjd8MTUiIHNwYWNlPSIwfCAiPiBhZGRyZXNzIA0KYWxsb2NhdGlvbiBhbmQ8L1NQQU4+ PFNQQU4gbGVmdC1wb3M9IjQyfDEyIiByaWdodC1wb3M9IjQyfDEyIiBzcGFjZT0iMHwgIj4gdXNl ciANCm1hbmFnZW1lbnQ8L1NQQU4+LiBUaGlzIGNvbmZpZ3VyYXRpb24gZW5hYmxlcyB0aGU8L1NQ QU4+PFNQQU4gbGVmdC1wb3M9IjE1fDYiIA0KcmlnaHQtcG9zPSIxNXw2IiBzcGFjZT0iMHwgIj4g bmV0d29yazwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMjF8MTIiIA0KcmlnaHQtcG9zPSIyMXwxMiIg c3BhY2U9IjB8ICI+IGNvbXBsZXg8L1NQQU4+LCBhbmQgbWFpbnRlbmFuY2Ugb2YgDQpuZXR3b3Jr PC9TUEFOPjxTUEFOIGxlZnQtcG9zPSIxNXw2IiByaWdodC1wb3M9IjE1fDYiIHNwYWNlPSIwfCAi PiANCm1hbmFnZW1lbnQ8L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjIxfDkiIHJpZ2h0LXBvcz0iMjF8 OSIgc3BhY2U9IjB8ICI+IA0KYmVjb21lczwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMzB8NiIgcmln aHQtcG9zPSIzMHw2IiBzcGFjZT0iMHwgIj4gDQpjb21wbGV4PC9TUEFOPi4gSWYgdGhlIFNHVyBh Y3RzIGFzIEVBUDwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMTh8NiIgDQpyaWdodC1wb3M9IjE4fDYi IHNwYWNlPSIwfCAiPiBhdXRoZW50aWNhdGlvbjwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMjR8NCIg DQpyaWdodC1wb3M9IjI0fDQiIHNwYWNlPSIiPiw8L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjI4fDYi IHJpZ2h0LXBvcz0iMjh8NiIgDQpzcGFjZT0iMHwgIj4gdGhlIG5ldHdvcms8L1NQQU4+PFNQQU4g bGVmdC1wb3M9IjM0fDkiIHJpZ2h0LXBvcz0iMzR8OSIgDQpzcGFjZT0iMHwgIj4gYmVjb21lczwv U1BBTj48U1BBTiBsZWZ0LXBvcz0iNDN8OSIgcmlnaHQtcG9zPSI0M3w5IiBzcGFjZT0iMHwgIj4g DQpzaW1wbGUsIGJ1dCB3ZSBuZWVkIHRvIHNvbHZlIHRoZSZuYnNwO1BNSzwvU1BBTj48U1BBTiBs ZWZ0LXBvcz0iNnw2IiANCnJpZ2h0LXBvcz0iNnw2IiBzcGFjZT0iMHwgIj4gZXhjaGFuZ2U8L1NQ QU4+PFNQQU4gbGVmdC1wb3M9IjE1fDUiIA0KcmlnaHQtcG9zPSIxNXw1IiBzcGFjZT0iMHwgIj4g YmV0d2VlbiBTR1cgYW5kPC9TUEFOPjxTUEFOIGxlZnQtcG9zPSIwfDYiIA0KcmlnaHQtcG9zPSIw fDYiIHNwYWNlPSIwfCAiPiBBQzwvU1BBTj48L0ZPTlQ+PEZPTlQgDQpzaXplPTM+LjxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGNsYXNzPW9yZGluYXJ5LW91 dHB1dHRhcmdldC1vdXRwdXQgDQpzdHlsZT0iQkFDS0dST1VORDogd2hpdGU7IE1BUkdJTjogYXV0 byAwY207IFRFWFQtSU5ERU5UOiA4LjlwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50OiAuODUiPjxG T05UIA0KY29sb3I9IzAwMDAwMD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtU0laRTog MTAuNXB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTIuMHB0OyBtc28tYmlkaS1mb250LWZhbWlseTog5a6L5L2TIj5CeSANCnRoZSB3YXksIFNH VyA8L1NQQU4+PEZPTlQgZmFjZT3lrovkvZM+PFNQQU4gbGVmdC1wb3M9IjI1fDMiIHJpZ2h0LXBv cz0iMjV8MyIgDQpzcGFjZT0iMHwgIj48Rk9OVCBzaXplPTM+YWN0cyBhcyB0aDwvRk9OVD48L1NQ QU4+PFNQQU4gbGVmdC1wb3M9IjI1fDMiIA0KcmlnaHQtcG9zPSIyNXwzIiBzcGFjZT0iMHwgIj48 Rk9OVCBzaXplPTM+ZTwvRk9OVD48L1NQQU4+PFNQQU4gbGVmdC1wb3M9IjI1fDMiIA0KcmlnaHQt cG9zPSIyNXwzIiBzcGFjZT0iMHwgIj48Rk9OVCBzaXplPTM+IEVBUCA8L0ZPTlQ+PC9TUEFOPjxT UEFOIA0KbGVmdC1wb3M9IjI1fDMiIHJpZ2h0LXBvcz0iMjV8MyIgc3BhY2U9IjB8ICI+PEZPTlQg DQpzaXplPTM+YXV0aGVudGljYXRpb248L0ZPTlQ+PC9TUEFOPjxTUEFOIGxlZnQtcG9zPSIzMHwz IiByaWdodC1wb3M9IjMwfDMiIA0Kc3BhY2U9IiI+PEZPTlQgc2l6ZT0zPiw8L0ZPTlQ+PC9TUEFO PjxTUEFOIGxlZnQtcG9zPSIyNXwzIiByaWdodC1wb3M9IjI1fDMiIA0Kc3BhY2U9IjB8ICI+PEZP TlQgc2l6ZT0zPiBmb3IgdGhlIG9wZXJhdG9yPC9GT05UPjwvU1BBTj48U1BBTiBsZWZ0LXBvcz0i MjV8MyIgDQpyaWdodC1wb3M9IjI1fDMiIHNwYWNlPSIwfCAiPjxGT05UIHNpemU9Mz5zPC9GT05U PjwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMjV8MyIgDQpyaWdodC1wb3M9IjI1fDMiIHNwYWNlPSIw fCAiPjxGT05UIHNpemU9Mz4gbW9yZSB0aGFuIG9uZSANCm9wdGlvPC9GT05UPjwvU1BBTj48U1BB TiBsZWZ0LXBvcz0iMjV8MyIgcmlnaHQtcG9zPSIyNXwzIiBzcGFjZT0iMHwgIj48Rk9OVCANCnNp emU9Mz5uPC9GT05UPjwvU1BBTj48U1BBTiBsZWZ0LXBvcz0iMjV8MyIgcmlnaHQtcG9zPSIyNXwz IiBzcGFjZT0iMHwgIj48Rk9OVCANCnNpemU9Mz4uPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05U PjwvUD4NCjxQIGNsYXNzPW9yZGluYXJ5LW91dHB1dHRhcmdldC1vdXRwdXQgDQpzdHlsZT0iQkFD S0dST1VORDogd2hpdGU7IE1BUkdJTjogYXV0byAwY207IFRFWFQtSU5ERU5UOiA4LjlwdDsgbXNv LWNoYXItaW5kZW50LWNvdW50OiAuODUiPjxGT05UIA0KY29sb3I9IzAwMDAwMD48Rk9OVCBmYWNl PeWui+S9kz48U1BBTiBsZWZ0LXBvcz0iMjV8MyIgcmlnaHQtcG9zPSIyNXwzIiANCnNwYWNlPSIw fCAiPjxGT05UIA0Kc2l6ZT0zPlRoYW5rcyE8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PG86 cD48L286cD48L1NQQU4+PFNQQU4gDQpsZWZ0LXBvcz0iMjV8MyIgcmlnaHQtcG9zPSIyNXwzIiBz cGFjZT0iMHwgIj48L1A+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJk YW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPiZuYnNwOyA8Rk9O VCBjb2xvcj0jMDAwMDAwPiZuYnNwO0JvIA0KR2FvPEJSPiZuYnNwOyZuYnNwOyBDaGluYSBUZWxl Y29tPEJSPiZuYnNwOyZuYnNwOyBOby4gMTgzNSwgU291dGggUHVkb25nIA0KUm9hZDxCUj4mbmJz cDsmbmJzcDsgU2hhbmdoYWkmbmJzcDsgMjAwMTIyPEJSPiZuYnNwOyZuYnNwOyANCkNoaW5hPEJS PjwvRElWPjwvRk9OVD48L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBj MGMwIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9ESVY+DQo8SFIgY29sb3I9I2I1YzRkZiBTSVpFPTE+ DQoNCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RST05HPuWPkeS7tuS6uu+8mjwv U1RST05HPiBYdWVsaSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXpl PTI+PFNUUk9ORz7lj5HpgIHml7bpl7TvvJo8L1NUUk9ORz4gMjAxMy0wNy0xMiZuYnNwOyAxODox NzozMiANCjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48U1RS T05HPuaUtuS7tuS6uu+8mjwvU1RST05HPiBTdGVmYW4gV2ludGVyOyANCnJhZGV4dEBpZXRmLm9y ZyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+PFNUUk9ORz7m ioTpgIHvvJo8L1NUUk9ORz4gZ2FvYm8gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmEgc2l6ZT0yPjxTVFJPTkc+5Li76aKY77yaPC9TVFJPTkc+IFJFOiBbcmFkZXh0XSBGVzog TmV3IFZlcnNpb24gDQpOb3RpZmljYXRpb24gZm9yZHJhZnQteHVlLXJhZGV4dC1rZXktbWFuYWdl bWVudC0wMS50eHQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0y PjwvRk9OVD4gPC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPkhp LCZuYnNwO1N0ZWZhbjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhhbmtzJm5ic3A7Zm9yJm5i c3A7eW91ciZuYnNwO2NvbW1lbnRzLi48L0RJVj4NCjxESVY+QW5kJm5ic3A7cGxlYXNlJm5ic3A7 c2VlJm5ic3A7bXkmbmJzcDtyZXBseSZuYnNwO2luJm5ic3A7bGluZS48L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPkJSPC9ESVY+DQo8RElWPkxpJm5ic3A7PC9ESVY+DQo8RElWPjwvRElWPg0KPERJ Vj4mZ3Q7LS0tLS1PcmlnaW5hbCZuYnNwO01lc3NhZ2UtLS0tLTwvRElWPg0KPERJVj4mZ3Q7RnJv bTombmJzcDtyYWRleHQtYm91bmNlc0BpZXRmLm9yZyZuYnNwO1ttYWlsdG86cmFkZXh0LWJvdW5j ZXNAaWV0Zi5vcmddJm5ic3A7T24mbmJzcDs8L0RJVj4NCjxESVY+Jmd0O0JlaGFsZiZuYnNwO09m Jm5ic3A7U3RlZmFuJm5ic3A7V2ludGVyPC9ESVY+DQo8RElWPiZndDtTZW50OiZuYnNwO0ZyaWRh eSwmbmJzcDtKdWx5Jm5ic3A7MTIsJm5ic3A7MjAxMyZuYnNwOzI6MzkmbmJzcDtQTTwvRElWPg0K PERJVj4mZ3Q7VG86Jm5ic3A7cmFkZXh0QGlldGYub3JnPC9ESVY+DQo8RElWPiZndDtTdWJqZWN0 OiZuYnNwO1JlOiZuYnNwO1tyYWRleHRdJm5ic3A7Rlc6Jm5ic3A7TmV3Jm5ic3A7VmVyc2lvbiZu YnNwO05vdGlmaWNhdGlvbiZuYnNwO2ZvciZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7ZHJhZnQteHVl LXJhZGV4dC1rZXktbWFuYWdlbWVudC0wMS50eHQ8L0RJVj4NCjxESVY+Jmd0OzwvRElWPg0KPERJ Vj4mZ3Q7SGVsbG8sPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtU aGVyZSZuYnNwO2lzJm5ic3A7YSZuYnNwO25ldyZuYnNwO3ZlcnNpb24mbmJzcDtmb3ImbmJzcDtS QURJVVMmbmJzcDtFeHRlbnNpb25zJm5ic3A7Zm9yJm5ic3A7S2V5Jm5ic3A7TWFuYWdlbWVudCZu YnNwO2luJm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7V0xBTjwvRElWPg0KPERJVj4m Z3Q7bmV0d29yay48L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJ Vj4NCjxESVY+Jmd0OyZndDsmbmJzcDtJdCZuYnNwO2lzJm5ic3A7YSZuYnNwO2dlbmVyYWwmbmJz cDtjYXNlJm5ic3A7dGhhdCZuYnNwO2F1dGhlbnRpY2F0b3ImbmJzcDtpcyZuYnNwO2RlcGxveWVk Jm5ic3A7b24mbmJzcDtnYXRld2F5Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7aW5z dGVhZCZuYnNwO29mJm5ic3A7QUMuJm5ic3A7U28mbmJzcDtJbiZuYnNwO3RoaXMmbmJzcDtzY2Vu YXJpbywmbmJzcDt0aGUmbmJzcDtlbmNyeXB0aW9uL2RlY3J5cHRpb24mbmJzcDtub2RlJm5ic3A7 Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7Y2FuJ3QmbmJzcDtvYnRhaW4mbmJzcDtQ YWlyd2lzZSZuYnNwO01hc3RlciZuYnNwO0tleSZuYnNwOyhQTUspJm5ic3A7aW5mb3JtYXRpb24m bmJzcDtkdXJpbmcmbmJzcDtFeHRlbnNpYmxlJm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5i c3A7QXV0aGVudGljYXRpb24mbmJzcDtQcm90b2NvbCZuYnNwOyhFQVApJm5ic3A7cHJvY2VkdXJl LCZuYnNwO2l0Jm5ic3A7aXMmbmJzcDtub3QmbmJzcDtzdWZmaWNpZW50Jm5ic3A7dG8mbmJzcDs8 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDthY2hpZXZlJm5ic3A7dHJhZmZpYzwvRElWPg0KPERJ Vj4mZ3Q7ZW5jcnlwdGlvbi9kZWNyeXB0aW9uJm5ic3A7cmVxdWlyZW1lbnQmbmJzcDtpbiZuYnNw O1dpcmVsZXNzJm5ic3A7TG9jYWwmbmJzcDtBcmVhJm5ic3A7TmV0d29yayZuYnNwOyhXTEFOKSZu YnNwOzwvRElWPg0KPERJVj4mZ3Q7bmV0d29yay48L0RJVj4NCjxESVY+Jmd0OyZndDs8L0RJVj4N CjxESVY+Jmd0OyZndDsmbmJzcDtUaGlzJm5ic3A7ZG9jdW1lbnQmbmJzcDthbmFseXplcyZuYnNw O3RoZSZuYnNwO3JlcXVpcmVtZW50Jm5ic3A7YW5kJm5ic3A7aXNzdWUmbmJzcDtmb3ImbmJzcDtr ZXkmbmJzcDttYW5hZ2VtZW50Jm5ic3A7PC9ESVY+DQo8RElWPiZndDsmZ3Q7Jm5ic3A7dGhhdCZu YnNwO2hhcyZuYnNwO2FyaXNlbiZuYnNwO3NvJm5ic3A7ZmFyJm5ic3A7ZHVyaW5nJm5ic3A7YXV0 aGVudGljYXRpb24mbmJzcDtwcm9jZXNzJm5ic3A7aW4mbmJzcDtXTEFOJm5ic3A7bmV0d29yay48 L0RJVj4NCjxESVY+Jmd0OyZndDsmbmJzcDtNZWFud2hpbGUsJm5ic3A7dGhlJm5ic3A7Y29udHJv bCZuYnNwO21lc3NhZ2VzJm5ic3A7Zm9yJm5ic3A7a2V5Jm5ic3A7bWFuYWdlbWVudCZuYnNwO2Fy ZSZuYnNwO2RlZmluZWQuPC9ESVY+DQo8RElWPiZndDsmZ3Q7PC9ESVY+DQo8RElWPiZndDsmZ3Q7 Jm5ic3A7VGhpcyZuYnNwO2RyYXQmbmJzcDtpcyZuYnNwO3VwZGF0ZWQmbmJzcDt3aXRoJm5ic3A7 Q2hpbmEtdGVsZWNvbSZuYnNwO2FzJm5ic3A7Y28tYXV0aG9yLjwvRElWPg0KPERJVj4mZ3Q7Jmd0 OyZuYnNwO1lvdXImbmJzcDtjb21tZW50cyZuYnNwO2FyZSZuYnNwO2FwcHJlY2lhdGVkLjwvRElW Pg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtXaGVuJm5ic3A7eW91Jm5ic3A7c3VibWl0dGVk Jm5ic3A7LTAwLCZuYnNwO3lvdSZuYnNwO2dvdCZuYnNwO3N1YnN0YW50aWFsJm5ic3A7Y3JpdGlj aXNtJm5ic3A7YXMmbmJzcDtwZXImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDs8L0RJVj4NCjxESVY+ Jmd0O2Nhc2VzJm5ic3A7Zm9yJm5ic3A7dGhpcyZuYnNwO2RvY3VtZW50OyZuYnNwO3RoZSZuYnNw O2FwcHJvYWNoJm5ic3A7dGFrZW4mbmJzcDt0byZuYnNwO29mZmxvYWQmbmJzcDt0aGUmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0O2F1dGhlbnRpY2F0b3ImbmJzcDtmdW5jdGlvbiZuYnNwO3RvJm5ic3A7 dGhlJm5ic3A7U0dXJm5ic3A7d2FzJm5ic3A7c2VlbiZuYnNwO2FzJm5ic3A7YSZuYnNwO3JhdGhl ciZuYnNwO29kZCZuYnNwO21vdmUuPC9ESVY+DQo8RElWPiZndDtOb3csJm5ic3A7aW4mbmJzcDst MDEsJm5ic3A7eW91Jm5ic3A7ZG9uJ3QmbmJzcDtyZWFsbHkmbmJzcDtyZWFjdCZuYnNwO3RvJm5i c3A7dGhpczsmbmJzcDt0aGUmbmJzcDtvbmx5Jm5ic3A7c3RhdGVtZW50Jm5ic3A7aW4mbmJzcDt0 aGF0Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtkaXJlY3Rpb24mbmJzcDtJJm5ic3A7c2VlJm5ic3A7 aXMmbmJzcDt0aGF0Jm5ic3A7eW91Jm5ic3A7cmVwZWF0ZWRseSZuYnNwO21ha2UmbmJzcDt0aGUm bmJzcDthc3NlcnRpb24mbmJzcDt0aGF0Jm5ic3A7Ikl0Jm5ic3A7aXMmbmJzcDthJm5ic3A7PC9E SVY+DQo8RElWPiZndDtnZW5lcmFsJm5ic3A7Y2FzZSZuYnNwO2luJm5ic3A7b3BlcmF0b3JzJm5i c3A7bmV0d29ya3MiLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jmd0O0kmbmJzcDtzaW1wbHkm bmJzcDtkb3VidCZuYnNwO3RoYXQmbmJzcDt0aGlzJm5ic3A7aXMmbmJzcDtnZW5lcmFsbHkmbmJz cDt0cnVlOyZuYnNwO21lcmVseSZuYnNwO21ha2luZyZuYnNwO2FuJm5ic3A7dW5iYWNrZWQmbmJz cDs8L0RJVj4NCjxESVY+Jmd0O2Fzc2VydGlvbiZuYnNwO3RoYXQmbmJzcDtpdCZuYnNwO2lzJm5i c3A7c28mbmJzcDtkb2Vzbid0Jm5ic3A7bWFrZSZuYnNwO2l0Jm5ic3A7dHJ1ZS48L0RJVj4NCjxE SVY+PC9ESVY+DQo8RElWPlt4dWVsaV0mbmJzcDtJJm5ic3A7YXBwcmVjaWF0ZWQmbmJzcDt0aGUm bmJzcDtjb21tZW50cyZuYnNwO3RvJm5ic3A7c2NlbmFyaW8mbmJzcDt0byZuYnNwO29mZmxvYWQm bmJzcDt0aGUmbmJzcDthdXRoZW50aWNhdG9yJm5ic3A7ZnVuY3Rpb24mbmJzcDt0byZuYnNwO1NH Vy48L0RJVj4NCjxESVY+VGhlcmUmbmJzcDthcmUmbmJzcDt0d28mbmJzcDtyZWFzb25zLCZuYnNw O3doaWNoJm5ic3A7SSZuYnNwO2NsYXJpZmllZCZuYnNwO3RoZSZuYnNwO3NjZW5hcmlvJm5ic3A7 aW4mbmJzcDt0aGUmbmJzcDtkb2N1bWVudCZuYnNwO3ZlcnNpb24mbmJzcDswMSZuYnNwO2FzJm5i c3A7OjwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDsiSW4mbmJzcDtFQVAmbmJzcDtmcmFt ZXdvcmssJm5ic3A7U0dXJm5ic3A7Y291bGQmbmJzcDthY3QmbmJzcDthcyZuYnNwO3RoZSZuYnNw O0F1dGhlbnRpY2F0b3ImbmJzcDtpbnN0ZWFkJm5ic3A7b2YmbmJzcDtBQzwvRElWPg0KPERJVj4m bmJzcDsmbmJzcDsmbmJzcDtiZWNhdXNlJm5ic3A7b2YmbmJzcDtzZXZlcmFsJm5ic3A7cmVhc29u cy4mbmJzcDsmbmJzcDtGaXJzdCZuYnNwO29mJm5ic3A7YWxsLCZuYnNwO2EmbmJzcDtwb3dlcmZ1 bCZuYnNwO0FDJm5ic3A7dGhhdDwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDthZ2dyZWdh dGVzJm5ic3A7dGhlJm5ic3A7QXV0aGVudGljYXRvciZuYnNwO2Z1bmN0aW9uJm5ic3A7aXMmbmJz cDtub3QmbmJzcDthJm5ic3A7YXBwcmVjaWF0ZWQmbmJzcDtjaG9pY2UmbmJzcDtmb3I8L0RJVj4N CjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7c29tZSZuYnNwO29wZXJhdG9ycy4mbmJzcDtUaGVyZSZu YnNwO2FyZSZuYnNwO2xhcmdlJm5ic3A7bnVtYmVycyZuYnNwO29mJm5ic3A7QUMmbmJzcDtkZXZp Y2VzJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtvcGVyYXRvcnM8L0RJVj4NCjxESVY+Jm5ic3A7Jm5i c3A7Jm5ic3A7ZXhpc3RpbmcmbmJzcDtuZXR3b3JrLiZuYnNwOyZuYnNwO1RoZSZuYnNwO0F1dGhl bnRpY2F0aW9uJm5ic3A7U2VydmVyJm5ic3A7KEFTKSZuYnNwO3dpbGwmbmJzcDtvdmVybG9hZCZu YnNwO3RoZSZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt3aXRoJm5ic3A7bGFyZ2U8L0RJVj4NCjxE SVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7bnVtYmVycyZuYnNwO29mJm5ic3A7QUMmbmJzcDtkZXZpY2Vz Jm5ic3A7aWYmbmJzcDtBQ3MmbmJzcDthY3RzJm5ic3A7YXMmbmJzcDt0aGUmbmJzcDtBdXRoZW50 aWNhdG9yLiZuYnNwOyZuYnNwO09uJm5ic3A7dGhlJm5ic3A7b3RoZXI8L0RJVj4NCjxESVY+Jm5i c3A7Jm5ic3A7Jm5ic3A7aGFuZCwmbmJzcDtTR1cmbmJzcDtNVVNUJm5ic3A7c3VwcG9ydCZuYnNw O3RoZSZuYnNwO1JBRElVUyZuYnNwO3Byb3h5Jm5ic3A7ZnVuY3Rpb24mbmJzcDt3aGVuJm5ic3A7 QUMmbmJzcDthY3RzJm5ic3A7YXMmbmJzcDt0aGU8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5i c3A7QXV0aGVudGljYXRvciZuYnNwO2luJm5ic3A7RUFQJm5ic3A7ZnJhbWV3b3JrLiZuYnNwOyZu YnNwO0luJm5ic3A7dGhpcyZuYnNwO3NjZW5hcmlvLCZuYnNwO2JvdGgmbmJzcDtTR1cmbmJzcDth bmQmbmJzcDtBQzwvRElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDtzaG91bGQmbmJzcDtiZSZu YnNwO3Jlc3BvbnNpYmxlJm5ic3A7Zm9yJm5ic3A7YXV0aGVudGljYXRpb24mbmJzcDtwcm9jZWR1 cmUuJm5ic3A7Jm5ic3A7Rm9yJm5ic3A7b3BlcmF0b3JzLDwvRElWPg0KPERJVj4mbmJzcDsmbmJz cDsmbmJzcDtpdCZuYnNwO2lzJm5ic3A7Y29zdCZuYnNwO2luJm5ic3A7bGFyZ2Utc2NhbGUmbmJz cDt1cGdyYWRlZCZuYnNwO2RlcGxveW1lbnQuIjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+TWVh bndoaWxlLCZuYnNwO3RoaXMmbmJzcDtyZXF1aXJlbWVudCZuYnNwO2lzJm5ic3A7YWxzbyZuYnNw O21lbnRpb25lZCZuYnNwO2luJm5ic3A7dGhlJm5ic3A7ZHJhZnQmbmJzcDsiJm5ic3A7aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FvLWNhcHdhcC1lYXAtMDAiPC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj5JdCZuYnNwO2lzJm5ic3A7ZGVzY3JpYmVkJm5ic3A7YXM8L0RJVj4NCjxE SVY+IkFSJm5ic3A7YWN0cyZuYnNwO2FzJm5ic3A7YXV0aGVudGljYXRvciZuYnNwO2luJm5ic3A7 dGhlJm5ic3A7RUFQJm5ic3A7ZnJhbWV3b3JrLiZuYnNwOyZuYnNwO0FmdGVyJm5ic3A7YXV0aGVu dGljYXRpb24sJm5ic3A7dGhlJm5ic3A7QVI8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7 cmVjZWl2ZXMmbmJzcDt0aGUmbmJzcDtFQVAmbmJzcDtrZXlpbmcmbmJzcDttZXNzYWdlJm5ic3A7 Zm9yJm5ic3A7dGhlJm5ic3A7c2Vzc2lvbi4mbmJzcDsmbmJzcDtCdXQmbmJzcDtBQyZuYnNwO2lz Jm5ic3A7c3VwcG9zZWQ8L0RJVj4NCjxESVY+Jm5ic3A7Jm5ic3A7Jm5ic3A7dG8mbmJzcDtkZWxp ZXZlJm5ic3A7dGhlc2UmbmJzcDtrZXlpbmcmbmJzcDttZXNzYWdlcyZuYnNwO3RvJm5ic3A7dGhl Jm5ic3A7QVAsJm5ic3A7YW5kJm5ic3A7QVImbmJzcDtoYXMmbmJzcDtubyZuYnNwO3N0YW5kYXJk PC9ESVY+DQo8RElWPiZuYnNwOyZuYnNwOyZuYnNwO2ludGVyZmFjZSZuYnNwO3RvJm5ic3A7c2hp cCZuYnNwO3RoZW0mbmJzcDt0byZuYnNwO3RoZSZuYnNwO0FQJm5ic3A7b3ImbmJzcDt0aGUmbmJz cDtBQy4mbmJzcDsmbmJzcDtUaGlzJm5ic3A7aXMmbmJzcDt1bmFjY2VwdGFibGUmbmJzcDtpbjwv RElWPg0KPERJVj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUmbmJzcDtzY2VuYXJpbyZuYnNwO29mJm5i c3A7RUFQLWJhc2VkJm5ic3A7YXV0by1hdXRoZW50aWNhdGlvbi48L0RJVj4NCjxESVY+IiZuYnNw O0FSJm5ic3A7aXMmbmJzcDt0aGUmbmJzcDthY2Nlc3MmbmJzcDtyb3V0ZXIuJm5ic3A7PC9ESVY+ DQo8RElWPjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+Jmd0O0kmbmJzcDthbHNvJm5ic3A7Y2Fu J3QmbmJzcDtoZWxwJm5ic3A7YnV0Jm5ic3A7bm90aWNlJm5ic3A7dGhhdCZuYnNwO21hbnkmbmJz cDtvZiZuYnNwO3lvdXImbmJzcDtub3JtYXRpdmUmbmJzcDtyZWZlcmVuY2VzJm5ic3A7YXJlJm5i c3A7PC9ESVY+DQo8RElWPiZndDtvbGQmbmJzcDthbmQmbmJzcDtvYnNvbGV0ZS48L0RJVj4NCjxE SVY+Jmd0OyombmJzcDtGb3ImbmJzcDtrZXkmbmJzcDtleGNoYW5nZSwmbmJzcDt5b3UmbmJzcDty ZWZlcmVuY2UmbmJzcDthbiZuYnNwO3VuYXBwcm92ZWQmbmJzcDtkcmFmdCZuYnNwO29mJm5ic3A7 SUVFRS04MDIuMTFpITwvRElWPg0KPERJVj4mZ3Q7QWxsJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtm ZWF0dXJlcyZuYnNwO2Zyb20mbmJzcDt0aGF0Jm5ic3A7ZHJhZnQmbmJzcDthcmUmbmJzcDttZWFu d2hpbGUmbmJzcDtwYXJ0Jm5ic3A7b2YmbmJzcDtJRUVFPC9ESVY+DQo8RElWPiZndDs4MDIuMTEt MjAxMiZuYnNwOyhhbmQmbmJzcDtJJm5ic3A7aG9wZSZuYnNwO3lvdSZuYnNwO2Rvbid0Jm5ic3A7 aW1wbGVtZW50Jm5ic3A7YW4mbmJzcDtvbGQmbmJzcDtkcmFmdCZuYnNwO3ZlcnNpb24mbmJzcDtp biZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7eW91ciZuYnNwO3Byb2R1Y3RzISkuPC9ESVY+DQo8RElW PiZndDsqJm5ic3A7VGhlJm5ic3A7bmV4dCZuYnNwO3JlZmVyZW5jZSZuYnNwO2lzJm5ic3A7dGhl Jm5ic3A7SUVFRSZuYnNwOzgwMi4xWCZuYnNwO3ZlcnNpb24mbmJzcDtmcm9tJm5ic3A7MjAwMSZu YnNwOy0mbmJzcDtpdCZuYnNwO2hhcyZuYnNwO3R3byZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7c3Vj Y2Vzc29ycyZuYnNwO21lYW53aGlsZS48L0RJVj4NCjxESVY+Jmd0OyombmJzcDtSRkMzNTc2Jm5i c3A7aXMmbmJzcDtvYnNvbGV0ZWQmbmJzcDtieSZuYnNwO1JGQzUxNzYuJm5ic3A7WW91Jm5ic3A7 bWVudGlvbiZuYnNwO2JvdGgmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO25vcm1hdGl2ZSZuYnNwOzwv RElWPg0KPERJVj4mZ3Q7cmVmZXJlbmNlczsmbmJzcDt0aGUmbmJzcDttYWluJm5ic3A7dGV4dCZu YnNwO3VzZXMmbmJzcDt0aGUmbmJzcDtBdXRoZW50aWNhdG9yJm5ic3A7ZmllbGQmbmJzcDtmcm9t Jm5ic3A7MzU3NiwmbmJzcDtidXQmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O3RoZSZuYnNwO3R5cGUm bmJzcDtkZWZpbml0aW9uJm5ic3A7ZnJvbSZuYnNwOzUxNzYuJm5ic3A7VGhhdCdzJm5ic3A7cHJv YmFibHkmbmJzcDthbiZuYnNwO292ZXJzaWdodDsmbmJzcDt0aGUmbmJzcDs8L0RJVj4NCjxESVY+ Jmd0O2NhbGN1bGF0aW9uJm5ic3A7b2YmbmJzcDtBdXRoZW50aWNhdG9yJm5ic3A7aGFzbid0Jm5i c3A7Y2hhbmdlZCZuYnNwO2JldHdlZW4mbmJzcDt0aGUmbmJzcDt0d28mbmJzcDtyZXZzLjwvRElW Pg0KPERJVj48L0RJVj4NCjxESVY+W3h1ZWxpXSZuYnNwO3RoYW5rcyZuYnNwO2EmbmJzcDtsb3Qu Jm5ic3A7PC9ESVY+DQo8RElWPjgwMi4xMWkmbmJzcDtpcyZuYnNwO2FscmVhZHkmbmJzcDthcHBy b3ZlZCZuYnNwO2luJm5ic3A7MjAwNC4mbmJzcDtJJm5ic3A7YW0mbmJzcDtub3QmbmJzcDtzdXJl Jm5ic3A7d2h5Jm5ic3A7eW91Jm5ic3A7c2F5Jm5ic3A7aXQmbmJzcDtpcyZuYnNwO2FuJm5ic3A7 dW5hcHByb3ZlZCZuYnNwO2RyYWZ0LjwvRElWPg0KPERJVj5Gb3ImbmJzcDtvdGhlciZuYnNwO3Jl ZmVyZW5jZXMsJm5ic3A7SSZuYnNwO3dpbGwmbmJzcDt1cGRhdGUuJm5ic3A7PC9ESVY+DQo8RElW PjwvRElWPg0KPERJVj4mZ3Q7WW91ciZuYnNwO3NlY3VyaXR5Jm5ic3A7Y29uc2lkZXJhdGlvbnMm bmJzcDthcmUmbmJzcDt2ZXJ5Jm5ic3A7aW5hZGVxdWF0ZS4mbmJzcDtZb3UmbmJzcDtzaW1wbHkm bmJzcDtzdGF0ZSZuYnNwO3RoYXQmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O3RoZSZuYnNwO2xpbmsm bmJzcDtiZXR3ZWVuJm5ic3A7U0dXJm5ic3A7YW5kJm5ic3A7QUMmbmJzcDttdXN0Jm5ic3A7YmUm bmJzcDtzZWN1cmUuJm5ic3A7RnJvbSZuYnNwO215Jm5ic3A7KHNraW1taW5nKSZuYnNwOzwvRElW Pg0KPERJVj4mZ3Q7dW5kZXJzdGFuZGluZyZuYnNwO29mJm5ic3A7dGhlJm5ic3A7ZHJhZnQsJm5i c3A7dGhlc2UmbmJzcDt0d28mbmJzcDtlbnRpdGllcyZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3R5 cGljYWxseSZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7bG9jYXRlZCZuYnNwO2luc2lkZSZuYnNwO3Ro ZSZuYnNwO3NhbWUmbmJzcDtwcmVtaXNlcywmbmJzcDtyaWdodD8mbmJzcDtJZiZuYnNwO3RoZXkm bmJzcDthcmVuJ3QsJm5ic3A7c2ltcGx5Jm5ic3A7PC9ESVY+DQo8RElWPiZndDthc3N1bWluZyZu YnNwO3NlY3VydGl5Jm5ic3A7b24mbmJzcDt0aGUmbmJzcDtsaW5rJm5ic3A7YmxpbmRseSZuYnNw O2lzJm5ic3A7YW4mbmJzcDtleHRyZW1lbHkmbmJzcDtiYWQmbmJzcDtpZGVhLiZuYnNwO0lNSE8s Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtub3QmbmJzcDtwcm90ZWN0aW5nJm5ic3A7dGhlJm5ic3A7 a2V5cyZuYnNwO2FuZCZuYnNwO3NlbmRpbmcmbmJzcDt0aGVtJm5ic3A7aW4mbmJzcDt0aGUmbmJz cDtjbGVhciZuYnNwO2lzJm5ic3A7YSZuYnNwO25vLWdvLjwvRElWPg0KPERJVj5beHVlbGldJm5i c3A7SSZuYnNwO2Rvbid0Jm5ic3A7dGhpbmsmbmJzcDtJJm5ic3A7bWVudGlvbmVkJm5ic3A7dGhh dCZuYnNwO3RoZSZuYnNwO2xpbmsmbmJzcDtiZXR3ZWVuJm5ic3A7QUMmbmJzcDthbmQmbmJzcDtT R1cmbmJzcDtpcyZuYnNwO3NlY3VyZS4mbmJzcDs8L0RJVj4NCjxESVY+SSZuYnNwO2hhdmUmbmJz cDthbHJlYWR5Jm5ic3A7cmVjb2duaXplZCZuYnNwO3RoZSZuYnNwO2tleSZuYnNwO3RyYW5zcG9y dGVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtsaW5rJm5ic3A7bXVzdCZuYnNwO2JlJm5ic3A7ZW5j cnlwdGVkLiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtJbiZuYnNwO3Ro ZSZuYnNwO3NhbWUmbmJzcDtzZWN0aW9uLCZuYnNwO3lvdSZuYnNwO3N0YXRlJm5ic3A7cm91Z2hs eSZuYnNwOyJPaCwmbmJzcDtpZiZuYnNwO3lvdSZuYnNwO25lZWQmbmJzcDtzZWN1cml0eSwmbmJz cDt1c2UmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O0lQU2VjISImbmJzcDstJm5ic3A7d2hpY2gmbmJz cDtpcyZuYnNwO3RvbyZuYnNwO3N1cGVyZmljaWFsJm5ic3A7YSZuYnNwO3N0YXRlbWVudCZuYnNw O3RvJm5ic3A7YmUmbmJzcDt1c2VmdWw7Jm5ic3A7eW91Jm5ic3A7c2hvdWxkJm5ic3A7PC9ESVY+ DQo8RElWPiZndDthdCZuYnNwO2xlYXN0Jm5ic3A7ZGlzY3VzcyZuYnNwO2hvdyZuYnNwO3RoZSZu YnNwO0lQU2VjJm5ic3A7ZW5kcG9pbnRzJm5ic3A7YXJlJm5ic3A7c3VwcG9zZWQmbmJzcDt0byZu YnNwO25lZ290aWF0ZSZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7SVBTZWMmbmJzcDtrZXlpbmcmbmJz cDttYXRlcmlhbCZuYnNwO3RvJm5ic3A7YmUmbmJzcDthYmxlJm5ic3A7dG8mbmJzcDtjb21tdW5p Y2F0ZSZuYnNwO2NvbmZpZGVudGlhbGx5LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+W3h1ZWxp XSZuYnNwO0kmbmJzcDt0b3RhbGx5Jm5ic3A7YWdyZWUmbmJzcDt3aXRoJm5ic3A7eW91Jm5ic3A7 YW5kJm5ic3A7dGhpcyZuYnNwO3BhcnQmbmJzcDtvZiZuYnNwO3dvcmsmbmJzcDt3aWxsJm5ic3A7 YmUmbmJzcDtwcmVzZW50ZWQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO25leHQmbmJzcDt2ZXJzaW9u LiZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDtCVFcsJm5ic3A7aWYmbmJz cDtJJm5ic3A7cmVjYWxsJm5ic3A7Y29ycmVjdGx5Jm5ic3A7eW91ciZuYnNwO2RyYWZ0Jm5ic3A7 d2FzJm5ic3A7bW90aXZhdGVkJm5ic3A7YnkmbmJzcDt0aGUmbmJzcDsiZmFjdCImbmJzcDsob3Im bmJzcDs8L0RJVj4NCjxESVY+Jmd0O3NvJm5ic3A7eW91Jm5ic3A7cHJlc2VudGVkJm5ic3A7aXQp Jm5ic3A7dGhhdCZuYnNwO2NoYW5naW5nJm5ic3A7dGhlJm5ic3A7QUMmbmJzcDt0byZuYnNwO3Rh a2UmbmJzcDtvdmVyJm5ic3A7dGhlJm5ic3A7PC9ESVY+DQo8RElWPiZndDthdXRoZW50aWNhdG9y Jm5ic3A7cm9sZSZuYnNwO2lzJm5ic3A7dG9vJm5ic3A7Y29zdGx5Jm5ic3A7aW4mbmJzcDt0ZXJt cyZuYnNwO29mJm5ic3A7aW1wbGVtZW50YXRpb24mbmJzcDtvciZuYnNwOzwvRElWPg0KPERJVj4m Z3Q7Y29tcHV0aW5nJm5ic3A7cG93ZXIuJm5ic3A7Tm93Jm5ic3A7aW4mbmJzcDtzZWN1cml0eSZu YnNwO2NvbnNpZGVyYXRpb25zLCZuYnNwO3lvdSZuYnNwO2dlbmVyb3VzbHkmbmJzcDs8L0RJVj4N CjxESVY+Jmd0O3JlY29tbWVuZCZuYnNwO3RvJm5ic3A7aW1wbGVtZW50Jm5ic3A7dGhlJm5ic3A7 ZW50aXJlJm5ic3A7SVBTZWMmbmJzcDtzdGFjayZuYnNwO29uJm5ic3A7dGhlJm5ic3A7QUMuJm5i c3A7SSZuYnNwO3dvdWxkJm5ic3A7YXJndWUmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O3RoYXQmbmJz cDtpdCdzJm5ic3A7ZWFzaWVyJm5ic3A7dG8mbmJzcDtpbXBsZW1lbnQmbmJzcDt0aGUmbmJzcDth dXRoZW50aWNhdG9yJm5ic3A7ZnVuY3Rpb24mbmJzcDtvZiZuYnNwO0lFRUUmbmJzcDs4MDIuMVgm bmJzcDt0aGFuJm5ic3A7aXQmbmJzcDtpcyZuYnNwO3RvJm5ic3A7aW1wbGVtZW50Jm5ic3A7SVBT ZWMuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5beHVlbGldJm5ic3A7SSZuYnNwO3NlZS4mbmJz cDtJJm5ic3A7anVzdCZuYnNwO2dpdmUmbmJzcDthJm5ic3A7cG9zc2libGUmbmJzcDtzb2x1dGlv biZuYnNwO3RvJm5ic3A7YWRkcmVzcyZuYnNwO3RoZSZuYnNwO3NlY3VyaXR5Jm5ic3A7cHJvYmxl bS4mbmJzcDtJJm5ic3A7YWdyZWUmbmJzcDt0aGF0Jm5ic3A7dGhlcmUmbmJzcDtjb3VsZCZuYnNw O2JlJm5ic3A7bW9yZSZuYnNwO29wdGltYWwmbmJzcDtzb2x1dGlvbnMuJm5ic3A7PC9ESVY+DQo8 RElWPkkmbmJzcDt3b3VsZCZuYnNwO2xpa2UmbmJzcDt0byZuYnNwO21lbnRpb24mbmJzcDtkdXJp bmcmbmJzcDt0aGUmbmJzcDttZWV0aW5nJm5ic3A7YW5kJm5ic3A7Y29sbGVjdCZuYnNwO2NvbW1l bnRzJm5ic3A7ZnJvbSZuYnNwO3RoZSZuYnNwO3NlY3VyaXR5Jm5ic3A7Z3V5cy4mbmJzcDtJcyZu YnNwO3RoYXQmbmJzcDtmYWlyJm5ic3A7ZW5vdWdoPzwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+ Jmd0OzwvRElWPg0KPERJVj4mZ3Q7VGhlJm5ic3A7c2FtZSZuYnNwO3NlY3Rpb24mbmJzcDthbHNv Jm5ic3A7c3VnZ2VzdHMmbmJzcDtNRDUmbmJzcDtlbmNyeXB0aW9uL2RlY3J5cHRpb24uJm5ic3A7 SGVyZSZuYnNwO0kmbmJzcDthbSZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Y29tcGxldGVseSZuYnNw O2xvc3QuJm5ic3A7VGhlJm5ic3A7S29BJm5ic3A7YW5kJm5ic3A7S29BJm5ic3A7QUNLL05BSyZu YnNwO21lc3NhZ2VzJm5ic3A7YXJlJm5ic3A7UkFESVVTJm5ic3A7cGFja2V0cywmbmJzcDs8L0RJ Vj4NCjxESVY+Jmd0O3JpZ2h0PyZuYnNwO0FzJm5ic3A7c3VjaCZuYnNwO3RoZXkmbmJzcDthcmUm bmJzcDthbHdheXMmbmJzcDttYWtpbmcmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO01E NSZuYnNwO3NoYXJlZCZuYnNwO3NlY3JldCZuYnNwO2ZvciZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7 aW50ZWdyaXR5Jm5ic3A7Y2hlY2tzOyZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7d2FudCZuYnNwO3Rv Jm5ic3A7cHJvdGVjdCZuYnNwO3RoZSZuYnNwOzgwMi4xMSZuYnNwO2tleWluZyZuYnNwO21hdGVy aWFsJm5ic3A7PC9ESVY+DQo8RElWPiZndDt0aGVuJm5ic3A7eW91Jm5ic3A7Y291bGQmbmJzcDt1 c2UmbmJzcDtlbmNyeXB0ZWQmbmJzcDthdHRyaWJ1dGVzJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNw O3NhbWUmbmJzcDtzaGFyZWQmbmJzcDtzZWNyZXQmbmJzcDs8L0RJVj4NCjxESVY+Jmd0Oyh0aGF0 J3MmbmJzcDt0aGUmbmJzcDt3YXkmbmJzcDtob3cmbmJzcDtVc2VyLVBhc3N3b3JkJm5ic3A7Z2V0 cyZuYnNwO2VuY3J5cHRlZCkuJm5ic3A7V2l0aCZuYnNwO2xpdHRsZSZuYnNwO3RvJm5ic3A7bm8m bmJzcDs8L0RJVj4NCjxESVY+Jmd0O2FkZGl0aW9uYWwmbmJzcDtpbXBsZW1lbnRhdGlvbiZuYnNw O2Nvc3QuJm5ic3A7SWYmbmJzcDt0aGF0J3MmbmJzcDt3aGF0Jm5ic3A7eW91Jm5ic3A7d2FudCZu YnNwOy0mbmJzcDtkb24ndCZuYnNwO3B1dCZuYnNwO2EmbmJzcDs8L0RJVj4NCjxESVY+Jmd0O2hh bGYtc2VudGVuY2UmbmJzcDtpbnRvJm5ic3A7c2VjdXJpdHkmbmJzcDtjb25zaWRlcmF0aW9ucy4m bmJzcDsqV3JpdGUmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3NwZWMmbmJzcDtpdHNlbGYmbmJzcDs8 L0RJVj4NCjxESVY+Jmd0O3RoYXQmbmJzcDt0aGUmbmJzcDthdHRyaWJ1dGUmbmJzcDtpcyZuYnNw O3RvJm5ic3A7YmUmbmJzcDtlbmNyeXB0ZWQqLjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElW Plt4dWVsaV0mbmJzcDtZZXMsJm5ic3A7dGhhdCZuYnNwO2lzJm5ic3A7d2hhdCZuYnNwO0kmbmJz cDt3YW50Jm5ic3A7dG8mbmJzcDtkby4uJm5ic3A7SSZuYnNwO3dpbGwmbmJzcDtjbGFyaWZ5Jm5i c3A7aXQuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj4mZ3Q7QlRXLCZuYnNwO2V2ZW4mbmJzcDtp ZiZuYnNwO3lvdSZuYnNwO2RvJm5ic3A7d3JpdGUmbmJzcDt0aGF0Jm5ic3A7aW4mbmJzcDt0aGUm bmJzcDtzcGVjLCZuYnNwO3lvdSdkJm5ic3A7c3RpbGwmbmJzcDtnZXQmbmJzcDthJm5ic3A7YmVh dGluZyZuYnNwOzwvRElWPg0KPERJVj4mZ3Q7Zm9yJm5ic3A7c3VnZ2VzdGluZyZuYnNwO01ENSZu YnNwO1JBRElVUyZuYnNwO2NyeXB0byZuYnNwO2luJm5ic3A7MjAxMy4mbmJzcDtUaGlzJm5ic3A7 ZW5jcnlwdGlvbiZuYnNwO21ldGhvZCZuYnNwO2lzJm5ic3A7bm90Jm5ic3A7PC9ESVY+DQo8RElW PiZndDtjb250ZW1wb3JhcnkuPC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5beHVlbGldJm5ic3A7 VGhhbmsmbmJzcDt5b3UmbmJzcDtmb3ImbmJzcDt5b3VyJm5ic3A7YWR2aWNlLiZuYnNwOzwvRElW Pg0KPERJVj5TZWN1cml0eSZuYnNwO2lzJm5ic3A7aW1wb3J0YW50Jm5ic3A7cGFydCZuYnNwO29m Jm5ic3A7dGhpcyZuYnNwO3dvcmsuJm5ic3A7PC9ESVY+DQo8RElWPkl0Jm5ic3A7aXMmbmJzcDtt eSZuYnNwO3BsYW4mbmJzcDt0byZuYnNwO2dvJm5ic3A7aW50byZuYnNwO3RlY2huaXF1ZSZuYnNw O2RldGFpbHMmbmJzcDthbmQmbmJzcDtnaXZlJm5ic3A7YSZuYnNwO21vcmUmbmJzcDtjb25jcmV0 ZSZuYnNwO3NlY3VyaXR5Jm5ic3A7c29sdXRpb24mbmJzcDtieSZuYnNwO3RoZSZuYnNwO25leHQm bmJzcDtJRVRGJm5ic3A7bWVldGluZy4mbmJzcDs8L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPiZn dDtHcmVldGluZ3MsPC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0O1N0ZWZhbiZuYnNw O1dpbnRlcjwvRElWPg0KPERJVj4mZ3Q7PC9ESVY+DQo8RElWPiZndDstLTwvRElWPg0KPERJVj4m Z3Q7U3RlZmFuJm5ic3A7V0lOVEVSPC9ESVY+DQo8RElWPiZndDtJbmdlbmlldXImbmJzcDtkZSZu YnNwO1JlY2hlcmNoZTwvRElWPg0KPERJVj4mZ3Q7Rm9uZGF0aW9uJm5ic3A7UkVTVEVOQSZuYnNw Oy0mbmJzcDtSw6lzZWF1Jm5ic3A7VMOpbMOpaW5mb3JtYXRpcXVlJm5ic3A7ZGUmbmJzcDtsJ0Vk dWNhdGlvbiZuYnNwO05hdGlvbmFsZSZuYnNwO2V0Jm5ic3A7PC9ESVY+DQo8RElWPiZndDtkZSZu YnNwO2xhJm5ic3A7UmVjaGVyY2hlJm5ic3A7NiwmbmJzcDtydWUmbmJzcDtSaWNoYXJkJm5ic3A7 Q291ZGVuaG92ZS1LYWxlcmdpPC9ESVY+DQo8RElWPiZndDtMLTEzNTkmbmJzcDtMdXhlbWJvdXJn PC9ESVY+DQo8RElWPiZndDs8L0RJVj4NCjxESVY+Jmd0O1RlbDombmJzcDsrMzUyJm5ic3A7NDI0 NDA5Jm5ic3A7MTwvRElWPg0KPERJVj4mZ3Q7RmF4OiZuYnNwOyszNTImbmJzcDs0MjI0NzM8L0RJ Vj4NCjxESVY+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon573820155088_=====-- From trac+radext@trac.tools.ietf.org Sun Jul 14 20:56:50 2013 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 82CC321F99D3 for ; Sun, 14 Jul 2013 20:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JSFIdtU7lkH for ; Sun, 14 Jul 2013 20:56:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 714C321F9D95 for ; Sun, 14 Jul 2013 20:56:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:49807 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UyZtu-0006oB-Kx; Mon, 15 Jul 2013 05:56:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com X-Trac-Project: radext Date: Mon, 15 Jul 2013 03:56:38 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:5 Message-ID: <081.8e2856e09114f63c61fb32d7ade0ac46@trac.tools.ietf.org> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130715035648.714C321F9D95@ietfa.amsl.com> Resent-Date: Sun, 14 Jul 2013 20:56:48 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #153: Section 2.8 Access-Info 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, 15 Jul 2013 03:56:50 -0000 #153: Section 2.8 Access-Info Comment (by bernard_aboba@hotmail.com): EAPOL-Announcement messages can be generic or specific. They can also refer to a particular NID-Name. So there is a question of how it is indicated what kind of EAPOL-Announcement message the access status is to be encoded in. One potential way of indicating the NID-Name to which the access-status applies is to assume that it applies to the NID-Name indicated in the Network-Id-Name attribute. However, the NID-Name attribute is not permitted within an Access-Challenge. Should this be changed? Proposed text is enclosed below: The Access-Info Attribute is utilized by implementations of IEEE-802.1X [IEEE-802.1X] to specify the Access status information field within an Access Information Type Length Value Tuple (TLV) to be sent to the user within MACsec Key Agreement (MKA) or EAPoL- Announcement (Specific) frames. Zero or one Access-Info Attribute is permitted within an Access- Accept, Access-Challenge, Access-Reject, Accounting-Request, CoA- Request or Disconnect-Request packet. When sent along with the Network-Id-Name Attribute, the Access-Info Attribute provides Access status information relating to that particular NID-Name. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: reopened Priority: critical | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Sun Jul 14 20:58:30 2013 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 CDE1821F9DB4 for ; Sun, 14 Jul 2013 20:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 zVr5sSGHwyBj for ; Sun, 14 Jul 2013 20:58:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3FB21F9DB1 for ; Sun, 14 Jul 2013 20:58:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:49941 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UyZvc-0006ro-L2; Mon, 15 Jul 2013 05:58:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 15 Jul 2013 03:58:24 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/169 Message-ID: <066.c432cc21d21b9ea3a853702eea13f968@trac.tools.ietf.org> X-Trac-Ticket-ID: 169 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130715035830.4A3FB21F9DB1@ietfa.amsl.com> Resent-Date: Sun, 14 Jul 2013 20:58:30 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #169: WLAN-SSID Attribute redundant 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, 15 Jul 2013 03:58:30 -0000 #169: WLAN-SSID Attribute redundant As currently defined, the WLAN-SSID attribute provides the same information that is already provided in the Called-Station-Id attribute, namely the SSID (maximum of 32 octets). Since encoding the same information multiple ways is likely to cause interoperability problems, the proposed resolution is to delete the WLAN- SSID attribute. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Sun Jul 14 21:19:12 2013 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 C1F8F21F9C88; Sun, 14 Jul 2013 21:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-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 obXimQaFeSpq; Sun, 14 Jul 2013 21:19:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6696B21F9AE6; Sun, 14 Jul 2013 21:19:12 -0700 (PDT) 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: 4.51.p2 Message-ID: <20130715041911.6899.25211.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 21:19:11 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ieee802ext-08.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, 15 Jul 2013 04:19: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 the IE= TF. Title : RADIUS Attributes for IEEE 802 Networks Author(s) : Bernard Aboba Jouni Malinen Paul Congdon Joseph Salowey Mark Jones Filename : draft-ietf-radext-ieee802ext-08.txt Pages : 29 Date : 2013-07-14 Abstract: RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifications on the usage of the EAP- Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ieee802ext-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ieee802ext-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From klaas@wierenga.net Mon Jul 15 05:36:27 2013 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 A9F6B21E808E for ; Mon, 15 Jul 2013 05:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 p+vWQCT9FctB for ; Mon, 15 Jul 2013 05:36:23 -0700 (PDT) Received: from out28-ams.mf.surf.net (out28-ams.mf.surf.net [145.0.1.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5469321E8082 for ; Mon, 15 Jul 2013 05:36:21 -0700 (PDT) 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 r6FCaEY4015422; Mon, 15 Jul 2013 14:36:14 +0200 Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=dhcp-10-61-106-199.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Uyi0P-000LsC-JN; Mon, 15 Jul 2013 14:35:53 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Klaas Wierenga In-Reply-To: <003501ce2c05$a2f4bd90$e8de38b0$@augustcellars.com> Date: Mon, 15 Jul 2013 14:36:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003501ce2c05$a2f4bd90$e8de38b0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1508) X-Antivirus: no malware found X-Bayes-Prob: 0.9999 (Score 4.7, 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: 0uK0AAerq - d69d5d7c8b62 - 20130715 X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "radext@ietf.org" , draft-wierenga-ietf-eduroam@tools.ietf.org Subject: Re: [radext] Comments on draft-wierenga-ietf-eduroam-00 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, 15 Jul 2013 12:36:27 -0000 On Mar 28, 2013, at 11:43 PM, Jim Schaad wrote: Hi Jim, It took a while, but we just submitted version 01 = (http://www.ietf.org/id/draft-wierenga-ietf-eduroam-01.txt) that = addresses your comments per below as well as a bunch of other changes, = like a paragraph on dynamic discovery and privacy considerations. Thanks again! Klaas (and Stefan, Tomasz) =3D=3D=3D > Remember you asked for it. >=20 > I am CC-ing the radext list for completeness not because I believe = this > should be a radext working group document. >=20 > 1. It is not clear to me that the use of RFC 2119 language is = appropriate > to a document that is describing what the current design is. Hmm, I understand the point, but we use that language on purpose in our = policy docs as well, perhaps a clarifying text to that extent? Proposed text: "Note: The policy that eduroam participants subscribe to = expresses the requirements for participation also in RFC 2119 language. " >=20 > 2. Introduction: Suggest that the introduction should give a layout = of the > document as well. Specifically there are two ways to organize the = second > half of the draft or and it = would > be good to set expectations of this upfront. OK, proposed text: "First this memo describes the original architecture = of eduroam. Then a number of=20 operational problems are presented that surfaced when eduroam gained = wide-scale deployment. Lastly, enhancements to the eduroam architecture that mitigate the = aforementioned issues=20 are discussed. " >=20 > 3. Given that RFC 6614 and 6613 are experimental - do you want to say = /IETF > standardization efforts/? I think we can argue that it is a standardization *effort* even if it = has not led to formal standardization yet >=20 > 4. Section 1.3 - Who has to be able to identify users? Just the IdP = or the > NAS as well? =20 Proposal: "The access provider (SP) needs to be able to determine = whether a user is authorized to=20 use the network resources. Furthermore, in case of abuse of the = resources, there is a=20 requirement to be able to identify the user uniquely (the IdP). = Lastly, it should not=20 be possible for a person to impersonate someone else or take over = their identity." >=20 > 5. what does it mean to either impersonate someone or to take over = their > identity? If I give you my name and password it is possible for you = to > impersonate me. This language should be tightened. Text rephrased to: ""The access provider (SP) needs to be able to = determine whether a user is authorized to=20 use the network resources. Furthermore, in case of abuse of the = resources, there is a=20 requirement to be able to identify the user uniquely (the cooperation = of the user=92s IdP is required)." >=20 > 6. Do you really want me to be able to access your network or are you = going > to provide a public network for me to be able to access and use? It = might > need to be clearer what is going on. The first implies a greater = degree of > identification that might actually exist. Added: "Note: traffic separation between guest users and normal users is = possible (for example through the use of VLANs), often desirable and = widely used in eduroam." >=20 > 7. I can see three different vectors of scalability - it might be = useful to > tease that out. Users, Orgs providing access, Orgs hosting users. = Are the > last two a one-to-one or not? =20 >=20 I think we address that further down > 8. For whom does it need to be easy to install and use - just clients = or > organizations as well? Can it be hard for an org to setup and still = be easy > for clients? added: "for both organizations and users" >=20 > 9. In the paragraph on security, I don't understand the purpose of = the > first sentence. This would tend to argue that secure is not an = absolute > design goal. There may be a trade off, but that would be a design = goal of > usability which is separate. changed to: "It is important to have a system that strikes a good = balance between ease of use and security. " >=20 > 10. The goal is secure and privacy preserving - however there is = nothing in > the text about who the privacy is supposed to be protected from. = While I > guess it could be the third part, that is hardly the limit of who one = could > wish for privacy to be protected from. Do you care about privacy from = the > visited SP? Should the IdP be able to know who the client is = visiting? We split security and privacy as follows: =93Secure One important design criteria has been that there needs to be a security = association between the end-user and their home organization, = eliminating the possibility of credentials theft. The minimal = requirements for security are specified by the eduroam policy. As an = additional protection against user errors and negligence, it should be = possible for participating organizations to set their own additional = requirements for the quality of authentication of users without the need = for the infrastructure as a whole to implement the same standard. Privacy preserving The design of the system provides for user anonymization, i.e. it should = be possible to hide user=92s identity from any third parties including = visited institutions.=93 >=20 > 11. It is laid out that organizations should be able to set their own > authentication structure. Is there going to be a minimum security = that is > imposed on organizations by the eduroam federation? addressed in the text addition above >=20 > 12. Were any other options considered for the architecture? If so = why were > they not used?=20 added: "Three architectures were trialed: one based on the use of = VPN-technologie (deemed=20 secure but not-scalable), one Web captive-portal based (scalable but = not secure) and=20 802.1X-based, the latter being the basis of what is now the eduroam = architecture." >=20 > 13. Section 2 - If you read the ABFAB architecture document, I think = we > talk about three different trust relationships. Two of which are > "pre-existing" and one of which is established during the protocol. =20= I think that is what is stated in the text: user-IdP, IdP-SP and the = transitive trust between user and SP. Ah, I now see why there is = confusion, adjusted text. >=20 > 14. Going from the term type of trust to trust relationship does = don't flow > well. >=20 changed to "trust relation" everywhere > 15. The term establishment is potentially confusing in this location. = Are > you talking about for a single event or initial establishment (i.e. > introduction ) between the user and the IdP. ack, removed the establishment phrase, it is not about introduction >=20 > 16. Section 2.1 - I can understand that authentication uses EAP. = However > how does it use 802.1X and not use RADIUS for authentication? If = 802.1x > does anything other than carry EAP this should be covered. Otherwise = you > should probably include RADIUS here as well. I added "(carried over RADIUS)" >=20 > 17. Section 2.1.1 ?? wireless networks MUST support WPA2+AES - What = does > this mean? It is a requirement that all networks deploy this or = merely that > the hardware has the capability to use it? If a network deploys both = WPA2 > and WPA does that require that multiple SSIDs be used? If so is there = a > naming convention that is documented for this usage type? They MUST deploy WPA2+AES, they MAY deploy WPA for legacy reasons. The = only SSID for both is 'eduroam' (given that one SSID can advertise = support for both simultaneously), the idea is to over time phase out WPA = (as was done previously with WEP) >=20 > 18. What are the security implications of not knowing who the SP is - = since > all SSIDs are "eduroam" it is not possible to distinguish from a user > perspective which are not to be used. added: Note: A direct implication of the common eduroam SSID is that the = users cannot=20 distinguish between a connection to a home network and a guest = network at another=20 eduroam institution (802.11-2012 does have the so-called = =93Interworking=94 extensions to make that distinction, but=20 these are not widely implemented yet). Therefore, users should be made aware that they should not assume data = confidentiality in the=20 eduroam infrastructure. >=20 > 19. Discuss the trade of for not always using "eduroam-foo" as the = SSID added: "The downside of the latter is that clients=20 will not automatically connect to that SSID, thus losing the seamless = connection=20 experience." >=20 > 20. Section 2.1.2 - What guidance is the federation giving on EAP = methods - > is that of interest to this document? see the text under figure 1 >=20 > 21. What is the "policy with regards to security properties" >=20 changed to: "as long as they adhere to minimal requirements as set in the eduroam policy (which change over time).", see also text = under figure 1 > 22. I don't understand the purpose of Figure 1 - It does not appear = to be > reference from the text in any way. The picture would seem to be > underspecified in that the specific protocols are not put any place = (i.e. > X802.1x) and the term EAP tunnel is not introduced in any manner. As = with > the ABFAB document I did like that it is not clear that the tunneled = eap is > not traveling directly between the host and the authentication server. >=20 I added: "As depicted in Figure 1, the use of a tunneled EAP-method = creates=20 a direct logical connection between the supplicant and the = authentication=20 server, even though the actual traffic flows through the = RADIUS-hierarchy." > 23. Note that mutual authentication does not imply privacy. If I > authenticate with EAP-TLS and send both the server and the client > certificates in the clear then I have mutual authentication however I = have > no privacy on identities. >=20 The sentence =93In order to preserve privacy, participating organizations MUST deploy = EAP-methods that provide mutual authentication.=94 should read: =93In order to preserve credentials protection, participating = organizations MUST deploy EAP-methods that provide mutual = authentication.=94 > 24. The term outer identity is problematic. There is the EAP outer > identity - and then there is the RADIUS user-identity attribute. The > routing is done on the later and it is generally (but not always) = copied > from the initial EAP method. However not all methods will have a = distinct > inner identity. Is there an identity that is transmitted on 802.1x = that is > used rather than the first eap name? should be ok with the previous change? >=20 > 25. When did you suddenly say than a TLS tunnel was required. If = this is > true it should be stated someplace explicitly. This is not a = requirement on > IdPs that was not there before. =20 I don't think we do >=20 > 26. Do you want to say that outer identities must be NAIs or not? The current policy consciously removed RFC4282 as a normative name = format because that RFC is somewhat broken. We will refer to the revised = NAI document when it=92s published; until then we helped ourselves by = explaining that it needs to be @-delimited with a DNS-domain-like = structure to the right. I wouldn=92t use the term NAI these days, as it = is highly debated in radext what exactly that *is* in the first place. >=20 > 27.. Section 2.2.1 - You just sprang a national server on me without > telling me what it represents. Are you assuming that all routing is = two > levels deep or is there three and four level deep routing. =20 The routing can be deeper than two levels. The smallest maximum depth = from a leaf (SP, IdP) to the root is two: leaf, national, international. = However, more intermediaries can come in; some countries have =93regional=94= servers which add a node between leaf and national; and some of the = nodes we consider leafs can also extend further (e.g. an IdP could have = independent departments, all having their own RADIUS server). I changed the wording slightly and added: "Note: In some circumstances = there may be more levels of RADIUS servers, like for=20 example regional ones." > 28. Do you want to say at this point who is operating the national = servers > and root servers? On what basis will they setup or remove shared = secrets > with organisations? hmm, do you think this operational stuff should be in? >=20 > 29. What are the trade offs of using anonymous@surfnet.nl vs = @surnet.nl for > the outer identity? The empty left-hand side is the recommended format of RFC4282, but it = has the downside of some supplicants or IdP servers choking over it = apparently. >=20 > 30. What, if anything needs to be said about the trust needed between = the > access points and the organization RADIUS server. Is this under some = type > of protections? >=20 added =93Note: The security of the connections between local wireless = infrastructure and local RADIUS servers is a part of the local network = of each SP, therefore it is out of scope of the document. For = completeness it should be stated that security between actual access = points and their controllers is vendor specific, security between = controllers (or standalone access points) and local RADIUS servers is = based on the typical RADIUS shared secret mechanism.=94 > 31. Section 3 - Not all of the issues appear to be future problems = that are > expected. This paragraph should be expanded to say that current = operations > have identified problems, in addition others are expected with an = increase > of =85 changed text to: "While the hierarchical RADIUS architecture in the = previous section has served as the basis for eduroam operations for an entire decade, the exponential growth of authentications is expected to lead to, and have = in fact in=20 some cases already lead to, performance and operations bottlenecks on the aggregation proxies. The following = sections describe=20 some of the shortcomings, and the resulting remedies." >=20 > 32. Section 3.1 - I think the word you are looking for is deduced = rather > than deducted in many of these sentences. ack >=20 > 33. I have a slight problem with the fact that you are using down the > authentication path since you have just told me that it is a tree and = thus > has both an up and a down component. 'Along' might be a better = choice. >=20 ack > 34. I would not use the term proxy chain when looking at the length. = I > would just say that the radius authentication chain contains more than = one > hop. If there were no proxies then you have no problems, but in that = case > the proxy chain is 0 hops? 1 hop? Not clear. hmm, but the authentication chain refers also to the supplicant, the NAS = etc., whereas this is specific to the RADIUS servers on the path >=20 > 35. I assume that if a server which is believed to be "dead" sends = you an > authentication request then you would also know that it is now live = (step 3) >=20 No, I don=92t think that=92s correct. Packet flows are always from SP to = IdP, with replies coming back. It=92s a directional graph. If you see = something coming from the other direction, then that hop acts as an SP. = It may well be that the SP function of a site is up, while it=92s IdP = function is not. It=92s not good to expect that =93the whole thing came = back=94 > 36. One option that is not discussed here is the option of always = flooding > and never assuming anything but realms fail. What are the operational > problem with this approach. >=20 this is discussed in = http://wiki.eduroam.cz/dead-realm/docs/dead-realm.html that we reference > 37. Presumably the use of TCP rather than UDP would also help this > situation. Since you seem to be talking about ways that can be used = to fix > this here. yes, mentioned further down >=20 > 38. Section 3.2 - ? reactively or retroactively? changed the whole sentence to: "The ability to send Status-Server = watchdog requests is only of use after the fact, in case a downstream server doesn't reply (or hasn=92t= been contacted in a long while, so that it=92s previous working state = is stale)." >=20 > 39. You don't say how much improvements from section 3.1 would deal = with > this issue. If you could get reliable - don't fail because I did not = get a > reply - does this help the situation in the event of no reply? Also this is extensively discussed in = http://wiki.eduroam.cz/dead-realm/docs/dead-realm.html >=20 > 40. What would be the security implications of being able to inject = an > error code into the stream by a middle man? Are they any worse than = the > injection of an access-deny? What error codes are you referring to? Afaik RADIUS doesn't have any. >=20 > 41. Do you need to talk about dropped packets in this context as well = as > dead servers? All failover is implementation-specific, so it's hard to say anything = for sure. In all implementations I know, a series of packets need to get lost before a server is assumed dead; the number is often configurable. So, just a bit of packet loss is not something that creates problems in terms of marking-dead. It merely increases time-to-auth for the request in question, because the NAS needs to re-transmit this packet. >=20 > 42. If 802.1x does not allow for returning errors. Are you = suggesting that > the RADIUS servers would inject EAP packets in the event of failures = or > should this be handled by the NAS? These happen on the first exchanged packet; an EAP-Identity from the = client, but no conversation going on yet. That=92s why the top-level = servers send an Access-Reject *without EAP-Message* in their reply. = Injecting EAP would be very evil! >=20 > 43. Section 3.3 - You need to tell me what a ccTLD and a gTLD are expanded acronyms >=20 > 44. What are the "downsides" to routing based on insertion of new > "national" servers that can talk directly to the org servers? These > servers would potentially need to be more intelligent - but it would > restrict the places where tables need to be routed. Was this = considered? Yes; administratively not wanted and operationally impractical. E.g. = shared secret negotiation with that fake =93national=94 server involves = people from around the globe in their actual countries - language = barrier etc. Also, these servers need to adhere to their respective = *national* polciies, but RADIUS connectivity enforcement is at the fake = national server, a third party. Also =93who owns .xyz=94 (i.e. where is = it located physically) is both a political question and one of = performance (round-trip time varies significantly depending on how close = you are). >=20 > 45. I am not sure that I understand why doing an add of a new route = would > be especially error prone. It seems that this should be easily = fixable by a > simple tool. Are you ever removing this from the table - it seems = that this > would be overwhelmed by adds. Are these mappings made at more than = just the > root level - that is not clear from the discussion although I assume = it > would be true. =20 perhaps we are just more stupid than other operational communities ;-)=20= >=20 > 46. Who are you imposing the recommendation on? Is this a new 802.1x > requirement for an updated draft? If so is this really what you want = - or > do you want to be able to negotiate the L2 packet size all the way = down? ehm=85 It is not a protocol recommendation - it's a call for implementations to = make a sane choice of size when crafting the packet. The Framed-MTU attribute already provides the information of the L2 max size on the supplicant link. The number of attributes (=3Dbytes) added = by proxies is unknown and variant. I don't think a negotiation would work reliably. However=85. thinking more about this, this is probably an issue that is = overtaken by events=85.=20 This recommendation comes from back in the day when we discovered that UDP fragmentation can kill auths if firewalls in the middle discard UDP fragments (surprise!). Our reaction back then was that we thought there's nothing we can do about those firewalls and = need to adapt the protocol sizes. Today, we think that this approach was wrong. If people deploy broken network equipment which unduly discards packets, then what they need to do is FIX THEIR EQUIPMENT. And I believe that this has happened in eduroam quite consistently. It's been a long time since I've heard from serious EAP-TLS problems. And that's not because supplicant vendors have listened and reduced the payload size for us (I much rather believe they ignored us or simply were not aware of our existence) - it's because internally in eduroam we got the message across that admins need to watch their firewalls. Many NRENs for example include oversize packet checks in their monitoring infrastructure. So in summary we propose to remove the paragraph ;-) >=20 > 47. For whom are they hard to diagnose? Are you just talking about = users or > are you talking about IT departments as well? Are there = recommendations on > how to do this diagnosis? Replaced last paragraph of 3.4 with: "Both of the previously mentioned = sources of errors (packet loss, fragment discard) lead to significant = frustration for the affected users. Operational experience of eduroam = shows that such cases are hard to debug since they require coordinated = cooperation of all eduroam administrators on the authentication path. = For that reason the eduroam community is developing monitoring tools = that help to locate fragmentation problems." >=20 > 48. Section 3.5 - Are EAP MSKs used in this configuration? If so = then you > have low level encryption on these and it could potentially be stolen = and > used. No, no MSKs, but rather server certificates, and proper settings >=20 > 49. It is not clear to me that using a pseudonymous client identifier = for > the client does much of anything to prevent linking to an actual = client. > You still can build a large mobility profile. There are two issues here. We identify problems related to the privacy = and essentially state that they cannot be easily rectified. Pseudonymous = identifiers are better from identifiers that explicitly expose user=92s = identity. It is up to the IdP to balance between the lack of anonymity = provided by EAP-TLS and the full credentials security. However the = motivation for 3.5 is to show that these unavoidable flaws can be made = less serious if traffic encryption is introduced. IThat is what we are = trying to say. >=20 > 50. You have not dealt with the issue for TLS of checking that the = server > certificate is still valid. This is also not currently done. True, this is a problem, albeit not specific to eduroam but EAP in = general. I don't think there is any good solution to that problem yet = (OCSP stapling?) >=20 > 51. Have you brought up the concept of an EAP configuration meta data > format in the EMU group? It is about to close. We brought it up at a AAA doctor=92s slot, and were told the best place = is likely opsarea/opsawg. We=92ll go there with an I-D in one of the = next meetings; not Berlin. >=20 > 52. Is there a reason why you don't reference RADIUS-TLS at this = point as > this would deal with this issue to a certain extent. I.e. no = protection > from the proxies but from eavesdroppers. I hope that the introductory text explaining how we separated problems = from potential solutions addresses this point >=20 > 53. Section 4.1.1 - why is the translation not satisfactorily = answered by > NASREQ? If a Diameter response is an Error response, it can=92t be translated to = RADIUS. NASREQ is silent what to do then - Access-Reject? Remain silent? = Also, if the Diameter reply has an attribute >253 bytes, no way to = convert it. The suggested way in NASREQ is to treat this as = Access-Reject, which is not a satisfactory result. Actually, this one = could go away with the extended attributes RFC. >=20 > 54. The last pargraph of 4.1.1. should be the first paragraph of = 4.1.2 ehm, it is intended as a segway into 4.1.2=85 >=20 > 55. Section 5 - It would seem that placing the policy enforcement = with > Chargeable User Identity at the RADIUS server nearest the NAS - or at = the > edge of the organization, would make as much sense as placing it on = the NAS > itself. This would allow for correlation between different access = points > and given a better idea of abuse on the network as a whole. Thus = using the > servers that do this would solve the problem better. If CUI support is built into the NAS then we have a lot more information = on the NAS level. If CUI is not on the NAS but retrofitted in the = server, then the server gets the same amount of information as before, = but NAS does not get anything, therefore the first scenario is a lot = more useful and should be promoted in the vendor community. >=20 > 56. Section 5.1 - It may be also taken as evidence that you have no = idea of > what is going on as you have not identified the serious incident as = being > serious. good point ;-) added: "It could of course also mean that we lack the proper tools or = insight into=20 the actual use and potential abuse of the service. In any case, many = of the attack=20 vectors that exist in open networks or networks where access control = is based on=20 shared secrets are not present, arguably leading to a much more = secure system." >=20 > 57. Section 5.2 - How does the fact that the home site is now going = have > the ability to block reflect back on the question of differences of = opinion > on if the action was abuse or not? What type of protocol is setup for > dealing with this type of request- is it automated, done by hand or = through > the infrastructure? changed the last paragraph of 5.1 to "The first action in the case of an = incident is to block the user's access to eduroam=20 at the visited site. Since the roaming user's true identity is = likely hidden behind=20 an anonymous/fake outer identity, the visited site can only rely on = the realm of the=20 user. Without cooperation from the user's home institution, the SP's = options are=20 limited to blocking authentications from the entire realm, which may = be considered as=20 too harsh. On the other hand, the home institution has only the = possibility of=20 blocking the user's authentication entirely, thus blocking this user = from accessing=20 eduroam in all sites. With eduroam becoming more and more global it = can be=20 expected that differences of opinions in interpreting user=92s = actions may arise between=20 SPs and IdPs. It is the obvious right of an SP to provide guest = access only under certain=20 conditions, when these conditions are violated by the user, the = network access may be=20 blocked at the current site, however there may be situations where = such a restriction=20 should only apply at a given SP and not eduroam as a whole. The = initial implementation=20 has been lacking a tool for an SP to make it=92s own decision of for = IdP to introduce a=20 conditional rule applying only to a given SP. The introduction of = support for=20 Operator-Name and Chargeable-User-Identity (see below) to eduroam = will make both of=20 these scenarios possible." that should address your point >=20 > 58. Section 5.3 - Given that home servers are required to regularly = churn > CUIs, how does this affect the local accounting problems in terms of > tracking and preventing people from abusing the system. Can the home = IdP > simply deal with this issue by changing the CUI of an individual every = time > an abuse is reported? While there is no REQUIREMENT for CUI churning, the CUI RFC does say: "Furthermore, where a reference is used to a real user identity, it is = recommended that the binding lifetime of that reference to the real = user be kept as short as possible." It also says: " The binding lifetime of the reference to the user is determined based = on business agreements."=20 The typical CUI usage scenario is within a charging environment where = billing periods apply. eduroam does not have any billing, therefore it = does not have a natural CUI lifetime either.=20 Our implementation in FreeRadius does not address this issue at all. = This may be a weakness on the implementation side, however adding this = would vastly complicate things, requiring the server to keep track if = validity periods.=20 The suggestion that CUI should be changed each time an incident is = reported would apply to a negligible number of cases and would not in = any case increase the privacy of all users who are not responsible for = any misconduct. Therefore is really not worth the trouble. Anyway, the = eduroam policy currently states that the CUI value MUST stay constant. we would prefer not to tackle this in this draft though=85 > Random changes >=20 > s/Abfab/ABFAB/ ack > s/in all continents/on all continents/ ack > s/like for example/like/ ack > s/alternative use/alternative uses/ ack > s/foresaw/?????? - I am not sure what this sentence is supposed to = say/ foresaw -> fore >=20 > Update reference to privacy terminology draft - it is now > draft-jab-private-considerations s/private/privacy, but ack From stefan.winter@restena.lu Tue Jul 16 05:53:57 2013 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 4220021F9D8F for ; Tue, 16 Jul 2013 05:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, 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 CdhLHVRptEPc for ; Tue, 16 Jul 2013 05:53:56 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7F86521F9E33 for ; Tue, 16 Jul 2013 05:53:23 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E1CDB1058A for ; Tue, 16 Jul 2013 14:53:21 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D2AE110583 for ; Tue, 16 Jul 2013 14:53:21 +0200 (CEST) Message-ID: <51E5423E.8030002@restena.lu> Date: Tue, 16 Jul 2013 14:53:18 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <065.8e3b593ce94ff54b06f468a19aa3f87e@trac.tools.ietf.org> <51D579F1.20905@restena.lu> In-Reply-To: <51D579F1.20905@restena.lu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TCTSTLSIPNSFQRDBOTGI" X-Virus-Scanned: ClamAV Subject: Re: [radext] #168: Remaining issues for dynamic-discovery draft 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, 16 Jul 2013 12:53:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TCTSTLSIPNSFQRDBOTGI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I'm currently assembling a slide deck (yes, I know, I'm too early ;-) ) for IETF87, and am wondering which of these issues deserve some airtime during the Berlin meeting. In summary, my idea of those issues is: 1) NAIRealm certificate extension --------------------------------- get an OID for UTF8String; no opinion about intermediate wildcards (foo.*.bar) 2) Privacy (JS) --------------- Suggest: no text update needed. 3) subsequent lookup steps (JS) ------------------------------- Scheduled for discussion in detail on slide deck, including input from Brian Julin. All, especially Jim, if you're happy about the no-text action on issue 2, please let me know. And if anyone has strong feelings about the wildcard thing - please do hit the Reply button. 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 ------enig2TCTSTLSIPNSFQRDBOTGI 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHlQkEACgkQ+jm90f8eFWYwXgCfSLJBb1UugjzyTNvRmWSB7oxG 1NwAn2bHKGA7bdyIhO0NoK0q31510AOg =xU+C -----END PGP SIGNATURE----- ------enig2TCTSTLSIPNSFQRDBOTGI-- From stefan.winter@restena.lu Tue Jul 16 06:07:56 2013 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 BB6EE21F9D5C for ; Tue, 16 Jul 2013 06:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 3xPiFlfZDBcK for ; Tue, 16 Jul 2013 06:07:56 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id CB5E221F9AC6 for ; Tue, 16 Jul 2013 06:07:55 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 20F831058A for ; Tue, 16 Jul 2013 15:07:55 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 11FF010583 for ; Tue, 16 Jul 2013 15:07:55 +0200 (CEST) Message-ID: <51E545A6.6040008@restena.lu> Date: Tue, 16 Jul 2013 15:07:50 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> In-Reply-To: <51DE5730.4080008@deployingradius.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MBLONTLPVJWMJNEMNHKK" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 16 Jul 2013 13:07:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MBLONTLPVJWMJNEMNHKK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> My point so far is: loops can occur, so we should do all we can to >> detect and prevent them. This requires all NAPTR -> SRV -> A/AAAA >> lookups to be done, and look for inconsistencies in the resulting set.= >> >> Brian's counter-point is: loops can happen also outside dynamic >> discovery, too; and will fix themselves by busting RADIUS packet >> boundaries. In the interest of speed, let's be less thorough in findin= g >> them and take shortcuts in DNS response evaluation wherever possible. >=20 > Sounds good to me. I'd feel good about the more relaxed attitude if there *were* a loop detection that works reliably, and independent of the discovery mechanism (DDDS vs. config file). I'd like to bring up the topic of a dedicated "TTL" attribute in Berlin (again, as I've previously received some beating for proposing it). I think this time the underlying situation has changed: Sam's proposal to lift the packet size boundary on TCP/TLS links means eternally-proxies packets now can bounce a LOT longer between hops until their aggregated Proxy-State size busts the packet limits. Relying on that sort of phenomenon becomes less and less useful IMHO. >> General loop detection in RADIUS is an issue beyond the scope of the d= raft -- >> albeit one which does deserve some attention. >=20 > That's very true. Good :-) It would be very simple and straightforward to write an I-D registering an integer attribute "Packet-TTL", with an integer value that is to be decremented. > It may be worth updating the draft to suggest that servers using > dynamic discovery either: >=20 > (1) use the same address for incoming and outgoing packets >=20 > (2) publish a different DNS record indicating their outgoing address >=20 > The SMTP world has had similar issues for a long time. Solutions lik= e > SPF may be applicable here. Yet another new DNS record would add much complexity to the draft; for little benefit. The TTL would solve this in one go. It would be equivalent to the SMTP's "Too many Received headers: suspecting a loop", much more than SPF. > I agree. This also brings up issues of authenticating the DNS > records. It may be useful to have reverse IP records, which serve as a= > cross-check. >=20 > e.g. if looking up "example.net" gets you 192.12.6.10, then doing a > reverse IP lookup on that IP should get you "example.com" (among others= ). >=20 > The document doesn't discuss reverse IP records or lookups. It doesn't, because the authentication of the results learned is done by X.509 certificate inspection during connection time. I find that a much more reliable mechanism than reverse IP checks. (if an attacker can fake an A record, then it may also be able to fake a PTR record). >> In general these problems are of the type that will not self-heal and= /or >> they indicate a security incident which merits notification of an admi= nistrator. >> Most implementations will probably elect not to permanently poison a r= ealm for >> fear that a single spoofed DNS result could use this as a DoS. They s= hould be >> at least encouraged to log such episodes as security events. >=20 > Having a reverse IP lookup can help with this situation. If the > forward and reverse records don't match, then that can be discovered > automatically. And before the proxy starts a secure connection to the > home server. Having it attempt /one/ TLS connection to the target doesn't consume much computing power. The discovering server could also keep a list of servers it has recently tried and found unacceptable; and save itself the effort of trying over and over again. This could be mentioned in Security Considerations, if you find it useful/important to have? Greetings, Stefan Winter >=20 > Alan DeKok. > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2MBLONTLPVJWMJNEMNHKK 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHlRaoACgkQ+jm90f8eFWbwgwCeP4V38X/koJjEvxW661PkMoHP iv0AoIm9m2SSQ7YtNvGVRWCrQjIrFOzS =huHQ -----END PGP SIGNATURE----- ------enig2MBLONTLPVJWMJNEMNHKK-- From aland@deployingradius.com Tue Jul 16 06:36:47 2013 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 206C211E80F6 for ; Tue, 16 Jul 2013 06:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzGqO6KXQ2VV for ; Tue, 16 Jul 2013 06:36:41 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02E6221E80B1 for ; Tue, 16 Jul 2013 06:36:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EB036224012A; Tue, 16 Jul 2013 15:35:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpCo6XunBi9c; Tue, 16 Jul 2013 15:35:41 +0200 (CEST) Received: from pc24.home (AAnnecy-157-1-115-178.w90-9.abo.wanadoo.fr [90.9.58.178]) by power.freeradius.org (Postfix) with ESMTPSA id 8497F22400DD; Tue, 16 Jul 2013 15:35:41 +0200 (CEST) Message-ID: <51E54C2E.80002@deployingradius.com> Date: Tue, 16 Jul 2013 15:35:42 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> In-Reply-To: <51E545A6.6040008@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 16 Jul 2013 13:36:47 -0000 Stefan Winter wrote: > Good :-) It would be very simple and straightforward to write an I-D > registering an integer attribute "Packet-TTL", with an integer value > that is to be decremented. It may also be good to add a "Global-Packet-ID". The idea would be that it's a 64-bit or 128-bit opaque token, created by the client. (Or a proxy close to the client). Other proxies would then never touch it. It could be cached by proxies for a period of time. If a proxy sees the same Global-Packet-ID in two different packets, it knows there's a loop or retransmission via an alternate path. > Yet another new DNS record would add much complexity to the draft; for > little benefit. The TTL would solve this in one go. The TTL wouldn't solve the forward / reverse problem. Using a reverse IP would catch that. >> The document doesn't discuss reverse IP records or lookups. > > It doesn't, because the authentication of the results learned is done by > X.509 certificate inspection during connection time. I find that a much > more reliable mechanism than reverse IP checks. That's true. > (if an attacker can fake > an A record, then it may also be able to fake a PTR record). I'm not sure I agree there. I can fake an A record for my own domain. But I can't fake a reverse IP record for an IP which you control. > Having it attempt /one/ TLS connection to the target doesn't consume > much computing power. The discovering server could also keep a list of > servers it has recently tried and found unacceptable; and save itself > the effort of trying over and over again. What about the discovered server? It would be subject to attacks by third parties. i.e. realm A lists proxy B as it's server via DDNS. It then publishes an article saying "free net access by using user@realmA". Everyone wanting free net access contacts proxy B. Repeat for 10,000 domains, and Proxy B gets a DoS. This should ideally be discovered *before* a using high-cost connection like TLS. That's why a reverse lookup is useful. Now... this is RADIUS, and there aren't that many RADIUS proxies. But if the DDNS draft makes it easier, there will be more RADIUS proxies, and more possibility for such an attack. > This could be mentioned in Security Considerations, if you find it > useful/important to have? Yes. Alan DeKok. From gaobo@sttri.com.cn Tue Jul 16 06:31:30 2013 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 0750211E80F6 for ; Tue, 16 Jul 2013 06:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457] 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 LV7LEdsJ7QSu for ; Tue, 16 Jul 2013 06:31:14 -0700 (PDT) Received: from corp.21cn.com (corp.forptr.21cn.com [121.14.129.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9898C11E80E6 for ; Tue, 16 Jul 2013 06:31:08 -0700 (PDT) Received: from ip?58.34.217.97? (unknown [10.27.101.9]) by corp.21cn.com (HERMES) with ESMTP id 1E40A1A4814; Tue, 16 Jul 2013 21:31:00 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.10.27.101.9.81620660 HMM_SOURCE_TYPE: WEBMAIL Received: from ip<58.34.217.97> ([58.34.217.97]) by 21CN-entas9(MEDUSA 10.27.101.9) with ESMTP id 1373981463.19176 for stefan.winter@restena.lu ; Tue Jul 16 21:31:06 2013 0/X-Total-Score: -120: 1/X-Total-Score: 3: 3/X-Brightmail-Tracker: AAAAAA== X-FILTER-SCORE: to=<94958687828f4f988a8f9586936193869495868f824f8d969996868d8a6189968298868a4f84908e938285869995618a8695874f909388>, score=<1373981466laXN0AcHFQlllllallXllNEwQfbsW4e22222E22w22Q2> X-REAL-FROM: gaobo@sttri.com.cn X-Receive-IP: 58.34.217.97 gaobo@sttri.com.cn Date: Tue, 16 Jul 2013 21:31:02 +0800 (CST) From: =?UTF-8?B?6auY5rOi?= To: Stefan Winter , Xueli Message-ID: <282253472.5481373981463196.JavaMail.hermes@ent-web4> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_580_1646969024.1373981462836" HMM_WEBCLN_IP: 10.27.10.89 X-HERMES-SENDMODE: normal X-HERMES-SET: cIGZxq/rTvOc1ZaFW8UJAdw6r+IdySmb X-Mailman-Approved-At: Tue, 16 Jul 2013 12:57:45 -0700 Cc: "radext@ietf.org" Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-01.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, 16 Jul 2013 13:31:30 -0000 ------=_Part_580_1646969024.1373981462836 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWw+CiA8aGVhZD48L2hlYWQ+CiA8Ym9keT4KICA8ZGl2PgogICAmbmJzcDsKICA8L2Rpdj4g CiAgPGRpdj4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDE1LjZw dCAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0i MyI+SGk8L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PD94bWw6bmFtZXNwYWNl IHByZWZpeCA9IG8gbnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl IiAvPgogICAgIDxvOnA+CiAgICAgIDxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZuYnNw OzwvZm9udD4KICAgICA8L286cD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBm YWNlPSJDYWxpYnJpIiBzaXplPSIzIj5UaGFuayB5b3UuPC9mb250Pjwvc3Bhbj48L3A+IAogICA8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPlBsZWFzZSBzZWUgbXkg cmVwbHkgZm9sbG93aW5nIGluIGJsdWUgbGluZS48L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+CiAgICAgPG86cD4KICAgICAgPGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+ Jm5ic3A7PC9mb250PgogICAgIDwvbzpwPjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxm b250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPlBsZWFzZSBhbGxvdyBtZSB0cnkgdG8gc25pcCB0 aGUgZW1haWwgYSBsaXR0bGUgaW4gb3JkZXIgdG8gbWFrZSBpdCBlYXN5IHRvIHJlYWQuIDwvZm9u dD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXpl PSIzIj5JIGhvcGUgdGhlIGZvcm1hdCBpcyBmaW5lIGZvciB5b3UuPC9mb250Pjwvc3Bhbj48L3A+ IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPgogICAgIDxvOnA+CiAgICAgIDxmb250IGZhY2U9IkNhbGlicmki IHNpemU9IjMiPiZuYnNwOzwvZm9udD4KICAgICA8L286cD48L3NwYW4+PC9wPiAKICAgPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj5CZXN0IFJlZ2FyZHM8L2ZvbnQ+ PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+CiAgICAgPG86cD4KICAgICAgPGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jm5ic3A7PC9mb250PgogICAgIDwvbzpwPjwvc3Bhbj48L3A+ IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPkJvIEdhbyA8 L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJH SU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+CiAgICAgPG86cD4KICAgICAgPGZv bnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jm5ic3A7PC9mb250PgogICAgIDwvbzpwPjwvc3Bh bj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPgogICAgIDxvOnA+CiAgICAgIDxmb250IGZhY2U9IkNh bGlicmkiIHNpemU9IjMiPiZuYnNwOzwvZm9udD4KICAgICA8L286cD48L3NwYW4+PC9wPiAKICAg PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mZ3Q7Jmd0OyBbeHVl bGldIEkgYXBwcmVjaWF0ZWQgdGhlIGNvbW1lbnRzIHRvIHNjZW5hcmlvIHRvIG9mZmxvYWQgdGhl IGF1dGhlbnRpY2F0b3I8L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQg ZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jmd0O2Z1bmN0aW9uIHRvIFNHVy48L2ZvbnQ+PC9zcGFu PjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jmd0 OyZndDsgVGhlcmUgYXJlIHR3byByZWFzb25zLCB3aGljaCBJIGNsYXJpZmllZCB0aGUgc2NlbmFy aW8gaW4gdGhlIGRvY3VtZW50PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxm b250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZndDt2ZXJzaW9uIDAxIGFzIDo8L2ZvbnQ+PC9z cGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+ Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7SW4gRUFQIGZyYW1ld29yaywgU0dXIGNv dWxkIGFjdCBhcyB0aGUgQXV0aGVudGljYXRvciBpbnN0ZWFkIG9mIEFDPC9mb250Pjwvc3Bhbj48 L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyZuYnNwO2JlY2F1c2Ugb2Ygc2V2ZXJhbCByZWFzb25zLiZuYnNwOyBG aXJzdCBvZiBhbGwsIGEgcG93ZXJmdWwgQUMgdGhhdDwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mZ3Q7Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyBhZ2dyZWdhdGVzIHRoZSBBdXRoZW50aWNhdG9yIGZ1bmN0aW9uIGlzIG5vdCBh IGFwcHJlY2lhdGVkIGNob2ljZSBmb3I8L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgc29tZSBvcGVyYXRvcnMuIFRoZXJlIGFyZSBsYXJnZSBudW1iZXJzIG9mIEFDIGRldmljZXMg aW4gdGhlIG9wZXJhdG9yczwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9u dCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBleGlz dGluZyBuZXR3b3JrLiZuYnNwOyBUaGUgQXV0aGVudGljYXRpb24gU2VydmVyIChBUykgd2lsbCBv dmVybG9hZCB0aGU8L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFj ZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jmd0O2NvbW11bmljYXRpb24gd2l0aCBsYXJnZTwvZm9udD48 L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIz Ij4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBudW1iZXJzIG9mIEFDIGRldmljZXMgaWYgQUNz IGFjdHMgYXMgdGhlIEF1dGhlbnRpY2F0b3IuPC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxmb250IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7CiAg ICAgIDxvOnA+CiAgICAgICAmbmJzcDsKICAgICAgPC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAog ICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZndDtUaGlzIGlz IHRoZSBwb2ludCB3aGVyZSB5b3UgbG9zdCBtZS4gV2h5IGlzIGl0ICZxdW90O25vdCBhcHByZWNp YXRlZCZxdW90OyBieSBvcGVyYXRvcnM/PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxmb250IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj4mZ3Q7CiAgICAg IDxvOnA+CiAgICAgICAmbmJzcDsKICAgICAgPC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZndDtTb21ldGltZXMg eW91IG5lZWQgdG8gYWRkIG5ldyBmdW5jdGlvbmFsaXR5IHRvIGEgZGV2aWNlOyB0aGUgdmVuZG9y IHdyaXRlczwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIzIj4mZ3Q7Y29kZSBhbmQgcHJvdmlkZXMgZmlybXdhcmUgdXBkYXRlcyBm b3IgdGhlc2UgZGV2aWNlcy4gRGVwbG95ZXJzIGFwcGx5IHRoZTwvZm9udD48L3NwYW4+PC9wPiAK ICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mZ3Q7ZmlybXdh cmUgdXBkYXRlLiBUaGF0IGlzIGEgbm9ybWFsIHBhcnQgb2YgZGF5LXRvLWRheSBvcGVyYXRpb25z IGluIGEgbmV0d29yay48L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 IkNPTE9SOiAjMWY0OTdkIj48Zm9udCBzaXplPSIzIj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJy aSI+Jmd0OwogICAgICA8bzpwPgogICAgICAgJm5ic3A7CiAgICAgIDwvbzpwPjwvZm9udD48L3Nw YW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4m Z3Q7SSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5b3UgZ28gb3V0IG9mIHlvdXIgd2F5IHRvIGRlZmlu ZSBhbiBlbnRpcmUgbmV3PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250 IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZndDsqcHJvdG9jb2wqIGp1c3QgZm9yIHRoZSBjb252 ZW5pZW5jZSBvZiBzYXZpbmcgYSBmaXJtd2FyZSB1cGRhdGUgaW4gYSBmbGVldCBvZjwvZm9udD48 L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIz Ij4mZ3Q7ZXF1aXBtZW50LiAoQW5kIG5vdCBldmVuIHRoYXQgaXMgdHJ1ZSwgc2VlIGJlbG93KTwv Zm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJ TjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBzaXplPSIzIj48L2ZvbnQ+ PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Jmd0OwogICAgICA8bzpwPgogICAgICAgJm5ic3A7CiAgICAg IDwvbzpwPjwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIzIj4mZ3Q7QXQgb3RoZXIgcGxhY2VzIHlvdSB3cml0ZSB0aGF0IGl0J3Mg ZGlmZmljdWx0IHRvIGltcGxlbWVudCBpbiB0aGUgYXV0aGVudGljYXRvcnM8L2ZvbnQ+PC9zcGFu PjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jmd0 O2FuZCBtb3JlIGNvbnZlbmllbnQgdG8gZG8gaXQgaW4gYSBjZW50cmFsIHBsYWNlLiBNeSBvbmx5 IHJlcGx5IHRvIHRoaXM6IHllcywgaXQnczwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mZ3Q7d29yayBhbmQgaXQgbmVlZHMg dG8gYmUgZG9uZS4gR2V0IG92ZXIgaXQuIEkgZG9uJ3Qgc2VlIGhvdyB0aGUgaGFzc2xlIG9mPC9m b250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNhbGlicmkiIHNp emU9IjMiPiZndDtkZWZpbmluZyBhIG5ldyBwcm90b2NvbCAtIHdoaWNoIGFsc28gbmVlZHMgdG8g Z2V0IGltcGxlbWVudGVkLCBhbmQgZmlybXdhcmU8L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+Jmd0O3VwZGF0ZWQgdG8gc3Vw cG9ydCBpdCAtIGlzIGluIGFueSB3YXkgZWFzaWVyIG9yIG1vcmUgdXNlZnVsLjwvZm9udD48L3Nw YW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMGNtIDBj bSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4KICAgICA8bzpwPgogICAgICA8Zm9udCBmYWNlPSJD YWxpYnJpIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+CiAgICAgPC9vOnA+PC9zcGFuPjwvcD4gCiAg IDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDE1LjZwdCAwY20gMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiAjMzY1ZjkxIj48Zm9udCBzaXplPSIzIj48 L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+W0JPXVRoZSBzY2VuYXJpbywgd2UgZGlzY3Vzc2Vk IGlzIHRoYXQgdGhlcmUgYXJlIGJvdGggQUMgYW5kIFNHVyBkZXBsb3llZCBpbiB0aGUgbmV0d29y aywgd2l0aG91dCBmdW5jdGlvbiBjb252ZXJnZWQuIAogICAgICA8bzpwPjwvbzpwPjwvZm9udD48 L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMTUu NnB0IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6ICMzNjVmOTEiPjxm b250IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj5BQyBpcyByZXNwb25zaWJs ZSBmb3IgQVAgbWFuYWdlbWVudCwgYW5kIFNHVyBpcyB0aGUgZ2F0ZXdheSBmb3IgdXNlciBtYW5h Z2VtZW50LCBpbmNsdWRpbmcgdXNlciBtYW5hZ2VtZW50IGFuZCBhZGRyZXNzIGFzc2lnbm1lbnQs IGV0Yy4gCiAgICAgIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJDT0xPUjogIzM2NWY5MSI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250 IGZhY2U9IkNhbGlicmkiPkluIHRoaXMgc2NlbmFyaW8sIHRoZXJlIGNvdWxkIGJlIHR3byBzb2x1 dGlvbnMgZm9yIGF1dGhlbnRpY2F0b3IuCiAgICAgIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48 L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42cHQgMGNt IDBwdCI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmkiPjw/eG1sOm5h bWVzcGFjZSBwcmVmaXggPSBzdDEgbnMgPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6c21hcnR0YWdzIiAvPgogICAgIDxzdDE6Y2htZXRjbnYgdzpzdD0ib24iIHRjc2M9IjAiIG51 bWJlcnR5cGU9IjEiIG5lZ2F0aXZlPSJGYWxzZSIgaGFzc3BhY2U9IlRydWUiIHNvdXJjZXZhbHVl PSIxIiB1bml0bmFtZT0iYWMiPgogICAgICA8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9S OiAjMzY1ZjkxIj4xIEFDPC9zcGFuPgogICAgIDwvc3QxOmNobWV0Y252PjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iQ09MT1I6ICMzNjVmOTEiPiBpcyB0aGUgYXV0aGVudGljYXRvciwgU0dXIG11 c3Qgc3VwcG9ydCBSQURJVVMgcHJveHkKICAgICAgPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDE1LjZwdCAwY20g MHB0OyBURVhULUlOREVOVDogNS4yNXB0OyBtc28tY2hhci1pbmRlbnQtY291bnQ6IC41Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiAjMzY1ZjkxIj48Zm9udCBzaXplPSIzIj48L2Zv bnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+LSZndDtUaGUgb3BpbmlvbnMgb24gdGhpcyBwb2ludCBw bGVhc2Ugc2VlIHRoZSByZXBseSBmb2xsb3dpbmcgdG8geW91ciBzZWNvbmQgY29uY2Vybi4KICAg ICAgPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJNQVJHSU46IDE1LjZwdCAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9IkNPTE9SOiAjMzY1ZjkxIj48Zm9udCBzaXplPSIzIj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2Fs aWJyaSI+MiA8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvc3Bhbj5TR1cg YWN0cyBhcyB0aGUgYXV0aGVudGljYXRvciwga2V5IGFubm91bmNlbWVudCBpcyBuZWVkZWQuCiAg ICAgIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJDT0xPUjogIzM2NWY5MSI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZhY2U9IkNh bGlicmkiPlRoZSBpc3N1ZSB3ZSBuZWVkIHRvIHJlc29sdmUgaW4gc3RhbmRhcmQgc29sdXRpb24u CiAgICAgIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJDT0xPUjogIzM2NWY5MSI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZhY2U9 IkNhbGlicmkiPkkgbXVzdCBjbGFyaWZ5IGhlcmU7IHdlIGFyZSBub3Qgc2F5aW5nIHdlIGNhbm5v dCBzdXBwb3J0IHNvbHV0aW9uIDEuIAogICAgICA8bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9w PiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMTUuNnB0IDBjbSAw cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6ICMzNjVmOTEiPjxmb250IHNpemU9 IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj5Ib3dldmVyIHRoZXJlIGFyZSBzb21lIGRp c2FkdmFudGFnZXMgd2hpY2ggbXVzdCBiZSBjb25zaWRlcmVkIGlmIHdlIHVzZSBzb2x1dGlvbiAx IC4gCiAgICAgIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogIzM2NWY5MSI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmkiPlRlY2hub2xvZ3kgc2lkZSBvZiB2aWV3OiBTR1cgaXMgb24gdGhlIGRhdGEg cGF0aCBvZiB1c2VyIHRyYWZmaWMuIFNHVyBpcyB0aGUgZ2F0ZXdheSBmb3IgdXNlciBtYW5hZ2Vt ZW50IGFuZCBhZGRyZXNzIGFzc2lnbm1lbnQuIFNvIFNHVyBtdXN0IGJlIFJhZGl1cyBwcm94eSB0 byBhY2hpZXZlIHVzZXIgbWFuYWdlbWVudCwgc3VjaCBhcyBjaGFyZ2luZyBhbmQgYWRkcmVzcyBh c3NpZ25tZW50LiBPdGhlcndpc2UsIGFsbCB0aGUgdHJhZmZpYyB3aWxsIHRyYW5zcGFyZW50IG9u IFNHVy4gSXQgY2Fubm90IGJlIGFjY2VwdGVkLgogICAgICA8bzpwPjwvbzpwPjwvZm9udD48L3Nw YW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMTUuNnB0 IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6ICMzNjVmOTEiPjxmb250 IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj5NYW5hZ2VtZW50IHNpZGUgb2Yg dmlldzogRm9yIG9wZXJhdG9ycywgdGhlcmUgYXJlIGVtcGxveWVlcyB3aG8gbWFuYWdlIGFuZCBo YW5kbGUgQUMgZGV2aWNlLiBUaGV5IGFyZSByZXF1aXJlZCB0byBoYXZlIGtub3dsZWRnZSBhYm91 dCBBQyBmdW5jdGlvbi4gU2ltcGxlIEFDIHdpbGwgcmVkdWNlIHRoZSByZXF1aXJlbWVudHMgZm9y IGVtcGxveWVlcy4gQWRkaXRpb25hbGx5LCB0aGVyZSBhcmUgbXVjaCBtb3JlIEFDcyB0aGFuIFNH VyBpbiByZWFsIG5ldHdvcmssIHdoaWNoIG1lYW5zIEFBQSB3aWxsIGNvbW11bmljYXRlIHdpdGgg bXVjaCBtb3JlIGNsaWVudHMgaWYgQUMgaXMgdGhlIGF1dGhlbnRpY2F0b3IgaW5zdGVhZCBvZiBT R1cuCiAgICAgIDxvOnA+PC9vOnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJDT0xPUjogIzM2NWY5MSI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmkiPldlIHNob3VsZCBoYXZlIGFub3RoZXIgb3B0aW9uYWwgc29sdXRpb24gZm9y IHRoZSByZWFsIG5ldHdvcmssIHdoaWNoIGlzIHNvbHV0aW9uIDIuIAogICAgICA8bzpwPjwvbzpw PjwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1B UkdJTjogMTUuNnB0IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6ICMz NjVmOTEiPjxmb250IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj5UaGV5IGFy ZSBib3RoIHBvc3NpYmlsaXRpZXMgZm9yIG9wZXJhdG9ycy4mbmJzcDsgCiAgICAgIDxvOnA+PC9v OnA+PC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i TUFSR0lOOiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxmb250IGZhY2U9IkNh bGlicmkiIHNpemU9IjMiPiZndDs8c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNw OyA8L3NwYW4+T24gdGhlIG90aGVyPC9mb250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjMiPiZndDs8c3BhbiBzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+aGFuZCwgU0dXIE1VU1Qgc3VwcG9y dCB0aGUgUkFESVVTIHByb3h5IGZ1bmN0aW9uIHdoZW4gQUMgYWN0cyBhcyB0aGU8L2ZvbnQ+PC9z cGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMyI+ Jmd0OzxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj5BdXRoZW50aWNhdG9yIGluIEVBUCBmcmFtZXdvcmsuPHNwYW4gc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj4mbmJzcDsgPC9zcGFuPkluIHRoaXMgc2NlbmFyaW8sIGJvdGggU0dXIGFuZCBB QzwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48Zm9udCBmYWNlPSJDYWxpYnJp IiBzaXplPSIzIj4mZ3Q7PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPnNob3VsZCBiZSByZXNwb25zaWJsZSBmb3IgYXV0aGVudGljYXRpb24g cHJvY2VkdXJlLjwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4KICAgICA8bzpw PgogICAgICA8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIzIj4mbmJzcDs8L2ZvbnQ+CiAgICAg PC9vOnA+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJH SU46IDBjbSAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGZvbnQgZmFjZT0iQ2FsaWJyaSIg c2l6ZT0iMyI+SSBhbHNvIGRvbid0IHNlZSB3aHkgdGhlIFNHVyBuZWVkcyB0byBiZSBhIFJBRElV UyBwcm94eS4gSWYgdGhlIGF1dGhlbnRpY2F0b3JzIGFyZSBpbXBsZW1lbnRlZCBjb3JyZWN0bHks IHRoZXkgaW1wbGVtZW50IHRoZSBSQURJVVMgY2xpZW50IHNpZGUgYW5kIGNhbiBiZSBjb25maWd1 cmVkIHRvIGNvbnRhY3QgYW55IFJBRElVUyBzZXJ2ZXIgdGhleSB3YW50LiBJZiB0cmFmZmljIGlz IGFkbWluaXN0cmF0aXZlbHkgKndhbnRlZCogdG8gZmxvdyBieSB0aGUgU0dXLCB0aGVuIHllcywg dGhlIFNHVyBtdXN0IGFsc28gaW1wbGVtZW50IHRoZSBSQURJVVMgcHJvdG9jb2wuIElmIG5vdCwg dGhlIGF1dGhlbnRpY2F0b3JzIGNhbiB0YWxrIHRvIHRoZSByZWFsIHRhcmdldCwgdGhlIGF1dGhl bnRpY2F0aW9uIHNlcnZlciwgb24gdGhlaXIgb3duLiBTbyB0aGlzIGlzIG5vdCBhIHByb3RvY29s IHByb2JsZW0sIGl0IGlzIGp1c3QgYSBkZXBsb3ltZW50IGNob2ljZS48L2ZvbnQ+PC9zcGFuPjwv cD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDE1LjZwdCAwY20g MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiAjMzY1ZjkxIj48Zm9udCBzaXpl PSIzIj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+W0JPXSBJbiB0aGUgc2NlbmFyaW8gZGVm aW5lZCBpbiB0aGUgZHJhZnQsIGlmIEFDIGFjdHMgYXMgdGhlIEF1dGhlbnRpY2F0b3IsIFNHVyBt dXN0IHN1cHBvcnQgUmFkaXVzIFByb3h5LiBJdCBkb2VzbuKAmXQgYWNjb3VudCB0aGF0IGltcGxl bWVudGF0aW9uIGlzIGNvcnJlY3Qgb3Igbm90LiBUaGUgbW90aXZhdGlvbiBpcyB0byBhY2hpZXZl IHVzZXIgbWFuYWdlbWVudCByZXF1aXJlbWVudCBvbiBTR1cuCiAgICAgIDxvOnA+PC9vOnA+PC9m b250Pjwvc3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lO OiAxNS42cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogIzM2NWY5 MSI+PGZvbnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmkiPkluIFdMQU4gbmV0 d29yaywgU0dXIGlzIHRoZSBnYXRld2F5IHdoaWNoIGNoYXJnZXMgdXNlciBtYW5hZ2VtZW50IGFu ZCBhZGRyZXNzIGFzc2lnbm1lbnQuIENvbnNpZGVyaW5nIHRoZSB1c2VyIGNoYXJnaW5nIGFuZCB1 c2VyIHRyYWZmaWMgZm9yd2FyZCBiZWhhdmlvciwgU0dXIG11c3QgcmVjb2duaXplIHRoZSB1c2Vy IGluZm9ybWF0aW9uIGJlY2F1c2Ugb2YgZm9sbG93aW5nIHJlYXNvbnMuIAogICAgICA8bzpwPjwv bzpwPjwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Ik1BUkdJTjogMTUuNnB0IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6 ICMzNjVmOTEiPjxmb250IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj5Gb3Ig ZXhhbXBsZSwgU0dXIG11c3QgcmVjb2duaXplIHdoZXRoZXIgdGhlIHNwZWNpYWwgdXNlciBpcyBh dXRoZW50aWNhdGVkIG9yIG5vdC4gVGhlbiBTR1cgd2lsbCBkZWNpZGUgdG8gZm9yd2FyZCB0aGUg dXNlciB0cmFmZmljIG9yIHJlamVjdCBpdC4gT3RoZXJ3aXNlLCBhbGwgdGhlIHVzZXIgdHJhZmZp YyB3aWxsIGJlIHRyYW5zcGFyZW50IG9uIFNHVywgZXZlbiB0aGUgdHJhZmZpYyBmcm9tIEhhY2tl ci4gVGhpcyBjYW5ub3QgYmUgYWNjZXB0ZWQuIAogICAgICA8bzpwPjwvbzpwPjwvZm9udD48L3Nw YW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Ik1BUkdJTjogMTUuNnB0 IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iQ09MT1I6ICMzNjVmOTEiPjxmb250 IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJpIj5Zb3UgbWF5IGFyZ3VlIEFDIGNh biBhY2hpZXZlIHVzZXIgbWFuYWdlbWVudCBhbmQgYWRkcmVzcyBhc3NpZ25tZW50LiBJZiBBQyBh bmQgU0dXIGFyZSBjb252ZXJnZWQgYXMgb25lIGRldmljZSwgSSBhZ3JlZS4gSG93ZXZlciwgaXQg aXMgb3V0IHRoZSBzY29wZSBvZiB0aGUgZHJhZnQuIEluIHRoZSBzY2VuYXJpbywgd2l0aCBBQyBh bmQgU0dXIGJvdGggZGVwbG95ZWQsIGlmIEFDIHN1cHBvcnQgdGhlIHVzZXIgbWFuYWdlbWVudCBh bmQgYWRkcmVzcyBhc3NpZ25tZW50IGZ1bmN0aW9ucywgdGhlIG5ldHdvcmsgYXJjaGl0ZWN0dXJl IHdpbGwgYmUgY2hhbmdlZC4gQUMgbXVzdCBzdXBwb3J0IHJvdXRlciBmdW5jdGlvbiwgYmVjYXVz ZSBsYXllciAyIG5ldHdvcmsgd2lsbCBiZSB0ZXJtaW5hdGVkIG9uIEFDLiBBbHNvLCBPU1BGIGV0 YyByb3V0aW5nIHByb3RvY29scyBhcmUgbmVlZGVkIG9uIEFDLiBUaGVyZSBhcmUgbWFueSBuZXR3 b3JrIGFuZCBkZXZpY2UgY2hhbGxlbmdlcy4KICAgICAgPG86cD48L286cD48L2ZvbnQ+PC9zcGFu PjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDE1LjZwdCAw Y20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiAjMzY1ZjkxIj48Zm9udCBz aXplPSIzIj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+Rm9yIHRoZSB0cmFkaXRpb25hbCBv cGVyYXRvcnMsIFdMQU4gbmV0d29yayBpcyBzdGFja2VkIGluIHRoZSBleGlzdGluZyBicm9hZGJh bmQgbmV0d29yaywgU0dXIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgYnJvYWRiYW5kIHVzZXIgbWFu YWdlbWVudCwgYWRkcmVzcyBhc3NpZ25tZW50LCBldGMuIENvbnNpZGVyaW5nIHRoZSB1cGdyYWRl IHdvcmsgbmVlZGVkIGlmIEFDIGlzIHRoZSBhdXRoZW50aWNhdG9yLCB0aGUgb3BlcmF0b3JzICgg SSBhbSBub3Qgc3VyZSBhbGwgdGhlIG9wZXJhdG9ycywgYXQgbGVhc3Qgc29tZSBvZiB0aGUgb3Bl cmF0b3JzKSBhcmUgc2Vla2luZyBhbm90aGVyIG9wdGlvbiB0byByZXNvbHZlIHRoZSB1bmlmb3Jt IGF1dGhlbnRpY2F0aW9uIGluIFdMQU4gbmV0d29yay4gSWYgdGhlIGF1dGhlbnRpY2F0b3IgY2Fu IG1vdmUgdG8gdGhlIFNHVywgdGhlIG5ldHdvcmsgYmVjb21lcyBzaW1wbGUsIGV4Y2VwdCBmb3Ig dGhlIGtleSBpc3N1ZS4gSWYgYXV0aGVudGljYXRvciBpcyBvbiB0aGUgU0dXLCB1c2VyIG1hbmFn ZW1lbnQsIHN1Y2ggYXMgY2hhcmdpbmcgYW5kIGFkZHJlc3MgYXNzaWdubWVudCB3aWxsIGJlIGVh c3kgdG8gYWNoaWV2ZSB3aXRob3V0IGNvbW11bmljYXRpb24gd2l0aCBBQy4KICAgICAgPG86cD48 L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJNQVJHSU46IDE1LjZwdCAwY20gMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9S OiAjMzY1ZjkxIj48Zm9udCBzaXplPSIzIj48L2ZvbnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+U28g d2UgbmVlZCB0byByZXNvbHZlIHRoaXMgaXNzdWUuCiAgICAgIDxvOnA+PC9vOnA+PC9mb250Pjwv c3Bhbj48L3A+IAogICA8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0iTUFSR0lOOiAxNS42 cHQgMGNtIDBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJDT0xPUjogIzM2NWY5MSI+PGZv bnQgc2l6ZT0iMyI+PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmkiPkkgY2Fubm90IHByb21pc2Ug d2hpY2ggc29sdXRpb24gdGhlIHNwZWNpYWwgb3BlcmF0b3Igd2lsbCBwaWNrLiBIb3dldmVyLCBp dCBpcyB0aGUgcmVhbCBzY2VuYXJpbyBvZiB0aGUgbmV0d29yayBkZXBsb3ltZW50LgogICAgICA8 bzpwPjwvbzpwPjwvZm9udD48L3NwYW4+PC9wPiAKICAgPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Ik1BUkdJTjogMTUuNnB0IDBjbSAwcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Q09MT1I6ICMzNjVmOTEiPjxmb250IHNpemU9IjMiPjwvZm9udD48Zm9udCBmYWNlPSJDYWxpYnJp Ij5UaGUgb3BlcmF0b3JzIGNhbiBjb25zaWRlciB0aGUgbmV0d29yayBzdGF0dXMgb2YgdGhlaXIg b3duIGFuZCBhbGwgdGhlIHVwZ3JhZGUgaXNzdWVzIGluIG9yZGVyIHRvIGNob2ljZSB0aGUgcHJv cGVyIHNvbHV0aW9uLiAKICAgICAgPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4gCiAgIDxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJNQVJHSU46IDE1LjZwdCAwY20gMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9IkNPTE9SOiAjMzY1ZjkxIj48Zm9udCBzaXplPSIzIj48L2Zv bnQ+PGZvbnQgZmFjZT0iQ2FsaWJyaSI+SSBob3BlIEkgY2xhcmlmeSBpdCBjbGVhcmx5LiAKICAg ICAgPG86cD48L286cD48L2ZvbnQ+PC9zcGFuPjwvcD4KICA8L2Rpdj4gCiAgPGRpdj4KICAgJm5i c3A7CiAgPC9kaXY+IAogIDxkaXYgaWQ9InNwblNpZ24yMDEzNzE2MjEyNSI+CiAgICZuYnNwOwog IDwvZGl2PiAKICA8ZGl2IHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVw eDsgQk9SREVSLUxFRlQ6ICNkZGRkZGQgMXB4IHNvbGlkIj48L2Rpdj4KIDwvYm9keT4KPC9odG1s Pg== ------=_Part_580_1646969024.1373981462836-- From mauricio.sanchez@hp.com Thu Jul 18 20:45:53 2013 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 1F4CE21E81A2 for ; Thu, 18 Jul 2013 20:45:53 -0700 (PDT) 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 MnzvyVQTtbKU for ; Thu, 18 Jul 2013 20:45:48 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id DE42C11E8176 for ; Thu, 18 Jul 2013 20:45:47 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 1FF9F2C2F8 for ; Fri, 19 Jul 2013 03:45:47 +0000 (UTC) Received: from G6W3998.americas.hpqcorp.net (16.205.80.213) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 19 Jul 2013 03:44:12 +0000 Received: from G6W2486.americas.hpqcorp.net ([169.254.9.155]) by G6W3998.americas.hpqcorp.net ([16.205.80.213]) with mapi id 14.03.0123.003; Fri, 19 Jul 2013 03:44:12 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: IETF 87: Preliminary Agenda Thread-Index: AQHOhDI7BgJjLm/b0EWVf2LbpCa9+A== Date: Fri, 19 Jul 2013 03:44:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [15.193.49.25] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3457025049_33478765" MIME-Version: 1.0 Subject: [radext] IETF 87: Preliminary Agenda 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, 19 Jul 2013 03:45:53 -0000 --B_3457025049_33478765 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable At IETF 87 RADEXT has 90 minutes allocated (Tuesday 7/30 5:00PM-6:30PM). Below is the draft agenda consisting of items the chairs would believe would be useful to discuss. Please respond with any suggested changes or comments. -Jouni & Mauricio=20 ----------------------- RADEXT WG IETF 87 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Tuesday, July 30, 2013 5:00 - 6:30PM Room Schoeneberg 1/2 5:00 - 6:10 PM, Preliminaries (10 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (40 minutes) ------------------------------------------- 6:10 - 6:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/id/draft-ietf-radext-dtls 6:20 - 6:30PM The Network Access Identifier, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-nai 6:30 - 6:40PM RADIUS dynamic discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 6:40 - 6:50PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-ieee802ext Chartered individual draft discussion (15 minutes) -------------------------------------------------- 6:50 - 7:00PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes) http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation Outside charter individual draft discussion ------------------------------------------- 7:00 =AD 7:10PM Data types in RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-datatypes 7:10 - 7:20PM RADIUS extensions for Key Management in WLAN Network, Li Xue (10 minutes) http://tools.ietf.org/html/draft-xue-radext-key-management Wrap-up (10 minutes) -------------------- 7:20 - 7:30 PM Next Steps: WG Chairs & ADs (10 minutes) WG Goals/Milestones status, next steps=20 --B_3457025049_33478765 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgORGno9ol0cZdOqtQCnwG5fTo LDsy0RNX4yfeoiGU6ngwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNzE5MDM0NDA5WjANBgkqhkiG9w0BAQEFAASCAQBxu6o+xHowM7PD6VYbPLCDfFgF LTNrb1jK/j+VkP6lBrMfG43r1uamsz9cTA8gg813ZPFzqdG8ZHT+DpWv/mgAgGdPnPuNzxM4 dG+Ax5VcJ3GfHknqFkZRZ2AwJUz4UgsjN8gDIISb6p2psVIBeYS5EiJVv4johUQKDv8lTueP 9hqc5ltMmSU7loxc8zf33OblA6c4Qd90KGyC9Kx4LwpNL8Y+uUaizO5OfGX+QbPO46wfdXy9 OXW4Ecp9ywzN8aMFs81AlJhneykKddDYCMChNv5vN/Hz1wqhNmnVK1673rEUuPpxxpq6Oy/B Z7staxr2OkguFJp3gOvHzyYK9sZb --B_3457025049_33478765-- From stefan.winter@restena.lu Wed Jul 24 03:07:04 2013 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 3FB6511E83F4 for ; Wed, 24 Jul 2013 03:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 mFZQb3X5OW8F for ; Wed, 24 Jul 2013 03:07:03 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEAC11E83AF for ; Wed, 24 Jul 2013 03:06:43 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2848410590 for ; Wed, 24 Jul 2013 12:06:42 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 19A861058C for ; Wed, 24 Jul 2013 12:06:42 +0200 (CEST) Message-ID: <51EFA72E.9050507@restena.lu> Date: Wed, 24 Jul 2013 12:06:38 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> In-Reply-To: <51E54C2E.80002@deployingradius.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fwKQRj0qIhmm3goi57LCE70DGpgtWlvbT" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 24 Jul 2013 10:07:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fwKQRj0qIhmm3goi57LCE70DGpgtWlvbT Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > It may also be good to add a "Global-Packet-ID". The idea would be > that it's a 64-bit or 128-bit opaque token, created by the client. (Or= > a proxy close to the client). Other proxies would then never touch it.= >=20 > It could be cached by proxies for a period of time. If a proxy sees > the same Global-Packet-ID in two different packets, it knows there's a > loop or retransmission via an alternate path. That's another approach, which would also work. There's a very small probability that two unrelated packets happen to get the same packet-id; that kind of indeterminism makes me a bit nervous. Anyway: I'm glad that we're discussing loop detection /at all/. I didn't get that far in my earlier attempts on the topic :-) Re the forward/reverse IP: > What about the discovered server? It would be subject to attacks by > third parties. >=20 > i.e. realm A lists proxy B as it's server via DDNS. It then publishe= s > an article saying "free net access by using user@realmA". Everyone > wanting free net access contacts proxy B. Repeat for 10,000 domains, > and Proxy B gets a DoS. >=20 > This should ideally be discovered *before* a using high-cost > connection like TLS. That's why a reverse lookup is useful. >=20 > Now... this is RADIUS, and there aren't that many RADIUS proxies. Bu= t > if the DDNS draft makes it easier, there will be more RADIUS proxies, > and more possibility for such an attack. That doesn't really help: the forward and reverse IP checks work on the A/AAAA pair that is the "leaf" of the discovery process. Third parties adding a NAPTR where they should not will not be detected. If the end server is actually offering a dynamic discovery endpoint, then it will be properly configured for its legimiate customers. Having other people send non-legitimate customers to the same destination as well will not be detectable with an IP address check. >> This could be mentioned in Security Considerations, if you find it >> useful/important to have? >=20 > Yes. The fact that DoS becomes possible by illegitimate clients is mentioned in RFC6614. I take your point that a mere usage of RFC6614 with hand-configured clients makes the problem less important, because firewalls could prevent the session establishment. For a next rev of dynamicdiscovery, I've added the following paragraph for Security Considerations in my working copy: With Dynamic Discovery being enabled for a RADIUS Server, and depending on the deployment scenario, the server may need to open up its target IP address and port for the entire internet, because arbitrary clients may discover it as a target for their authentication requests. If such clients are not part of the roaming consortium, the RADIUS/TLS connection setup phase will fail (which is intended) but the computational cost for the connection attempt is significant. With the port for a TLS-based service open, the RADIUS server shares all the typical attack vectors for services based on TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with Dynamic Discovery should consider these attack vectors and take appropriate counter-measures (e.g. blacklisting known-bad IPs on a firewall, rate-limiting new connection attempts, etc.). Is that okay for you? 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 --fwKQRj0qIhmm3goi57LCE70DGpgtWlvbT 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHvpzIACgkQ+jm90f8eFWaMmwCeIGHxD2sBrdZ5z/Q9Xo0tJNQv 73MAn2ujkFKhx0EmNuTPcFbGfUusB+OL =yYuH -----END PGP SIGNATURE----- --fwKQRj0qIhmm3goi57LCE70DGpgtWlvbT-- From aland@deployingradius.com Wed Jul 24 06:30:49 2013 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 8A53811E80FD for ; Wed, 24 Jul 2013 06:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXfa6efWFpnT for ; Wed, 24 Jul 2013 06:30:16 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB0F21F9FDE for ; Wed, 24 Jul 2013 06:30:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6450122400C8; Wed, 24 Jul 2013 15:29:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh193Pn22geO; Wed, 24 Jul 2013 15:29:17 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id BF958224009D; Wed, 24 Jul 2013 15:29:16 +0200 (CEST) Message-ID: <51EFD6AD.9020006@deployingradius.com> Date: Wed, 24 Jul 2013 09:29:17 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> <51EFA72E.9050507@restena.lu> In-Reply-To: <51EFA72E.9050507@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 24 Jul 2013 13:30:49 -0000 Stefan Winter wrote: > That's another approach, which would also work. There's a very small > probability that two unrelated packets happen to get the same packet-id; > that kind of indeterminism makes me a bit nervous. There's no good solution for global uniqueness. It can be mitigated via a 128-bit ID. That means the probability of two IDs being the same is one in 2^64, which is rare enough to not really worry about. > That doesn't really help: the forward and reverse IP checks work on the > A/AAAA pair that is the "leaf" of the discovery process. Third parties > adding a NAPTR where they should not will not be detected. If the end > server is actually offering a dynamic discovery endpoint, then it will > be properly configured for its legimiate customers. Having other people > send non-legitimate customers to the same destination as well will not > be detectable with an IP address check. I'm not sure. Maybe I'm missing something. If a proxy is about to send radsec traffic for realm A to IP address B, can't it do a DNS lookup on IP address B to see if realm A is listed? > For a next rev of dynamicdiscovery, I've added the following paragraph > for Security Considerations in my working copy: > > With Dynamic Discovery being enabled for a RADIUS Server, and > depending on the deployment scenario, the server may need to open up > its target IP address and port for the entire internet, because > arbitrary clients may discover it as a target for their > authentication requests. If such clients are not part of the roaming > consortium, the RADIUS/TLS connection setup phase will fail (which is > intended) but the computational cost for the connection attempt is > significant. With the port for a TLS-based service open, the RADIUS > server shares all the typical attack vectors for services based on > TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with > Dynamic Discovery should consider these attack vectors and take > appropriate counter-measures (e.g. blacklisting known-bad IPs on a > firewall, rate-limiting new connection attempts, etc.). > > Is that okay for you? Yes. Alan DeKok. From stefan.winter@restena.lu Wed Jul 24 07:50:04 2013 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 4426411E8108 for ; Wed, 24 Jul 2013 07:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 eD8kE7N5IxMA for ; Wed, 24 Jul 2013 07:50:02 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7F17011E8221 for ; Wed, 24 Jul 2013 07:48:37 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2363010590 for ; Wed, 24 Jul 2013 16:48:21 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1543E1058C for ; Wed, 24 Jul 2013 16:48:21 +0200 (CEST) Message-ID: <51EFE930.9040903@restena.lu> Date: Wed, 24 Jul 2013 16:48:16 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> <51EFA72E.9050507@restena.lu> <51EFD6AD.9020006@deployingradius.com> In-Reply-To: <51EFD6AD.9020006@deployingradius.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hoJPtjfrgOPEH5O4jppqEJd9AVSPHFaNu" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 24 Jul 2013 14:50:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hoJPtjfrgOPEH5O4jppqEJd9AVSPHFaNu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I'm not sure. Maybe I'm missing something. If a proxy is about to > send radsec traffic for realm A to IP address B, can't it do a DNS > lookup on IP address B to see if realm A is listed? Well, if realmA (or anyone for that matter) wants to DoS proxy B, then it can also see which realms B actually serves (say, "therealrealm"), and publish an article stating "free net access for username@therealrealm= ". B would have an IP reverse with the indication that it *is* serving that realm - and the TLS connection would come up. The reverse IP check doesn't help with that. Besides that, I also don't like that an IP's reverse DNS lookup which is intended to provide a *host*name would now be re-used in the different semantics of providing a *realm*name. >> For a next rev of dynamicdiscovery, I've added the following paragraph= >> for Security Considerations in my working copy: >> >> With Dynamic Discovery being enabled for a RADIUS Server, and >> depending on the deployment scenario, the server may need to open u= p >> its target IP address and port for the entire internet, because >> arbitrary clients may discover it as a target for their >> authentication requests. If such clients are not part of the roami= ng >> consortium, the RADIUS/TLS connection setup phase will fail (which = is >> intended) but the computational cost for the connection attempt is >> significant. With the port for a TLS-based service open, the RADIU= S >> server shares all the typical attack vectors for services based on >> TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with >> Dynamic Discovery should consider these attack vectors and take >> appropriate counter-measures (e.g. blacklisting known-bad IPs on a >> firewall, rate-limiting new connection attempts, etc.). >> >> Is that okay for you? >=20 > Yes. Okay, will be in -08. Greetings, Stefan Winter >=20 > Alan DeKok. > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --hoJPtjfrgOPEH5O4jppqEJd9AVSPHFaNu 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHv6TQACgkQ+jm90f8eFWYw5gCcCdqVhcBKes71eAzNYOM9KGZB JZoAnj6xMx4idpjIwC7tjSb7Jbiq4y9q =HvR9 -----END PGP SIGNATURE----- --hoJPtjfrgOPEH5O4jppqEJd9AVSPHFaNu-- From stefan.winter@restena.lu Wed Jul 24 07:57:57 2013 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 5F53D21F8468 for ; Wed, 24 Jul 2013 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a-g+d+2-MqS for ; Wed, 24 Jul 2013 07:57:01 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3333921F841B for ; Wed, 24 Jul 2013 07:56:59 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3964C10590 for ; Wed, 24 Jul 2013 16:56:58 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2981C1058C for ; Wed, 24 Jul 2013 16:56:57 +0200 (CEST) Message-ID: <51EFEB39.4060102@restena.lu> Date: Wed, 24 Jul 2013 16:56:57 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> In-Reply-To: <51E54C2E.80002@deployingradius.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uCEfWf9VDnjWO0mSBaqeTc8Ju18ohvKAN" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 24 Jul 2013 14:57:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uCEfWf9VDnjWO0mSBaqeTc8Ju18ohvKAN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > What about the discovered server? It would be subject to attacks by > third parties. >=20 > i.e. realm A lists proxy B as it's server via DDNS. It then publishe= s > an article saying "free net access by using user@realmA". Everyone > wanting free net access contacts proxy B. Repeat for 10,000 domains, > and Proxy B gets a DoS. It also just occured to me that your attack is too complex to be useful for an attacker; it would require actual humans lured into trying to log into realmA in masses, so that their login attempts overload proxy B. It would require hundreds or thousands of humans trying to log in per second so that proxy B feels the load. If realmA really wants to DoS proxy B, they would take note of proxy B's IP address and port, and hire a cheap botnet. The botnet would simply not care whether there is a reverse IP to check. In short... once your server is up in the open, it can be contacted by anyone, like it or not. An implementation needs to cope with that. 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 --uCEfWf9VDnjWO0mSBaqeTc8Ju18ohvKAN 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHv6zkACgkQ+jm90f8eFWb21QCeNxGsm1k3vAePKYc6HgYRWmLV 7GMAnihJ3+yWf8HyT2JPF5wcbeAw3Qxi =Dolk -----END PGP SIGNATURE----- --uCEfWf9VDnjWO0mSBaqeTc8Ju18ohvKAN-- From hartmans@painless-security.com Wed Jul 24 09:29:38 2013 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 64C9E11E80EA for ; Wed, 24 Jul 2013 09:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pViktjP8QVz3 for ; Wed, 24 Jul 2013 09:29:32 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC1C21F8445 for ; Wed, 24 Jul 2013 09:29:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 458EE201E7; Wed, 24 Jul 2013 12:29:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT3kN0Y7Zjl2; Wed, 24 Jul 2013 12:29:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [109.144.232.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 24 Jul 2013 12:29:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A463787F70; Wed, 24 Jul 2013 12:29:28 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> <51EFA72E.9050507@restena.lu> <51EFD6AD.9020006@deployingradius.com> <51EFE930.9040903@restena.lu> Date: Wed, 24 Jul 2013 12:29:28 -0400 In-Reply-To: <51EFE930.9040903@restena.lu> (Stefan Winter's message of "Wed, 24 Jul 2013 16:48:16 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 24 Jul 2013 16:29:38 -0000 Also, how is this valuable at all without cryptographic binding of the cert to the IP address? We cannot be planning to have security of RADIUS over TLS devolve to an IP ACL check. I'm hoping I'm missing something here. From aland@deployingradius.com Wed Jul 24 17:59:03 2013 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 EA92321F99CE for ; Wed, 24 Jul 2013 17:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 OVGJ63jxlpOU for ; Wed, 24 Jul 2013 17:58:58 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0932C21F99D2 for ; Wed, 24 Jul 2013 17:58:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D562822400C8; Thu, 25 Jul 2013 02:57:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1GgSLThqbE0; Thu, 25 Jul 2013 02:57:56 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id 53621224009D; Thu, 25 Jul 2013 02:57:56 +0200 (CEST) Message-ID: <51F07814.5030200@deployingradius.com> Date: Wed, 24 Jul 2013 20:57:56 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman , "radext@ietf.org" References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> <51EFA72E.9050507@restena.lu> <51EFD6AD.9020006@deployingradius.com> <51EFE930.9040903@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 25 Jul 2013 00:59:04 -0000 Sam Hartman wrote: > We cannot be planning to have security of RADIUS over TLS devolve to an > IP ACL check. It won't. Maybe I'm missing something. I just want to ensure that we have a *simple* way to check if an IP address can accept requests for a realm. If the answer is "no", then TLS shouldn't start. If the answer is "yes", then TLS starts, with all of the security mandated by TLS. i.e. It's a low-cost additional check before TLS. I never proposed it *replace* TLS. I'm worried about administrators mis-configuring realms. "Hey, company X says that server Y is a RADIUS proxy. We'll list it for our realm Z!" And then all of the traffic for these idiots goes to server Y. No one figures out this is wrong until after the TLS handshake. Which can give a DoS attack on server Y. A *simple* double-check can help prevent this. The proxies get told to go to server Y. So they ask it. "Do you handle realm Z"? When the answer is "no", they know to go bug realm Z to fix their business relationships. They DON'T bug server Y with useless requests. Alan DeKok. From aland@deployingradius.com Wed Jul 24 18:04:22 2013 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 0719E21F9A2E for ; Wed, 24 Jul 2013 18:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+9g8bDjQLdL for ; Wed, 24 Jul 2013 18:04:16 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE5221F9A2A for ; Wed, 24 Jul 2013 18:04:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 765E522400C8; Thu, 25 Jul 2013 03:04:15 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK4mSeGbpkjY; Thu, 25 Jul 2013 03:04:15 +0200 (CEST) Received: from Thor-2.local (unknown [67.71.147.228]) by power.freeradius.org (Postfix) with ESMTPSA id E21E92240072; Thu, 25 Jul 2013 03:04:14 +0200 (CEST) Message-ID: <51F0798F.4@deployingradius.com> Date: Wed, 24 Jul 2013 21:04:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> <51EFEB39.4060102@restena.lu> In-Reply-To: <51EFEB39.4060102@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 25 Jul 2013 01:04:22 -0000 Stefan Winter wrote: > It also just occured to me that your attack is too complex to be useful > for an attacker; it would require actual humans lured into trying to log > into realmA in masses, so that their login attempts overload proxy B. It > would require hundreds or thousands of humans trying to log in per > second so that proxy B feels the load. I suppose there are no companies with 10M customers, and imperfect administrators? > If realmA really wants to DoS proxy B, they would take note of proxy B's > IP address and port, and hire a cheap botnet. The botnet would simply > not care whether there is a reverse IP to check. I'm not trying to make perfect security. I'm trying to make it cheaper to catch mistakes. > In short... once your server is up in the open, it can be contacted by > anyone, like it or not. An implementation needs to cope with that. Yes. There's no question there. I would like to discover *misconfiguration* quickly. A reverse IP check is cheap. It's more expensive to have 100K customers hit your proxy because an admin mis-configured something. Alan DeKok. From mauricio.sanchez@hp.com Wed Jul 24 20:27:05 2013 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 6DE7A21F9A1C for ; Wed, 24 Jul 2013 20:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 JIrYSPDNPcvx for ; Wed, 24 Jul 2013 20:27:00 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3361B21F89D8 for ; Wed, 24 Jul 2013 20:27:00 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id A7F0224063 for ; Thu, 25 Jul 2013 03:26:59 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 25 Jul 2013 03:25:22 +0000 Received: from G6W2486.americas.hpqcorp.net ([169.254.9.155]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.03.0123.003; Thu, 25 Jul 2013 03:25:23 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: IETF 87 - 1st call for presentation material Thread-Index: AQHOiOaYkkwFr89Xj02E1Y5qNknUVQ== Date: Thu, 25 Jul 2013 03:25:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [15.193.49.27] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3457542333_20260823" MIME-Version: 1.0 Subject: [radext] IETF 87 - 1st call for presentation material 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, 25 Jul 2013 03:27:05 -0000 --B_3457542333_20260823 Content-type: multipart/alternative; boundary="B_3457542333_20247920" --B_3457542333_20247920 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The RADEXT WG is schedule to meet Tuesday, July 30 from 1700-1830. If you are scheduled to present, please email slides to myself and Jouni ASAP.=20 Thanks, Jouni & Mauricio=20 ------------------------------- RADEXT WG IETF 87 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Tuesday, July 30, 2013 5:00 - 6:30PM Room Schoeneberg 1/2 5:00 - 5:10 PM, Preliminaries (10 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (40 minutes) ------------------------------------------- 5:10 - 5:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/id/draft-ietf-radext-dtls 5:20 - 5:30PM The Network Access Identifier, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-nai 5:30 - 5:40PM RADIUS dynamic discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 5:40 - 5:50PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-ieee802ext Chartered individual draft discussion (15 minutes) -------------------------------------------------- 5:50 - 6:00PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes) http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation Outside charter individual draft discussion ------------------------------------------- 6:00 =AD 6:10PM Data types in RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-datatypes 6:10 - 6:20PM RADIUS extensions for Key Management in WLAN Network, Li Xue (10 minutes) http://tools.ietf.org/html/draft-xue-radext-key-management Wrap-up (10 minutes) -------------------- 6:20 - 6:30 PM Next Steps: WG Chairs & ADs (10 minutes) WG Goals/Milestones status, next steps --B_3457542333_20247920 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
The RADEXT WG is s= chedule to meet Tuesday, July 30 from 1700-1830.

<= /div>
If you are scheduled to present, please email slides to myself and= Jouni ASAP. 

Thanks,
Jouni & Ma= uricio 

-------------------------------
<= div>

RADEXT WG IETF 87 Agenda  
=

Chairs:
Jouni Korhonen <jouni.korhonen at n= sn.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

Jabber room: radext at jabber.ietf.org (Please join)
Tuesday, July 30, 2013
5:00 - 6:30PM

=
Room Schoeneberg 1/2 
5:00 - 5:10 PM, Preliminaries (10 = minutes)
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda ba= sh
Document Status

Working group draft di= scussion (40 minutes)
-------------------------------------------<= /div>
5:10 - 5:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10= minutes)
http://tools.ietf.org/id/draft-ietf-radext-dtls

5:20 - 5:30PM The Network Access Identifier, Alan DeKok (10= minutes)
http://tools.ietf.org/html/draft-ietf-radext-nai

5:30 - 5:40PM RADIUS dynamic discovery, Stefan Winter (10 = minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-disc= overy

5:40 - 5:50PM RADIUS Attributes for IEEE 802 = Networks, Bernard Aboba (10 minutes)
http://tools.ietf.org/html/dr= aft-ietf-radext-ieee802ext

Chartered individual dra= ft discussion (15 minutes)
---------------------------------------= -----------
5:50 - 6:00PM Support of fragmentation of RADIUS packe= ts, Diego Lopez (15 minutes)
http://tools.ietf.org/html/draft-pere= z-radext-radius-fragmentation

Outside charter indiv= idual draft discussion
-------------------------------------------=
6:00 – 6:10PM Data types in RADIUS, Alan DeKok (10 minutes)=
http://tools.ietf.org/html/draft-dekok-radext-datatypes

6:10 - 6:20PM RADIUS extensions for Key Management in WLAN N= etwork, Li Xue (10 minutes)
http://tools.ietf.org/html/draft-xue-r= adext-key-management

Wrap-up (10 minutes)
--------------------
6:20 -  6:30 PM Next Steps: WG Chairs &= amp; ADs (10 minutes) 
WG Goals/Milestones status, next steps=  

--B_3457542333_20247920-- --B_3457542333_20260823 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgmnnvW3h3ByjWKhdASO1Pr5wz l1BG3VpD6E3XdBDdZHMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNzI1MDMyNTMzWjANBgkqhkiG9w0BAQEFAASCAQBCahgT7KZalCm5+Ujl+ozNLKTz ap2a7+LolQltn4bsKfJPTxivMu55sbxHU781Lg1mQBghEQJD6gHI7c6M0egbEN7Y+Hs4PG7F v7KhrHoEpcsk+eHg8fzjW5/KotwdaCRuEVWRwWomvLzg00euQgIDHKfZM014O8q/kndngXfx r/lPk6t747ZNTPHvns8JmIdUSVGyviRyXSxU/VED9yhZL5vUXD/uhthGykklEsO95Z7H0PuE bwNvpuqtJtS3XvK+fwbVnl0iK4f6fkydkjT7VTOnYASayn192QhRXVpD0kVJpVDZLF7Slw3Y pADjTa3O9oahv1CK02SV3nR3b83S --B_3457542333_20260823-- From stefan.winter@restena.lu Thu Jul 25 00:23:48 2013 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 BC50621F9A44 for ; Thu, 25 Jul 2013 00:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfFOzCYUEZmP for ; Thu, 25 Jul 2013 00:23:41 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8876921F9A2D for ; Thu, 25 Jul 2013 00:23:37 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 67BB610584 for ; Thu, 25 Jul 2013 09:23:36 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 58A0910581 for ; Thu, 25 Jul 2013 09:23:36 +0200 (CEST) Message-ID: <51F0D274.8070701@restena.lu> Date: Thu, 25 Jul 2013 09:23:32 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: radext@ietf.org References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com> <51EFEB39.4060102@restena.lu> <51F0798F.4@deployingradius.com> In-Reply-To: <51F0798F.4@deployingradius.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AewkpMIiO4iMTCaxddlHNVuD4xGou8l63" X-Virus-Scanned: ClamAV Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery 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, 25 Jul 2013 07:23:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AewkpMIiO4iMTCaxddlHNVuD4xGou8l63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> It also just occured to me that your attack is too complex to be usefu= l >> for an attacker; it would require actual humans lured into trying to l= og >> into realmA in masses, so that their login attempts overload proxy B. = It >> would require hundreds or thousands of humans trying to log in per >> second so that proxy B feels the load. >=20 > I suppose there are no companies with 10M customers, and imperfect > administrators? Even 10M customers distribute their login timestamps over the day; any reasonable server should be able to cope with that. And to be honest, I'd expect an ISP of this size not do such stupid mistakes, or at least to find out about it *very* shortly after it happened because lots of customers will be unable to authenticate when it's happened. > I'm not trying to make perfect security. I'm trying to make it > cheaper to catch mistakes. >=20 >> In short... once your server is up in the open, it can be contacted by= >> anyone, like it or not. An implementation needs to cope with that. >=20 > Yes. There's no question there. >=20 > I would like to discover *misconfiguration* quickly. A reverse IP > check is cheap. It's more expensive to have 100K customers hit your > proxy because an admin mis-configured something. Reverse IP checks are also "something completely different", and the semantics of hostname identification is uneasy. Imagine a proxy with IP 1.2.3.4 who is AAA proxy for "cnn.com" "microsoft.com" "yahoo.com" "telekom.de" and has corresponding PTRs to fulfill your proposed reverse-matching. Now someone looks up the reverse of that IP address for totally non-AAA reasons and finds that the IP address claims to be all four domains. Huh? Unless we invent a new PTR-like construct just for the AAA misconfiguration catching purpose, I'm against using such a mechanism. And frankly, inventing an own DNS RR just for that seems like enormous overkill to me. I take your point on hammering the server with misconfigured discovery entries though. I see it as a deficiency in the current spec, particularly section 2.1.1.2: Definition of Conditions for Retry/Failure That section basically states: if client and server found out they don't like each other, ignore the entry and try the next. Which is fine in that instant, but doesn't speak about the persistence of ignoring the target. I've added a new last sentence to my working copy to ensure that there is some backoff time: " If the TLS session setup to a discovered target does not succeed, that target (as identified by IP address and port number) SHOULD be ignored from the result set of any subsequent executions of the discovery algorithm at least until the target's Effective TTL has expired or until the entity which executes the algorithm changes its TLS context to either send a new client certificate or expect a different server certificate." This provides an extra level of rate-limiting; well-behaved clients will stop hammering the target for a while, independently of the NAI realm that led to that server. I.e. one hotspot generates one TLS session request, and will then be quiet for a significant amount of time. I believe this takes the heat out of such pathological misconfigurations.= I know, this conflates the Effective TTL timer with something that's unrelated to DNS: the retry should happen when the server-side changed their TLS cert, because then it might work. But that condition can't be signalled, so the timeout that DNS provides us with is the best we have. The alternative would be to make that particular backoff time a configuration variable. 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 --AewkpMIiO4iMTCaxddlHNVuD4xGou8l63 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.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHw0ngACgkQ+jm90f8eFWbWugCdGurTFMjv+Ab4yOqClC0ennM6 w/sAn29PMiVz8OEx/YNTMmbPqTSRNK/m =fMuq -----END PGP SIGNATURE----- --AewkpMIiO4iMTCaxddlHNVuD4xGou8l63-- From ietf-secretariat-reply@ietf.org Thu Jul 25 07:54:18 2013 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 27C0121F9B26 for ; Thu, 25 Jul 2013 07:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-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 i+6D1iikE91W for ; Thu, 25 Jul 2013 07:54:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9457F21F9B2F for ; Thu, 25 Jul 2013 07:54:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: radext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130725145417.18332.9451.idtracker@ietfa.amsl.com> Date: Thu, 25 Jul 2013 07:54:17 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 26 Jul 2013 08:01:59 -0700 Subject: [radext] Milestones changed for radext WG 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, 25 Jul 2013 14:54:18 -0000 Changed milestone "Updates to RFC 2618-2621 RADIUS MIBs submitted for publication", set due date to December 2004 from December 2004. Changed milestone "SIP RADIUS authentication draft submitted as a Proposed Standard RFC", set due date to December 2004 from December 2004. Changed milestone "RFC 2486bis submitted as a Proposed Standard RFC", set due date to February 2005 from February 2005. Changed milestone "RFC 3576 MIBs submitted as an Informational RFC", set due date to December 2005 from December 2005. Changed milestone "RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)", set due date to October 2006 from October 2006. Changed milestone "RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)", set due date to December 2006 from December 2006. Changed milestone "Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC", set due date to January 2009 from January 2009. Changed milestone "Status-Server I-D submitted as a Proposed Standard RFC", set due date to March 2009 from March 2009. Changed milestone "RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC", set due date to March 2011 from March 2011. Changed milestone "IPv6 Access I-D submitted as a Proposed Standard RFC", set due date to December 2012 from December 2012, resolved as "Done". Changed milestone "RFC 4282bis submitted as a Proposed Standard RFC", set due date to December 2012 from December 2012. Changed milestone "Extended Attributes I-D submitted as a Proposed Standard RFC", set due date to December 2012 from December 2012, resolved as "Done". Changed milestone "Dynamic Discovery I-D submitted as a Proposed Standard RFC", set due date to December 2012 from December 2012. Changed milestone "IEEE 802 Attributes I-D submitted as a Proposed Standard RFC", set due date to December 2012 from December 2012. Changed milestone "RADIUS over DTLS I-D submitted as an Experimental RFC", set due date to January 2013 from January 2013. Changed milestone "RADIUS packet fragmentation submitted as an Experimental RFC", set due date to February 2013 from February 2013. URL: http://datatracker.ietf.org/wg/radext/charter/ From jouni.nospam@gmail.com Mon Jul 29 00:13:55 2013 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 7B7BA21F9AE6 for ; Mon, 29 Jul 2013 00:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lgha+zEVdNq1 for ; Mon, 29 Jul 2013 00:13:54 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A1FAA21F9AE3 for ; Mon, 29 Jul 2013 00:13:54 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so5503239pad.4 for ; Mon, 29 Jul 2013 00:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cRI/+eHGr2tkwvvD+xTig60r7IXNmxTTRdAGLOCrs8U=; b=XE0v9Brp3HPQBIKT+kfXiDvLZZamP1HIXjuaNxXE5eP2UohvwRfs5YGebjG/i4wel1 1/KjHLdU+aaqcgMrIoAJnWGV1umY5pt1sL8a0cWjt3k4lTTVVJ5Nl83jQGDxXkYQw+8I 2n+w86SLagRpKgKPms0VH9ny6oilBGRgALWPoG0wReHf88E1aQVXYkV2juIJVRWCFQ+K DuVFaK5k+Ua5kQizGxgmFD866dNwSRbPtjhGyuSlQOJIZw6qFR3qMCpx//bhQK5BSYwY uWLG2MhzeM64XNm3dJDSZAITQdk6mcAq3hf91NBI6Qn+OX4xE3VJu6+1pOpS3gUgjRGr 0+Ig== X-Received: by 10.66.253.4 with SMTP id zw4mr52677308pac.119.1375082034341; Mon, 29 Jul 2013 00:13:54 -0700 (PDT) Received: from dhcp-54af.meeting.ietf.org (dhcp-54af.meeting.ietf.org. [130.129.84.175]) by mx.google.com with ESMTPSA id sz6sm19092957pab.5.2013.07.29.00.13.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 00:13:53 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 29 Jul 2013 10:13:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "radext@ietf.org" X-Mailer: Apple Mail (2.1508) Cc: Mauricio Sanchez Subject: Re: [radext] IETF 87 - 1st call for presentation material 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, 29 Jul 2013 07:13:55 -0000 Folks, Just a reminder for submitting the slides ASAP. We are still missing = few. - JOuni On Jul 25, 2013, at 6:25 AM, "Sanchez, Mauricio" = wrote: > The RADEXT WG is schedule to meet Tuesday, July 30 from 1700-1830. >=20 > If you are scheduled to present, please email slides to myself and = Jouni ASAP.=20 >=20 > Thanks, > Jouni & Mauricio=20 >=20 > ------------------------------- >=20 >=20 > RADEXT WG IETF 87 Agenda =20 >=20 > Chairs: > Jouni Korhonen > Mauricio Sanchez >=20 > Jabber room: radext at jabber.ietf.org (Please join) > Tuesday, July 30, 2013 > 5:00 - 6:30PM >=20 > Room Schoeneberg 1/2=20 > 5:00 - 5:10 PM, Preliminaries (10 minutes) > Audio/Video & Remote Presentation Debugging > Note Well > Note Takers > Jabber scribe > Agenda bash > Document Status >=20 > Working group draft discussion (40 minutes) > ------------------------------------------- > 5:10 - 5:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 = minutes) > http://tools.ietf.org/id/draft-ietf-radext-dtls >=20 > 5:20 - 5:30PM The Network Access Identifier, Alan DeKok (10 minutes) > http://tools.ietf.org/html/draft-ietf-radext-nai >=20 > 5:30 - 5:40PM RADIUS dynamic discovery, Stefan Winter (10 minutes) > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery >=20 > 5:40 - 5:50PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba = (10 minutes) > http://tools.ietf.org/html/draft-ietf-radext-ieee802ext >=20 > Chartered individual draft discussion (15 minutes) > -------------------------------------------------- > 5:50 - 6:00PM Support of fragmentation of RADIUS packets, Diego Lopez = (15 minutes) > http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation >=20 > Outside charter individual draft discussion > ------------------------------------------- > 6:00 =96 6:10PM Data types in RADIUS, Alan DeKok (10 minutes) > http://tools.ietf.org/html/draft-dekok-radext-datatypes >=20 > 6:10 - 6:20PM RADIUS extensions for Key Management in WLAN Network, Li = Xue (10 minutes) > http://tools.ietf.org/html/draft-xue-radext-key-management >=20 > Wrap-up (10 minutes) > -------------------- > 6:20 - 6:30 PM Next Steps: WG Chairs & ADs (10 minutes)=20 > WG Goals/Milestones status, next steps=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Mon Jul 29 00:46:49 2013 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 7FCC321F9C41 for ; Mon, 29 Jul 2013 00:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 YkUFkr20Izzh for ; Mon, 29 Jul 2013 00:46:48 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D4D0A21F99A9 for ; Mon, 29 Jul 2013 00:46:48 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so3952076pad.28 for ; Mon, 29 Jul 2013 00:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=F5LdTk/gGHXPpBfDgJokX/0k1h5OkNWfy4BDGMILbuc=; b=WdBhBntNi6JzqSra/SMQxgKZGx2lmq6eY19KZVe/vERqaEdtSwsGxS5p3VERIJ/LeZ u/VRxa0sRXa+kewziJB1sc5sxJuDH4kgwVsLsUelkf8JRCVYsKtX9DdfVqWdtcOKy3Ef oWKrK+rLI1MGYUkbVVP/hqjTHfvvCvQTFek6skRYTHig/vsvcanrznyPqiiHR3HccMmU 43mTQAb9r8MtrjkPlkJ3jHI6lbePZYkD6FKRK3XwE4vf9Vy2NmlSV9GoNwhugzc3B6PV gyVcUwNGVosmwh4OE6InIZwIVc+QSvMCJaHTaW0g72TFIuVWYMQazGJg8XmoAVgR3iDZ M6gw== X-Received: by 10.69.15.33 with SMTP id fl1mr66565252pbd.189.1375084008541; Mon, 29 Jul 2013 00:46:48 -0700 (PDT) Received: from ?IPv6:2001:df8::80:e97a:9420:feea:fa9d? ([2001:df8:0:80:e97a:9420:feea:fa9d]) by mx.google.com with ESMTPSA id yk10sm19214944pac.16.2013.07.29.00.46.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 00:46:47 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <32B6CFEE-5231-4470-962A-91E21534EF40@gmail.com> Date: Mon, 29 Jul 2013 10:46:43 +0300 To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [radext] Meetecho at RADEXT WG meeting 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, 29 Jul 2013 07:46:49 -0000 Folks, Those who participate remotely can make use of Meetecho this time. The link for IETF87 Meetecho page is here: http://ietf87.conf.meetecho.com Or use the shortcuts: http://www.meetecho.com/ietf87/radext http://www.meetecho.com/ietf87/recordings - Jouni From mauricio.sanchez@hp.com Tue Jul 30 02:26:30 2013 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 37CA621F9E0A for ; Tue, 30 Jul 2013 02:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.202 X-Spam-Level: X-Spam-Status: No, score=-109.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Pf-G5BWm7fHJ for ; Tue, 30 Jul 2013 02:26:16 -0700 (PDT) Received: from g6t0187.atlanta.hp.com (g6t0187.atlanta.hp.com [15.193.32.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8C38721F9F9C for ; Tue, 30 Jul 2013 02:24:39 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0187.atlanta.hp.com (Postfix) with ESMTPS id EFDE5280FB for ; Tue, 30 Jul 2013 09:24:37 +0000 (UTC) Received: from G6W3999.americas.hpqcorp.net (16.205.80.214) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jul 2013 09:23:51 +0000 Received: from G6W2486.americas.hpqcorp.net ([169.254.9.155]) by G6W3999.americas.hpqcorp.net ([16.205.80.214]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 09:23:51 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: RADEXT WG: IETF 87 agenda (draft 2) Thread-Index: AQHOjQaA2l6nOokZ1kKGYhCL6YpEJw== Date: Tue, 30 Jul 2013 09:23:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [15.193.49.18] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3458028228_268859" MIME-Version: 1.0 Subject: [radext] RADEXT WG: IETF 87 agenda (draft 2) 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, 30 Jul 2013 09:26:30 -0000 --B_3458028228_268859 Content-type: multipart/alternative; boundary="B_3458028228_274739" --B_3458028228_274739 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Radext will be meeting this afternoon. Below is the current agenda. -MS -------------------------------------------- RADEXT WG IETF 87 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Tuesday, July 30, 2013 5:00 - 6:30PM Room Schoeneberg 1/2 5:00 - 5:10 PM, Preliminaries (10 minutes) Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (40 minutes) ------------------------------------------- 5:10 - 5:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/id/draft-ietf-radext-dtls 5:20 - 5:30PM The Network Access Identifier, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-nai 5:30 - 5:40PM RADIUS dynamic discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 5:40 - 5:50PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-ieee802ext Chartered individual draft discussion (15 minutes) -------------------------------------------------- 5:50 - 6:05PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes) http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation Outside charter individual draft discussion ------------------------------------------- 6:05 =AD 6:15PM Data types in RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-datatypes 6:15 - 6:25PM RADIUS extensions for Key Management in WLAN Network, Li Xue (10 minutes) http://tools.ietf.org/html/draft-xue-radext-key-management Wrap-up (5 minutes) -------------------- 6:25 - 6:30 PM Next Steps: WG Chairs & ADs (5 minutes) WG Goals/Milestones status, next steps --B_3458028228_274739 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Radext will be meeting = this afternoon.  Below is the current agenda. 

-MS
--------------------------------------------
R= ADEXT WG IETF 87 Agenda  

Chairs:
Jo= uni Korhonen <jouni.korhonen at renesasmobile.com>
Mauricio = Sanchez <mauricio.sanchez at hp.com>

Jabber r= oom: radext at jabber.ietf.org (Please join)
Tuesday, July 30, 201= 3
5:00 - 6:30PM

Room Schoeneberg 1/2 = ;
5:00 - 5:10 PM, Preliminaries (10 minutes)
Audio/Video= & Remote Presentation Debugging
Note Well
Note Take= rs
Jabber scribe
Agenda bash
Document Status

Working group draft discussion (40 minutes)
-------------------------------------------
5:10 - 5:20PM DTLS a= s a Transport Layer for RADIUS, Alan DeKok (10 minutes)
http://too= ls.ietf.org/id/draft-ietf-radext-dtls

5:20 - 5:30PM= The Network Access Identifier, Alan DeKok (10 minutes)
http://too= ls.ietf.org/html/draft-ietf-radext-nai

5:30 - 5:40P= M RADIUS dynamic discovery, Stefan Winter (10 minutes)
http://tool= s.ietf.org/html/draft-ietf-radext-dynamic-discovery

5:40 - 5:50PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 mi= nutes)
http://tools.ietf.org/html/draft-ietf-radext-ieee802ext

Chartered individual draft discussion (15 minutes)
--------------------------------------------------
5:50 - 6= :05PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes)
http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation<= /div>

Outside charter individual draft discussion
-------------------------------------------
6:05 – 6:15PM= Data types in RADIUS, Alan DeKok (10 minutes)
http://tools.ietf.o= rg/html/draft-dekok-radext-datatypes

6:15 - 6:25PM = RADIUS extensions for Key Management in WLAN Network, Li Xue (10 minutes)
http://tools.ietf.org/html/draft-xue-radext-key-management

Wrap-up (5 minutes)
--------------------
6:25 -  6:30 PM Next Steps: WG Chairs & ADs (5 minutes) 
WG Goals/Milestones status, next steps 


--B_3458028228_274739-- --B_3458028228_268859 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgLFEXZ2CAf7YGDix+1oaXt3qu ad4aBx8HjiCbAPFyyfAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwNzMwMDkyMzQ4WjANBgkqhkiG9w0BAQEFAASCAQBZWvLp+BeC8TSAlrWQIzGvQPEj jQ8eQ3QS/0lhkFtPa5Yxse7w1EY288AQZ2SjAPdUDzSFuk5KPRqWsf9PLZJl0IefUva4zV9Q PKQki+nFojbMsuJAEa2oYYnWX0mPaozWP6EOS+/XPcqjgZp5bEjWP6qtd+iDX70hQWkmYfxF y18MfFculCInunpKVs+uVvkI1JCeS3DrbijfxQGrEaobVwVKrEai9af3Uxseq9XbKDja8R06 C54XVBugU9A21E1Ax+YcXKdM/KMZhu7qzGIB2ttFrRMEKY++22Eo+BkAJuAt/Xl/CsjLwS8d +4uHsrfEhLuuoroKRXW6KSppfF6l --B_3458028228_268859-- From bernard_aboba@hotmail.com Tue Jul 30 16:35:30 2013 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 854BA21F9306 for ; Tue, 30 Jul 2013 16:35:30 -0700 (PDT) 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.527, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 eBPc1Gnt1Ro4 for ; Tue, 30 Jul 2013 16:35:24 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id 908AC21F92E7 for ; Tue, 30 Jul 2013 16:35:24 -0700 (PDT) Received: from BLU404-EAS305 ([65.55.111.72]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 16:35:24 -0700 X-TMN: [6LiHZD48wmQWtjFzXM4PMgQNnR7lornN] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-F85330FE-5667-4D8A-9426-A552789D0D43" Content-Transfer-Encoding: 7bit References: <51F7E8AF.4050503@sbcglobal.net> From: Bernard Aboba Date: Wed, 31 Jul 2013 01:35:22 +0200 To: MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 30 Jul 2013 23:35:24.0897 (UTC) FILETIME=[771A6510:01CE8D7D] Subject: [radext] Fwd: radext-ieee802 discussion at ietf-87 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, 30 Jul 2013 23:35:30 -0000 --Apple-Mail-F85330FE-5667-4D8A-9426-A552789D0D43 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: > From: Mick Seaman > Date: July 30, 2013, 6:24:15 PM GMT+02:00 > To: Brian Weis , Joe Salowey , Bernard= Aboba > Subject: radext-ieee802 discussion at ietf-87 >=20 > Well I had hoped that this was being put to bed more or less "as is" since= I think it is probably a never ending subject. > [I make that comment in the light of the recent 'OmniRAN' exec study group= in 802, whose mission seems to be to > range between some new over-arching access architecture for both wired and= wireless at one extreme and complaining > that they cant find the necessary radius attributes or don't like the way t= hey are written down at the other. I'm prepared to > believe in existence of some gaps, so the effort may produce some further i= tems. It would be good to get the base-line down]. >=20 > If you are moving in the direction of being able to quote any/all EAPOL an= nouncement items in Radius then I would suggest > you not leave out the Organizationally Specific items. This (organizationa= l specific extensions in general) seems to be a usefulsafety valve/play pen f= or certain government related orgs who both want to have 'their stuff' in 1X= while at the same time not wanting to > be very specific about what this 'stuff' is. >=20 > Seem to be three ways of going forward as philisophy: >=20 > 1. Add items from EAPOL announcements to Radius one by one if and when the= y are understood in Radius terms, in particular when it is known they are no= t best derived from existing Radius attributes. >=20 > 2. Provide a way for carrying the EAPOL announcement items in general, but= state when the same info would be better carried > in another Radius attribute of established use (and then possibly translat= ed/copied into EAPOL announcements as a result of > some (authenticator local) policy. >=20 > 3. Finish radext-ieee802 now by most expedient means and add additional it= ems later as part of new work. >=20 > I would favour some mix of 1 and 3. I think something that falls between 1= and 2 but is not either of them is probably not a good idea. >=20 >=20 > Brian, we could follow up with discussion in York on this topic if it is n= ot put to bed before then. >=20 > Mick >=20 --Apple-Mail-F85330FE-5667-4D8A-9426-A552789D0D43 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+PGJyPjxi cj48YnI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48ZGl2PjxiPkZyb206PC9iPiBNaWNrIFNlYW1hbiAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1pY2tzZWFtYW5Ac2JjZ2xvYmFsLm5ldCI+bWlja3NlYW1hbkBzYmNnbG9iYWwubmV0PC9h PiZndDs8YnI+PGI+RGF0ZTo8L2I+IEp1bHkgMzAsIDIwMTMsIDY6MjQ6MTUgUE0gR01UKzAyOjAw PGJyPjxiPlRvOjwvYj4gQnJpYW4gV2VpcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJld0BjaXNjby5j b20iPmJld0BjaXNjby5jb208L2E+Jmd0OywgSm9lIFNhbG93ZXkgJmx0OzxhIGhyZWY9Im1haWx0 bzpqc2Fsb3dleUBjaXNjby5jb20iPmpzYWxvd2V5QGNpc2NvLmNvbTwvYT4mZ3Q7LCZuYnNwOyBC ZXJuYXJkIEFib2JhICZsdDs8YSBocmVmPSJtYWlsdG86YmVybmFyZF9hYm9iYUBob3RtYWlsLmNv bSI+YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbTwvYT4mZ3Q7PGJyPjxiPlN1YmplY3Q6PC9iPiA8 Yj5yYWRleHQtaWVlZTgwMiBkaXNjdXNzaW9uIGF0IGlldGYtODc8L2I+PGJyPjxicj48L2Rpdj48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj5XZWxsIEkgaGFk IGhvcGVkIHRoYXQgdGhpcyB3YXMgYmVpbmcgcHV0IHRvIGJlZCBtb3JlIG9yIGxlc3MgImFzIGlz IiBzaW5jZSBJIHRoaW5rIGl0IGlzIHByb2JhYmx5IGEgbmV2ZXIgZW5kaW5nIHN1YmplY3QuPC9z cGFuPjxicj48c3Bhbj5bSSBtYWtlIHRoYXQgY29tbWVudCBpbiB0aGUgbGlnaHQgb2YgdGhlIHJl Y2VudCAnT21uaVJBTicgZXhlYyBzdHVkeSBncm91cCBpbiA4MDIsIHdob3NlIG1pc3Npb24gc2Vl bXMgdG8gYmUgdG88L3NwYW4+PGJyPjxzcGFuPnJhbmdlIGJldHdlZW4gc29tZSBuZXcgb3Zlci1h cmNoaW5nIGFjY2VzcyBhcmNoaXRlY3R1cmUgZm9yIGJvdGggd2lyZWQgYW5kIHdpcmVsZXNzIGF0 IG9uZSBleHRyZW1lIGFuZCBjb21wbGFpbmluZzwvc3Bhbj48YnI+PHNwYW4+dGhhdCB0aGV5IGNh bnQgZmluZCB0aGUgbmVjZXNzYXJ5IHJhZGl1cyBhdHRyaWJ1dGVzIG9yIGRvbid0IGxpa2UgdGhl IHdheSB0aGV5IGFyZSB3cml0dGVuIGRvd24gYXQgdGhlIG90aGVyLiBJJ20gcHJlcGFyZWQgdG88 L3NwYW4+PGJyPjxzcGFuPmJlbGlldmUgaW4gZXhpc3RlbmNlIG9mIHNvbWUgZ2Fwcywgc28gdGhl IGVmZm9ydCBtYXkgcHJvZHVjZSBzb21lIGZ1cnRoZXIgaXRlbXMuIEl0IHdvdWxkIGJlIGdvb2Qg dG8gZ2V0IHRoZSBiYXNlLWxpbmUgZG93bl0uPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxz cGFuPklmIHlvdSBhcmUgbW92aW5nIGluIHRoZSBkaXJlY3Rpb24gb2YgYmVpbmcgYWJsZSB0byBx dW90ZSBhbnkvYWxsIEVBUE9MIGFubm91bmNlbWVudCBpdGVtcyBpbiBSYWRpdXMgdGhlbiBJIHdv dWxkIHN1Z2dlc3Q8L3NwYW4+PGJyPjxzcGFuPnlvdSBub3QgbGVhdmUgb3V0IHRoZSBPcmdhbml6 YXRpb25hbGx5IFNwZWNpZmljIGl0ZW1zLiBUaGlzIChvcmdhbml6YXRpb25hbCBzcGVjaWZpYyBl eHRlbnNpb25zIGluIGdlbmVyYWwpIHNlZW1zIHRvIGJlIGEgdXNlZnVsc2FmZXR5IHZhbHZlL3Bs YXkgcGVuIGZvciBjZXJ0YWluIGdvdmVybm1lbnQgcmVsYXRlZCBvcmdzIHdobyBib3RoIHdhbnQg dG8gaGF2ZSAndGhlaXIgc3R1ZmYnIGluIDFYIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgbm90IHdh bnRpbmcgdG88L3NwYW4+PGJyPjxzcGFuPmJlIHZlcnkgc3BlY2lmaWMgYWJvdXQgd2hhdCB0aGlz ICdzdHVmZicgaXMuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPlNlZW0gdG8gYmUg dGhyZWUgd2F5cyBvZiBnb2luZyBmb3J3YXJkIGFzIHBoaWxpc29waHk6PC9zcGFuPjxicj48c3Bh bj48L3NwYW4+PGJyPjxzcGFuPjEuIEFkZCBpdGVtcyBmcm9tIEVBUE9MIGFubm91bmNlbWVudHMg dG8gUmFkaXVzIG9uZSBieSBvbmUgaWYgYW5kIHdoZW4gdGhleSBhcmUgdW5kZXJzdG9vZCBpbiBS YWRpdXMgdGVybXMsIGluIHBhcnRpY3VsYXIgd2hlbiBpdCBpcyBrbm93biB0aGV5IGFyZSBub3Qg YmVzdCBkZXJpdmVkIGZyb20gZXhpc3RpbmcgUmFkaXVzIGF0dHJpYnV0ZXMuPC9zcGFuPjxicj48 c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjIuIFByb3ZpZGUgYSB3YXkgZm9yIGNhcnJ5aW5nIHRoZSBF QVBPTCBhbm5vdW5jZW1lbnQgaXRlbXMgaW4gZ2VuZXJhbCwgYnV0IHN0YXRlIHdoZW4gdGhlIHNh bWUgaW5mbyB3b3VsZCBiZSBiZXR0ZXIgY2FycmllZDwvc3Bhbj48YnI+PHNwYW4+aW4gYW5vdGhl ciBSYWRpdXMgYXR0cmlidXRlIG9mIGVzdGFibGlzaGVkIHVzZSAoYW5kIHRoZW4gcG9zc2libHkg dHJhbnNsYXRlZC9jb3BpZWQgaW50byBFQVBPTCBhbm5vdW5jZW1lbnRzIGFzIGEgcmVzdWx0IG9m PC9zcGFuPjxicj48c3Bhbj5zb21lIChhdXRoZW50aWNhdG9yIGxvY2FsKSBwb2xpY3kuPC9zcGFu Pjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPjMuIEZpbmlzaCByYWRleHQtaWVlZTgwMiBub3cg YnkgbW9zdCBleHBlZGllbnQgbWVhbnMgYW5kIGFkZCBhZGRpdGlvbmFsIGl0ZW1zIGxhdGVyIGFz IHBhcnQgb2YgbmV3IHdvcmsuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPkkgd291 bGQgZmF2b3VyIHNvbWUgbWl4IG9mIDEgYW5kIDMuIEkgdGhpbmsgc29tZXRoaW5nIHRoYXQgZmFs bHMgYmV0d2VlbiAxIGFuZCAyIGJ1dCBpcyBub3QgZWl0aGVyIG9mIHRoZW0gaXMgcHJvYmFibHkg bm90IGEgZ29vZCBpZGVhLjwvc3Bhbj48YnI+PHNwYW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+ PGJyPjxzcGFuPkJyaWFuLCB3ZSBjb3VsZCBmb2xsb3cgdXAgd2l0aCBkaXNjdXNzaW9uIGluIFlv cmsgb24gdGhpcyB0b3BpYyBpZiBpdCBpcyBub3QgcHV0IHRvIGJlZCBiZWZvcmUgdGhlbi48L3Nw YW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+TWljazwvc3Bhbj48YnI+PHNwYW4+PC9zcGFu Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-F85330FE-5667-4D8A-9426-A552789D0D43--